QDS_LOADDB is recorded while Query Store loads its data for a database during that database’s startup, after instance restarts, failovers, crash recovery, or the database coming back online. Here is the part that bites: by default (before SQL Server 2019), that load is synchronous, and queries cannot run against the database until it finishes. The more Query Store data, the longer the block.
A big Query Store can quietly add seconds or minutes to your effective failover time.
Is It a Problem?
For high-uptime systems, potentially yes, and it is a sneaky one: everything looks recovered, but sessions stall on QDS_LOADDB while a multi-gigabyte Query Store reads in. On SQL Server 2016 and 2017, trace flag 7752 switches the load to asynchronous so queries run immediately (Query Store starts capturing once loaded); SQL Server 2019 onward made async load the default, retiring the problem for current versions.
If failovers feel slower than recovery times explain, check this wait and your Query Store sizes.
Common Causes
- Large Query Store data sets loading synchronously at database startup on 2016/2017 without TF 7752.
- Frequent failovers multiplying how often the load cost is paid.
- Generous
MAX_STORAGE_SIZE_MBsettings accumulating years of query history.
What To Do
- On SQL Server 2016/2017: enable trace flag 7752 as a startup flag if failover time matters. On 2019+, confirm you are simply current; the default is async.
- Right-size Query Store: cap
MAX_STORAGE_SIZE_MBsensibly and let cleanup policies trim stale history; smaller stores load faster regardless of mode. - Measure it once: after a controlled failover, this wait’s duration tells you exactly what Query Store adds to database availability.
How To See It
Rank it against everything else with Get-WaitStatistics; it clusters entirely around database startup events.
Part of the SQL Server Wait Types Library.
Related deep dive: IO_COMPLETION Wait Type.
Leave a Reply