Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: DBA work load

Re: DBA work load

From: Tim Gorman <Tim_at_SageLogix.com>
Date: Tue, 24 Sep 2002 07:08:22 -0800
Message-ID: <F001.004D7D50.20020924070822@fatcity.com>


The intent of my reply was not to bring out stories about the exceptional and the fortunate, but to aid someone who is (presumably) trying to staff responsibly. There are 168 hours in a week -- most people prefer to work 40 of them (or less). Simple math. If you factor in holiday/vacations, training, sick-time, and leave, then they only work something like 32-35 hours per week or thereabouts. Factor in the frequency of meetings; the number of available hours decreases further...

Obviously, not all of those 168 hours are equally intense, requiring a conscious person to be available on-call (you *do* get compensated for being on-call during off-hours, don't you?). Maybe none of them are. Maybe all of them are. Start with the premise of four people and add or subtract as local conditions warrant...

I'm sure that someone will point out that it is not just the hours expended -- it is what is accomplished during those hours, how much is automated, measuring and improving processes, etc. Yes, quite true. Consider those to be factors that decrease the number of people actually needed from the baseline of four, just as the lack of those advantages may increase the number of people required. This way, you put value on those activities (and the people who perform such activities) in a way that is tangible to management...

And just think: with Oracle9i, SQL Server, and Teradata, you don't need any DBAs at all...

> I'm in a 24x7 shop where I am the only DBA ... and I have lasted over 2
> years!
>
> I look after about 12 Oracle production databases - all of which have a
98%
> rebatable SLA attached to them. I also have 6 SQL Server databases with
the
> same rebatable SLA.
>
> Thankfully, our environment is stable (knock on wood). Whenever we run
into
> a huge problem and there is too much work going on I have the option of
> getting a "loan" DBA from another part of the company. This has happened
> about 3 times - two times I was on holiday.
>
>
>
> -----Original Message-----
> Sent: Tuesday, 24 September 2002 2:13 PM
> To: Multiple recipients of list ORACLE-L
>
>
> As metrics, Gb per DBA or databases per DBA are quite irrelevant. A
single
> DBA, well-rested, experienced, and with proper planning and support, can
> manage hundreds of databases and dozens of Tb of data. On the other hand,
> some database production environments are so chaotic as to consume several
> DBAs and reduce them all to tears of exhaustion and frustration...
>
> The question needs to be viewed from a more mundane perspective. Take the
> number hours in a week. There are 168 of them, the world over. If the
> business has the expectation of 24x7 coverage, then at least four people
are
> needed, each working approximately 40 hours per week. Period.
>
> Two FTE (full-time equivalent) can expect to cover normal "weekday" hours
> (i.e. 7am-7pm weekdays), one FTE to cover week-day off-hours, and one more
> FTE to cover weekend off-hours, vacation backfill, training backfill, and
> sick-time backfill. Let's not forget maternity and paternity leave
> backfill. I am not saying that this will be the division of labor, but if
> you figure that it will be likely that there will be meetings to attend as
> well as work to perform during normal working hours on the weekdays, then
it
> will likely work out to something like this...
>
> Of course, I expect to hear from people who are single-handedly managing a
> 24x7 shop. Many people are forced through that wringer for a time...
>
> ..there is another prolific member of this list to whom I related this
> formula, six years ago. He was the sole Oracle DBA in a 24x7 shop,
> supporting a fast-growing company that is now the market leader in its
> industry. I related this rule of thumb: four systems/database
> administrators in a 24x7 shop is sustainable over time. Three
> systems/database administrators in a 24x7 shop is sustainable for a short
> period of time, but ultimately leads to burnout and turnover. Two
> systems/database administrators in a 24x7 environment is totally
> unsustainable, as one of them (if not both) will always be in an active
job
> search at any one time. And rightly so...
>
> He asked, "What if there is only one DBA in a 24x7 shop?". I grinned,
> saying that they would not last more than a month or two. He replied that
> he was now entering his third month in just such an environment...
>
> ..I think he lasted another 3 months or so, but ultimately with the
> inevitable result. A truly heroic performance, but somewhat reminiscent
of
> Wile E Coyote trying to scramble back to the cliff's edge, having been
lured
> into thin air by the Road Runner...
>
> ---
>
> Of course, if you don't have a 24x7 environment enforced by service-level
> agreements, then your mileage may vary. Obviously, there are environments
> that get by quite well on 1, 2, or 3 DBAs, but I am certain that they are
> not truly 24x7 nor is instability in those environments...
>
> But the point is that the job of database administrator is like any other
> critical support role. Only the medical profession is so criminally
idiotic
> as to expect and demand 30- and 40-hour shifts from its most valuable
> personnel...
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Monday, September 23, 2002 7:43 PM
>
>
> > I'm trying to justify hiring another DBA, and
> > management wants more justification. I have put
> > together the usual reasons, but they want "Industry
> > Standards",
> > like how many Databases can one DBA manage. Or how
> > many GB/DBA or endusers/DBA?
> > Does anyone keep these kind of stats?
> > thanks
> >
> > __________________________________________________
> > Do you Yahoo!?
> > New DSL Internet Access from SBC & Yahoo!
> > http://sbc.yahoo.com
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: tony ynot
> > INET: tony_ynot_at_yahoo.com
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting services
> > ---------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Tim Gorman
> INET: Tim_at_SageLogix.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Sujatha Madan
> INET: Sujatha.Madan_at_cmc.optus.net.au
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Tim Gorman
  INET: Tim_at_SageLogix.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Tue Sep 24 2002 - 10:08:22 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US