小编SAi*_*nCA的帖子

ALTER INDEX [PK_Order_Line_Inventory] 
ON [OrderManager_C].[Order_Line_Inventory] REBUILD 
WITH ( ONLINE = ON (WAIT_AT_LOW_PRIORITY (MAX_DURATION= 5, ABORT_AFTER_WAIT=SELF) )

SPID 58 中的 3 个线程满足了这一点。但是，在争论同一个数据页时，其中一个线程成为死锁受害者。进程 ID 不同，执行上下文 ID 和 Txn 属性也不同。对于同一个命令，实际上有两个死锁，一个用于 3 个线程，第二个用于幸存的 2 然后成为一个。

SQL 2017在线索引操作指南中有这样一段，“虽然不常见，但在线索引操作在与数据库更新交互时会因为用户或应用程序活动而导致死锁。在这些罕见的情况下，SQL Server 数据库引擎会选择用户或应用程序活动是死锁受害者。 ”，但由于死锁涉及“本身”，我的根本原因没有找到。

该表只有一个单列、bigint、Clustered PK，在 520MB 中包含 2.7M 行；在 1::0/1 关系中对其父级的一个 FK。

出现问题：

1. 这是一个错误吗？我已经十多年没有在 SQL Server 上看到这种行为了。
2. REBUILD 中的任何一个存活下来了吗？
3. 这种情况有可能复发吗？
4. 我想我可以增强我们的碎片整理工具，以允许选择将特定表的 MAXDOP=4 覆盖为 =1，但这真的有必要吗？

我一直在寻找类似的事件，但是从 SQLCoffee 到 MS KB978250 的一个看起来很有希望的链接遇到了 404 错误，并且从搜索 MS（原始线程）中根本没有命中。该 KB 谈到了对 SQL2008 的修复 - 如果相关，人们会认为它仍然应该是 2016 位的修复......

任何人都可以对此有所了解吗？ …

将客户的 SQL 2014 EE DB 恢复到我们的 Developer Edition 实例，没有问题，然后运行一个DBCC CHECKDB发现零错误的聚集列存储索引，声称超过 10 亿行，一个简单的SELECT TOP 1 FROM TheBaseTable没有返回任何数据 - 使用 3845 运行了 6m 38s读取、155 次物理读取和超过 400K 毫秒的 CPU，因此它看起来像是在做某事。

奇怪的是，恢复时兼容模式是 2008。将其更改为 120 并将页面验证更改为CHECKSUM.

修复了 SQL 登录 SID（只有 1 个孤立）。登录具有db_owner、db_accessadmin和db_securityadmin角色成员资格，因此它似乎并不缺乏特权，但它现在还具有db_datareader和db_datawriter成员资格。

跑sp_updatestats是因为 DMV 显示行但SELECT语句返回零。

客户端是否有可能将兼容性设置为 2008 年，并且存在 CCSI 弄乱了元数据？

请问有人听说过这样的吗？

关于如何查看数据的任何想法？

这是桌子 - 我看不出有什么可疑之处......

CREATE TABLE dbo.tbl_HistoryByType(
    InventoryID int NOT NULL,
    SalesTypeID int NOT NULL, …