sql-server – 如何在索引重组期间防止事务日志变满？

发布时间：2020-12-12 06:20:21 所属栏目：MsSql教程来源：网络整理

导读：我们有多台机器,我们预先将事务日志的大小分配给50gb.我试图重组的表的大小是55 – 60 GB,但是会不断增加.我想重组的主要原因是收回空间和任何表现上的好处,因为这是一个额外的好处. 该表的碎片级别为30-35％.在其中一些机器上,我收到“事务日志已满”错误并

我们有多台机器,我们预先将事务日志的大小分配给50gb.我试图重组的表的大小是55 – 60 GB,但是会不断增加.我想重组的主要原因是收回空间和任何表现上的好处,因为这是一个额外的好处.

该表的碎片级别为30-35％.在其中一些机器上,我收到“事务日志已满”错误并重新组织失败.事务日志大小高达48GB.有什么好办法来对付这个？我们没有打开自动增量,我不愿意这样做.

我可以将日志大小增加到更大的值,但随着表格大小的增加,值可能不够.如果我要平均增加日志大小,它也会破坏重新组织以回收空间的目的.关于如何有效对抗这个问题的任何想法？使用批量模式不是一种选择,因为数据丢失是不可接受的.

解决方法

REORGANIZE(在ALTER INDEX … REORGANIZE中)是一个非常快速的操作(好吧,主要是……),它需要少量的日志,可以随时中断并在以后恢复,并在 small batch transactions内部工作：

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倍.

如果表已分区,则可以一次离线(并重新组织)一个分区.在线重建只能在整个表级进行.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!