Ron - As a solo DBA shop, I can't be much help except to point out that most of what I've heard involves the DBAs specializing between production work and development work. Some DBAs administer the production databases, others work with the developers. This also seems to suit the personality types.
Dennis Williams DBA, 40%OCP, 100% DBA Lifetouch, Inc. [EMAIL PROTECTED] -----Original Message----- Sent: Thursday, March 13, 2003 6:39 PM To: Multiple recipients of list ORACLE-L All, I would like to open a discussion to solicit information regarding the support structure you utilize in your Data Management department. We currently have a flat end-to-end approach whereby a dba adopts an application and subsequent database in the early planning stages via teaming up with the Data Architect and developers and owns that application all the way through design, development, testing, and ultimately production support. As a smaller group (3-5) dba's this model worked fine, and everyone knew their respective database quite well. As more and more applications (internal and 3rd party) continue to rollover from legacy systems into Oracle solutions, this is proving to be very challenging to provide 24x7 support and related on-call duties spanning three RDBMS platforms (Informix, Oracle, and MS SQL Server). Our challenges are two fold: One, we are (like any shop today) extremely overloaded with work requests, so this makes cross-application training to spread the knowledge nearly impossible to accomplish. Two, with everyone tied to a project, we have no resource with large enough buckets of time to take on new and imperative technologies such as java, replication, high availability, xml as examples that our development teams would like to leverage in the database. We are in the early stages of looking at organization alternatives. We are fortunate in that 90% of the database support is already centralized in our department for the company, so that allows us the ability to minimize every dba learning lessons the hard way. Specifically, we are considering some "role" divisions amongst the DBA's. That is to say a subset dedicated to "engineering" such as implementing and architecting new technologies and related best practices, a second subset for implementation of systems being developed, and a third subset for production support. I would like to hear about the organization structure you are involved with and the pro and cons of a flat structure as compared to a more "role" based structure. Thanks in advance, -Ron- Lead Oracle DBA -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: DENNIS WILLIAMS 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).
