?

不要使用这里的任何技术。强制日志截断的正确方法是临时切换数据库导简单恢复模式，如前所述。

?

计划事务日志收缩

如在处理事务日志满错误部分讨论的，事务日志在很少情况下是因为管理不当造成的，日志增长正被活动管理，使用DBCC SHRINKFILE来回收事务日志占用的空间是个可以接受的操作。

?

但我们绝不能把日志收缩作为日常，计划维护操作的一部分。原因是我们每次收缩日志，它会为接下来的事务立即再次增长来存储日志记录。如在日志大小和增长部分讨论的，事务日志不能利用即时文件初始化，因此所有日志增长引发SQL Server需要分配的存储空间填零操作。另外，如果我们依赖事务日志自动增长（下部分会谈到），在日志文件了会聚集更多的VLF，这个日志碎片会影响任何需要读取这个日志文件的进程性能，如果碎片实在太多，也会影响到数据修改性能。

?

对于事务日志文件的最佳做法是预先设置好它的合适大小，这样的话正常情况下就不会增长。然后，监视它的使用率来决定是否需要人为增长，允许你决定合适的增长大小且决定要添加到日志文件里的VLF的大小和个数。在第8篇我们会具体讨论。

?

妥当的日志管理

?

没有任何意想不到的操作或问题而导致不正常的日志增长（复制问题，未提交的事务等等），如果事务日志关联的数据库运行在完整恢复模式，还一直增长，其实只有2个原因：

?

日志文件大小太小，支持不了当前数据库所发生的数据修改。

?

日志备份的频率不够，满足不了日志文件里快速空间重用。

?

最好的做法，如果你不能通过减少它们之间的时间来增加日志备份的频率，当在加载的时，可以人为增加日志文件大小而不是让它自动增长，然后恢复原来大小。有大的我们人为增长的事务日志文件，但有最小化数量的VLF并不是个坏事，即使大部分时间日志文件有空余空间。我们会在第8篇详细讨论这个。

?

小结

?

对于SQL Server数据库的操作，事务日志非常重要，还有在灾难事件里能最小化数据丢失风险。在日志疯狂增长的情况里，甚至满了，DBA需要快速诊断并解决问题，同时要保持冷静也非常重要，避免不深思熟虑的反应，例如强制日志截断，还有计划定期的日志收缩，这只会弊大于利。