在之前的一篇博客文章中，我谈到了“不赞成使用的”代码，并强调了这样一个事实，即在SQL Server 2008中不再允许使用NO_LOG和TRUNCATE_ONLY语句进行备份。我提到过，这些功能上等价的语句是截断日志和释放空间的一种快速方法。这些语句的缺点是，它们会破坏日志备份的“链”，使数据库暴露于潜在的数据丢失，直到可以进行完整的数据库备份为止。
好吧，微软试图保护我们免受自己的伤害，但是我们应该怎么做呢?好吧，官方的“SQL Server 2005中已弃用的数据库引擎特性”文档首先提到了“None”的替换。好吧，如果没有替代品我们该怎么办?该文档继续写道:“当数据库使用简单恢复模型时，事务日志会被自动截断”。这是正确的，但这意味着我们只能将数据库恢复到上次完整或差异数据库备份的时间。与完全恢复模型一样，在故障点之前没有恢复。您知道，我们不能在简单恢复模型中使用事务日志进行恢复。同样，该文档继续写道:“如果您需要从数据库中删除日志备份链，请切换到简单恢复模式”。(这意味着我们会尽快回到完全恢复的模式)。
同样，这是正确的，但这也破坏了日志备份的“链”，因此在可以进行完整的数据库备份之前公开数据库。所以我们又回到了起点。微软给了我们一个很好的解决方案，让我们可以回到以前的错误做法中去。那么我们该怎么办呢?实际上，我们使用NO_LOG或TRUNCATE_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操作。(信不信由你，由于事务日志的内部存储，有时我们不得不运行这个序列两次，以释放最大的空间。试试看吧!)因此，您保留了日志备份链并释放了空间。如果您找到的磁盘空间确实是临时的，您应该立即执行完全备份。然后继续正常的备份周期。使用这种方法，您在任何时候都不会将数据库暴露于潜在的数据丢失。当然，所有的备份和恢复过程都需要经过彻底的测试和记录，同时还要进行定期的消防演习。
这样，当灾难发生时，我们应该能够遵循一个简单的清单，并运行一些脚本。未恐慌。无需更新我们的简历。我们需要最坏的打算和最好的希望。这是关键。
好运！
布莱恩
最近的博客文章……
SQL Server 2008的组策略——声明式管理框架(DMF)
波士顿马拉松使用SQL Server -我希望我足够快来强调它!