RE: Organizational Challenge - Data Management Team
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--
RE: Organizational Challenge - Data Management Team
In a previous life, I worked at WilTel (very well managed), which became WorldCom (so-so), which became MCI WorldCom (no comment). I started out in WilTel's Engineering Department which (wisely) kept all of IT operations separate and independent from the grand and glorious (and huge) company IT department. We had our own mail servers (POP3), print servers (PostScript ... YEA!), file servers, etc. (which I maintained), and even a semi-firewall between us and the WAN (put there by Big IT because they didn't like us ... arrogant engineering assholes that we were). When I moved into DBA work, I moved from Engineering into the Giant Octopus IT department. For what it's worth, here's how things were set up (at the Tulsa location, which was the majority of the pre-MCI operations). There were two general DBA groups: Test/Dev and Production. The test/dev DBA's were, generally, the more experienced because it was their responsibility to: 1. Ensure that the final test database was, if not an exact copy of production, at least functionally equivalent to production prior to testing a release. 2. Ensure that implementation scripts and any required documentation for the production staff to perform the release were tested and correct. The documentation provided to production would list such things as steps to perform, estimated time for each step, any new filesystem space requirements, any security related requirements (for example, the need for a user to have restricted session), etc. The production DBA staff always had one, experienced, senior DBA in case something blew up. There might be more, but most of the production staff were there to follow procedures and not do much thinking. So the majority of the production staff were less experienced. It was up the test/dev DBA's to make sure anything sent to production was in clear, reliable, monkey see - monkey do form, and that it would work the first time, every time. The DBA's were not the owners of the data. Whoever owned the data was expected to manage their data. This is just a simple case "If you own it, then you take care of it." Or "If we take care of, then we own it, and you don't mess with it unless we say so." Sometimes, if you explain it to people the second way, then they are more likely to step up and take responsibility for what is theirs. Database design was managed by a dedicated database design person(s), the reason being that this is the best way to get uniformity in design and naming. This provides a central point for all matters related to design. Each project had a primary DBA and a secondary DBA (so the primary could take a vacation ... you want what!?). A DBA might be associated with more than one project depending on the complexity of the project. The test/dev group had one on-call DBA who, if required, would contact the primary or secondary DBA for a project if needed. The on-call rotated weekly among the test/dev DBA's. The coding of stored procedures, triggers, packages, etc. varied by project. Maybe a test/dev DBA would do it; maybe not. This was mostly determined by the practical matter of who had the ability to do it. If the test/dev DBA was to write the code, it was the responsibility of the application owner to write a clear specification for what was to be written: input values, output values, format, data checking, error handling, etc. As a recent example: The "Corrected SQL Question" would have been rejected by our group as being incomplete. It was NOT the responsibly of the DBA to determine whether the specification was appropriate for the application; so if the requirements group specified garbage, they got garbage. The GIGO rule was in effect; although if it were obvious that the specification was inappropriate, the DBA would say so. And, as long as we are on the topic of requirements, it can't be emphasized too much the importance of assigning the responsibility for requirements to a requirements group. This relieves developers and DBA's from wasting their time documenting requirements; and a clear set of requirements gives the test group (you have one of those ... RIGHT?!!) a clear set of things to test. Doctors don't service bed pans, and your technically skilled people shouldn't be wasting time in meetings determining and documenting requirements. The test/dev DBA's could not log into the production servers at the OS level. Since test/dev was responsible for verifying that test was at least a functional duplicate of production (preferably and exact duplicate), we could log into the production database and had CREATE SESSION and SELECT ANY TABLE privilege. I'm sure this is an incomplete description. But maybe it will answer some of the questions and give rise to new questions. By the way, the Engineering department was set up similar to what you are moving away from. But, even there, we had a clear division between test/dev and production. A good philosophy for this is like Heaven and Hell (
RE: Organizational Challenge - Data Management Team
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).
