我们有 8 个进程，每个进程通过游标处理表中的一组单独的数据，以便可以使用多个 CPU 来迭代数据。这用于数据迁移，因此此时服务器计算机未用于其他任何用途。
有时，此进程会锁定，并且 SQL 的 CPU 使用率实际上会回落到 0。这些进程中的每一个都陷入了 WAITFOR 状态，最长可达 30 秒，然后再次降至 0。我们的 SQL 或代码端没有 WAITFOR 命令，并且 SQL 不会告诉我它在活动监视器或 DMV 中等待什么。这种情况似乎更多地发生在资源规格较低的机器上，但我觉得一旦 CPU 使用率回落，SQL 最终应该停止等待 CPU。
我在这里遗漏了什么吗？我们有什么办法可以解锁这些进程吗？
我正在从使用对象 ID 和属性类型作为聚集索引的属性表中迁移一些存储为“键值”样式的数据（我也尝试过作为非聚集索引）：
CREATE TABLE [dbo].[#attrs](
[DataMigrationEventObjectID] [int] NOT NULL,
[AttributeType] [varchar](128) NOT NULL,
[AttributeValue] [varchar](255) NULL
)
CREATE CLUSTERED INDEX pk ON #attrs ([DataMigrationEventObjectID],AttributeType);
我添加了属性值来选择值，因为数据库中的属性表有很多其他数据，我可以只为这个迁移事件选择它。使用我的测试数据集填充此表的查询插入 ~3k 行并在不到一秒的时间内运行（我的数据集中总共有大约 50 个对象，每个对象都有几个属性）。
查询中表的连接如下所示，连接到聚簇索引：
INNER JOIN #attrs obj_gvn
ON obj_gvn.DataMigrationEventObjectID = obj.DataMigrationEventObjectID
AND obj_gvn.AttributeType = 'GivenName'
通过 14 个连接到这个临时表，查询在几秒钟内完成。对于 15 个连接，查询需要一分钟，对于 16+ 个连接，它在半小时后仍在运行。
我已经检查了所有连接是否存在会导致返回太多行的意外情况，当它在 1 分钟内返回时它只返回正确的行，所以我认为没有意外的笛卡尔连接。设置 MAXDOP 值不会影响它，查询运行一分钟后返回的查询计划不会标记任何问题。
关于 SQL，我错过了什么导致它以这种方式运行的聚集索引上的大量连接，理论上应该很快，记录数量如此之少？
我无法获得实际执行计划，因为查询未完成，并且因为它使用了临时表，所以我无法获得它的估计计划。我试图将临时表伪造为数据库中的真实表并生成一个估计计划，但 2 分钟后该计划仍未生成，所以看起来延迟是在“创建计划”方面
粘贴查询的缩短版本的计划：brentozar.com/pastetheplan/ ?id=Hy76dd92i
为了以防万一，我已经更新了数据库的统计信息，但它仍然没有生成计划。
我过去曾处理过越来越多的问题连接查询，其中计划编译仍然是即时的。我觉得它在“生成计划”步骤中失败的事实一定意味着什么。
不幸的是，更新到最新的 CU 没有帮助。sp_whoisactive仅显示 CPU 使用率攀升和攀升（屏幕截图），其他资源上没有任何问题。
这是我的开发机器，因此 SQL 上只有一个进程处于活动状态，这是我正在运行的查询。没有别的，所以我假设它必须是 SQL 试图生成计划。
我怀疑如果我部署它，Production 会很好地运行它，但是“在主键上有很多连接会导致性能下降”的问题是非常奇怪的。我可能会考虑干脆放弃开发服务器并从头开始。
为了解决这个问题，在这种情况下，我们正在修复一个数字数据库，其中在损坏之前没有进行任何备份，因此恢复备份不是一种选择。不是我的数据库:)
在使用 REPAIR_ALLOW_DATA_LOSS 运行 DBCC CHECKDB 时，我们会收到数千个如下所示的错误：
Msg 8928, Level 16, State 1, Line 7
Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data): Page (1:24911) could not be processed. See other errors for details.
Repairing this error requires other errors to be corrected first.
Msg 8965, Level 16, State 1, Line 7
Table error: Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data). The off-row data node at page (1:24911), slot 0, text ID 265289728 is referenced by page (1:24820), slot 0, but was not seen in the scan.
Repairing this error requires other errors to be corrected first.
Msg 8928, Level 16, State 1, Line 7
Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data): Page (1:24912) could not be processed. See other errors for details.
Repairing this error requires other errors to be corrected first.
Msg 8965, Level 16, State 1, Line 7
Table error: Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data). The off-row data node at page (1:24912), slot 0, text ID 265289728 is referenced by page (1:24820), slot 0, but was not seen in the scan.
Repairing this error requires other errors to be corrected first.
Msg 8928, Level 16, State 1, Line 7
Object ID 2105058535, index ID 1, partition ID 72057594038779904, alloc unit ID 72057594039762944 (type LOB data): Page (1:24913) could not be processed. See other errors for details.
Repairing this error requires other errors to be corrected first.
反复运行它并不能减少错误，所以看起来 DBCC 无法修复它。
我的下一个想法是尝试识别并删除表中有问题的行。但是，当我尝试删除已知有问题的行时，它也出错了，所以我目前的想法是将已知良好的行提取到与旧表具有相同架构的新表中，删除旧表并重命名新表以匹配旧的。
这样做的问题是，SQL Server 没有提供可捕获的错误，而是在遇到问题行时简单地断开连接，因此我似乎无法找到一种编程方式来识别“好”行。
T-SQL 中是否有任何方法可以强制它提供一个很好的可捕获错误，以便我可以遍历表并提取好的行，或者 DBCC CHECKDB 的一些“高级”模式可能能够修复它在网络上的任何地方都不明显？