Hi Simon,
I don't have direct access to the server (not a DBA anymore - but I play one from time to time :-)
I've got data collected by Jean-Paul Martin's asemon tool - the wait events from monProcessWaits look like this:
| waiting for memory or a buffer | 157 | 613,318 | 2,775,500 | wait for object to be returned to pool |
| waiting to output to the network | 251 | 1,543,226 | 846,400 | waiting for network send to complete |
| waiting to be scheduled | 214 | 388,484 | 210,600 | waiting on run queue after yield |
| waiting for memory or a buffer | 36 | 20,563 | 22,400 | waiting for MASS to finish writing before changing |
| waiting for a disk write to complete | 51 | 13,590 | 13,900 | waiting for last i/o on MASS to complete |
| waiting for a disk write to complete | 55 | 18,895 | 12,600 | wait for i/o to finish after writing last log page |
| waiting for a disk write to complete | 52 | 2,831 | 10,100 | waiting for i/o on MASS initated by another task |
| waiting for a disk read to complete | 29 | 1,512 | 8,000 | waiting for regular buffer read to complete |
| waiting to take a lock | 150 | 76 | 4,900 | waiting for a lock |
| waiting for a disk write to complete | 31 | 5,795 | 4,000 | waiting for buf write to complete before writing |
| waiting for a disk write to complete | 54 | 36 | 100 | waiting for write of the last log page to complete |
For the server (monSysWaits) it look like this for the same period (the first one is wait event 250, which is the usual set of SPIDs in recv sleep status, so can no doubt be discounted):
| waiting for input from the network | waiting for incoming network data | 1,313,535 | 125,480 | 10,468.08 |
| waiting to take a lock | waiting for a lock | 66,348 | 1,141 | 58,148.99 |
| waiting for memory or a buffer | wait for object to be returned to pool | 13,899 | 3,093,134 | 4.49 |
| waiting to be scheduled | waiting on run queue after yield | 12,821 | 5,488,920 | 2.34 |
| waiting for input from the network | waiting while allocating new client socket | 7,732 | 4,018 | 1,924.34 |
| waiting for a disk write to complete | waiting for last i/o on MASS to complete | 5,458 | 3,355,169 | 1.63 |
| waiting to output to the network | waiting for network send to complete | 5,201 | 2,356,781 | 2.21 |
| waiting to be scheduled | waiting on run queue after sleep | 2,517 | 19,125,580 | 0.13 |
| waiting for a disk write to complete | waiting for i/o on MASS initated by another task | 2,380 | 929,741 | 2.56 |
| waiting for a disk write to complete | wait for i/o to finish after writing last log page | 1,817 | 2,400,633 | 0.76 |
| waiting to output to the network | waiting for CTLIB event to complete | 994 | 102,165 | 9.73 |
| waiting for a disk read to complete | waiting for regular buffer read to complete | 923 | 1,266,616 | 0.73 |
| waiting for a disk write to complete | waiting for buf write to complete before writing | 582 | 388,386 | 1.50 |
| waiting for memory or a buffer | waiting for MASS to finish writing before changing | 423 | 385,630 | 1.10 |
I don't know if this can give more information - I guess the only thing I should add is that the process that generated all the 157 waits was doing quite a lot of SELECT statements for tracing purposes redirected to a disk file, but I don't really see how that could cause this behavior.
Thanks!
Michael