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?
Brad M McGehee 
Well said and not limited to DBAs.
Flo
Brad, excellent advise.
Was this a government agency? A few years ago I worked as a contractor for a government agency. Every time I asked why are you doing it that way? I got the same answer, “We always do it that way”.
At first it I was not questioning, more trying to learn the system and why they were doing things the way they were.
When it seemed the same answer was given repeatedly, I started to really question and investigate. I then made suggestions in such a way as to spark interest on some things. This eventually lead to change but somethings stayed the same.
This wasn’t a government agency, but I can imagine that this problem is even worse in the public sector than it is in the private sector.
When you do everything “by the book”, is it your fault if nobody ever thinks about updating “the book”?
I’ve seen this a lot, especially in government. There’s a tendency to let inertia drive system operations among those whose jobs are pretty much guaranteed. (I know, this isn’t just a government problem.)
Pingback: Tweets that mention But We Have Always Done It That Way | SQL Aloha -- Topsy.com
Hello Guys,
Brad’s argument is common sense, but I’ve seen managers argue not to waste the time exploring new settings as the old DBA’s settings have always worked in the past.
I often use this site as a check list: http://www.brentozar.com/archive/2008/03/sql-server-2005-setup-checklist-part-1-before-the-install.
If anyone know any other good articles, please feel free to add them here.
Thayal
Its all about thinking about your work as if at any time someone could come up and challenge it. If you have an answer or justification, right or wrong it doesn’t matter, thats the point of the challenge.. but the cardinal sin is not having an answer at all !!
I greatly agree with Rob, the DBA needs to think, and not just automatically accept the status quo.The status quo might be perfectly fine, but the DBA doesn’t know until he or she has evaluated the status quo, and determined what is appropriate. This evaluation may include reading existing documentation, asking questions, trial and error (on a test machine), or using their own experience as being a DBA. As a proactive DBA, I would also challenge a manager who told me to keep things as they are, without question. I would make my own independent evaluation, and if required, get the permission of the manager to made the change. If I found the manager was making many poor choices, and I couldn’t persuade him to make the correct choices, then most likely I would be looking for another job.