在之前的一篇博客文章中，我谈到了“Deprecated”代码，并强调了SQL Server 2008不再允许BACKUP LOG WITH NO_LOG和BACKUP LOG WITH TRUNCATE_ONLY语句。我提到过，这些功能上等价的语句是截断日志和释放空间的一种快速方法。这些语句的缺点是，它们会破坏日志备份的“链”，使数据库暴露于潜在的数据丢失，直到可以进行完整的数据库备份。
好吧，微软试图保护我们不受自己的伤害，但我们应该怎么做呢?好的，官方的“SQL Server 2005中已弃用的数据库引擎特性”文档首先是指“None”的替换。好吧，如果没有替代品，我们该怎么办?该文档接着说:“当数据库使用简单恢复模型时，事务日志将被自动截断”。这是正确的，但这意味着我们只能将数据库恢复到上次完全或差异数据库备份的时间。与完整恢复模型一样，在故障点之前没有恢复。您可以看到，我们不能使用事务日志对Simple恢复模型进行恢复。同样，该文档继续写道:“如果您需要从数据库中删除日志备份链，请切换到简单恢复模式”。(这意味着我们将尽快切换回完全恢复模式)。
同样，这是正确的，但这也破坏了日志备份的“链”，因此公开数据库，直到可以进行完整的数据库备份。所以我们又回到了起点。微软给了我们一个很好的解决方案，让我们回到我们以前可以做的坏做法。我们该怎么做?实际上，我们使用NO_LOG或truncat_only选项的主要原因是磁盘空间已用完。在那些日子里，磁盘空间是有点稀缺和昂贵的。这个问题的真正解决方案是在某个地方找到一些磁盘空间，甚至是临时磁盘空间，并将日志备份到那里。(磁带备份没问题，但需要更长的时间)。然后继续正常操作，因为正常的BACKUP LOG语句将同时备份和截断日志。注意，截断将释放事务日志中用于新事务的空间，但不会减少日志文件本身的大小。 If the transaction log is growing too large then you should increase the frequency of log backups. (The Full database backup does not actually truncate the transaction log at all).
如果需要恢复事务日志中的空闲空间，还需要执行一个SHRINKFILE操作。(信不信由你，由于事务日志的内部存储，有时我们不得不运行这个序列两次以释放最大的空间。试试看!)。因此，您保留了日志备份链，同时也释放了空间。如果您找到的磁盘空间确实是临时的，则应该立即执行Full备份。然后继续正常的备份周期。使用这种方法，您就不会暴露数据库可能的数据丢失。当然，所有的备份和恢复过程都需要经过彻底的测试和记录，以及定期的消防演习。
这样，当灾难发生时，我们应该能够遵循一个简单的检查表并运行一些脚本。没有恐慌。不需要更新我们的简历。我们需要做最坏的打算，抱最好的希望。这是关键。
好运！
布莱恩
最近的博客文章……
SQL Server 2008的组策略-声明式管理框架(DMF)
波士顿马拉松使用SQL Server -我希望我能足够快地强调它!