Ever stop and wonder why everyone is always asking you questions about so many different Microsoft products? Besides the fact that as a DBA you are usually the smartest person in the room to begin with, chances are they think you are an expert in anything that has the letters ‘SQL’. Here is an excerpt from chapter four of my book, DBA Survivor.
SQL Server has a LOT of functionality inside. Have you ever noticed how many components have the letters ‘SQL’? Here’s a short list:
- SQL Server
- SQL Server Management Studio (SSMS)
- SQL Server Reporting Services (SSRS)
- SQL Server Integration Services (SSIS)
- SQL Server Analysis Services (SSAS)
- SQL Server Notification Services (SSNS)
- SQL Azure
And if it has the letters ‘SQL’ you can bet that someone will walk up to you at some point to ask you a question. And when you respond with “No, I do not know how to wrap a notification from SSNS into an SSIS package, build a report in SSRS, and then push everything to SQL Azure” you will get a blank stare and hear the words “But aren’t you the DBA?”
Tip: Remember, no one person knows everything.
The answer is “yes”. Yes we are the DBA, but that does not mean we know everything about each product that has the letters ‘SQL’. It’s the same reaction a developer has when I say “what do you mean you need me to restore the production database from yesterday down to test so that you can get a stored procedure? Don’t you have a copy of the stored procedure in your source control?”
[Getting Asked About SQL
What Tom says about the letters S, Q, and L is true. You really will get asked. A few years ago, I was approached about teaching a class on “SQL”. I don’t remember now whether it was someone who’d read my books and articles, or whether the person had simply heard that I was good at SQL. What I soon discovered though, was that the person wanted someone to teach a class not on SQL the query language, but on SQL Server the database management system. They are two different things, of course. Trust me. I am comfortable with SQL, but you do not want to see me teaching about SQL Server.]
Now that we have established that SQL Server has a lot of functionality you need to be aware that developers are going to ask you a lot of questions about various components that you have never used. That’s OK, do not panic, the developers are doing their job well and are researching different ways to complete a particular task.
With all the functionality the SQL has to offer, developers are not only going to ask you to help them to make something work, but they are going to also expect that you can help explain why something works in a particular way. It could very well be the case that a particular component of SQL is working in a way that is contrary to what everyone expects. Of course you will be expected to provide an answer for the behavior; the answer had better be found fast, and the answer better come with a solution that does not require the developer to undo months of coding. If it does then that same developer is going to ask for you to take out a hammer and make the square peg fit into the round hole.
If such a situation comes up you should do your best to offer the developers a handful of alternative solutions. The last thing anyone wants is for some band-aid solution to make its way to production. Too many times I have seen poorly designed systems deployed to production simply because a developer did not want to admit that perhaps they could have done things in a way that did not cause a slow memory leak and subsequent server reboots once a week.
Usually when that happens they do their best to shrug their shoulder and tell you to ask Microsoft for a patch to fix the problem. After all, they don’t have time to fix things right because they are under pressure to finish some other project.