The Glory of Cloned Databases

there are a bunch of ways you could create a database clone. backup and restore is one method. export/import is another. there are even third party tools that will help with that. however, each of these has a problem. it’s moving all the data, not just once, but twice. you move the data when you export it and you move it again when you import it (same thing with backup and restore). that makes these methods slow for larger databases. how can you create a database clone without moving the data multiple times?

don’t move the data at all

new with sql server 2016, expanded in sp1 and added to sql server 2014 sp2 , is a new command, dbcc clonedatabase . this is like a dream come true. the use is extremely simple:

dbcc clonedatabase(wideworldimporters,clonedb);

what happens is that it creates a new database on the server. in that database, you get the full set of schema plus all the statistics and metadata. what metadata, you might ask? query data store information is moved as part of this. the database is created read only and the file size is whatever the value is on the model database.

for example, my wideworldimporters database is currently about 1gb worth of data. the new clonedb that i created is 80mb in size. you can, as of sp1, control this even further by choosing to not move statistics or not move query store data.

and the point would be?

why would you just create an empty database with statistics and query store information? what is that going to do for you?

obviously, without data, you’re not going to be troubleshooting data issues. however, what you have is a database that you can run performance tests against. because it has the statistics and the metadata from your original database, this cloned database will behave as if it had data inside of it in terms of generating execution plans. you can run all kinds of queries and see how they would behave, without moving data around.

you’re excited now, right?

the database is read only so that you avoid a statistics update. if you were to take the database out of read only and then update the statistics, there’s no data. therefore you would end up with statistics showing that there is no data. any execution plans generated would not be reflective of the original database.

i’d recommend caution when using this. you may create the clone on production, but i wouldn’t suggest leaving it there or using it in tests there. even microsoft suggests caution. here is the output from my clone operation:

database cloning for ‘adventureworks2014’ has started with target as ‘qdsclone’.
database cloning for ‘adventureworks2014’ has finished. cloned database is ‘qdsclone’.
database ‘qdsclone’ is a cloned database. a cloned database should be used for diagnostic purposes only and is not supported for use in a production environment.
dbcc execution completed. if dbcc printed error messages, contact your system administrator.

i’d probably back up that clone and restore it to a non-production server for any testing.

only move the data once

so, what if you really do want to have data. is there a fast way to move it twice? not really. however, what if you only move it once? redgate sql clone is a new piece of software that does just that.

what happens is a copy is made of your database. it’s about the size of a backup and takes just as long. then, using virtual drives, that is mounted to the server and it occurs pretty much instantly. however, the data doesn’t move at all. you’re reading from the copy of the database, not local storage. further, more than one server can attach to the copy, so lots of servers can have a clone.

the main use for this would be for troubleshooting production data, but offline, away from the production server. if you cleaned the data and made a clone of that, you have another primary use as your development database. you can have a clean copy of production that only takes up the space of a single backup on multiple development servers. that’s a win.

again, i wouldn’t recommend using this in a production environment either. yes, the initial backup can be from production, but the mounted clones should not be.

this is a great way to get a clone of your database but only have to move the data a single time.

conclusion

it is possible to get that copy of the database off your production server without having to move the data twice. if you’re only looking for performance tuning, check out dbcc clonedatabase. if you also need data, take a look at sql clone from redgate. either way, it is possible to get a copy of your database faster and easier than moving the data two times.