RE: Managing developers recommendations
- From: "Jesse, Rich" <Rich.Jesse@xxxxxxxxxxxxxxxxx>
- Date: Wed, 12 Oct 2005 16:50:00 -0500
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Paul Drake
Sent: Wednesday, October 12, 2005 4:21 PM
To: fred_fred_1@xxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Managing developers recommendations
On 10/12/05, Fred Smith <fred_fred_1@xxxxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
