Today is the launch of SQL Clone, a great new tool that helps you quickly and easily provision SQL Server databases for development and testing.
Oh god, that sounds like marketing speak. To heck with that. Let me tell you why I’m so excited about SQL Clone and why I think you’re going to be excited too.
Once Upon a Time…
Almost two years ago one of the developers here at Redgate called me over. He wanted to show off this neat trick he’d figured out. What I saw was a good-sized database, about 200gb, created on his local instance of SQL Server in about 10 seconds. Now, that’s fast. Further, he showed me the files and disk space on his machine, and it was only taking up a few kb. Then he did it again, and again, and again. There were four copies of the database on his local instance, none of which were taking up more than a few kb, all of which could be read from, edited, whatever, treated like unique and independent databases.
It was magic.
So I made him walk me through what he did to make it happen. Then I made him walk me through it again, because I’m not as smart as he was and didn’t get the point at which the magic occurred. Unfortunately, I had to make him take me through it a third time before I finally got exactly what he was doing and exactly how he was doing it.
Take My Money!
I immediately wanted this tool, well, the tool that became SQL Clone.
Why? Because I could create multiple copies of a database in Dev, QA, Pre-prod, wherever. Not only could I create all these copies of this database, but I could do it really, really quickly. In tests I was creating a terrabyte database in about 15 seconds. Further, it wasn’t using up all my disk space everywhere. Yeah, you had to create one copy of the database using a special mechanism, but then that copy could feed others, none of which were taking up space, all of which could be quickly and easily provisioned. Talk about the ability to automate and enable DevOps, testing, you name it. It was right there, fast, easy, and most importantly, small.
Before there was a DevOps movement, I had been doing DevOps at my previous company. We believed in integrating between the two environments and in making methods that allowed for fast, agile, development and deployment processes. We built a push-button deployment methodology, partly using home-grown tools, partly using the tools available at the time. We even had an automated provisioning mechanism. Of course, it took hours and hours to implement because we were copying VMs and recreating databases, allocating tons of disk space, etc. It was hard. We wanted a way to provision servers for development and testing in seconds, but were happy enough we could do it in hours instead of days.
If only we’d had SQL Clone available, we’d have bought it on the spot. If for no other reason than the fact that we were using 4-5 times as much disk space in dev and QA as we were in production. Even with the low cost of storage these days, that still equates to a serious cash outlay. SQL Clone would have saved one heck of a lot of money, let alone time (which is also money).
Come and Get It!
Fast forward to today. SQL Clone is now available. Not only can you create an image from a database and you can create a clone from that image. Further, you can create an image from a backup of a database, so you never need to go anywhere near your production server. You can create an image from a clone. Then, once you’ve created these images, you can put them on your database servers as long as they can read from wherever the image is stored, and you have a cloned database (or lots more than one).
That’s not enough though. I want to automate this, both for myself as a DBA so that I can appropriately clean-up production data for use within development and testing, but also for all the QA/Test/Dev people I have to support, so that they can self-provision their own clones of databases when and where they need them. Great! SQL Clone has a full set of Powershell commands so that you can set up the automation any way you want.
SOLD!
Seriously, though, I’m very excited about this. I think we here at Redgate have a pretty darned exciting new tool that’s really going to help testing and developers while simultaneously making the DBAs life better. Please take a look at SQL Clone because I think you’ll end up as excited about it as I am.
I’m going to be hosting a LiveStream event on the 29th of March to go into a LOT more detail about this. Click here to register for that event.
Very interesting. Starts at $6,995. Right now we have full-sized copies of our 6 TB prod database in about 10 dev/QA environments. That’s a lot of time spent copying, plus disk space. We mainly use Netapp disk devices and have talked about some of their clone technology, but never got it off the ground. For one performance-testing environment, the servers are located in our DR center across the country and it takes a week to copy the 1 TB compressed backup files back there. There have been attempts to make a small copy of prod with data realistic enough to be useful, but none have been successful — the first attempt at this usually bombs in trying to delete data where there is a high level of referential integrity. For all of these reasons, we’re lucky to refresh QA from prod once a year.
So user entitlements. If you have, say, an average of 5 Devs or QAs using each of these 10 environments, how would the licensing work for that, or is it even user-head-count based
Hey Randal!
Let me introduce you to Grant Fritchey, nerd.
I’m not sure what the licensing costs are. They are published on the web site, so you should be able to get them there. There are costs listed for teams of 5,10,and 20+. In addition, you can (you should) negotiate your license cost. I hope that helps.
[…] has released a new product, SQL Clone. I’ve already talked about how excited I am about it. Now, it’s your turn to get […]
I’m ready to get the trial version. My manager is interested. We have about ten QA environments and each has a 6 TB copy of the prod database so SqlClone sounds exciting. This actually sounds a bit like Netapp FlexClone technology which we’ve talked about but not implemented. Most of our prod and QA environments sit on Netapp disk devices. Two concerns: one is the IO with multiple environments working off one SqlClone “snapshot.” The other is PII data/encryption/obfuscation. One of our QA environments has Safenet encryption on four PII columns to mimic production ( social security number etc ). So there we’d just create a sqlclone from the prod backup and it should work. In the other QA environments I typically restore a prod backup, tweak some views to “bypass” safenet and run some home-grown obfuscation scripts on PII data. So in the latter cases I’d have to restore to QA, obfuscate and then use that copy to create my sqlClone master. I’m curious how various QA environments can make different DDL/DML changes and keep their release/build levels different when working off one snapshot/clone.