| Tune the code without autotrace+ dictionary - fed up with DBA advice (merged 3) [message #429639] |
Wed, 04 November 2009 21:18  |
Richard2009
Messages: 21
Registered: October 2009
Location: London
|
Junior Member |
|
|
Hi ,
Our DBAs are not providing access to view the explain using autotrace and select any dictionary access to development database for tuning the application. I believe most of the Oracle experts recommends even the oracle developer should have access to view explain and dictionary tables access such as v$sql , v$sqlare and so on as far as the development database is concerned. I have asked them the reason for N times and there were no response from their side.
Please share your expertise and guide me on how to talk those fungus DBAs. Any link or documentation on this would be much appreciated so that I can forward the same to my management.
|
|
|
|
|
|
| Re: Tune the code without autotrace+ dictionary - fed up with DBA advice (merged 3) [message #429792 is a reply to message #429644] |
Thu, 05 November 2009 16:48  |
 |
Kevin Meade
Messages: 2103
Registered: December 1999
Location: Connecticut USA
|
Senior Member |
|
|
Agreed, it is a development database, there should be few restrictions. My suggestion is to use your managment chain and start complaining. Make a case for why not having this access is causing problems for you.
Just remember, there may be legitimate security concerns you might have to address. But then again, these concerns are rarely related to the privilegs you get. They are usually related to data.
For example:
Are you test databases created by refreshing them from production data?
If so, do these database have what is known in the industry as PII (Personnally Identifiable Information (like Crediate Card numbers, SSNs, birthdatea/addresses/phone numbers))?
If so do you outsource?
What keeps your outsourced partners locally and overseas from ripping off this data and using it for nefarious purposes?
It is my experience that most companies do not really have a security group that manages database security correctly. They keep falling back to "credentials and privileges" as the answer when in fact controling these though important is really a mistake if this is the primary focus of your security. You get a false sense of saftey when in fact your data is at high risk.
Good luck, Kevin
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
