Important SQL Server Database Properties and JumpstartTV

kellyb — Fri, 23 Jan 2009 16:22:21 GMT

JumpstartTV is another one of these sites that are popping up that offer short and sweet tech screen casting. They offer 5-10 minutes videos covering the basics of a narrow technical topic. JumpstartTV focuses primarily on SQL Server topics, but they do have other material from time to time. I like this because I’m not really a database guy. I’ve designed a built a lot of applications, and therefore I fully appreciate the role the RDBMS plays in an system architecture, but my mind thinks in objects – not relational schema.

Today’s topic was SQL Server Properties to Avoid and I’m going to leave a quick crib note summary because this is good stuff to have handy in a checklist format.

File Initial Size and Autogrowth

By default SQL Server picks Initial Size: 2MB and an autogrowth of 1MB. For anything beyond tiny applications, these settings will cause significant I/O thrashing and disk fragmentation as the database grows. Set these properties to values that make sense for the database size you’re anticipating to go into. 10% autogrowth is a good starting point and the number of files should match the number of hard drive spindles you have.

Options – Auto Close

Turn it off. This will close all connections from the pool and deallocate the database from memory and cause the database to spin down. THis will cause performance problems when it has to spin back up for the next user to re-enter

Options – Auto Shrink

Turn it off. It’s best to create a job to do a shrink at night. Auto Shrink will arbitrarily pick a time to doing this resource intensive process, which could be at a bad time for your application.

Options – Recovery Model

Pick the one that makes sense. By default “Full” gives you point-in-time recovery which might be overkill for you application. “Simple” requires much less overhead and yield much greater performance, if it can support your business.

Options – Compatibility Level

While this doesn’t necessarily impact performance or system strain, picking the highest possible level of compatibility for your requirements is the right thing to do. I believe SQL Server will default to the lowest compatibility level (not sure about that).

Governance

You can create Policies in SQL Server 2005 to detect (and correct) issues with servers/dbs of interest. You can also script all of these settings, or apply these changes through SQL Server Management Studio.