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 (I'll leave it to you to decide which was which) with a chasm between the two over which no being shall cross. At my current job, it's more of a big free-for-all. Fun! Fun! Fun! -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephen Lee 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).
