-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.
-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.
