In a Fabric environment where a report is running much longer than usual, which DMV should you query to identify the currently executing requests causing the delay?

In a Fabric environment where a report is running much longer than usual, which DMV should you query to identify the currently executing requests causing the delay?

• A. sys.dm_exec_requests
• B. sys.dm_exec_sessions
• C. sys.dm_exec_query_stats
• D. sys.dm_exec_connections

Answer: (A)

When diagnosing a long-running report, you need visibility into what is actively executing right now. The appropriate DMV shows every request currently in progress, including the session, status, wait type, and any blocking information. It also provides the sql_handle you can use to fetch the exact SQL text, helping you identify the specific statement causing the delay and whether it’s waiting on a lock or another resource. This real-time view is what lets you pinpoint the current operation driving the slowdown. Other DMVs serve different purposes: sessions lists connected users but not the exact running commands; connections shows connection-level details; query_stats stores historical aggregates for completed or cached queries rather than what’s actively running. So for finding the currently executing requests causing the delay, the active-requests view is the best fit.

When diagnosing a long-running report, you need visibility into what is actively executing right now. The appropriate DMV shows every request currently in progress, including the session, status, wait type, and any blocking information. It also provides the sql_handle you can use to fetch the exact SQL text, helping you identify the specific statement causing the delay and whether it’s waiting on a lock or another resource. This real-time view is what lets you pinpoint the current operation driving the slowdown.

Other DMVs serve different purposes: sessions lists connected users but not the exact running commands; connections shows connection-level details; query_stats stores historical aggregates for completed or cached queries rather than what’s actively running. So for finding the currently executing requests causing the delay, the active-requests view is the best fit.