Use Query Store query performance monitoring

Query Store a statement performance monitoring and tuning tools SQL Server 2016 introduced, it not only automatically capture query statistics history information of the execution plan and run, but also can identify performance differences due to the implementation of plans to change the result of simplifying the performance of the troubleshooting process. Query Store means be interpreted literally, it is a warehouse query, which uses asynchronous update mode, the data stored in the hard disk (Disk) in.

First, enable Query Store

Query Store is off by default, enabled Query Store or have a certain impact on query performance,

ALTER DATABASE { database_name | CURRENT }
SET QUERY_STORE
{
        = OFF
        | = ON [ ( <query_store_option_list> [,...n] ) ] 
        | CLEAR [ ALL ]
}

<query_store_option_list> ::=
{
      OPERATION_MODE = { READ_WRITE | READ_ONLY }
    | CLEANUP_POLICY = ( STALE_QUERY_THRESHOLD_DAYS = number )
    | DATA_FLUSH_INTERVAL_SECONDS = number
    | MAX_STORAGE_SIZE_MB = number
    | INTERVAL_LENGTH_MINUTES = number
    | SIZE_BASED_CLEANUP_MODE = { AUTO | OFF }
    | QUERY_CAPTURE_MODE = { ALL | AUTO | CUSTOM | NONE }
    | MAX_PLANS_PER_QUERY = number
    | WAIT_STATS_CAPTURE_MODE = { ON | OFF }
    | QUERY_CAPTURE_POLICY = ( <query_capture_policy_option_list> [,...n] )
}

<query_capture_policy_option_list> :: =
{
    STALE_CAPTURE_POLICY_THRESHOLD = number { DAYS | HOURS }
    | EXECUTION_COUNT = number
    | TOTAL_COMPILE_CPU_TIME_MS = number
    | TOTAL_EXECUTION_CPU_TIME_MS = number
}
View Code

Parameter Notes:

  • CLEAR : Clear Query Store memory
  • The OPERATION_MODE : READ_WRITE refers Query Store will continue to collect and persistent query plan (query plan) and run-time execution statistics, and READ_ONLY refers only read information from the Query Store, but does not update the Query Store.
  • CLEANUP_POLICY : time window defined data retained beyond the window, cleared out of date data from the Query Store.
  • DATA_FLUSH_INTERVAL_SECONDS : definition data persistence frequency to the hard disk, the default is 900s (15min). To optimize performance, the data collected Query Store asynchronous write mode, some time will capture the data written to the hard disk intervals.
  • MAX_STORAGE_SIZE_MB : Set the maximum storage space Query Store. If Query Store reached the maximum storage limit, Query Store will operate mode (OPERATION_MODE) Change READ_ONLY
  • INTERVAL_LENGTH_MINUTES : runtime execution statistics for the polymerization every certain time window, then the aggregate value is stored in the Query Store.
  • SIZE_BASED_CLEANUP_MODE : whether to start the clean-up program based on the size of the space occupied by the control Query Store clean up Query Store program automatically removes obsolete data and free space of Query Store
  • QUERY_CAPTURE_MODE : Capture capture schema definition query, the default value is ALL, expressed capture all queries, AUTO representation to capture related queries based on the number of executions and resource consumption.
  • MAX_PLANS_PER_QUERY : defined as the number of maintenance plans for each query, the default value is 200
  • WAIT_STATS_CAPTURE_MODE : whether to wait for capture statistics (wait stats)
  • QUERY_CAPTURE_POLICY : Query the policy definition capture,
    • STALE_CAPTURE_POLICY_THRESHOLD : Define Assessment intervals (evaluation interval period), to determine whether a query should be captured according to the following options, the default value evaluation period is 1day
    • EXECUTION_COUNT : The default value is 30, in the evaluation period, if a query execution frequency exceeds the specified value, then capture the query.
    • TOTAL_COMPILE_CPU_TIME_MS : The default value is 1000ms, in the evaluation period, if a query compilation time than the specified time, then capture the query.
    • TOTAL_EXECUTION_CPU_TIME_MS : The default value is 100, in the evaluation period, if the execution time of a query exceeds the specified time, then capture the query.

For example, use the default values ​​to enable Query Store:

ALTER DATABASE [QueryStoreDB]  
SET QUERY_STORE = ON 
    (
      OPERATION_MODE = READ_WRITE, 
      CLEANUP_POLICY = ( STALE_QUERY_THRESHOLD_DAYS = 90 ),
      DATA_FLUSH_INTERVAL_SECONDS = 900,
      MAX_STORAGE_SIZE_MB = 1000, 
      INTERVAL_LENGTH_MINUTES = 60,
      SIZE_BASED_CLEANUP_MODE = AUTO, 
      MAX_PLANS_PER_QUERY = 200,
      WAIT_STATS_CAPTURE_MODE = ON,
      QUERY_CAPTURE_MODE = CUSTOM,
      QUERY_CAPTURE_POLICY = (
        STALE_CAPTURE_POLICY_THRESHOLD = 24 HOURS,
        EXECUTION_COUNT = 30,
        TOTAL_COMPILE_CPU_TIME_MS = 1000,
        TOTAL_EXECUTION_CPU_TIME_MS = 100 
      )
    );

The user can view the configuration of various options through the system view:

sys.database_query_store_options

You can also use SSMS to configure the various options Query Store:

Two, Query Store information captured

Query Store contains four Store, are query store, plan store, runtime stats store and wait stats store. query store for capturing information query execution plan plan store information used to capture, runtime change records and statistics stats store for capturing execution plan, etc., stats store to wait for capture statistics.

1, mandatory plan (Plan Forcing)

Due to some unforeseen reasons, such as statistical information changes, schema changes, the index creation / deletion, SQL Server query any of the execution plan usually changes over time. Due to memory pressure, plans will be evicted from the plan cache, which leads to the plan cache stores only the latest execution plan for the query. Query performance decline caused by the changes to the implementation plan, disappeared without trace, to solve time-consuming.

Because Query Store for each query execution plan more reserved, so that it can indicate the query processors (Query Processor) to force a particular query execution plan, which is called compulsory plan (Plan Forcing). Query Store in the compulsory program (Plan Forcing) working mechanism similar to USE PLAN query hint, but does not require any changes in the application in the user program can query a compulsory settlement plan changes resulting in a very short period of time performance degradation issues.

2, wait statistics (Wait Stats)

Wait statistics are another source of information to solve the query performance issues for a long time, waiting for the statistics are available only at the instance level, which makes it difficult to go back to wait for a particular query. From SQL Server 2017 (14.x) and Azure SQL database to start, waiting for query memory able to track information specific statement.

ALTER DATABASE AdventureWorks2012 
SET QUERY_STORE = ON ( WAIT_STATS_CAPTURE_MODE = ON );

Three, Query Store related views

Query Store related views divided into four categories: Query, Plan, Runtime Stats and Wait Stats. Note, Wait Stats from SQL Server 2017 (14.x) began to support.

1, information about the Query

The only query identification field is query_id 

select q.query_id
    ,t.query_text_id
    ,t.query_sql_text
    ,q.object_id as parent_object
    ,q.is_internal_query
    ,q.query_parameterization_type
    ,q.query_parameterization_type_desc
    ,q.count_compiles
    ,q.avg_compile_duration
    ,q.avg_bind_cpu_time
    ,q.avg_bind_duration
    ,q.avg_compile_memory_kb
    ,q.avg_optimize_cpu_time
    ,q.avg_optimize_duration
from sys.query_store_query as q   
inner join sys.query_store_query_text as t  
    on q.query_text_id = t.query_text_id ;  

2, information about the Plan of

plan associated query, the fields may be related by query_id

select p.plan_id
    ,p.query_id
    ,t.query_sql_text
    ,p.query_plan
    ,p.is_parallel_plan
    ,p.is_forced_plan
    ,p.force_failure_count
    ,p.last_force_failure_reason
    ,p.last_force_failure_reason_desc
    ,p.count_compiles
    ,p.avg_compile_duration
from sys.query_store_plan p
inner join sys.query_store_query q
    on p.query_id=q.query_id
inner join sys.query_store_query_text t
    on q.query_text_id=t.query_text_id

3, on the Plan of Runtime Statistics

runtime stats through a query associated to a particular plan_id

select r.runtime_stats_id
    ,r.plan_id
    ,r.runtime_stats_interval_id
    ,i.start_time as interval_start_time
    ,i.end_time as interval_end_time
    ,r.execution_type
    ,r.execution_type_desc
    ,r.count_executions
    ,r.avg_duration
    ,r.avg_cpu_time
    ,r.avg_dop
    ,r.avg_logical_io_reads
    ,r.avg_logical_io_writes
    ,r.avg_physical_io_reads
    ,r.avg_query_max_used_memory
    ,r.avg_rowcount
from sys.query_store_runtime_stats r
inner join sys.query_store_runtime_stats_interval i
    on r.runtime_stats_interval_id=i.runtime_stats_interval_id

4, statistical information on waiting

The view is waiting for statistics relating to the implementation plan with a single

select w.wait_stats_id
    ,w.plan_id
    ,w.runtime_stats_interval_id
    ,w.wait_category
    ,w.wait_category_desc
    ,w.execution_type
    ,w.execution_type_desc
    ,w.avg_query_wait_time_ms
    ,w.min_query_wait_time_ms
    ,w.max_query_wait_time_ms
from sys.query_store_wait_stats w
inner join sys.query_store_plan p
    on w.plan_id=p.plan_id

 

Reference documents:

Monitoring performance by using the Query Store

Query Store Catalog Views (Transact-SQL)

Guess you like

Origin www.cnblogs.com/ljhdo/p/11821213.html