Distributed queries within SQL Server are queries across multiple data sources, usually through an OLEDB connection such as a linked server or OPENROWSET. Multiple Active Result Sets (MARS) also use distributed queries and this wait statistic is part of the deadlock monitoring within  MARS.

The wait runs from the moment the distributed query starts until the distributed query finishes. The wait is completely external to your SQL Server instance and is dependent on the other resource. You have to look at the external resources to understand why the call is taking a long time.


  • Check the affected queries and the Top queries table for queries making calls to linked servers. Determine if these queries can be modified to pass filtering on to the remote resource through OPENROWSET, to reduce processing time and data transfer. For example, avoid operations that join unfiltered data across servers.

  • Ensure the remote login has sufficient permissions to read remote table and index statistics, in order to generate appropriate execution plans. See Other guidelines in Guidelines for using distributed queries (MSDN).

  • Check that the remote resource of a linked server or OPENROWSET is not suffering from some type of bottleneck caused by the query, such as bad or missing indexes or inappropriate T-SQL code.

Investigating the remote resource

Since this wait type is indicating a wait on an external resource, you may only be able to address the issue at that resource's location. You may consider avoiding using the external resources in future.

Didn't find what you were looking for?