Dmitry, > > Am I right to think that I need to create a process to run the command on a > regular basis (every 5 secs?) to find what objects locks are waiting for? > > Yes. But we're still guessing in the dark, the reason of the slowdown could be > completely unrelated to the lock manager (e.g. bad plans, undesired access > to MON$ tables inside triggers, whatever else).
Here are some more recent results: LOCK_HEADER BLOCK Version: 145, Active owner: 0, Length: 67108864, Used: 22695696 Flags: 0x0001 Enqs: 232862988, Converts: 2119345, Rejects: 251137, Blocks: 2802169 Deadlock scans: 20, Deadlocks: 0, Scan interval: 10 Acquires: 393659923, Acquire blocks: 185848452, Spin count: 0 Mutex wait: 47.2% Hash slots: 90001, Hash lengths (min/avg/max): 0/ 0/ 7 Remove node: 0, Insert queue: 0, Insert prior: 0 Owners (498): forward: 732776, backward: 22433480 Free owners (8): forward: 22510432, backward: 12606880 Free locks (3604): forward: 734616, backward: 5104832 Free requests (4539): forward: 19996544, backward: 11915160 Lock Ordering: Enabled The -o -w switches generated details such as: OWNER BLOCK 732776 Owner id: 114332029419524, type: 1, pending: 0 Process id: 26620 (Alive), thread id: 2348 Flags: 0x08 wake Requests (431): forward: 732888, backward: 10111616 Blocks: *empty* 732776 waits on nothing. Most of the entries show: Flags: 0x08 wake Oddly, all of the entries show: Blocks: *empty* I would have expected at least some of the entries to have values associated with "Blocks". What am I missing? Sean