zoukankan      html  css  js  c++  java
  • SQL Server ->> SQL Server 2016新特性之 --- Query Store

    前言

    SQL Server 2016引入新的查询语句性能监控、调试和优化工具/功能 -- Query Store。以前我们发现一条查询语句性能突然下降,我们要去找出问题的所在往往需要通过调用一些DMV(比如sys.dm_exec_query_stats, sys.dm_exec_sql_text和sys.dm_exec_query_plan)来获取查询计划的一些信息,比如XML格式的执行计划,查询语句的代码,执行了多少次以及一些资源和时间的的使用消耗情况。然后根据这些信息来判断这条语句是否存在性能问题。问题在于但一条语句出现了性能下降,我们可能需要和过去的信息进行一个比较,才能知道性能是否下降了。比如一条语句如果过去花了1秒,现在3-5秒,我们可能第一眼会认定它是没有问题的,但是其实它性能是下降了的。所以我还需要一个任务去定时收集这些资料。比如下面这条语句就是用来收集这些信息的。

    SELECT s2.dbid, 
        (SELECT TOP 1 SUBSTRING(s2.text,statement_start_offset / 2+1 , 
          ( (CASE WHEN statement_end_offset = -1 
             THEN (LEN(CONVERT(nvarchar(max),s2.text)) * 2) 
             ELSE statement_end_offset END)  - statement_start_offset) / 2+1))  AS sql_statement,
        s3.query_plan,
        execution_count,     plan_generation_num,     last_execution_time,       total_worker_time,     last_worker_time,     min_worker_time, 
        max_worker_time,    total_physical_reads,     last_physical_reads, 
        min_physical_reads,      max_physical_reads,      total_logical_writes,     last_logical_writes,     min_logical_writes,     max_logical_writes
    FROM sys.dm_exec_query_stats AS s1 
    CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2  
    CROSS APPLY sys.dm_exec_query_plan(plan_handle) AS s3

    SQL Server 2016引入了Query Store来自动收集数据库的查询计划和相关的一些性能信息,还提供了4种不同类型的报表可以来查看收集的数据。不通过报表,我们也可以通过一些新增的DMV来查询收集好的数据。

    那么究竟Query Store可以在哪些方面帮到我们?

    1)快速定位查询语句的查询计划性能回退,找出哪些查询语句最近因为查询计划的改变出现性能回退?这当中可能是因为删除了某条索引、过去某个时间点有大量的数据涌入数据表中而统计数据没有及时得以更新、或者最近代码发现了改变等原因。

    2)获知查询在某段时间内的资源使用/占用情况以及执行次数。有时语句本身可能执行计划没有回退的情况出现,但是由于语句本身写法问题或者缺乏合理的索引,导致语句的执行非常消耗资源,对于SQL Server整体的性能或者服务器的性能造成很大的印象。作为DBA本身也需要及时去定位这些类型的语句,最后得出一些解决办法。

    3)获知数据库过去某段时间内的整体查询工作负荷,包括承受的并发查询压力(量级),资源消耗情况。

    架构

    Query Store存储分两部分,一部分是用于存储编译好的执行计划的Plan Store,另一部分用于存储语句执行执行过程中的一些统计数据。这些数据先是驻留在内存,随后会根据你设定好的时间间隔写入到数据库的主文件组中。

    因为Query Store也需要背面的线程来定时写入数据,所以启用Query Store大概会付出3-5%的性能代价。间隔越短,性能的代价越大。间隔大了,由于SQL Server重启导致丢失收集好在内存中但是还没有写入磁盘的那些数据的损失就越大。 

    Query Store在访问收集好的数据时是会先查看数据是否是否已经在内存中,这样就必须去磁盘找了。只有不在内存中才去磁盘找。它会先调用一个叫QUERY_STORE_RUNTIME_STATS_IN_MEM的表函数去访问内存中的数据,同时访问plan_persist_runtime_stats这张表去访问磁盘的数据。

    启用Query Store功能

    通过代码启用Query Store

    ALTER DATABASE XXXXX SET  QUERY_STORE = ON;
    
    ALTER DATABASE XXXXX
    SET QUERY_STORE
      (
      MAX_STORAGE_SIZE_MB = 250,
      SIZE_BASED_CLEANUP_MODE = AUTO,
      CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 30)
      );

    上面括号中的选项对应的GUI上选项列表

    内置Query Store报表

    这大概是Query Store最有用的功能。通过报表的形式和已经定制好的性能调优类型的报表来让用户知道过去一段时间内的数据情况。

    目前一共提供了4种类型的报表,分别的:回归的查询,总体资源的使用,前几个资源使用的查询,跟踪的查询。

    Query Store相关的DMV

    他们的关系

    select *
    from sys.query_store_query qsq join
            sys.query_context_settings qcs on qsq.context_settings_id = qcs.context_settings_id join
            sys.query_store_query_text qst on qst.query_text_id = qsq.query_text_id join
            sys.query_store_plan qsp on qsp.query_id = qsq.query_id join
            sys.query_store_runtime_stats qsrs on qsrs.plan_id = qsp.plan_id join
            sys.query_store_runtime_stats_interval qsrsi on qsrsi.runtime_stats_interval_id = qsrs.runtime_stats_interval_id

    参考:

    SQL Server 2016:通过Query Store定位回归缺陷

    The SQL Server 2016 Query Store: Overview and Architecture

  • 相关阅读:
    关于linux curl 地址参数的问题
    mac系统安装php redis扩展
    Shell获取上一个月、星期的时间范围
    python redis使用
    python pycurl模块
    Memcached常规应用与分布式部署方案
    mysql忘记密码重置(mac)
    shell命令从目录中循环匹配关键词
    python两个文件的对比
    MySQL优化方案
  • 原文地址:https://www.cnblogs.com/jenrrychen/p/6131570.html
Copyright © 2011-2022 走看看