Re: process M000 holds library cache lock

Hi Remigiusz,

> as a summary for this post:
> we started with killing M000 and this went well, but the next run of
> M000 repeated the hold of library cache mutex (so we were again in the
> same position) - then the only option was to restart and with still
> decreasing performance we did it, which helped of course

I had a similar situation where the culprit turned out to be an application
that didn't use bind variables in a DB (10.1.0.5) that was setup for AMM. 
The end result over time was a 11G shared pool (with only a ~16GB buffer
cache) with some SQLs in excess of 250K similar entries in the library
cache.

The "quick" fix for me was to statically size the memory pools to manageable
proportions, as the app is 3rd party and still generating SQLs without
binds.  You may want to carefully investigate the contents of your library
cache.

GL!

Rich

--
http://www.freelists.org/webpage/oracle-l


Other related posts: