You have an Azure SQL Managed Instance that is experiencing performance degradation. You suspect a query is causing excessive blocking. You need to identify the blocking chain and the resource holding the lock. Which DMV should you query?
These DMVs together provide lock information and waiting tasks to identify blocking.
Why this answer
To identify the blocking chain and the specific resource holding the lock, you need to combine lock metadata with wait information. sys.dm_tran_locks shows current locks and their resource types (e.g., RID, KEY, PAGE, OBJECT), while sys.dm_os_waiting_tasks reveals which sessions are waiting on those locks and the blocking session ID. Together, these DMVs allow you to trace the blocking chain from the blocked session back to the blocker and pinpoint the exact resource causing contention.
Exam trap
The trap here is that candidates often pick sys.dm_exec_requests (Option A) because it shows wait_type and blocking_session_id, but it lacks the granular lock resource information (e.g., RID, KEY) that sys.dm_tran_locks provides, which is essential for identifying the exact resource holding the lock.
How to eliminate wrong answers
Option A is wrong because sys.dm_exec_requests shows currently executing requests and their wait types, but it does not provide detailed lock resource information (e.g., which specific row or key is locked) needed to identify the exact resource holding the lock. Option C is wrong because sys.dm_exec_query_stats aggregates query performance metrics (CPU, I/O, duration) over time and does not contain real-time lock or blocking chain data. Option D is wrong because sys.dm_tran_active_snapshot_database_transactions is specific to snapshot isolation level transactions and tracks version store usage, not blocking chains or lock resources.