重新构建 HEAP 会导致停机吗？

Question

这是一个有点尴尬的问题，我不敢相信我已经错过了这么多年。

我有一个包含 401 个堆表的供应商第三方数据库。我最近开始使用 Brent Ozar 的脚本并设置sp_BlitzFirst为每 15 分钟运行一次以收集等待统计信息等。

它发现的是每次运行 24 小时期间，它都告诉我修复转发记录。可能会让一些读者感到震惊的是，我在 DMV 上运行了一个查询，并取回了一些包含超过 150,000 个转发记录值的表。

我明白要解决这个问题是在整个表中有一个聚集索引，或者作为运行ALTER TABLE [tablename] REBUILD.

然而，我无法找到的是这是否会使表脱机，以及在运行此命令之前我是否应该注意其他任何问题。

我正在使用 2008 R2 的企业版，我想知道以这种方式运行它是否会消除中断的需要？

ALTER TABLE [tablename] REBUILD WITH (ONLINE = ON);  

有人对这个有经验么？

Answer 1

好消息：150,000 条转发记录实际上并没有那么糟糕，这取决于我们谈论的时间跨度。只要服务器启动，就会跟踪转发的记录（在特定的 2012/2014 版本中存在一些关于错误的问题。）

即使它确实在线工作，您的用户也会注意到它，这取决于您的 IO 吞吐量、表的大小、非聚集索引的数量和您的工作负载。

这是我解决它的方法：

• 从最小到最大的表大小（不是转发记录的数量）列出带有转发记录警告的表
• 按顺序手动重建这些表，一次几个。不要自动执行此操作 - 您想了解系统如何响应重建小表。如果您的服务器可以跟上，您将很快学会。
• 密切关注您的事务日志使用情况。如果您的日志文件是 10GB，并且您正在尝试重建 50GB 的堆，那么您可能会遇到问题。您可以通过在维护窗口期间提前注销并在执行此操作时进行频繁的日志备份来缓解这些问题 - 但老实说，在几天内转发了 15 万条记录，我不会不用费心去完成这么多工作。
• 展望未来，与供应商合作在这些表上放置一个聚集键。是的，有时堆是合适的，但如果您遇到转发记录问题，您可能不会处于那些堆友好的情况之一。