-latch sleeps skyrocketed for library cache, shared pool, and row cache
objects with many having at least 4 sleeps. The 'dlm resource hash list '
latch had about the same number of sleeps, but the number of gets
increased by ~x10.
For the 10046 traces (taken a few weeks ago) I had a chance to look
through a few of the multitude before they were deleted.=20
-Lots of latch free:library cache, shared pool, and row cache object
waits. The library cache wait always pointed to the same address (the
same 1 of 5 children). -Increase in library cache lock and library cache
pin. These are pointing to the same handle address. Also an increase in
the library cache pin instance lock enqueue.
My working model is that the latch free (library cache) waits are a
symptom. Something is holding a library cache pin/lock and another
process wants it. Get a latch. Someone else wants it. Latch contention.
Latch contention builds. Spin, sleep, another process, more latch
contention, ... Take a systemstate dump to see what is happening.=20
