Azure SQL db/dw series (9) -- re understanding the query store (2) -- working principle

This paper belongs to Azure SQL DB/DW series
Last article ：Azure SQL DB/DW series （8）—— Reunderstanding Query Store（1）—— brief introduction
In this paper, Query Store Technology insider

Data sources

  Query Store The data in consists of three data sources ：

1. Query and plan information ： Data about the query itself and the execution plan derived by the query optimizer from the query .
2. The runtime information of the query ： How fast queries run , How many times have I been called , And performance related information at runtime .
3. Waiting information for query ： Collect the relevant waiting information of the query at run time .

Collect information about queries and plans

   When a query （ Not limited to SELECT） Submitted to the SQL Server when , It will go through a series of processes , These processes include verification SQL And the objects that need to be used , But the most important thing is to optimize , And generate the execution plan as soon as possible , At the same time, the implementation plan should be good enough . The general process is as follows ：

  Query Store Collect only DML Information , these DML Include SELECT/UPDATE/DELETE/INSERT etc. , and DDL Will not be collected . At least not for now .
   Look at the picture below , When the query is compiled, analyzed and optimized, an execution plan is generated , There will be an asynchronous process to obtain the information of query and execution plan and send it to Query Store. This process will first store the information temporarily in memory , Then at certain intervals （Query Store Can be defined in ） Then write to disk asynchronously . On the one hand, this is to reduce the pressure of too many real-time operations on the server , The other is to reduce the intervention in the optimization process . With one exception , It's mandatory planning , This process will interfere with the normal optimization process , If the query has a plan constraint applied , Then the forced plan will be written to the cache , Instead of an execution plan generated by the optimizer .

   This process is independent of the statement level , Not based on stored procedures or batches . If the query belongs to an object （ stored procedure 、 batch ）, So the object of ID It will also be brought into the collected information .

Collect runtime and wait information for queries

   After obtaining the execution plan , The runtime statistics and waiting information will be collected , Of course , This information is generated only when it is actually running , That is to say, it will be collected at runtime . These data will be stored in memory 15 minute , Will be written to disk .
   After collecting information once , Because recompilation causes the execution plan to be regenerated . If you follow Query Store The same as in China , Then only the statistics will be updated . If a new execution plan is generated due to recompilation , Then the new execution plan will also be captured Query Store in .
   Because the collected data goes to the memory and then to the disk , Therefore, abnormal loss may occur , For example, the server is restarted or the memory is emptied . You can use it manually sys.sp_query_store_flush_db To brush to disk .
   Readers may wonder why the runtime and waiting information that appear to be queried together should be collected separately , because Query Store from 2016 appear , stay 2016 and 2017 The waiting statistics are added , So we need to look at it separately . In addition, although the collection time of these two information is close to the same , But many times analysis needs to be separated .
   Let's move on to a more in-depth introduction .

Query and query plan information

   This part of the information , You can get from the following four catalog views ：

• sys.query_context_settings： About the context configuration of query running .
• sys.query_store_query： This is the core of the relationship , Connect the other three catalog views .
• sys.query_store_query_text： Stored the text information of the query .
• sys.query_store_plan： This view stores the execution plan of the query , Through foreign keys query_id and sys.query_store_query relation .

   The relationship between them is shown in the figure , In the following articles, we will introduce and demonstrate .

Runtime information

   The catalog views involved are ：

  sys.query_store_runtime_stats adopt plan_id and runtime_stats_interval_id Associated with the other two tables . In fact, we can also learn some database design concepts from these table relationships .
  sys.query_store_runtime_stats There are many columns that we are interested in , such as duration（ The duration of the ）,CPU time, Row number , Memory, etc. .
  sys.query_store_runtime_stats_interval In this view ,execution_type Will affect the collection of information , It has three values ：0—— Successful execution ;3—— User terminates execution ;4—— Unexpected termination of execution .

Waiting for Statistics

   The relationship between catalog views is as follows ：

   Same as runtime information , They summarize data by running time interval . At the same time, as the runtime information, every 15 Brush the memory data to the disk every minute .

summary

   This paper introduces Query Store The three components of , Through these three parts , Queries are collected and stored separately .

Next article ：Azure SQL DB/DW series （10）—— Reunderstanding Query Store（3）—— Configure query storage