Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Managing developers recommendations

RE: Managing developers recommendations

From: Jesse, Rich <Rich.Jesse_at_quadtechworld.com>
Date: Wed, 12 Oct 2005 16:50:00 -0500
Message-ID: <FB5D3CCFCECC2948B5DCF4CABDBE66971FFC63@QTEX1.qg.com>


Paul,

I'm not sure how you use TOAD, but it requires no special or excessive privs. Of course this depends on how it's implemented, but that would be no different from any other Oracle development tool, including SQL*Plus. If specific users require access to specific objects the security can be handled via standard Oracle GRANTs to the user or to a role or by creating a package or procedure to handle it (e.g. perhaps to create new objects in an app schema).

Our current environment has the devs logging into the app schema to do their procedures. I use Oracle auditing and some cron and DBMS_JOBs to report on development being done as well as any problems.

My $.02,
Rich

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Paul Drake Sent: Wednesday, October 12, 2005 4:21 PM To: fred_fred_1_at_hotmail.com
Cc: oracle-l_at_freelists.org
Subject: Re: Managing developers recommendations

On 10/12/05, Fred Smith <fred_fred_1_at_hotmail.com> wrote: Hi all,
  My developers (who currently just use SQL Plus) now are wanting to use Quest TOAD. From what I've used it in the past, it is far too powerful for
developers. (I don't trust my developers with creating tablespaces, etc.).
Plus, I've found that TOAD is far too easy to delete objects, etc.   Any recommendations, etc would greatly be appreciated! -Fred S.

Fred,

Concerning TOAD as a specific developer tool, it does require (IMHO) excessive permissions to be effective. Your developers will want to have dictionary privileges, as well as "execute any procedure" and "alter any procedure" to even view source code via the PL/SQL editor.

Grant them that via a role in development.

Put up DDL triggers to block them actually altering the app schema for certain operations.
Do not under any circumstances allow them into production with any tool. (or throw out the qualifier that you're not responsible for what they do in production if they are allowed in ... other than you'll do your best to recover the database in a media recovery frame of reference).

That leaves the battle in QA.
Think DMZ between North and South Korea. Think "unwinable battle".
After you lose the battle for sys_privs in QA, use DDL triggers to block changes being made in QA.

hth.

Paul

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 12 2005 - 16:52:17 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US