数据库损坏：QueryStore 内部表

Question

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

日期/时间：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: IndexId = 1 Metadata: ObjectId = 197575742      
m_prevPage = 0:0)                  m_nextPage = (0:0) pminlen = 0                 
m_slotCnt = 2                       m_freeCnt = 1634 m_freeData = 6568
m_reservedCnt = 0                   m_lsn = (46041:1506360:18)
m_xactReserved = 0                  m_xdesId = (0:0)                  
m_ghostRecCnt = 0 m_tornBits = -99702035              DB Frag ID = 1

在主副本上运行以下命令：

select OBJECT_NAME (197575742)

plan_persist_plan

问题

1. 我说我有一个plan_persist_plan作为查询存储一部分的表的聚集索引损坏是否正确？

2. 是运行以下内容的最佳/唯一修复程序：

   ALTER DATABASE MyDatabase SET QUERY_STORE CLEAR; 
   

3. 如果#2 是最好的解决方法，有没有什么好的方法可以在查询存储中保留将被删除的数据？

4. 这种损坏是否表示 IO 子系统有问题？

其他信息

• 我显然启用了 QueryStore，它的容量为 350MB，当前处于读写模式，刷新间隔为 15 分钟，每小时收集一次统计信息，捕获模式为 ALL，基于自动大小的清理，5 天的陈旧查询阈值。
• DB id 9 是业务关键用户数据库
• 错误详细信息为错误：605，严重性：21，状态：3。

我已按照指南检查了 Windows 系统事件日志。这仅产生了“信息性”事件，没有错误。

DBCC CHECKTABLE ('sys.plan_persist_plan');  

结果：

DBCC results for 'sys.plan_persist_plan'.
There are 12562 rows in 240 pages for object "sys.plan_persist_plan". 
DBCC execution completed. 
If DBCC printed error messages, contact your system administrator.

我无法建立正确的命令来重建索引，以下不起作用：

ALTER INDEX PK_plan_persist_plan_cidx ON sys.plan_persist_plan REBUILD;

Answer 1

正如我在上面的评论中所指出的，我在查询存储内部表中遇到了类似的损坏问题。

正如您自己所建议的那样，我曾经ALTER DATABASE MyDatabase SET QUERY_STORE CLEAR;尝试解决该问题，并且效果很好。在SQL Server 2017年，微软补充说，可以在清零数据可以尝试修复程序：sp_query_store_consistency_check（源）

如果您想保留数据，那么可能唯一的方法是复制表 - 我找不到为此创建脚本的任何人。

通常由于损坏，我也会担心我的磁盘，但在这种情况下，我有点怀疑问题出在查询存储本身上。