Re: V$ tables

In article <db479d88.0206140441.584fe727_at_posting.google.com>,  Charlie3101_at_hotmail.com (Charlie Edwards) wrote:

> 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?

OPINION ALERT!!! First, realize that the V$ views are just that: VIEWS. They are, for the most part, virtual. That is to say, they exist only once an instance has been started, and remain only as long as the instance is running. With that in mind, I have no problem granting SELECT on these views to developers, because as long as they aren't able to modify any values, I can't see the harm. Personally, I'd be more impressed with a developer who is concerned about the performance of his code than I would be a developer who isn't. ;-)

Or, as one of my first Oracle instructors used to say in class, if you attempt to modify values in these views, your very next command should be

CREATE RESUME IMMMEDIATE;

-- 
The underscore character does not belong in my address. You know the drill...
***
Anyone sufficiently smart enough to configure and use USEnet for research should
be smart enough to Read The Freakin' Documentation!