(The Curious Case of… used to be part of our bi-weekly newsletter but we decided to make it a regular blog post instead so it can sometimes be more frequent. It covers something interesting one of us encountered when working with a client, doing some testing, or were asked in a random question from the community.)
Erin worked with a client recently who was experiencing very long failover times with a large ad hoc workload and needed to understand why. By very long, we’re talking more than 30 minutes for an availability group failover, and they’d tested failovers under load before and never had it take more than a few minutes. They wondered if their workload had changed or there was some configuration setting that was off because they’d also recently upgraded.
Obviously Erin didn’t want them to do another failover and take more downtime and luckily they have a process in place to capture wait statistics all the time so Erin could see what waits happened while the failover was in progress. One stood out to her right away: QDS_LOADDB.
The QDS_LOADDB wait happens when a database is bring brought online, Query Store is enabled, and the Query Store data is being loaded from disk. No queries can execute until that data has finished loading. In this case, the client had enabled Query Store after upgrading and with their large workload of ad hoc queries, there was 100GB of Query Store data to load. That was the cause of the long failover time and they didn’t realize that Query Store has this behavior.
Luckily there is a workaround other than disabling Query Store. You can enable documented trace flag 7752 which makes the Query Store data load asynchronous with the database startup. This means that queries can run before the data load completes, but Query Store won’t capture any information about them (Query Store is essentially read-only until the data load completes). Erin discusses this and other Query Store trace flags in her post here, and in general about Query Store settings and data size in this post.
Bottom line: make sure you understand how a feature changes behavior before enabling it, and HA/DR testing should be performed regularly to catch unexpected behaviors such as this.