tempdb中的索引重建任务对事务日志的影响？

Question

我已经阅读了很多关于索引维护以及重组、重建、在线、离线、TEMPDB 和时间安排的所有优点/缺点的文章，现在我比以往任何时候都更加困惑......

目标是用更灵活和碎片化驱动的解决方案替换一些简单的重建维护计划，以遵循最佳实践并执行所需的操作而不是不需要的操作。因此，按照Kendra Little和许多其他聪明人的类似建议，我转向了Ola Hallengreen 的解决方案。

到目前为止，一切都设置正确，按照Brent Ozar 的建议创建两个不同的工作（一个侵入性较小的工作，例如每天运行的重组/在线重建工作和一个周末工作，做更多的工作，可能是离线处理）并准备好了。

但我不确定，也不太关心（副作用）的影响。

因为我们有几个非常大的表，所以我试图根据我在这个问题中找到的以下代码，找出索引重建对事务日志的影响，观察日志文件大小和 entris 增长数：

backup log myDB to disk = 'NUL'
-- check log space/usage:
dbcc sqlperf (logspace)
-- query index log records 
SELECT LogRecordsGenerated = COUNT(*)  FROM sys.fn_dblog(NULL, NULL)  WHERE AllocUnitName = 'dbo.TableName.indexName' 
-- COMMINT THE INDEX OPERATION (Online / Offline)
-- Check the above values again...

令人惊讶的是，索引重建离线任务需要日志空间并生成事务日志条目，而在线则不需要！我期望它反过来......？

我找不到答案的问题是：

• 重建联机或脱机作业将如何影响日志文件增长？我该如何衡量？有没有更好的办法？
• 我必须在我的数据文件中为重建过程保留多少空间？我发现了大约 110%-120% 的索引大小的提示（例如在这个 MS 文档中）。如果我的所有索引一起使用大约 10 GB，是否意味着数据文件中必须有 12 GB 的额外大小可用？或者，顺序维护一个又一个索引的索引重建作业是否会重新使用可用空间并在完成索引后释放它？
• 如果我使用 SORT_IN_TEMP，事务日志增长也会发生在 tempdb 中吗？另外，如果它设置为简单恢复模式？

Answer 1

离线和在线重组/重建操作都会消耗日志空间。对于以任何方式修改数据库的所有操作都是如此，甚至对于最小日志记录操作（例如TRUNCATE TABLE. 这就是 SQL Server 维护事务一致性的方式。除非记录每个操作以便在必要时可以回滚或前进，否则“一致性”是不可能的。

\n\n

索引重组使用的日志空间比索引重建更少。重组会逐页对索引进行碎片整理，而重建则会创建正在重建的索引的全新副本，然后删除索引的旧副本。如果单个索引为 1GB，则重建它至少需要 1GB，再加上由于重建失败或被取消而可能发生的任何回滚的空间。由于任何回滚操作也会被记录，因此在所有事务开始之前会保留日志空间，以确保事务可以成功回滚。这表明索引重建所需的最大潜在日志空间将是重建操作开始时索引大小的两倍。因此，对于 1GB 索引，您应该确保在操作期间可以支持重建操作使用至少 2GB 的日志空间。这并不能保证会使用很多空间，它只是操作可能需要的最大空间。任何其他同时发生的事务都将需要额外的空间。

\n\n

任何消耗 tempdb 的操作也会消耗 tempdb 日志空间。如果启用SORT_IN_TEMPDB，则 tempdb 日志中需要足够的空间来支持对整个索引进行排序；这个数量很大程度上取决于索引的结构，包括键列的大小等。

\n\n

如果索引重组/重建操作是连续执行的，即一个接一个地执行，那么事务日志中将需要最大索引大小 x 2 的空间。即，如果最大索引是 1GB，为了安全起见，您需要确保 2GB 的事务日志可用于您的索引操作。如果在重组/重建作业时有效的简单日志记录，并且所有操作都不在单个事务中，则每个单独的操作将重新使用事务日志空间。如果启用了完整事务日志记录，并且在重组/重建作业期间没有发生事务日志备份，则日志大小需要为要重建的所有索引的总大小 + 要重建的最大索引的大小。通过在重建过程中运行日志备份作业可以在一定程度上缓解这种情况。

\n