如何防止索引重组期间事务日志变满？

我们有多台机器，我们已将事务日志的大小预分配为50gb。我尝试重新整理的表格大小为55-60 GB，但会不断增加。我要重组的主要原因是要回收空间和任何性能收益，因为这是额外的好处。

该表的碎片级别为30-35％。在其中一些计算机上，我收到“事务日志已满”错误，并且重组失败。事务日志大小达到48gb。有什么好方法可以解决这个问题？我们没有打开自动增量功能，我不愿意这样做。

我可以将日志大小增加到一个更大的值，但是随着将来表大小的增加，该值可能会不够。如果我要平等地增加日志大小，它也会破坏进行重组以回收空间的目的。关于如何有效应对这一问题的任何想法？由于无法接受数据丢失，因此无法使用批量模式。

最佳做法是将REORGANIZE碎片分散到大约30％REBUILD以下。简单地，REBUILD制作一个干净的副本，REORGANIZE就地完成。

检查您的实际操作：您没有同时执行的维护计划吗？

在较大的表（50GB的表已到达该表）上，REORGANIZE如果遵循此规则，我会消耗掉所有事务日志空间。并不经常：只有一个具有特定负载模式的系统。在REORGANIZE刚跑，直到日志扩大和消费的所有磁盘空间。

我们改用REBUILD其他问题，但忽略了低于25％的碎片。这对我们来说效果更好：您必须查看它是否对您有用。

REBUILD可能对性能的影响要比REORGANIZE对生产的影响大，但是有时可以通过使用ONLINE选件（需要企业版）来缓解。

REORGANIZE（如ALTER INDEX ... REORGANIZE）是一种非常快速的操作（嗯，主要是...），它需要少量的日志，可以随时中断并稍后恢复，并且在小批量事务中在内部工作：

碎片整理是作为一系列短事务执行的，因此，如果频繁进行日志备份或恢复模型设置为SIMPLE，则不需要大日志。

您确定不是要进行重建吗？索引REBUILD速度慢，价格昂贵，消耗大量日志（如果不是脱机且无法最小化日志，则不能最小化记录在线重建），它是一个巨大的事务，并且在不丢失所有工作的情况下不能被中断。

在我看来，您正在进行重建，这是一个非常特殊的操作，除非您有深思熟虑的理由，否则不应该这样做。您希望获得什么样的空间回收？有什么DBCC CLEANTABLE不能处理的吗？您是否检查过表的物理结构，它是否偏离了逻辑结构（有关详细信息，请参见幕后的SQL Server表列）？

如果您确实需要重建表，那么恐怕您别无选择，只能忍耐一下并分配必要的日志。不要让它自动增长，只会减慢该过程。将其预增长到表大小的2.5倍。

如果表已分区，则可以一次离线重建（并重新组织）一个分区。联机重建只能在整个表级别进行。

我以前有过这个问题。

• 您有一个大数据库和一个小日志驱动器。您想进行重组（出于多种原因）。
• 在较大的碎片表上尝试执行此操作时，日志将填满，直到日志驱动器已满，然后命令中止。
• 如果处于简单模式，则其他事务可能会失败，直到在下一个检查点中清除日志为止；如果处于完全模式，则其他事务可能会失败，直到下一个日志备份为止。断电！
• 如果您处于完全模式，则可以增加日志备份频率，但是由于重组是在隐式事务中完成的，因此无法避免该问题，直到事务完成或中止或停止该事务后，日志才会清除。
• 您真的希望重组可以完成。

这有点违反直觉，因为您知道如果中止重组，它可以从中断处继续执行，只是中止会提交事务而不是回滚。

这就是你要做的。它有点长，但是很简单。

• 将日志文件预增长到相对较大的大小，但不能达到最大。基本上，您想留出足够的空间来做有用的工作，如果有的话，还要有一些小的增长，以便正常操作不会停止。
• 创建一个作业以运行索引重新组织（“ Reorganize”）。

• 在性能情况下创建代理WMI警报（“重新组织放泄阀”）。

  • 对象：SQLServer：数据库
  • 计数器：已用百分比日志
  • 实例：（您的大数据库名称）
  • 计数器升至上方时发出警报：80
  • 响应：执行作业（“重新组织检查”）

• 创建工作（“重新组织检查”）

  • 在作业中，检查msdb.dbo.sysjobactivity，以查看“重组”作业是否正在运行。如果是...
  • 停止作业并轮询直到停止。这可能需要几秒钟。
  • （如果处于完整模式）触发日志备份作业并确认完成时间。
  • 仔细检查sys.dm_os_performance_counters，您的日志可用空间计数器已减少到阈值以下。
  • 开始“重组”工作。

• 在将其粘贴到生产服务器上之前，甚至在开发沙箱中都进行测试，以确保其正常运行。

您将看到“重新组织”作业开始，并开始填充日志。当日志达到已满百分比时，它将触发WMI警报（大约30秒内），该警报将运行您的其他作业，该作业会看到“重新组织”作业正在运行，并且很可能出错。然后，它将停止“重新组织”，进行备份，确认日志可用空间恢复到合理的值，然后再次启动“重新组织”作业，该作业将从上次中断的地方继续进行。

因此，在这种情况下，您可以将日志预先调整为合理的大小是为了减少增长/触发/作业/停止/重新启动的次数，这样可以提高效率，并为没及时赶上的偶然增长。

这是一种奇怪的情况。我敢肯定，几年前我对此不屑一顾，显然这里存在一些基本的潜在问题。但是，如果您要处理数百台服务器，那么无论出于何种业务原因，此类边缘情况都将无法解决，除非通过MacGyvering临时解决方案来完成任务。

只要它是安全的，合乎逻辑的，经过测试的并且有据可查的，就应该没有问题。

这是我通常所做的（我也有一些表，每个表有80 + GB大）用于索引重组（因为可以随时停止索引重组而不会失去以前的重组工作）。

1. 在索引重组期间，我会将日志备份从我的常规30分钟频率增加到每10分钟频率
2. 我有另一个会话每隔1分钟执行一次tlog可用空间检查，如果tlog可用空间低于阈值，我将停止索引重组会话并开始（或等待）tlog备份。然后重新启动索引重组。

在索引维护框架中，我将索引分为两类，一组用于索引重建，另一组用于索引重组。对于索引重建，我将使用一些不同的方法，因为我不想停止索引重建会话（这将导致回滚并丢失所有先前的工作）。在索引重建期间，如果我的监视会话发现一个tlog文件可用空间已用完方案，则该监视会话将自动预增加该tlog文件，在最坏的情况下（即磁盘已满），我的监视会话将创建另一个日志文件（但稍后我将其放到另一个驱动器（备份驱动器）上

我和问题作者有同样的问题，看看他的评论，我可以说我有相同的设置。当我尝试执行时REORGANIZE，无论大小如何，日志都会增长为满，甚至达到整个表大小的几倍。

该问题是由事务复制引起的。显然，在REORGANIZE操作完成之前，无法备份日志。我在某处读到它是Microsoft已知的问题，但我不确定在哪里。

禁用事务复制后，日志备份将再次正常工作，并且每30秒进行一次日志备份，同时进行重组对我来说效果很好。

我假设您正在执行以下操作：

重新组织索引

不幸的是，无法运行部分组织（例如，可以部分收缩日志文件的方法）。我可以解决此问题的方法是：

1）在运行重组时将数据库设置为简单恢复模式，但是您说这是不可接受的

2）对索引进行分区-如果可以想到一种对索引进行分区以获得大致相等大小的分区的方法，则您将能够独立地重新组织（或使用在线选项重建）每个分区，从而限制日志文件的增长

我确定您正在执行此操作，但是如果不这样做，则可能需要在进行任何索引优化之前和之后启动日志文件备份，这将允许它回收已用空间。