该表的碎片级别为30-35％.在其中一些机器上,我收到“事务日志已满”错误并重新组织失败.事务日志大小高达48GB.有什么好办法来对付这个？我们没有打开自动增量,我不愿意这样做.
我可以将日志大小增加到更大的值,但随着表格大小的增加,值可能不够.如果我要平均增加日志大小,它也会破坏重新组织以回收空间的目的.关于如何有效对抗这个问题的任何想法？使用批量模式不是一种选择,因为数据丢失是不可接受的.
解决方法
the defragmentation is performed as a series of short transactions,
so a large log is unnecessary if log backups are taken frequently or
if the recovery model setting is SIMPLE.
你确定你不是在谈论重建吗？索引REBUILD速度慢,价格昂贵,消耗大量日志(如果不是脱机且不能是minimally logged,在线重建不能记录最少),是一个单一的巨型事务,不能在不丢失所有工作的情况下中断.
在我看来,你正在进行重建,这是一个非常特殊的操作,你不应该做,除非你有非常好的思想理由.你跳的是什么样的空间回收？ DBCC CLEANTABLE无法处理的任何事情？您是否检查了表的物理结构,是否已从逻辑结构中移出(有关详细信息,请参阅SQL Server table columns under the hood)？
如果你真的需要重建表格,那么我担心你别无选择,只能咬紧牙关并分配必要的日志.不要让它自动增长,它只会减慢这个过程.预先生长到桌子大小的2.5倍.
如果表已分区,则可以一次离线(并重新组织)一个分区.在线重建只能在整个表级进行.
