Re: V$ tables

There are problems with DBA_ views, you can get the passwords easily from dba_users, you can look the password in db links easily from dba_db_links, you can spool data model from other schemas easily from dba_tables, you can see audit from dba_audit* views etc etc etc. Its about how do you want to secure your database, otherwise these user_, all_ dba_ views would not be seperated

Data in data dictionary can get or not very sensitive depending on your environments

Regarding v$ views agree that some of them should be avaibale to the developers but I would not say all of them neither.....

May be we will agree when someday someone's database is hacked :-)

Daniel Morgan <dmorgan_at_exesolutions.com> wrote in message news:<3D0A137B.F00D3EC9_at_exesolutions.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
>
> Please allow me to ask the question in a different way. What possible
> justification is there for not giving developers access to all v_$
> views? And for that matter all dba_ views too?
>
> Can they change anything?
> Can they do any damage?
> Is there a negative side to having developers that know and care about
> how their work will impact production?
>
> Give them the whole darned thing and be glad they asked.
>
> The only reason I have ever felt for DBAs denying access to the data
> dictionary views (other than ego) is that they are so insecure with
> their own skills that they are afraid someone might see that they
> haven't been doing their job well.
>
> Daniel Morgan
Received on Sat Jun 15 2002 - 09:26:43 CDT