相关疑难解决方法(0)

永无止境的查询存储搜索

我从一开始说,我的问题/问题类似于此之前的一个,但因为我不知道的原因或起始信息是一样的,我决定后,我的问题有一些更多的细节。

手头问题:

  • 在一个奇怪的时间(接近工作日结束),一个生产实例开始出现异常行为:
    • 实例的高 CPU(从大约 30% 的基线增加到大约两倍并且仍在增长)
    • 增加的事务数/秒(尽管应用程序负载没有看到任何变化)
    • 增加空闲会话数
    • 从未显示此行为的会话之间的奇怪阻塞事件(即使读取未提交的会话也会导致阻塞)
    • 间隔的顶部等待是非页面闩锁排在第一位,锁排在第二位

初步调查:

  • 使用 sp_whoIsActive 我们看到我们的监控工具执行的查询决定运行速度极慢并占用大量 CPU,这是以前从未发生过的;
  • 其隔离级别未提交读取;
  • 我们查看了我们看到古怪数字的计划:StatementEstRows="3.86846e+010" 有大约 150 TB 的估计数据要返回
  • 我们怀疑是监控工具的查询监控功能造成的,所以我们禁用了该功能(我们还向我们的提供商开了一张票,以检查他们是否知道任何问题)
  • 从第一个事件开始,它又发生了几次,每次我们终止会话,一切都会恢复正常;
  • 我们意识到该查询与MS 在 BOL 中用于查询存储监控的查询之一极为相似- 最近性能下降的查询(比较不同时间点)
  • 我们手动运行相同的查询并看到相同的行为(CPU 使用不断增加,增加闩锁等待,意外锁定......等)

有罪查询:

Select qt.query_sql_text, 
    q.query_id, 
    qt.query_text_id, 
    rs1.runtime_stats_id AS runtime_stats_id_1,
    interval_1 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi1.start_time), 
    p1.plan_id AS plan_1, 
    rs1.avg_duration AS avg_duration_1, 
    rs2.avg_duration AS avg_duration_2,
    p2.plan_id AS plan_2, 
    interval_2 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi2.start_time), 
    rs2.runtime_stats_id AS runtime_stats_id_2
From sys.query_store_query_text AS qt 
Inner Join sys.query_store_query AS …
Run Code Online (Sandbox Code Playgroud)

statistics system-tables sql-server-2016 query-store

11
推荐指数
2
解决办法
1229
查看次数

为什么不使用 sys.query_store_plan 加入消除工作?

以下是查询存储遇到的性能问题的简化:

CREATE TABLE #tears
(
    plan_id bigint NOT NULL
);

INSERT #tears (plan_id) 
VALUES (1);

SELECT
    T.plan_id
FROM #tears AS T
LEFT JOIN sys.query_store_plan AS QSP
    ON QSP.plan_id = T.plan_id;
Run Code Online (Sandbox Code Playgroud)

该plan_id列被记录为 的主键sys.query_store_plan,但执行计划并不像预期的那样使用连接消除:

  1. DMV 没有投射任何属性。
  2. DMV 主键plan_id不能复制临时表中的行
  3. 使用了 A LEFT JOIN,因此无法T消除from中的任何行。

执行计划

平面图

为什么会这样,在这里可以做些什么来消除连接?

performance join sql-server execution-plan query-store query-performance

10
推荐指数
1
解决办法
386
查看次数

令人难以置信的缓慢且无法使用的查询存储

我从查询存储开始,它有问题:-( 没有生成 Top Resource Consuming Queries 的报告。它只是一直说“等待”几个小时和几个小时。后台查询(请参见下面的示例)不是能够完成并消耗大量 CPU。无论我如何更改配置选项,它一直在等待和等待(甚至最后一小时报告)。这是查询存储的现实吗?听起来是一个很棒的工具,但完全是实际无法使用?

我的查询存储大小约为 1.7 GB。我正在以 1 小时的间隔和自动捕获模式收集 7 天的数据 - 所以对我来说这似乎是合理的设置。

这是一个从未完成的后台查询示例:

SELECT TOP (@results_row_count)
    p.query_id query_id,
    q.object_id object_id,
    ISNULL(OBJECT_NAME(q.object_id),'') object_name,
    qt.query_sql_text query_sql_text,
    ROUND(CONVERT(float, SUM(rs.avg_duration*rs.count_executions))*0.001,2) total_duration,
    SUM(rs.count_executions) count_executions,
    COUNT(distinct p.plan_id) num_plans
FROM sys.query_store_runtime_stats rs
    JOIN sys.query_store_plan p ON p.plan_id = rs.plan_id
    JOIN sys.query_store_query q ON q.query_id = p.query_id
    JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id
WHERE NOT (rs.first_execution_time > @interval_end_time OR rs.last_execution_time < @interval_start_time)
GROUP BY p.query_id, qt.query_sql_text, q.object_id
HAVING COUNT(distinct p.plan_id) >= 1 …
Run Code Online (Sandbox Code Playgroud)

performance query-store sql-server-2017 query-performance

8
推荐指数
1
解决办法
1787
查看次数