Landrovers, will take a lot of pounding and neglect, but when my wife drove hers to Australia she made very sure it was properly set up for 2 years on the road
Similarly SQL Server is also often out in the wild far from DBA’s and inspection from maintenance tools, like System Center. However now might be a good time for a bit of TLC if things are quiet for you in August. In my last post I dealt with Servers in general, so today I want to look at a SQL Server spruce up, particularly for those who are not full time DBAs.
As per that post you may well be able to decommission whole VMs running SQL Server, but what I want to cover here is what you might want to check at the on instances and the databases themselves. Books have been written on this but I would be interested in:
- Compatibility level – the ability to get a shiny new copy of SQL Server look like an older one, should only be set where you actually need to have backward compatibility. Note that by default this is kept at the old level after an upgrade from an older version.
- Memory reservation should be set less than what’s available and not left blank. The question is how much less, and the answer is what else is running on that server but at least 768Mb for the operating system itself
- Where and how many TempDBs there are, as per TechNet guidance here.
For individual databases you might want to check that
- Statistics are up to date for all your tables
- Checking for and repairing index fragmentation
- There is no extraneous fluff in your databases such as copies of tables, and indexes as well as remnants of dev code like spare views and procedures.
Rather than perform all of these sort of checks yourself, you could deploy System Center Advisor which is a free cloud based service. It matches your installation and database against best practice from Microsoft Premier Feld Engineers and tells you every day what you need to worry about. It can be securely deployed behind a gateway in your infrastructure so your actual SQL Servers don’t need to be internet facing and I have posts on how to do that here.
Finally you might also want to benchmark your database by putting a known load on it that you can use as a reference when making any changes to it, such as virtualise, it upgrade it etc. To be honest I couldn’t find too much on TechNet/MSDN/Codeplex to help with this so you may want to resort to third party tools such as Dell(Quest), Idera, RedGate, SQL Sentry, and dare I mention PowerShell (as per this article by Aaron from SQL Sentry) etc.