RE: Why an organization would need an enterprise DB team
- From: <Jay.Miller@xxxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 27 Mar 2007 15:52:26 -0400
The split can work, but it's tricky. IMO, the worst set up is where
there is no one with DBA knowledge working with the developers. We had
previous management that tried to enforce that, it ended up with me
giving advice and help under the table but a lot of bad design coming
through that I had no power to stop.
For the split to work, there must be strong communication at all times
between the operational and application DBAs (at which point why not
just have them in the same group?). We have just had this split and the
battle we're fighting is that we don't hear about anything until it's
ready to go into production. We get emails like, "Project X is ready to
go into production, please have the database ready for us tomorrow."
Our response is, "What is project X? What are the servers? Is there a
DR requirement? What is the size, what is the expected growth, and
incidentally the firewall ports aren't opened for us to access the
server so you're going to have to wait a lot longer than 'tomorrow'."
Jay Miller
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Phil Singer
Sent: Wednesday, March 21, 2007 9:11 PM
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Why an organization would need an enterprise DB team
EPA wrote:
> Hi guys,
>
> I guess I was not enough clear. The coming re-org wants to separate
the DBAs
> between 1) operational (backup, recovery, upgrade...) and 2)
application
> (logical design, physical design,...) and move the 2nd group to
application
> services team. This means they will report and follow AS
managers/directors.
> And I would like to proof and keep them in one group.
>
> I don't have any doubt about having DBA competency in development
team, what
> I am looking is the cons if we separate the team and pros if we keep
them
> together.
>
>
>
> Thanks again,
>
> Estifan Panosian
>
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.11/723 - Release Date:
3/15/2007
> 11:27 AM
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.12/724 - Release Date:
3/16/2007
> 12:12 PM
>
>
>
The company I work at does this (actually goes even further). I think
it's a bad idea, although I don't have any reasons that would make sense
to a management type.
The reason I don't like it is that it has led to the "central" DBAs (the
ones who doe the backup/recovery/operational tasks) becoming very
isolated from the actual applications, so they don't know the details of
how they are supposed to work. As a consequence, all Oracle Instances
have to be very plain vanilla (or else they won't know what is going
on).
Meanwhile, the application DBAs are unable to have the DBA role (since
those tasks are reserved for the real DBAs). So there is very little
experimentation going on. Sort of like Oracle evolution stopped with
release 7.3.4.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
