-CPU time almost unchanged=20
-a huge change in the Total Wait Time (cs) for the following events (the
number of waits were all within an order of 2 of each other except for la=
tch
free which jumped from 200 to 150,000).
-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 increas=
ed
by ~x10.
For the 10046 traces (taken a few weeks ago) I had a chance to look throu=
gh
a few of the multitude before they were deleted.=20
-Lots of latch free:library cache, shared pool, and row cache object wait=
s.
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 instan=
ce
lock enqueue.
My working model is that the latch free (library cache) waits are a sympt=
om.
Something is holding a library cache pin/lock and another process wants i=
t.
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
