| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Slightly OT: Development Vs. Production DBA
DITTO! ... I personally like it when they come screaming to me (I am the "production" dba for the most part) that the test database is all messed up... couldn't be them... they haven't touched their code... all they did is point the same code at test instead of development... DBAs must have broken it. (Because I don't have anything better to do than mess with duhvelopers... nothing more fun, granted, but more important sometimes). But you know... no one has said word one after they found out that the networking people upgraded websphere on the server where the java code was running and not anywhere else... and the code (when tested EVERYWHERE else) works fine... yeah, yeah... I broke my database just to mess with them...
muerdame
April
April Wells
Oracle DBA
Great spirits have always encountered violent opposition from mediocre minds
-- Albert Einstein
-----Original Message-----
Sent: Tuesday, January 28, 2003 11:09 AM
To: Multiple recipients of list ORACLE-L
I agree 100%. I am fighting this battle as we speak. Many Duhvelopers think they can do it all until something goes wrong then guess who they call to bail them out. Then Damagement is breathing down your neck to get it fixed when you have no idea what happened.... neither does the Duhveloper!
I think an organization needs to have clear policies in place and enforce them to the end.
Valerie H. Webber
Management Systems Designers, Inc
Database Administrator
valerie.h.webber_at_irs.gov
704-566-5321
-----Original Message-----
<mailto:BoivinP_at_mar.dfo-mpo.gc.ca> ]
Sent: Tuesday, January 28, 2003 8:04 AM
To: Multiple recipients of list ORACLE-L
A "development DBA" is a developer who wants to design the schemas his/her application will rely on. I prefer calling them application designers, because that's what they are. Sometimes you have another role, that of "Application Administrator." This second group is for larger applications that sometimes require constant attention, esp. if user accounts have to be created, or custom views etc. ... or if the application wasn't ready for production and was placed into production anyway -- then it will require constant babysitting.
Consultants come in usually to implement new projects, or to add features to
an existing system. That makes them application designers or application developers. Sometimes (rarely) consultants are hired to tune systems, that would be a blend of DBA and application designer. This is rare though, usually the database layer is working properly it seems to me, if the DBA has been there for more than a year, has read a book or two, and has at least the echo of a conscience.
A "production DBA" is responsible for ensuring that the structure beneath the application stays up and is tuned properly. He/she works with the system administrator(s) to ensure that the hardware and the Oracle software (rdbms, developer server, iAS, networking,...) are all working properly and as expected.
I don't fully understand why developers (some developers) strive to be called a DBA. Here is my guess:
Perhaps this distinction stays fuzzy in organizations because there is a constant tug-of-war for control over resources between the development and production groups. If an overlap can be created, then there is an opportunity to take over some of the other group's resources. Also, when responsibilities are not delineated clearly, there is an opportunity for one
side to blame the other and management can never figure out who is doing what. I worked in a lab where we were implementing Good Laboratory Practice
(GLP) for the Food and Drug Administration (FDA), there was supposed to be no overlap between positions. I noticed that the managers who played games and only thought about their own advancement didn't like GLP at all, they fought it tooth and nail. I liked the idea of separate each person's circle
of responsibility myself. Why can't IT shops strive to do the same?
Speaking as a DBA, it is my perception that developers tend to be project-oriented. That's fine, it's why they are there. But that tendency also means, when they see their deadlines coming, that they sometimes aren't
keen on thinking long term. Perhaps it's not their fault, it's because of the way projects are funded. Which client wants to hear that for every project, money will have to be allocated for ongoing costs of maintenance, operation, upgrades every 2-3 years? No one wants to think about that when they only want to think about the great new things they will be able to do with the new application.
Also, no one wants to spend more money than necessary, so there is a tendency to try to cut corners to get to the end of the project. That is probably why projects tend to be rushed into production. Once the projects are in production mode funding to finish the product dries up. That sometimes leaves the application designer off the hook and leaves the "production DBA" holding the bag.
Finally, if you are designing a new project, the tendency is to try to retain control over as much of it as possible. If you declare yourself to be a "development DBA", then people are less likely to insist that you consult the DBA(s) during the design phase of a project. "What a bother that is, having to listen to other people -- it's "my" project! It will only slow us down... Worse, I will have to share the credit once the application works properly. That won't be as good for my career." If you know that the DBA in the organization is stubborn and intractable, then this
is the route the application designers will try to take.
I could draw up a list of things that can go wrong when DBAs are not involved in the design phase of a project, but I think all people need to do
is brainstorm for ten minutes to get a list of 10 or more things that can go
wrong... Then try to put a cost value to each of these items.
Can you think of any examples from your work place?
; )
Regards,
Patrice Boivin
Systems Analyst (Oracle Certified DBA)
[this is my opinion, not the opinion of my employer... etc. etc.]
-----Original Message-----
[ mailto:Ranganath.Krishnaswamy_at_blr.hpsglobal.com
<mailto:Ranganath.Krishnaswamy_at_blr.hpsglobal.com> ]
Sent: Tuesday, January 28, 2003 4:29 AM
To: Multiple recipients of list ORACLE-L
Hi Listers,
I would like to know the differences between Development and Production DBA w.r.t. Roles and Responsibilities, Scope etc. Is there any difference in the role(s) played by a DBA in OLTP and DSS environments? Your invaluable viewpoints in this regard is most welcome.
Thanks and Regards,
Ranganath
WARNING: The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorised. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message in
error. Thank you.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
<http://www.orafaq.net>
--
Author: Krishnaswamy, Ranganath
INET: Ranganath.Krishnaswamy_at_blr.hpsglobal.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
<http://www.fatcity.com>
San Diego, California -- Mailing list and web hosting services
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
<http://www.fatcity.com>
San Diego, California -- Mailing list and web hosting services
The information contained in this communication, including attachments, is strictly confidential and for the intended use of the addressee only; it may also contain proprietary, price sensitive, or legally privileged information. Notice is hereby given that any disclosure, distribution, dissemination, use, or copying of the information by anyone other than the intended recipient is strictly prohibited and may be illegal. If you have received this communication in error, please notify the sender immediately by reply e-mail, delete this communication, and destroy all copies.
Corporate Systems, Inc. has taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses. We specifically disclaim all liability and will accept no responsibility for any damage sustained as a result of software viruses and advise you to carry out your own virus checks before opening any attachment.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: April Wells
INET: awells_at_csedge.com
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: ListGuru_at_fatcity.com (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). Received on Wed Jan 29 2003 - 04:48:41 CST
 |
 |