You’ve taken a new job ! You’re now responsible for 50+ SQL Sever instances, maybe more. What do you plan to do in your first 30, 60 or 90 days? Make sure backups are running? Make sure consistency checks are running? Implement maintenance routines, if none already exist? Those are all great ideas and things you should consider doing sooner rather than later. However, there is one thing you’ll want to do first, that is far more important than those or any other typical database administration task you might be thinking of.
Many of us have been there. You think you’re monitoring your entire SQL estate. You think you have all your backups properly configured. Then one day, you get a call, an application is offline. But wait, you’ve never even heard of this application. You have no idea what SQL Server is running behind it. Finally, with some help from a senior developer, you track down the SQL Server. You log on. Then, it hits you. You realize backups have not run successfully for months and a database is in a suspect state.
Now, that’s not a situation I wish upon anyone. But let’s face it, we often inherit a mess when taking over a new SQL Server environment. However, the phrase “I didn’t know about that server” is not typically going to take you very far in this industry, nor with your boss. After all, as a DBA, it’s your job to know where all your SQL Servers are.
So, what’s your first priority as a DBA? You’ve probably guessed it by now. The first thing you’ll want to do is get an accurate list of your SQL Server inventory. Preferably using automated collection with a regular refresh. Because, let’s face it, people love to go rogue and randomly install SQL Server instances for some side project they’re working on, without telling any one. Then suddenly it becomes your problem one day when it breaks.
So, before you run off and start changing configuration options, changing backups schedules, tuning queries, or whatever that shiny object is sitting in front of you, I want you to go get an accurate list of your inventory. One that you know you can trust. Sure, this is probably the least interesting part of our job. But it’s a must, and it’ll pay you dividends in the end.
It’s not going to be easy. People are going to try to side track you left and right with new shinny objects. Everyone always thinks their problem is the top priority, and sometimes it might be. That’s for you to access on a case by case basis. But if you’re not diligent, you’ll get 6, 12 or even 18 months into your new job, and still not have an accurate inventory list.
Once you finally have an accurate inventory list, you can start tackling your tech debt. Because at this point, you can trust that once you start reconfiguring backups, integrity checks, or monitoring, that you’ve covered your entire SQL estate. At this point, the chances of finding a random SQL Server sitting under someone’s desk are slim.
There are many tools out there to help you collect and find your SQL inventory, and I won’t go into detail about which one to use or how to use it. Here are few commons ones, in no particular order. Most importantly, pick one you feel comfortable with and get started.
- dbatools Find-DbaInstance
- Idera SQL Discovery
- Microsoft MAP Toolkit
Please leave a comment with the tool of your choice, or let me know if there is one you think should make the list.
Lastly, where do you feel inventory collection falls on a DBA’s priorities list?
Brendan McCaffrey 