RE: RE: Frustration with Toad Debugger

From: Jamadagni, Rajendra <Rajendra.Jamadagni_at_espn.com>
Date: Wed, 25 Feb 2004 08:53:20 -0500
Message-ID: <A186CBDC8B1D61438BC50F1A77E91F735B6938@xchgbrsm1.corp.espn.pvt>

I agree, (though I am nowhere near that 12 year experience mark).

Another problem I have seen is in development databases, system privileges and roles are sometimes excessive, like 'select any table' or such. A lot of them develop code without regard to the privilege set on the production (which of course is much more restricted). Then when the stuff starts failing, it is suddenly someone else's fault.

This is not developer bashing, it is just to point out *why* sometimes DBAs ask more (or intrusive) questions when extra privs are requested on development systems. I have not yet seen a legitimate request being denied.

To workaround this and still help development do their job, I wrote a bunch of code for development and support personnel as a package and granted them execute on it. The package is owned by SYSTEM (I know !!).

This let's them do (across all RAC instances)

checks the locks in the db
list sessions
find sessions for a user
If a session seems slow, they can create a session report (current sql, locks, waits, stats etc)

in addition following is available in all non-production databases

5. compile invalid code in non-production databases
6. Get listing of invalid code (much getter than what oracle provides)
7. create/drop public synonyms
8. change user passwords (except schema and dba accounts)
9. grant/revoke single roles to/from single user

10. grant/revoke multiple roles to/from multiple users 11. show table, associated index, associated indexed columns stats in a tree like structure ...

This helps us (the DBAs) in the sense that everyone is using the same code, so we don't have to ask the question "Where did you get that script??" and as we own it, we don't have to grant them excessive privs except for execute on the package.

Raj

Rajendra dot Jamadagni at nospamespn dot com All Views expressed in this email are strictly personal. select standard_disclaimer from company_requirements; QOTD: Any clod can have facts, having an opinion is an art !

-----Original Message-----

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Rachel Carmichael Sent: Wednesday, February 25, 2004 8:18 AM To: oracle-l_at_freelists.org
Subject: RE: RE: Frustration with Toad Debugger

the problem with "it's just development" and allowing developers to do anything in that environment is that they can and will and DO start coding based on objects they have created -- and those objects may or may not conform to good practices within a production environment. Once the code is written and tested against garbage, it's almost impossible to get them to change it to the way it should be done.

And, I have NEVER, in 12+ years as a DBA, found that a corrupted database, even if caused by a developer, is not my responsibility to fix, and fix fast and "how could you let this happen"

I am more than willing to allow my developers restricted access to the database. I even let them create objects, within their own schemas. But NOT within the copy of the production schema.

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html


-----------------------------------------------------------------

Received on Wed Feb 25 2004 - 07:50:19 CST