小编Dat*_*ill的帖子

让我在这篇文章的序言中说，我在跟踪中遗漏了一些事件，但我已经添加了它们，以便下次发生这种情况时添加它们。

最近，我们在我们的环境中看到了 HADR_SYNC_COMMIT 等待类型的奇怪激增（~40k tran/s）。今天的“事件”发生在凌晨4点58分：

在继续之前，我必须补充一点，我们正在对一个大型审计表进行在线索引维护（从 OLTP 表触发器大量记录到此审计表的意义上进行审计），并且索引重建本身被阻止约 22 秒。显然，这在这个特定实例中发挥了作用，但我不太确定它与 HADR_SYNC_COMMIT 有何关系。此外，我们在白天不进行索引维护时也看到过这种情况发生。

查看跟踪，这是我在主设备上看到的：

...以及辅助设备上的所有内容：

...最后回到主要：

2023 年 12 月 1 日凌晨 4:11 左右再次发生了类似的问题，我相信我明白发生了什么。不幸的是，我没有针对这种情况的扩展事件，但我确实有一些日志记录可以描绘出更清晰的画面。从 2023-12-01 04:10:18.5430090 开始，Ola 的索引维护记录了相关数据库上索引的开始时间。Ola 报告的完成时间为 2023-12-01 04:11:13.9431563，但我相信实际 REBUILD WITH ONLINE = ON 完成的时间要早​​得多。

在查看 DPA 时，我注意到 pagelatch_sh 和 pagelatch_ex 等待时间在凌晨 4:11:03-4:11:04 出现峰值：

紧接着这些等待，同一个查询开始看到 HADR_SYNC_COMMIT，并且这些相同的等待在凌晨 4:11:13-4:11:14 完全消失，这正是 Ola 报告索引完成的时间。我的假设是索引 REBUILD 是在凌晨 4:11:03 提交的（大约需要 45 秒的工作），这导致同一数据库中的不相关 INSERT 查询只是等待所有这些日志块在辅助数据库上硬化。一旦索引完成，剩余的日志块就会立即硬化，因为它们只是微小的插入。

我有一个 1 TB 的数据库，其中包含数百个季度存档表，我希望删除任何早于 5 个财务季度的表，这将释放约 600 GB 的空间。提供一个表架构的示例：

myTable myTable_Q4_21 myTable_Q3_21 myTable2_Q4_21 myTable2_Q3_21

我想知道在删除这些表并缩小数据库以回收新释放的空间后，是否需要 ALTER..REBUILD 每个剩余的 HEAP 表或在每个表上放置一个 CX 并随后将其删除。