【发布时间】：2015-08-31 23:08:58
【问题描述】：
假设我们有两个节点参与 SQL 2012 AO。这是一个测试实例。在一次索引重建操作期间，日志变得非常大（250 GB）。由于空间限制，我们无法备份它。如果我们将 Tlog 备份到 Nul（只是为了缩小它）会怎样——这会破坏 Always On 吗？
【问题讨论】：
【发布时间】：2015-08-31 23:08:58
【问题描述】：
AlwaysOn 是一个（营销）总称，涵盖可用性组 (AG) 和故障转移集群实例 (FCI)。从上下文来看，我假设您是在询问 AG？
对于 FCI 和 AG，简短的回答是相同的：执行事务日志备份（无论目标如何）不会“破坏”您的 HA 功能。但是，我会敦促您永远不要备份到 NUL:，除非您不关心数据库中的数据。将日志备份到 NUL：（无论您使用的是 AG、FCI 还是两者都不使用）会破坏您的日志备份链，并阻止时间点恢复。
如果您使用的是可用性组，SQL Server 不会使用事务日志备份 在节点之间进行同步。它使用事务日志本身，因此如果有日志数据需要同步到另一个节点，则不会清除事务日志。也就是说：如果您的 AG 同步落后，您的事务日志将继续填充/增长，直到同步赶上，无论执行多少事务日志备份。
您的事务日志可能会继续增长有多种原因，而 AG 同步只是其中之一。如果 SQL Server 由于 AG 中的事务不同步而无法重用事务日志，sys.databases 中的log_reuse_wait_desc 列将显示值“AVAILABILITY_REPLICA”。
回到你的根本问题：重建索引让你的事务日志变得非常非常大。
当您执行ALTER INDEX...REBUILD 时，SQL Server 会创建整个新索引（数据大小操作），并且如果索引创建出错或在完成之前被终止，则必须能够回滚。因此，您可能会看到sys.databases 中的log_reuse_wait_desc 列在非常大、长时间运行的索引重建期间显示为“ACTIVE_TRANSACTION”。重建本身会阻止您重用日志，并会导致日志增长。
【讨论】：