How Many DBAs Does It Take to Administer a Database?
What would happen if there was no one to administer SQL Server on a daily basis? Kalen explores how managed service providers can work in this scenario.
March 18, 2009
I’m frequently asked how many DBAs are needed to manage the SQL Server installations in an organization, and as you could guess, there’s no one right answer. I have talked to people from organizations that have only a couple of SQL Server systems and several DBAs, and companies with hundreds of SQL Server systems and only one DBA. Really answering this question would require a much longer discussion of what exactly a DBA is and what tasks a DBA is responsible for.
Then there are companies that have no DBAs on staff. They buy a SQL Server application and just expect it to run with support from the vendor. Although the vendor might have reasonably good developers on its staff, in many cases, those developers really know very little about the best ways to work with SQL Server.
In these times of economic hardship, I’ve seen DBAs laid off, and if those DBAs are part of a team, the company probably can survive. But what if a company has to lay off its only DBA?
If there are no problems, SQL Server can work fine without an onsite DBA. But if it doesn’t work fine, you might not know where to turn. In fact, you might not even know that your SQL Server system isn’t working fine. For example, if your log backups stop working, and you never check your job history or error log, you might not know they aren’t working until you need to do a restore. At that point it might be too late for help from the vendor, even if the vendor knows how to troubleshoot the problem.
And who do you turn to if your application starts experiencing performance problems? Will the vendor know how to troubleshoot the problem? Perhaps performance will get so bad you’ll decide to hire a consultant. But how can you quickly find someone who is capable of tracking down the problem in an efficient manner? Choosing a SQL Server tuning consultant from an online list is a daunting task.
Another option to consider is managed services. I found a very nice description of what a managed service provider (MSP) can offer at en.wikipedia.org/wiki/Managed_Service_Provider, although there was no mention of SQL Server services on that page. However, the range of benefits of engaging a MSP is equally applicable to SQL Server managed services, especially if you just substitute SQL Server for network in the key customer benefits list at en.wikipedia.org/wiki/Managed_Service_Provider.
With a MSP, you can get the basics implemented, such as backups and health checks, as well as ongoing monitoring of critical performance areas. And if specific problems crop up, you’ve got somebody immediately available to start troubleshooting.
Even big companies with a team of DBAs could benefit from an MSP. If you engage a MSP with true SQL Server expertise on staff, they might be able to track down the problem in a fraction of the time that an overworked DBA (who doesn’t spend his or her whole day troubleshooting performance problems) might be able to. After all, big companies will keep lawyers on retainer, even if they don’t need them every day or even every week. Might it make sense to keep a SQL Server tuning expert on retainer, also?
About the Author
You May Also Like