But just "desc v$access" caused so notable contention is also a common situation? I even can't catch "latch free" wait events from v$session_wait when I run "desc v$access" in our database, we just have 200 connections. On 2/28/06, Steve Adams <steve.adams@xxxxxxxxxxxx> wrote: > > Hello Syed, > > Any access to V$ACCESS on an instance with 1000+ connections creates at > least short term contention for the library cache latches. That is not a > bug. It is a consequence of all the work that is needed to instantiate > the view. With your system already suffering contention for another > latch, it is not strange that any reference to V$ACCESS would induce > severe library cache latch contention. In short, I don't think that this > is a bug. > > @ Regards, > @ Steve Adams > @ http://www.ixora.com.au/ - For DBAs > @ http://www.christianity.net.au/ - For all > > > The Human Fly wrote: > > Hello list, > > > > We have faced a very very strange problem when accessing or desc > v$access table. > > > > Database : Oracle 9i Rel.2 (9205) > > OS : AIX 5.3 JFS2 Filesystem. > > CPU = 30+ > > No. Connections = 1000+ > > > > We are facing problem with latch free (cache buffer chains), when the > > problem occurs, cpu becomes 0% ideal and we kill some process from > > which transaction are coming. > > > > I just desc v$access from the sql prompt, and strangly, all the > > session are started waiting on 'latch free' and this time its was > > library cache and when I kill the session which was desc v$access, > > then, everything comes normal. > > > > It was not just an accident, I can still reproduce the same error. > > Whatever action I do on v$access, this is causing. If this was a bug, > > we have same OS server, same oracle version for another database, > > where this doesn't happens. The only differene between these two > > databases are just no. of cpus. > > > > It is really drawing me crazy. Does anyone has experience the same? > > > > -- > > Best Regards, > > Syed Jaffar Hussain > [snip] > -- > //www.freelists.org/webpage/oracle-l > > > -- Kamus <kamusis@xxxxxxxxx> Oracle8i & 9i Certified DBA from China