一个常见的问题，学生带来的上课的时候，我的教学是这样的：“我的事务日志是完全不成比例生长出来 - 我该怎么办？”我总是一个问题回答“你是否支持它？”学生通常回答说：“当然，我们的备份整个数据库每天晚上”。“但是你备份日志？”此时学生让我知道，如果我们解决这一难题，老板会感觉之类的成本是值得的那里，然后。那么，答案，相信与否，是备份日志的两倍。是的，两次。让我解释...
正如我在前面的博客讨论，备份事务日志不仅备份日志中最新提交的事务也将截断日志文件。截断意味着备份的交易都是从日志文件中删除，新的事务日志文件中腾出空间。事实是，如果你没有备份事务日志，它会继续永远增长，直到你的磁盘空间用完。新DBA对SQL Server的假设完整数据库备份截断事务日志 - 事实并非如此。它确实需要事务日志的快照在最后，这样一个长期运行的完整备份过程中犯下的交易实际上是备份太（这是很聪明的），但它不会截断日志。所以学生来上课与拥有16GB事务日志100MB数据库。让人惊讶。那么，长期的解决办法是备份事务日志频繁。这将保持事务日志“精益和均值”。但如何频繁频繁？ Well, it depends. Generally, we try to keep the transaction log under 50% of the size of the data files. If it grows beyond this, then we back it up more frequently. This is why for some very active databases, we may backup the log every 15 minutes. As I said, it depends.
好了，让我们回到了16GB的日志文件。我们应该做些什么来把它恢复到一个合理的规模？那么，备份日志首先的。它包含了一些宝贵的更新。这将截断日志，但不会使文件的任何小。那么其次，执行DBCC SHRINKFILE操作。现在，我们这样做的时候，我们可能看不到任何收缩（你看到了Seinfeld情节？我离题了...）。因此，让我们参考联机丛书中的智慧，其中规定：“它可能需要两个备份实际释放的空间”。是的，如果一开始你没有成功，再试一次。实际的解决方法是运行两次备份日志/ DBCC SHRINKFILE序列！
第二次左右，你应该看到显著收缩。（对不起，乔治！）
后来，
布赖恩
管理事务日志文件（在MSDN）的大小：