There is little worse than having to figure out which of several different ways to do something previous employees decided to do things.
Over the last week, I began managing several SQL Servers as the DBA for a client. No worries there – it’s what I do.
I began reviewing the first SQL Server. Backups were done via a maintenance plan. No worries there. Many places rely on maintenance plans to do their backups each day.
On the second SQL Server, I found no maintenance plans. What I did find though, was a SSIS package creating backups each night for all of the databases on the server.
On the third SQL Server, I found an older version of Ola Hallengren’s Scripts. Now don’t get me wrong, you don’t always need the latest version of a solution, especially if you “had” to make modifications to a previous version.
On the fourth SQL Server, well, you get the point. After discussing with the client, I found that previous employees who had attempted to become a DBA for the company had differing ideas on the best way to back up the databases on the SQL Server.
One of the many items that I will be recommending to the client is that we take one of these solutions – preferably the newest version of Ola’s scripts – and implement that on all of the SQL Servers. I love Ola’s scripts because of all of the data that it provides about the backups and the number of parameters that I have control over easily.
This way, I don’t need to remember how data is being backed up on that particular SQL Server whenever the backup fails (or I need to restore the database). It also allows me to gather usable data about the backups all in the same spot from each SQL Server. Importantly, it also allows me to know exactly how the backup is taken on each SQL Server.
My point today is that, even if the SQL Servers have been there for 5+ years, for your own sanity, make sure to be consistent as much as possible so that when you need to know things, ie 2 AM, you don’t have to seriously think about how that particular server is configured. And, yes, this goes far beyond just taking backups of the databases.
Until next time my friends! Until then, I’ll be taking stock of several new (to me) SQL Servers.