I recently ran across the following scenario. A SQL Server instance had been upgraded from SQL Server 2005 to SQL Server 2008. At the same time, the older physical hardware had been replaced by newer hardware. The DBA who had set up and configured the older server was no longer at the organization, and a new DBA had performed the upgrade. After the upgrade was completed, I was asked to review its configuration. I started by reviewing the various server and database settings, along with the assorted database maintenance jobs, and then I began to ask questions about them.

I was expecting to get specific answers to each of my questions so I could better understand why settings and jobs were configured as they were, but instead, I got the same answer to all my questions: “The settings on the new server were used because they were the same ones used for the older server.” I followed up by asking the DBA if he knew why these particular settings and jobs were chosen in the first place for the older server. The DBA didn’t know, and said, “This is the way we have always done it.”

I just wanted to scream when I heard those words. What the DBA was telling me was that he was not thinking about the implications of how an upgraded version of SQL Server and new hardware could affect how SQL Server is configured. It also told me that the DBA had never bothered to take the time to review the server to see if the settings and jobs configured by the original DBA were even valid in the first place.

As DBAs, it is our job to ensure that all our servers are running as optimally as possible. We can’t just shirk off our responsibility because “this is the way it has already been done.” As DBAs, we need to be proactive. So if you start a new DBA job, don’t assume that the SQL Server instances are correctly configured. Take the time to evaluate each one, and don’t be afraid to challenge the status quo. If you upgrade a server to a new version, or to new hardware, don’t assume that the older settings are still appropriate. And even if you have optimized your SQL Server instances in the past, this doesn’t automatically mean that the original settings are still optimal. Over time, more data is added to databases, and often, different queries are run against the database, which could mean that older settings need to be updated. In other words, SQL Server instances need to be reviewed periodically to see if they are configured appropriately.

So the next time that someone asks you how your SQL Server instances are configured, be sure you can tell them exactly why the server is configured as it is. Anything less, then you aren’t doing your job.

What do you think?