?

?最好的方法是判断镜像问题的原因并解决它。例如，调优生成大量日志记录的操作，例如大容量加载数据，或者重组索引，在操作期间可以减少对系统的影响。

?

处理事务日志满错误

最坏的情况，事务日志管理不当或突发、快速的日志增长会造成事务日志增长，最后吞食完硬盘上所有可用空间。到这个时候就不能增长了，你会遇到9002错误，事务日志满错误，数据库会变成只读。

?

尽管这个问题很紧迫，冷静面对很重要，避免这类接下来会提到的”无意识“的解决方法，处理不当或做不该做。显然当前的问题是让SQL Server可以继续写日志，通过生成更多可用空间。如果起因是缺少日志备份，第一个要做的是重新运行代码7.1；如果log_reuse_wait_desc列返回值是 Log Backup，那么和可能这是问题原因。一个在MSDB数据库里对backupset表的查询，如代码7.10所示，会确认是否要在数据库上进行一次日志备份，还有上一次日志备份的时间。

?

1 USE msdb ;

2 SELECT ? backup_set_id ,

3 ? ? ? ? ?backup_start_date ,

4 ? ? ? ? ?backup_finish_date ,

5 ? ? ? ? ?backup_size ,

6 ? ? ? ? ?recovery_model ,

7 ? ? ? ? ?[type]

8 FROM ? ? dbo.backupset

9 WHERE ? ?database_name = 'DatabaseName'

?

（代码7.10：哪个备份已做，什么时候做的）

?

在type列，D代表数据库备份，L代表日志备份，I代表差异备份。如果没有日志备份，或者它们并不频繁，那么你最好的做法是进行一次日志备份（这里假定数据库运行在完整或大容量日志恢复模式）。希望，这个能释放日志里的实在空间，然后你可以进行合适的日志备份计划和日志增长管理策略。

?

如果因为某些原因不能进行日志备份，例如磁盘空间不足，或者进行日志备份的时间超过可接受的问题解决时间，那么，取决于对问题数据库的灾难恢复策略，或许可以通过临时切换到简单恢复模式来强制日志截断，这样在检查点的时候日志中不活动的VLF会被截断。然后你可以切换回完整数据库恢复模式，进行新的完整数据库备份（或差异备份，这里假定先前已经有一次完整备份）来重新开始用于时间点恢复的日志链。当然，你还是充分调查问题，来保证空间不会再次直接吞食完。还有记住这点，刚才讨论过的，如果阻止空间重用的问题不是日志备份，那么这个技术就无效了，因为这些记录会保留在活动日志里，阻止截断。

?

如果缺少日志备份不是问题，或者进行完日志备份不能解决问题，那么调查原因可能会花更多的时间。最快和最简单的方法是在日志硬盘上增加更多的空间。这表示要清理掉其他文件，或者增加当前日志硬盘的容量，或者在不同的硬盘列里增加额外日志文件，但这会占用你一点喘息的空间，你需要让数据库摆脱只读模式，然后进行一次日志备份。

?

如果日志备份释放空间失败，你要找出什么阻止了日志里的空间重用。调查下sys.databases（代码7.1）来找出什么阻止了日志空间重用，采取合适的行动，如刚才缺少日志空间重用部分介绍的。

?

如果这个啥都没透露，你需要进一步调查找出什么操作造成过度日志导致日志增长，如事务日志过度增长部分介绍的。

?

最后，解决了任何空间重用问题，很可能我们的日志文件会在磁盘上占用很大的空间。作为一次性的测量，例如假定我们采取措施保证日后日志增长有妥善的管理（下一部分就会谈到），是可以使用DBCC SHRINKFILE来回收臃肿事务日志文件使用的空间。在第8篇我们会提供如何做的例子。

?

我们要么指定收缩日志的文件target_size，要么指定0位目标大小，让日志收缩的尽可能小，然后立即使用ALTER DATABASE来调整到合适的大小。后者是推荐的方法，它会最小化日志文件的碎片。碎片问题是你应该从不定期进行的DBCC SHRINKFILE任务的主要原因，因为它只用来控制日志大小；我们会在下个部分详细讨论这个。

?

处理不当和不该做的事

?

遗憾的是，在网络上搜索”事务日志满“会返回大量 论坛的帖子，博客文章，甚至很多复制于SQL Server网站的文章，那些建议矫正的方法，坦白说，很危险。我们在这里会谈其中一些流行的建议。

?

分离 数据库，删除日志文件

?

这个方法，你清理了所有用户的数据库，分离数据库（或者关闭它），删除日志文件（或重命名），然后重新附加数据库，会引起新的日志文件创建，它的大小由model数据库决定。这可以说是处理完整事务日志的最可怕的方式。它会造成数据库启动失败，数据库为RECOVERY_PENDING状态。

?

取决于数据库在日志删除时是否正常关闭，在数据库正常部分的恢复阶段，数据库可能不能进行撤销和重做操作，因为事务日志已经丢失，不能返回数据库为一致的状态。当日志文件丢失时，数据库需要事务日志来进行故障恢复，数据库不能正常启动，只能从最近的可用备份里恢复数据库，这就会导致数据丢失。

?

创建，分离，附加，修复可疑数据库

?

在特定情况下，可以黑入现存的数据库的配置，允许事务日志重建，但这会破坏数据库里现有数据库的完整性。这类操作是，最好是最后实在绝对没法恢复数据库数据了，这是我们这个系列文章不推荐的做法。至于如何尝试黑入数据库来看已删除的事务日志，可以看下Paul Randal的文章：创建，分离，附加，修复可疑数据库。

?

强制日志文件截断

?

在SQL Server 2000 和2005，BACK LOG WITH TRUNCATE_ONLY是SQL Server支持的强制截断事务日志的方法，在数据库运行在完整或大容量日志模式。使用这个命令实际不会做日志内容备份副本；在截断VLF里的记录会忽略。因此，不像正常日志备份，你在破坏你的LSN链，你只能恢复数据库到先前任何日志备份里的时间点。还有，即使数据库设置为完整恢复模式，实际上，从那个点开始，会运行在自动截断模式，在检查点会继续截断不活动的VLF。为了让数据库运行在完整恢复模式，重新开始LSN链，你需要进行一次完整（或差异）备份。

?