相关疑难解决方法(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 …

这解释起来有点复杂，但很容易重现。

精简版：

对于大约 10%-30% 的查询（按计数），大量的查询存储数据不可用。我查看了 SQL 2016 和 SQL 2017，其中查询存储已经运行了数周以上，数据库上有活动。

下面的查询将返回两组数据，顶部集没有 值query_store_query.last_execution_time，而底部集在字段中有数据。“没有”也缺少大多数运行时统计数据。

EXEC sp_query_store_flush_db;  --Same results without this, but just to rule it out in the examples. 
go
Select * from sys.query_store_query
where query_store_query.last_execution_time is null -- there are bunch of these, also missing other data, why? 

Select * from sys.query_store_query
where query_store_query.last_execution_time is not null 

问题解决：

1. 我最初使用导出的查询存储数据发现了这一点我的数据在 Excel 工作表中，我进行了排序和比较，但没有发现任何将“拥有”与“没有”分开的共同因素

2. 为了排除数据导出问题，我使用上面的代码直接从系统数据视图中获取数据。结果与导出数据中的结果相似。

3. 为了排除系统数据视图，我使用“跟踪查询”从根数据报告。（查询存储 > 跟踪查询 > 配置）

   3.A. 对于“拥有”，查询计划等会显示出来，正如您所期望的

   3.B. 对于“没有”，没有查询计划和指标

4. 我发现的唯一范围限制因素是，在非常活跃的数据库上，“没有”仅限于最后几个小时。但是在慢速数据库上，“没有”可能有可以追溯到几周前的 initial_compile_start_time。（我怀疑“没有”正在被清除，然后在下次运行“以前从未见过，新”查询时重新创建）

5. “没有”可以有任何范围的编译计数、计划数量等。

题 …

今天早上，收到了以下电子邮件警报：

日期/时间：2/28/2018 9:26:42 AM

描述：尝试在数据库 9 中获取逻辑页 (1:3948712) 失败。它属于分配单元 72057594045857792 不属于 72059184917512192。

评论：（无）

作业运行：SQL Sentry 2.0 警报陷阱

查看辅助副本的事件日志，同一消息出现了 3 次：

源 spid138

消息 尝试获取数据库 9 中的逻辑页 (1:3948712) 失败。它属于分配单元 72057594045857792 不属于 72059184917512192。

在辅助副本（2 节点同步可用性组）上运行以下内容：

DBCC TRACEON(3604)
dbcc page (9, 1,3948712,3)
go
DBCC TRACEOff(3604)

任一副本的结果片段：

Page @0x00000070DAB8C000

m_pageId = (1:3948712)              m_headerVersion = 1               
m_type = 3 m_typeFlagBits = 0x0                m_level = 0            
m_flagBits = 0x8200 m_objId (AllocUnitId.idObj) = 129   m_indexId
(AllocUnitId.idInd) = 256  Metadata: AllocUnitId = 72057594046382080  
Metadata: PartitionId = 72057594040811520                             
Metadata: …