Azure SQL db/dw series (11) -- re understanding the query store (4) -- Query store maintenance

This paper belongs to Azure SQL DB/DW series
Last article ：Azure SQL DB/DW series （10）—— Reunderstanding Query Store（3）—— Configure query storage
After the function is turned on , Of course, it needs to be maintained and monitored , In this paper, Query Store The maintenance of the .

brief introduction

   When we use Query Store In the process of , There will be many problems , such as Query Store The state of , It may be caused by some reasons, such as the space is full READ_WRITE become READ_ONLY even to the extent that ERROR. This is the time to understand what happened . Then fix it .
   In addition, you also need to monitor the space utilization , So as to judge whether the collection and storage interval is reasonable .
   There is also the success of plan enforcement .
   Finally, clean it regularly .

Countermeasures

Monitoring status

   First , maintain Query Store To understand its current status , You can use the following SQL Check it out. , Check the operation mode required for query storage （desired_state） And query the operation mode of storage （actual_state） Is it consistent ：

SELECT DB_NAME() database_name,
actual_state_desc,
desired_state_desc
FROM sys.database_query_store_options
WHERE desired_state_desc <> actual_state_desc

   If you need to check all databases , It can be used ：

DECLARE @SQL NVARCHAR(MAX) = N'';
SELECT @SQL += REPLACE(REPLACE(N'USE [{
    {DBName}}]; SELECT "{
    {DBName}}" database_name, actual_state_desc, desired_state_desc FROM {
    {DBName}}.sys.database_query_store_options WHERE desired_state_desc <> actual_state_desc '
,'{
    {DBName}}', [name])
,'"', "")
FROM sys.databases
WHERE is_query_store_on = 1
ORDER BY [name];
EXEC (@SQL);

   If found from READ_WRITE Turned into READ_ONLY, There may be many reasons for , These reasons are stored in the view readonly_reason Column , The descriptions are ：

• 1 - The database is in read-only mode
• 2 - The database is in single user mode
• 4 - The database is in emergency mode
• 8 - The database is a secondary copy （ Apply to Always On and Azure SQL Remote database replication ）. This value can only be effectively observed on a readable secondary copy
• 65536 - Query storage has reached MAX_STORAGE_SIZE_MB Option to set the size limit .
• 131072 - The number of different statements in the query store has reached the internal memory limit . Consider deleting unneeded queries or upgrading to a higher service tier , To allow the query store to be transferred to read-write mode . Applicable to ： Azure SQL database .
• 262144 - The size of items in memory waiting to be retained on disk has reached the internal memory limit . The query store will be temporarily in read-only mode , Until the items in memory remain on disk . Applicable to ： Azure SQL database .
• 524288 - The database has reached the disk size limit . The query store is part of the user database , therefore , If the database does not have more free space , This means that query storage cannot grow any further . Applicable to ： Azure SQL database .

   After finding out why , We should consider repairing , from 2017 Start , There may be potential performance problems in manual forced scheduling or automatic scheduling of regression corrections , In this case , Generally try to Query Store Set to OFF, Then change back to READ_WRITE. If it doesn't , Then try running sys.sp_query_store_consistency_check. And then empty Query Store The data in it . Here is a script to repair all databases ：

DECLARE @SQL AS NVARCHAR(MAX) = N'';

SELECT @SQL += REPLACE(
		N'USE [{
    {DBName}}] --Try Changing to READ_WRITE IF EXISTS (SELECT * FROM sys.database_query_store_options WHERE actual_state=3) BEGIN BEGIN TRY ALTER DATABASE [{
    {DBName}}] SET QUERY_STORE = OFF ALTER DATABASE [{
    {DBName}}] SET QUERY_STORE = READ_WRITE END TRY BEGIN CATCH SELECT ERROR_NUMBER() AS ErrorNumber ,ERROR_SEVERITY() AS ErrorSeverity ,ERROR_STATE() AS ErrorState ,ERROR_PROCEDURE() AS ErrorProcedure ,ERROR_LINE() AS ErrorLine ,ERROR_MESSAGE() AS ErrorMessage; END CATCH; END --Run sys.sp_query_store_consistency_check IF EXISTS (SELECT * FROM sys.database_query_store_options WHERE actual_state=3) BEGIN BEGIN TRY EXEC [{
    {DBName}}].sys.sp_query_store_consistency_check ALTER DATABASE [{
    {DBName}}] SET QUERY_STORE =ON ALTER DATABASE [{
    {DBName}}] SET QUERY_STORE (OPERATION_MODE = READ_WRITE) END TRY BEGIN CATCH SELECT ERROR_NUMBER() AS ErrorNumber ,ERROR_SEVERITY() AS ErrorSeverity ,ERROR_STATE() AS ErrorState ,ERROR_PROCEDURE() AS ErrorProcedure ,ERROR_LINE() AS ErrorLine ,ERROR_MESSAGE() AS ErrorMessage; END CATCH; END --Run purge Query Store IF EXISTS (SELECT * FROM sys.database_query_store_options WHERE actual_state=3) BEGIN BEGIN TRY ALTER DATABASE [{
    {DBName}}] SET QUERY_STORE CLEAR ALTER DATABASE [{
    {DBName}}] SET QUERY_STORE (OPERATION_MODE = READ_WRITE) END TRY BEGIN CATCH SELECT ERROR_NUMBER() AS ErrorNumber ,ERROR_SEVERITY() AS ErrorSeverity ,ERROR_STATE() AS ErrorState ,ERROR_PROCEDURE() AS ErrorProcedure ,ERROR_LINE() AS ErrorLine ,ERROR_MESSAGE() AS ErrorMessage END CATCH; END '
		, '{
    {DBName}}', [name])
FROM sys.databases
WHERE is_query_store_on = 1;

EXEC (@SQL);

Monitor space usage

   By default , When Query Store achieve 90% Space utilization , Will clear the space to 80%. If MAX_STORAGE_SIZE_MB Set too small , At the same time, the transaction consists of many , that Query Store Will grow far beyond the definition of maximum size . The following script is to monitor more than in the instance 90% The database of ：

USE [<Database>];
GO
SELECT current_storage_size_mb,
max_storage_size_mb,
FROM sys.database_query_store_options
WHERE CAST(CAST(current_storage_size_mb AS
DECIMAL(21, 2)) / CAST(max_storage_size_mb AS
DECIMAL(21, 2)) * 100 AS DECIMAL(4, 2)) >= 90
AND size_based_cleanup_mode_desc = 'OFF';

   If this happens , You can use one of two methods to clean up ：

ALTER DATABASE [<Database Name>] SET QUERY_STORE CLEAR ALL;

   perhaps

USE [<Database>];
GO
EXEC sys.sp_query_store_flush_db;

Plan enforcement failed

   Due to index changes , Hints The forced operation of the plan fails due to the following reasons , At this time, you can check the reason first , have access to T-SQL：

SELECT plan_id,
force_failure_count,
last_force_failure_reason
FROM sys.query_store_plan

You can also use extended events ：

CREATE EVENT SESSION [QueryStore_Forcing_Plan_Failure]
ON SERVER
ADD EVENT qds.query_store_plan_forcing_failed
ADD TARGET package0.ring_buffer WITH
(
MAX_MEMORY=4096 KB,
EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,
MAX_DISPATCH_LATENCY=30 SECONDS,
MAX_EVENT_SIZE=0 KB,
MEMORY_PARTITION_MODE=NONE,
TRACK_CAUSALITY=OFF,
STARTUP_STATE=ON
);

   If you find a plan that has failed , Only need Query Store Remove this plan from , After removal , Its runtime statistics are also removed .

EXECUTE sys.sp_query_store_remove_plan @plan_id = <plan_id>;

Reset execution plan statistics

  sys.sp_query_store_reset_exec_stats You can clear runtime statistics for a specific schedule , But the execution plan will be kept .

USE [<Database>];
GO
EXECUTE sys.sp_query_store_reset_exec_stats @plan_id = <plan_id>;

   Let's start with Query Store The report of , This is Query Store The results presented to the user , Only when you understand and use them well can you be able to use them Query Store 了 . However, there are many reports , So I will introduce it in several articles .
   Next article ：Azure SQL DB/DW series （12）—— Use Query Store（1）—— Report Introduction （1）