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
- RE: Schema updates - roles
- From: Kerber, Andrew W.
- RE: Schema updates - roles