![]() When working with clones, it is much better, once a new build has been successfully made, stocked with appropriate data and tested, to delete all the clones and then the image that they used. With SQL Clone, it is a matter of seconds. Also, in doing so, you would be getting around a problem that has ceased to exist, which is the length of time it takes to copy a database. Also, because the changes will be held on a differencing disk on local storage on the server, you will gradually lose one of the great advantages of SQL Clone, which the huge saving in disk space. You can certainly apply a synchronization script in order to bring each clone up to the latest version, although this isn’t always practical, because each clone could be in a different state, and so each clone would require its own synchronization script. When you are working with a cell of test and development servers, this can present a challenge. ![]() ![]() Whenever the version changes, these clones need to be migrated to the new version. With SQL Clone, you take an image from the database that represents that build, plus data, and clone identical copies of it. In testing or development, it is important to be sure of working with a known version of the database, usually the latest build. The scripts, taken together are intended to manage a typical provisioning cycle to keep the clones in sync with the current version of the database. By combining the deletion script with the installation script, you can, in effect, refresh all clones when the image is updated, to reflect changes in the original database. ![]() As for the rollback process, this script aims to manage the deletion process to ensure that work doesn’t get lost. Here, I present a PowerShell script that you can use to safely delete all clones, and then the parent image, in readiness for refreshing all development and test instances with the latest version of the database. These scripted modifications would then run automatically as part of installing the clones, without any need to touch the code in the installation script. Simply by adapting the data in the config file, we could use Image modification scripts to alter the image before the clones are taken from it, and both Clone templates and SQL Scripts to check and alter the individual clones. The second article, Scripting Custom SQL Server Clones for Database Development and Testing, showed how one could apply T-SQL modification scripts during image and clone creation, to customize all clones, or individual clones, prior to use. A second PowerShell script showed how to revert, or roll back, a clone to its original state, ready for the next set of tests or development work to begin, first ensuring, if necessary, that any changes made since the clone was created were saved to source control. It presented a shared configuration data file and then a PowerShell clone installation script that used this config file to create a suite of clones, for testing or development work. The first article, Deploying and Reverting Clones for Database Development and Testing, mapped out a Clone installation consisting of a source database, an image and some clones. This is the third article in a series that explains how to use SQL Clone, part of SQL Provision, plus a collection of PowerShell scripts, all with a shared configuration data file, to deploy, revert, customize, delete and refresh clones, for database development and testing work. He is a regular contributor to Simple Talk and SQLServerCentral. Phil Factor (real name withheld to protect the guilty), aka Database Mole, has 30 years of experience with database-intensive applications.ĭespite having once been shouted at by a furious Bill Gates at an exhibition in the early 1980s, he has remained resolutely anonymous throughout his career.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |