Phil Factor

30 April 2019

• SQL Clone
• Development and Testing with Clones

SQL Clone on your Laptop

For some reason, the idea of running SQL Clone on a laptop seems odd to me. Why would you use a tool like this on a partially-disconnected device when it is so dependent on specific local network services? Why use a laptop at all for database development when a relational database is, by its very nature, a multi-user system?

The answer is that many people are doing development work on a laptop at work and including the database. They use SQL Clone because means they can have a behemoth of a database on their laptop without any fear of running out of space, and one they can easily and quickly refresh when doing tests.

They then want to take their laptop home, sometimes working with it offline or on an unreliable connection. This article is about how you can do this without upsetting SQL Clone or SQL Server.

The Problem

SQL Clone uses disk-based virtualization. This requires, and assumes, a permanent network link to the source file that represents the VHD. If the image becomes inaccessible, both SQL Clone and SQL Server will react to this ‘disturbance in the force’. What happens depends which one gets there first. If SQL Clone reacts first, it will automatically detach the clone database. If SQL Server reacts first and tries to access what it thinks is the local hard disk, but is in fact the image (parent VHD), the disk driver gives back error 21 (the device is not ready). It will then assume, reasonably, that your hardware is failing, so it then locks down the database and won’t touch it. The Clone agent will keep trying to resolve the problem and keep failing because SQL Server won’t let it. Once you hit error 21, you’ll need to restart the SQL Server service.

Disconnecting

If, for any reason, you wish to disconnect a device temporarily from a SQL Clone network, you need to stop the SQL Clone Agent service on the machine, and then take the database offline. It is that simple. You may, of course, wish to copy your SQL Clone database locally first via conventional backup followed by restore under a different name, if you want to continue to work on it during a flight or whatever. The clone itself must remain offline because it no longer really exists whilst bereft of its associated image file. The data is no longer there.

Naturally, you can do this manually. You first stop the SQL Clone Agent service from the services.msc plug-in (Control Panel | System and Security |Administrative Tools).

Right-click on the SQL Clone agent and click on the ‘stop’ item in the context menu that appears. Then you need to use SSMS to log into your local SQL Server instance (well, every local instance if you are using your laptop to the max) and execute this code in Master database.

Now you can snap the clamshell shut and run for the train. Once your laptop is undocked from the network, that clone database is out of bounds. You can see it in SSMS marked as ‘offline’. Just don’t try setting it online while the Clone agent is stopped.

Connecting

Once you get back to the office, the first thing you do is to run this:

Note that we can’t check the extended property that says that the database is a clone because once the database is taken offline, the extended property is taken offline as well. We just assume that all databases that are offline are clones. This is unsafe, but the only way left to us without querying SQL Clone GUI or by using PowerShell to identify the databases on this server that are clones. If you’re not a risk-taker, then you can check on SQL Clone’s GUI for confirmation and create the SQL accordingly.

Then we can restart the Clone agent service. This is just like the process I’ve already described, except that you need to click on the ‘start’ menu item.

At this point, you will probably be shaking your head and wondering if there is a better way. Fortunately, there is. We can use PowerShell.

A scripted approach

Only one script is required since the disconnect procedure is similar to the connect procedure. It must be executed when running PowerShell as administrator; this is stopping a service after all which is not something you’d want to do accidentally. It can be executed within an ordinary script, but the start-service and stop-service cmdlets require execution as administrator.

One script is used for both in this design. You can turn it into a function and call it from Cmdlets you create, called something like Start-LocalClone and Stop-Localclone. The $disconnecting variable must be $true if you are disconnecting and $false if you are connecting. You might, alternatively, just want to execute two separate scripts, each permanently set to do the one job.

Summary

I don’t think that the Redgate team who developed SQL Clone imagined that it would be useful to have a clone on a partially-connected device, such as a laptop, but plenty of people try it. The trouble, of course, is disconnecting the clone from its image in a way that doesn’t upset the system. One day, I guess, there will be an elegant way of doing this, using the GUI or maybe a special cmdlet. In the meantime, this is a fix that does the job. One thing is clear, though; it is going to be tricky to devise a cloning system that is geared to mobile and partially-disconnected devices until internet speeds get close to local network speeds and until MS Windows supports such a network for Virtual hard disks. In the meantime, you can take the laptop anywhere, but that cloned database must stay offline until the laptop is back on the Work network!