SQL SERVER – Query Store Status for All the Databases

One of my clients who is running one of the most popular web hosting services online reached out to me to help them with the Comprehensive Database Performance Health Check. Today we will discuss how I was able to help them with a query script of Query Store Status for All the Databases.

SQL SERVER - Query Store Status for All the Databases querystorestatus0-800x344

Slow Intermediate Performance

My client has over 1000s of small databases on a very powerful server. They have been running fine for over a year but recently they started to face sudden slowdown even during when their server is not busy. After doing health check we figured out the issue was with one particular database which was just too busy running dynamic query is creating problems for us. We started with that database and eventually found nearly 100s of similar database which recently started to show the symptoms of slow performance.

What Changed? – Query Store Status

As the performance problems were recent, I asked what has been changed in recent times on their server and I learned that for a few of the databases they have recently turned on Query Store. Here is the query which I ran to find out Query Store Status for All the Databases.

SELECT name, database_id, is_query_store_on
FROM sys.databases

SQL SERVER - Query Store Status for All the Databases querystorestatus

When we looked at the result it was clear that all the 100+ databases where they started to recently face performance troubles had query stored enabled on it. We disabled query store for all the databases by running following query one at a time for the databases.

USE [master]

After we turned off the query store, the server performance was once again restored. We did a few more tests on the server and determined that if we want to enable a query store for over 100+ databases we needed more powerful servers and also have to tune our few things during Comprehensive Database Performance Health Check.

After Server Upgrade

Yesterday my client performed the server upgrade to better hardware. As we had more resources available for our system, we decided to enable Query Store for the few of our selected database. However, this time instead of enabling it for 100s of the databases, we decided that we will enable one at a time for our most important databases.

Note: Please do not get the impression that the Query Store is bad or leads to poor performance for the system. Just like any other feature when it is enabled it also takes a part of the resource from your system and if your system is not capable to handle an additional load this feature can negatively impact the performance. Always do the capacity analysis of your system before enabling any feature on the server.

Reference: Pinal Dave (http://blog.SQLAuthority.com)

Query Store, SQL DMV, SQL Server
Previous Post
SQL SERVER – Query for CPU Pressure
Next Post
SQL SERVER – Stress Testing with oStress – Load Testing

Related Posts

4 Comments. Leave new

  • Hi Pinal,
    I can confirm that Query Store might have some issues. One of our customers has their database servers in a clustered environment (1 primary and 1 secondary SQL Server 2016 Enterprise Edition – Cumulative Update 4), and all was working well – until the Query Store was turned on.
    When Query Store was enabled for one of the databases, the users experienced a lot of hang situations and blocking.
    After some investigation, we found that the Query Store for 2016 and 2017 has a bug which can block the truncation of the transaction log: https://support.microsoft.com/en-us/help/4461562/transactions-and-log-truncation-may-be-blocked-when-using-query-store

    So, despite that Query Store should be better, and that SQL Server Profiler is deprecated – I actually prefer the Profiler. There are no such bugs there. :)

  • Albertina Geller
    April 24, 2020 1:07 pm

    Thank you for the heads up! That bug could cause a lot of issues.

  • Query Store needed time for issues to surface so being as current as you can should make a difference. The settings make a big difference too. See what Erin Stellato (SQLSkills) says to get these right

  • Bear in mins that that bug was fixed 8 SQL releases ago. We did have that but upgraded to fix it.


Leave a Reply