THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Rick Heiges

News about SQL Server and the SQL Server Community

How many SQL Server DBAs does an organization need?

"How many SQL Server DBAs do we need?" - This is a question that often comes up in conversations with customers.  Essentially, customers want to know if they have enough DBAs or too many.  This is not  a trivial question.  If you do some research online via your favorite search engine, you will most likely come across numbers such as 40-65 DBs per DBA (for SQL Server).  I remember finding another number relating to storage space instead of the number of DBs; the range was 3-5TB per DBA.

 I have had custoemrs that had a team of 5-6 DBAs supporting a single application (logically a single DB).  I have also had customers that had 2000-3000 DBs (not all prod, but still) per DBA.  But just saying that a DBA can manage x number of DBs over y TBs of storage just doesn't seem right.

Here are the factors that I have found that influence the number of DBAs needed:

  • Mission Criticality - If a DB is mission critical, it deserves more attention in order to stay available.  The more it is intertwined with the success of the enterprise, the more DBA resources are needed.
  • Churn - How often does data get loaded or get modified?  Usually a DB that has minimal INSERTS/UPDATES/DELETES requires periodic attention for growth, index rebuilds, etc. 
  • Usage Patterns - Even a DB primarily used for Reporting with few updates can require attention if the usage of the DB changes. For example, a reporting DB that has many users that can query the data in anyway that they want can scream for attention.
  • Permissions - But not in the secuity sense... Many DBs are from vendors which restrict what type of modifications that a DBA can perform such as restricting the additon of indexes for example.
  • Skillset of the DBA Team - A team of DBAs that embrace standardization, atuomation, scripting (especially powershell) can manage resources more efficiently.

There are many other factors as well.  I wish that I could say that I came up with a magical formula with these factors built in, but I have not.  I never seem to run into those situations where there are too many SQL Server DBAs.  With that iin mind, I have come across quite a few situations where a qualified DBA is needed either because there is none or the factors listed above warrant an addition of resources.  How does this happen?  SQL Server is "Simple".  Just about anyone can install SQL Server and be up an drunning in no time.  The default settings are adequate for many applications as they are initially built/installed.  Over time, the usage of the system becomes greater and the importance of the data does as well.  Before you know it, an organization may need a DBA and not know it.

If you are unsure that you need a full time DBA, consider a "DBA on-call" service or perhaps a local consultant who specializes in SQL Server.  This type of service can also be helpful to support the organization if you have a DBA or a team of DBAs to cover for vacations, sickness, etc.  The important thing to note is that you do not let your DBA be the potential single point of failure.  When this happens, you truly understand the value of a well qualified DBA. Don't forget that DBAs are people too who have real lives.  :-)

Published Wednesday, July 24, 2013 11:51 AM by RickHeiges

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Patrick Keisler said:

Great article. My boss just asked me this very same question last week. My answer was based on the current workload and the level of service you want us to provide, we need 4 more DBAs. I wish there was an easy button for this.

July 24, 2013 2:36 PM
 

Colin Allen said:

Before things get worse, and they will, I've never been anywhere where they get better, you need to put some work in identifying where all the time goes now. Next, create a list of everything you should be doing that you don't have time for. Another list of things that will increase your workload, eg. tighter security, more audits, lack of disk space, upgrades, tighter change control processes. Now start producing charts illustrating growth, number of databases, number of incident tickets, disk space, etc. and feed to management on a weekly basis.

July 25, 2013 1:59 PM
 

Kin said:

Good article. We have a team of 12 DBA's globally as we have to operate 24 x 7 in all regions.

July 25, 2013 3:32 PM
 

RickHeiges said:

@Patrick - Glad to hear that you enjoyed the blog post.  You are lucky that your boss is cognizant of your situation.

@Colin - Good Point.  By doing an "inventory" of the types of work filling your day, your can better target the type of DBA(s) to help out.

@Kin - Sounds like an environment that is becoming increasingly common.  Do you feel like your team of 12 DBAs is enough?

July 25, 2013 7:25 PM
 

jeff yao said:

We always say if it cannot be measured,it cannot be improved. This is indeed a real issue to lots of questions, and I tried to tackle the same issue with my blog "DBA Work Accounting" http://www.sqlservercentral.com/blogs/jeffrey_yao/2012/10/22/dba-work-accounting/

Each company's DBA work may be different in the context of company policy/ requirement / practices, so it is better to gauge the workload specific to the company, and then  start to "budget" for DBA resource.

July 26, 2013 1:56 PM
 

Hugo Shebbeare said:

Exactly, a good post, I asked much the same question a few years back:

http://dbhive.blogspot.ca/2012/02/full-time-employees-per-number-of.html hope the comments help.  I agree that once you get to 3-4TB, you should have a full time backup, that is for sure.

July 28, 2013 9:41 PM
 

Thulasi said:

Hello Rick: Thanks for the information and these are few factors to evaluate. But as someone said workload will also depends on Organization. Few Org don't have dedicated DBA's for Implementing of fresh Servers , DB upgrades/ Patch deployments or DB Migrations , High availability planning etc. In such case the work load needs to be consider apart from daily maintenance work. As a team Seniors will do planning & implemenation and other resources will manage them :) .As Colin said we are also doing the reporting stuff for DB health check.

July 29, 2013 2:30 AM
 

RickHeiges said:

@Jef3, @Hugo, @Thulasi - Excellent comments and additions to the discussion.

July 29, 2013 7:54 AM
 

None said:

How about none. "We don't need a DBA!"

August 3, 2013 3:40 AM
 

david Pro said:

I've been in an org with 300 db. 200 were for a single app that had never required a single intervention.

I think we sould consider number of apps.

Dépends if your job is made of R&D on software and hardware innovations, if you regularly train your admins around the world, your implication in app development, if you have efficient monitoring ans admin tools, your level of standardization, on your company's security audit policy...

August 3, 2013 1:52 PM
 

RickHeiges said:

@DavidPro - Number of Apps is another good one.  I tend to think of R&D as non-production. The mission criticality of those DBs tend to not be as high as Production DBs. And agree on Security/audit policies....

August 4, 2013 12:55 PM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement