-- [Q] What are *your* dba rules?

Hello all,

I have been recently promoted to "enterprise d.b.a." in my organization. I have taken it upon myself
to create a set of guidelines (which are currently not in place :-( ) for "rules of engagement" for
myself and my team of dba's. Some of them are basic, others are special cases, but all need to be
documented and followed. I was wondering if anyone who has gone through this process before
could shed light on some areas they find in their shop that I may need to address. Here's an example
of what we are looking at:

A lot of dba's at my shop have the same complaint. Developers come into their office, many times
disgruntled. They complain of "the damn database is all messed up again, can you change these
init.ora params and restart the instance". (this is a development environment, of course) The database
has not been changed in weeks. This is usually the fault of the programmer not compiling this, or
another developer running that. (you get the point) I cannot stress enough to my team (some are jr
level) that *they* are the experts and if a developer needs something changed, they must document
the specific database problem (error numbers, log data (jdbc outputs etc)) before wasting time
on these issues. The programmers, of course, are insulted by this and have taken to creating their
own databases (a whole other beast to tackle) and cutting my staff out of the loop until it comes time
to fix problems they unknowingly (read: didn't know how to do) created (again, a time waster, and
another topic).

You can see the problems I am encountering. (And this is only the tip of my iceberg)

I was wondering how some of you each handle creating/enforcing such policies? I am sure you
all have kept in mind that it's not just technology we deal with, but also balancing "programmer
ego" with these procedures also.

Any suggestions from folks that have "been there- done that"?

tia
//
cr Received on Sun Feb 06 2000 - 21:48:16 CST