FWIW... There is no "fair measure" in my opinion. It depends on how well a model environment was set up in the first place for each database instance. A first class model environment needs less maintenance in general than a hack environment. You spend much less time in break/fix mode as a result and more time in optimizing/tuning for zero administration (shameless plug - Live 2003 - White Paper Presentation - Where there's smoke there's fire... Firefighter or Arsonist) Many times we are our own worst enemies and unintentionally trap ourselves into break/fix mode 7X24. On the other hand, sometimes you inherit these environments and there is no alternative but break/fix because there is no time.
All of that having been said, here's some thoughts... 1. Use any off the shelf software to help you build a model environment which includes lights out proactive monitoring that you are comfortable with. 2. Ditto for backup software 3. Where you can't use off the shelf software, use the minimum number of scripts possible to help you manage your database and provide critical email alerts daily for non-critical maintenance and only send pages for critical failures about to happen. 4. Keep a detailed workbook of every utility script. If you wrote it once, you will probably need it again so why not save it and document it for later use. 5. Make EVERY database environment as close to identical in OFA layout as possible. I've run teams where the ratio is over 100:1 and they run like a swiss clock because of excellent planning and execution. I've also been in shops where 4:1 was nearly impossible because the initial setup and on going configuration of every database is completely different and no consistent implementation of installation, configuration, monitoring and maintenance is in place. In the 4:1 shops... my primary goal was to get the shop to a consistent configuration in a minimalist mode at first and then evolve the more sophisticated monitoring and tuning aspects of the environment. Don't know if this helps. If not, find me at Live 2003 and let's talk. Regards, Bill Burke "The Kinder and Gentler DBA" www.OracleGuru.com International Oracle Users Group www.ioug.org Board of Directors Elect - 2003-2005 Board of Directors - 2000-2002 University Master Class Faculty 2001-2002 Oracle Development Tools User Group www.odtug.com Board of Directors 1996-2000 -----Original Message----- Sent: Wednesday, March 12, 2003 3:14 PM To: Multiple recipients of list ORACLE-L I'd twelfth (or whatever number we are upto by now) the comments so far on how it isn't a fair measure. For what its worth we now have 19 Oracle instances and 7 sql server databases, probably 50+ schemas. You can take your pick as to what you mean by database. We have 3 dbas. One thing that does complicate this is that most of the databases get there own server because of the slightly mad project driven way budgets work (like there is no budget for database servers but each team will have a budget for software and hardware). Sometimes it seems really quiet and stereotypically govt overmanned, othertimes I don't see my daughter awake for a week at a time. What would I say adds to demands on time/efficiency Rate of change of db Number of managers interested in using you as a resource Number of servers Uptime requirements Rate of development Niall > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Chuck Hamilton > Sent: 11 March 2003 21:29 > To: Multiple recipients of list ORACLE-L > Subject: Re: POLL: Database to DBA ratio > > > You are the first reply out of at least 20 (public and > private) who has a larger ratio than we do. The average seems > to be somewhere around 20 so far. As many have pointed out, > there are other factors to be considered if you're trying to > measure the DBA's workload. I'm not trying to be that precise > though. The DB to DBA ratio is close enough for me. > > BTW in case anyone is interested we have 2 DBAs managing 66 > databases. 25 are dev/test. 41 are production. Of the 41, 39 > are 24x7, 6 are over 100g, one is over 1000g. These #'s are > more accurate that what I reported off the top of my head to > a few in private. > > ----- Original Message ----- > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > Sent: Tuesday, March 11, 2003 1:31 PM > > > > > > Consider yourself lucky. We've got a 71:1 ratio here. > > > > > > > > "Chuck Hamilton" > > <[EMAIL PROTECTED]> T > > To: Multiple > recipients of list ORACLE-L > > Sent by: > <[EMAIL PROTECTED]> > > [EMAIL PROTECTED] cc: > > > > bcc: > > Subject: > POLL: > > 03/11/03 09:59 AM Database > to DBA ratio > > > Please respond to > > ORACLE-L > > > > > > > > > > > > > > I'm trying to build a case for management that we need > additional DBAs > > so I'd like to take a quick poll if I may. What is the > ratio of Oracle > > databases to DBAs in your shop? This includes development and > > production databases. At our shop it's 33:1. > > > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Chuck Hamilton > > INET: [EMAIL PROTECTED] > > > > 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: [EMAIL PROTECTED] (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.net > > -- > > Author: > > INET: [EMAIL PROTECTED] > > > > 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: [EMAIL PROTECTED] (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.net > -- > Author: Chuck Hamilton > INET: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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.net -- Author: Niall Litchfield INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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.net -- Author: Burke, William F (Bill) INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
