Re: dba staffing question

From: Chris Weiss <chris_at_hpdbe.com>
Date: 21 Oct 2002 06:33:12 -0700
Message-ID: <da62ca49.0210210533.2ffa8efe_at_posting.google.com>


eeb <beach9z_at_yahoo.com> wrote in message news:<3DB22BAE.3090702_at_yahoo.com>...
> Does anyone have a rule of thumb for DBA staffing like number of
> databases per DBA. I know this is kind of a strange question since the
> number can vary widely but in larger shops it might average out.

The number of DBAs required depends completely on your level of automation, and the use of tools. If you have a highly customized environment with many different databases and few consistent policies, then you will need more dbas. If you have a pretty vanilla environment with only a few different databases and well defined processes you will need fewer. In a stable production environment, you need fewer dbas than you do in a development environment.

In a shop that is highly automated, a single DBA per shift could support a hundred servers or more. This means using automated backup tools, automated space monitoring tools, and well defined monitoring for paging the dba in the event of a trace or ORA error in an alert log.

In an evolving environment, ten servers per DBA is about the max.

The level of availability also affects how many DBAs are needed. If you need 24/7 active support, then this roughly doubles the number of DBAs. If you only need passive support after hours, then you only need enough staff to make sure that you always have at least two people on pager duty. Obviously, you need the most number of DBAs when your databases are busiest and can taper in the off shifts. One critical point is that you need two tiers of support - a primary pager recipient and a "guru" or senior dba who can be paged for the more difficult calls when the primary pager recipient is stumped.

The best approach is to staff up with contractors until your environment is stable and then staff down as the workload drops, hiring permanent employees when you know the consistent load. It is better to start off slightly overstaffed and trim back than to go cheap and find yourself with a high rate of turnover due to burnout, which is why contractors are ideal. It is too expensive and demoralizing to staff to overhire permanent employees and then to lay off some.

It is also important to hire a senior dba early and have him or her build your team and guide the evolution of your environment, emphasizing automation and the appropriate level of engineering effort. One of the most expensive mistakes companies make is to under or over engineer their systems, with under performing system causing the most pain. A good senior DBA should keep your systems sized well, with enough capacity for anticipated growth.

Good Luck!
Chris



High Performance Database Engineering
http://www.hpdbe.com Received on Mon Oct 21 2002 - 15:33:12 CEST

Original text of this message