Re: V$ tables

I agree with what's been said by Daniel: why not? And I see the point of Sybrand: they are not supposed to use the V$ or DBA views in the application.
So: create a read only account in the database with "select any table" privilege so they can use that one to look. I even think the developers should have such an account in production.

In the Dutch magazine "Optimize" Anjo Kolk was interviewed and he has a very good vision.
DBA's should really get involved with the development of applications. The focus should move from "how can I optimize this statement" to "why is the statement here?". Or: most performance gain is in writing good applications. Focus on application-efficiency. When you as DBA get the blaim for bad performance anyway, better get involved where the problems are created.

And then it works both ways: the DBA can improve the application when it is the easiest: from the beginning of the development, he can watch if V$ views are used properly and can explain developers the meaning of columns. Both disciplines should learn from each other because each has knowledge of only part of the issues involved.

Charlie Edwards <Charlie3101_at_hotmail.com> schreef in berichtnieuws db479d88.0206140441.584fe727_at_posting.google.com...
| Hi,
|
| I would be grateful for a DBA's opinion on this ...
| Which V$ tables should be available to developers as a matter of
| course?
|
| v$process, v$session, v$lock, v$sqlarea, v$sqltext, v$locked_object,
| v$session_longops ...
|
| Any others?
|
| For that matter, is there any reason why developers should not have
| acess to ALL V$ tables in a development environment?
|
| Thanks,
|
| CE
Received on Fri Jun 14 2002 - 14:07:55 CDT