MSQL_DQ is recorded while a task waits for a distributed query operation to finish, a query spanning a linked server or another OLE DB data source. The wait runs for the duration of the remote call, and the engine also uses it to detect potential MARS application deadlocks in distributed scenarios.
Together with OLEDB, it is where linked server pain shows up in the wait stats: OLEDB for the provider calls themselves, MSQL_DQ for distributed query operations awaiting completion.
Is It a Problem?
It is honest accounting of remote latency, so its importance equals how much your workload depends on distributed queries. Sustained high MSQL_DQ means sessions are spending real time waiting on remote systems, and users feel that directly. The fix is rarely local: the time is being spent on the remote server’s execution, the network between, or in moving too many rows across the link.
The classic worst case is a distributed query that cannot push its predicates remote, dragging a whole remote table across the wire to filter locally.
Common Causes
- Slow query execution on the remote SQL Server or OLE DB source.
- Remote queries that fail to push filters and joins to the source (“remote scan” plans).
- Network latency or bandwidth between the servers.
- MARS-heavy applications multiplying concurrent distributed calls.
What To Do
- Identify the distributed queries via
sys.dm_exec_requestsduring the wait, and get their plans; look for remote query operators pulling large rowsets. - Push work to the source:
OPENQUERYwith the full filtered query, or restructure so joins happen remotely. - Performance-tune the remote side as its own problem; the local wait is just the bill.
- For recurring pulls, stage remote data locally on a schedule instead of querying live per request.
How To See It
Rank it against everything else with Get-WaitStatistics, read together with OLEDB and your linked server inventory.
Part of the SQL Server Wait Types Library.
Related deep dive: ASYNC_NETWORK_IO Wait Type.
Leave a Reply