Re: V$ tables

I agree with both Daniel and Sybrand.

Allow developers to access v$ and dictionary views. Let them learn about how to trace sessions, identify locks, identify bad SQL etc. They'd be grateful. However, enforce a rule about not using v$ views in application code.

Hemant
"Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message news:l89kgukkr0abc7ovgi5kt4jaq0r03v96en_at_4ax.com...
> On 14 Jun 2002 05:41:15 -0700, 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?
> >
> >Thanks,
> >
> >CE
>
>
> The only reason not to do this is they are subject to change with
> every new release and you might hit yourself, especially if you are
> planning to use those views in your own pl/sql procedures, which will
> create a myriad of grants that are difficult to maintain.
> There used to be a MONITORER role that covered the most important
> views.
> As long as you don't use v$ views where regular functionality is
> available now (I'm especially referring to the SYS_CONTEXT function
> which seems to replace direct use of v$session) I don't see any
> problem.
> Most developers though, wouldn't know how to interpret the data.
>
> Regards
>
>
>
> Sybrand Bakker, Senior Oracle DBA
>
> To reply remove -verwijderdit from my e-mail address
Received on Sat Jun 15 2002 - 22:09:03 CDT