标签: query-store

每周一次，在过去 5 周内，大约在一天中的同一时间（清晨，可能基于人们开始使用它时的用户活动），SQL Server 2016（AWS RDS，镜像）开始超时很多查询。

所有表上的 UPDATE STATISTICS 总是立即修复它。

在第一次之后，我让它每晚（而不是每周）更新所有表上的所有统计信息，但它仍然发生了，（更新统计信息运行后大约 8 小时，但不是每天运行）。

这最后一次，我启用了查询存储，看看我是否能找到它是哪个特定的查询/查询计划。我想我可以将其缩小为一个：

找到该查询后，我添加了一个推荐索引，该索引在这个不常用的查询中缺失（但它确实触及了很多常用表）。

错误的查询计划正在执行索引扫描（在只有 10k 行的表上）。其他以毫秒为单位返回的查询计划，虽然用于执行相同的扫描。最新的查询计划，在创建新索引后只查找。但即使没有该索引，99% 的情况下，它也会在几毫秒内返回，但是，每周需要超过 40 秒。

• 坏的超时：http : //brentozar.com/pastetheplan/?id=rymaWt56e
• 以前没有超时的计划：http : //brentozar.com/pastetheplan/?id=HyN7ftcpe
• 带有新索引的最新计划：http : //brentozar.com/pastetheplan/?id=ryLuGKcag

这是从 2012 年迁移到 SQL Server 2016 后开始发生的。

DBCC CHECKDB 没有返回错误。

1. 新索引是否会解决问题，使其不再选择糟糕的计划？
2. 我应该“强制”现在运行良好的计划吗？
3. 我如何确保这不会发生在另一个查询/计划中？
4. 这是更大问题的征兆吗？

我刚刚添加的索引：

CREATE NONCLUSTERED INDEX idx_AppointmetnAttendee_AttendeeType
ON [dbo].[AppointmentAttendee] ([UserID],[AttendeeType])

CREATE NONCLUSTERED INDEX [idx_appointment_start] ON [dbo].[Appointment]
(
    [ProjectID] ASC,
    [Start] ASC
)
INCLUDE (   [ID],
    [AllDay],
    [End],
    [Location],
    [Notes],
    [Title],
    [CreatedByID]) WITH (PAD_INDEX = OFF, …

如果在可用性组中的主节点上强制执行计划，它是否应用于在辅助节点上运行的查询？

我正在寻找涵盖计划强制两种可能性的答案：

• 计划指南
• 查询存储强制计划

我已阅读以下内容，这些内容表明 QS 强制计划不会结转，但在文档中找不到任何权威信息，或任何有关计划指南的信息。

• Erin Stellato 的查询存储和可用性组
• Vikas Rana在 AlwaysOn Readable Secondary 上查询数据存储强制计划行为

强制的决定性证据是辅助节点的执行计划中存在Use Plan或PlanGuideName和PlanGuideDB属性。

查询存储强制计划功能似乎没有执行该计划。

我知道Query Store - Forced 并不总是意味着 Forced；然而，我的计划可能不会发生微不足道的变化，但查询优化器可能会继续选择不正确的索引、循环选择等。

基本上：它不尊重我被迫的计划选择。我强迫了很多计划，但它根本行不通。

1. 当我查看sys.query_store_plan force_failure_count.
2. 扩展事件query_store_plan_forcing_failed不会产生任何结果。0 事件。

例如，在 20.09 强制执行的计划。只有 1 个编译碰巧使用了强制计划。

计划大相径庭，一个使用带有 INDEX 1 的 Hash Match join，另一个使用带有 INDEX 2 的 Loop Join。

版本：Microsoft SQL Server 2016 (SP1-GDR) (KB3210089) - 13.0.4202.2 (X64)

我在这里缺少什么？

SQL Server 2016 中引入的新查询存储很棒。它很好地替代了我以前使用旧的 Profiler 工具所做的大部分工作。但是，我还没有找到一种方法来捕获与对它嗅出的高资源消耗查询的单个调用相关联的参数值。这可能吗？

我知道查询存储更多地处理聚合数据而不是单个调用，所以我怀疑我在这里可能不走运。当我发现一个缓慢的查询时，我发现将参数与其最慢的调用之一关联起来也很方便进行故障排除。我想知道如何使用最新最好的工具来做到这一点。（我不会错过使用 Profiler！）

在安全方面，查询存储比 Profiler 更容易锁定吗？我认为它需要从某个级别的单个调用中捕获数据才能计算聚合。只是不确定它是否存储了其中的任何一个。

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

手头问题：

• 在一个奇怪的时间（接近工作日结束），一个生产实例开始出现异常行为：
  • 实例的高 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 …

什么是 SQL 的“不可提及的词”？

我正在阅读sys.query_store_query_text (Transact-SQL)并且我看到以下内容，所以我谷歌了 {SQL "unmentionable" word}

has_restricted_text
bit
查询文本包含密码或其他不可提及的词。

除了 3 个将我带回到我找到它的位置的链接之外，我没有找到任何似乎显示与密码或 SQL 可能关心的任何关系的内容。

我一直在深入研究 SQL Server 查询存储，我经常看到对“临时”查询的引用。但是，我还没有看到查询存储确定临时查询是什么。我见过一些地方，它可以被推断为不带参数的查询或只执行一次的查询。是否存在对此的正式定义？我不是说一般。我的意思是因为它与查询存储有关。

例如，此页面显示了从查询存储中删除临时查询的示例，但它使用的条件似乎只是执行计数为 1。这似乎是临时查询的奇怪定义。顺便说一句，如果您转到该页面，请搜索“删除临时查询”。

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

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;

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

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

执行计划

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

对 SQL 系统数据库（master、model、msdb、tempdb）的查询存储只能在 msdb 上使用。我查看并没有在 msdb 上找到任何有关查询存储的文档。

虽然您无法在 GUI 中看到它，但可以在您的 SQL 2016 实例上对其进行验证

验证查询存储已关闭

USE msdb
SELECT * FROM sys.database_query_store_options; 

打开查询存储

USE [master]
GO
ALTER DATABASE msdb SET QUERY_STORE = ON
GO
ALTER DATABASE msdb SET QUERY_STORE (OPERATION_MODE = READ_WRITE
, INTERVAL_LENGTH_MINUTES = 30
, MAX_STORAGE_SIZE_MB = 1000
, QUERY_CAPTURE_MODE = AUTO)
GO

验证查询存储已开启

USE msdb
SELECT * FROM sys.database_query_store_options; 

在所有系统数据库中，为什么 msdb 是唯一一个可以选择使用查询存储的数据库，它增加了什么价值？

-- Stop Query Store
USE [master]
GO
ALTER DATABASE msdb SET QUERY_STORE = OFF
GO

我最近将我们的 2016 SQL Server 更新到 SP2 和 2018 年 8 月发布的最新 CU (KB4458621)。就在最后一天左右，我注意到我有一些阻塞。我无法杀死 SPID b/c，它不是用户进程。根据 SP_WHO2，命令是“Query Store ASYN”。我尝试通过脚本和 UI 清除数据并禁用查询存储。似乎没有任何效果，它只是旋转，然后开始造成更多阻塞。还有其他人有这个问题吗？谁能帮我弄清楚如何成功禁用查询存储？SP_WhoIsActive @show_System_SPIDS = 1 个结果如下（仅查询存储结果）

更新 - 这现在导致 TempDB 驱动器填满。几个小时后尝试重新启动，看看是否能解决问题。将及时向大家发布。

谢谢，内特