RE: Schema updates - roles
- From: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxxxxx>
- To: <Andrew.Kerber@xxxxxxx>
- Date: Thu, 29 Mar 2007 09:17:37 -0400
I think what it really comes down to is, the culture and history of that
particular shop. Ultimately, it really doesn't matter much, especially if you
have a robust change control procedure in place.
Define a process and follow it. If that means developers put changes into
prod, then so be it. Nobody is infallible, not even a DBA! ;-) (Did I really
say that out loud?? ;-))
Seriously, though, anytime a change is introduced to a production environment,
there is a risk.
As for my personal experience, DBAs control all aspects of production,
including rolling changes out. At least in my company, I think the main reason
for that is that the DBA is considered the "the buck stops here" position when
it comes to keeping production up and running.
Just my two bits,
-Mark
-Mark
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Kerber, Andrew W.
Sent: Thu 3/29/2007 8:22 AM
To: Mark.Brady@xxxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: Schema updates - roles
The simplest reason is that you don't want to give developers the necessary
privileges to create objects outside of their personal schemas, and developers
typically don't have personal schemas in production. The other answer is that
in most places, the Unix admins and the Wintel admins are the people who put
the changes in, not developers.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Brady, Mark
Sent: Wednesday, March 28, 2007 1:24 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Schema updates - roles
I've never understood why this is so:
Our Unix Admins don't execute our changes to our Unix apps
Our Wintel Admins don't execute our changes to our Wintel apps
Our Database Admins insist they execute our changes to our database apps.
Please no knee-jerk reactions. Everyone thinks/feels their area is special,
that no one could live without them. Before you answer with "database servers
are special because _____________" think twice.
If developers promote code to production web servers, production app servers,
production Unix servers, why not production database servers?
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Dennis Williams
Sent: Wednesday, March 28, 2007 10:36 AM
To: thump@xxxxxxxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Schema updates - roles
One final argument for separating duties. Today your developers may indeed
be top-notch. However, tomorrow a big project may be started and many
contractors hired to develop on the new project. If you have a history of
developers updating production, it may be difficult to clamp down on some
cowboy developer before they trash your production.
>>> This e-mail and any attachments are confidential, may contain legal,
professional or other privileged information, and are intended solely for the
addressee. If you are not the intended recipient, do not use the information
in this e-mail in any way, delete this e-mail and notify the sender. CEG-IP2
------------------------------------------------------------------------------
NOTICE: This electronic mail message and any attached files are confidential.
The information is exclusively for the use of the individual or entity intended
as the recipient. If you are not the intended recipient, any use, copying,
printing, reviewing, retention, disclosure, distribution or forwarding of the
message or any attached file is not authorized and is strictly prohibited. If
you have received this electronic mail message in error, please advise the
sender by reply electronic mail immediately and permanently delete the original
transmission, any attachments and any copies of this message from your computer
system. Thank you.
==============================================================================
--
http://www.freelists.org/webpage/oracle-l
- References:
- RE: Schema updates - roles
- From: Kerber, Andrew W.
Other related posts:
- » Schema updates - roles
- » Re: Schema updates - roles
- » RE: Schema updates - roles
- » RE: Schema updates - roles
- » RE: Schema updates - roles
- » Re: Schema updates - roles
- RE: Schema updates - roles
- From: Kerber, Andrew W.