Ron, I think you are starting at a good place.
Production DBA's worry about different things than Development DBA's. Mostly they are concerned with (in priority order) Backup schedules & Validations (make sure they are working), disk usage (make sure there is enough) and on-going tuning issues. Add to that the migration of new releases of the product and database structure changes. Development DBA's deal with (in priority order) rapid changes to the database structure,migration of the changes to user test and production instances, disk sizings of projected data, and delivering the application and database to a production environment. So you can see that the priorities are a bit different. Saying that, I think the best structure is to have a team of people who monitor production databases. This could be done in a rotating basis so that everyone can become familiar with the production environment. And I really think that having a DBA assigned to a database as it is being developed is a good idea. The application team gets a dedicated person who grows in knowledge with the system. Of course, all of this only works if you have solid DBA Standards - everything from server structure layout to database object naming standards. This creates an environment where anyone can step in anyplace and learn the system as quickly as possible. Good luck! Tom Mercadante Oracle Certified Professional -----Original Message----- Sent: Friday, March 14, 2003 11:49 AM To: Multiple recipients of list ORACLE-L 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mercadante, Thomas F 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).
