Re: process M000 holds library cache lock

> 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