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

I appreciate all you say.

However can I throw in another slant on the problem.

You refer continually to procedures, could it be that what is really required is the personal touch. Talk regularly and frequently to the programmers to aim at cooperatively solve their development problems.

Surely at the end of the day DBAs are there to enable the task the developers are doing, not hinder it. This will be the way developers will see it if you cannot get them to think about the broader issues DBAs have to face.

I speak as an ex-developer, now DBA. So you might think me biased. But give the extra openness of comunication approach at least some thought.

Regards and best of luck
--
Kevin A Lewis (BOCM PAULS LTD) - Animal Feed Manufacturer - Ipswich United Kingdom)

                        <Kevin_A_Lewis_at_Hotmail.com>

The views expressed herein by the author of this document are not necessarily those of BOCM PAULS Ltd. crumedgeon <zimsbait_at_hotmail.com> wrote in message news:87lfbf$ic8$1_at_nntp9.atl.mindspring.net...
> 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 Mon Feb 07 2000 - 04:26:45 CST