<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://sqlblog.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Search results matching tags 'SQLMag', 'Transact-SQL Programming', and 'SQL Programming'</title><link>http://sqlblog.com/search/SearchResults.aspx?o=DateDescending&amp;tag=SQLMag,Transact-SQL+Programming,SQL+Programming&amp;orTags=0</link><description>Search results matching tags 'SQLMag', 'Transact-SQL Programming', and 'SQL Programming'</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP2 (Build: 61129.1)</generator><item><title>Dev Advice: Make a Tiny Dev Database Act Like a HUGE Prod Database</title><link>http://sqlblog.com/blogs/kevin_kline/archive/2012/03/16/dev-advice-make-a-tiny-dev-database-act-like-a-huge-prod-database.aspx</link><pubDate>Fri, 16 Mar 2012 14:30:00 GMT</pubDate><guid isPermaLink="false">21093a07-8b3d-42db-8cbf-3350fcbf5496:42346</guid><dc:creator>KKline</dc:creator><description>&lt;p&gt;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:&lt;/p&gt;&lt;p style="padding-left:30px;"&gt;&lt;em&gt;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? &lt;/em&gt;&lt;/p&gt;&lt;p&gt;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.&lt;/p&gt;&lt;p&gt;Actually, you have a better alternative - &lt;em&gt;a clone database&lt;/em&gt;, sometimes called a &lt;em&gt;shell&lt;/em&gt; database.  Here's how I described a cloned database a few years ago here in my &lt;a title="Kevin Kline's Tool Time Column on SQL Server Pro Magazine" href="http://www.sqlmag.com/article/sql-server-2005/efficiently-clone-databases"&gt;Tool Time column for SQL Server Pro Magazine&lt;/a&gt;:&lt;/p&gt;&lt;p style="padding-left:30px;"&gt;&lt;span&gt;&lt;em&gt;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.&lt;/em&gt;&lt;/span&gt;&lt;/p&gt;&lt;p&gt;The article gives you all the detail you need to effectively and quickly &lt;span style="text-decoration:underline;"&gt;&lt;strong&gt;create a small version of a big, ol' production database&lt;/strong&gt;&lt;/span&gt; that produces the same query execution plans as you'd get on the prod server.&lt;/p&gt;&lt;p&gt;If you're struggling with doing development on a big SQL Server database, learn the ropes on cloned databases &lt;em&gt;asap!&lt;/em&gt;  You'll be glad you did.&lt;/p&gt;&lt;p&gt;Enjoy!&lt;/p&gt;&lt;p&gt;-Kev&lt;/p&gt;&lt;p&gt;-&lt;a title="Kevin Kline's Twitter Feed" href="http://twitter.com/kekline"&gt;Follow me on Twitter&lt;/a&gt;&lt;/p&gt;</description></item></channel></rss>