| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.misc -> Re: -- [Q] What are *your* dba rules?
I have to agree with Kevin here. I also want to add that you'll probably
need some sort of commitment from management. If management doesn't
commit to "DBAs are the only ones to create databases" then developers
will continue to create databases and you won't be able to stop them
from doing so. Maybe you also want to set up some sort of configuration
management board. I'm not a big fan of them, but they do serve a
purpose.
HTH,
Brian
Kevin A Lewis wrote:
>
> 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
> >
> >
--
 |
 |