Here’s an evergreen question. It’s a question that never completely goes away. But lately, I’ve been getting it a few times per week. So I thought it’s time to readdress the question, which usually takes some form of the following:
I can’t really do effective development on my little dev laptop because our production SQL Server database is 15 gazillionbytes, way too big for my workstation. What’s a uber-nerd to do?
Well, maybe they didn’t use the word “uber-nerd”. But you get my drift, right? The production database is really, really big – unmanageably big for keeping a local copy. So that means the dev either has to create a metadata-only version of the database, which won’t produce realistic query plans, or somehow crush their laptop under 15 gazillionbytes of MDF and LDF files.
Actually, you have a better alternative – a clone database, sometimes called a shell database. Here’s how I described a cloned database a few years ago here in my Tool Time column for SQL Server Pro Magazine:
In effect, a cloned database includes all of the schema objects of the database (e.g., tables, views, stored procedures), as well as the statistics and histograms (the so-called “statistics blob”). This metadata is quite small by volume but can tell you what estimated query plans look like outside of a large production environment and how those estimated query plans might change when SQL Server is upgraded. Cloned databases are especially useful when the data is confidential, classified, or subject to privacy laws.
The article gives you all the detail you need to effectively and quickly create a small version of a big, ol’ production database that produces the same query execution plans as you’d get on the prod server.
If you’re struggling with doing development on a big SQL Server database, learn the ropes on cloned databases asap! You’ll be glad you did.