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