Question

I’m trying to investigate a performance problem at a client site. I’ve looked through the blocking data for the site and come up with a couple of SPIDs to investigate over a time period. I’ve then looked at the data from sys.syslockinfo and found that one of the problem SPIDs has a WAIT on an Intent Exclusive Table lock. I tried to find the blocking SPID, but I can’t find any GRANT locks before the WAIT in a time period that seems reasonable.

Is there any reason that it might have to WAIT even through no other session had the table locked? Any known bugs around sys.syslockinfo?

I’ll have to check with the way that the locking information is grabbed – it may be an every 15 seconds kind of thing, in which case maybe the GRANT simply wasn’t captured. In the meantime, if anyone knows of another potential cause I’d greatly appreciate your insight.

Thanks!

Answer 1

When you say there is no corresponding GRANT, what exactly are you looking at? An IX on a resource would conflict with any S, U or X lock obtained on the same resource. So if anyone has a S lock on the table, it would conflict with the IX. A typical example would be a request trying to update data and requesting a IX lock on the table to start the lock hierarchy (IX table->IX page->X key), and conflicting with a scan that did a lock escalation and obtained a full S lock on the table.

When a request is blocked on waiting this IX lock, look at the blocking_session_id in sys.dm_exec_requests and then check what locks are held by that session in sys.dm_tran_locks.