OLEDB indicates SQL Server is waiting for an OLE DB provider call to return. This usually means linked server access and distributed queries, but the same interface is used internally, so the wait has a famous false positive built in.
The false positive first: DBCC CHECKDB and its siblings generate OLEDB waits, because the DBCC code consumes its internal data through an OLE DB rowset. A server that runs integrity checks will bank large amounts of this wait with no linked server in sight. Some monitoring tools that poll DMVs frequently add to it too.
Is It a Problem?
Check the timing before anything else. OLEDB accumulated during your DBCC CHECKDB window is the integrity check working, not a bottleneck. Outside that window, sustained OLEDB means sessions are genuinely blocked on external provider calls, and because these waits happen mid-query, users feel them directly when a remote source is slow or unstable.
Common Causes
- DBCC CHECKDB and related commands consuming data through the internal OLE DB rowset.
- Linked server queries to slow or overloaded remote systems.
- Network latency or intermittent connectivity between SQL Server and provider endpoints.
- Large result sets pulled across provider boundaries, or remote queries that cannot push their filters to the source.
What To Do
- Rule DBCC activity in or out by correlating the wait’s growth with your integrity check schedule.
- For genuine linked server pain, find the calling queries (
sys.dm_exec_requestsfiltered to this wait) and see which endpoint they target. - Push filters and aggregation to the remote side (
OPENQUERYor REMOTE JOIN hints where appropriate) so less data crosses the link. - Cache or stage remote data locally for recurring workloads, and take endpoint-side slowness to the team that owns the remote system.
How To See It
Rank it with Get-WaitStatistics. If OLEDB is high, correlate with linked server usage and remote query timings.
Part of the SQL Server Wait Types Library.
Related deep dive: ASYNC_NETWORK_IO.
Leave a Reply