Sql server 巨大的事务日志-这正常吗？

我有一个5GB的数据库和一个20GB的事务日志（SQLServer2005）。不确定它为什么这么大，或者是什么原因使它这么大，它过去的大小大约是DB的1/2。DB的增长速度约为1GB/月

对于事务日志相对于数据库文件大小应该有多大，是否有任何指导原则

---

编辑：我不是说我的事务日志很大（我知道有些DBA会嘲笑我的小数据库），只是相对于数据库文件，我认为它很大。

如果你有很多事务行为，这一点也不少见。然而，您可能应该研究使其变小的方法。这方面有很多选择，但在不了解您的恢复模型的情况下，我永远无法提出建议。从这个开始，这个，然后从那里开始。小心地……）

如果您的代码执行大量事务（相对于数据库的实际大小），那么它肯定会使日志膨胀

如果您现在还没有，我绝对建议您设置一个数据库维护计划来进行夜间备份（可能还有更频繁的事务日志备份）。通常，备份过程会在备份完成后将日志大小恢复到合理的大小

作为一般性的指导原则，我尝试将其保持在数据库大小的50%以下，尽管在备份计划中，我通常看不到我们的日志会接近这一点

如果您不关心保留事务记录，这种类型的查询将对其进行收缩，但我会先阅读收缩文件

Backup Log DatabaseName With Truncate_Only
GO

Declare @LogFileLogicalName sysname
select @LogFileLogicalName=RTRIM(Name) from sysfiles where filename like '%.ldf%'
--SELECT @LogFileLogicalName
DBCC Shrinkfile(@LogFileLogicalName,2)

---

呃。。。请原谅明显的出血，但是您是否有带有“备份日志”的定时备份

如果恢复模式已满，则需要这样做

我还将包括其他罕见的选项（并非详尽）：

• 大型表索引重建/维护。但是，备份日志将清除此项
• 阻止备份日志删除条目的打开事务（因此它会增长）
• 与的连接（参见上一点）

---

关于“这是否正常”，请记住，在正确设置备份和检查点之前，事务将永远累积在日志中。例如，如果您没有做到这一点，那么数据库中的每个记录都至少有一个insert事务。

除了检查数据库中使用的恢复模型外，您还可以进一步了解“是什么使它变得如此庞大的””-您可以阅读它并查看什么类型的事务以及日志中保存了多少事务。此外，您还可以检查事务发生的时间和执行者

为此，您可以使用本机SQL Server函数fn_dblog、DBCC PAGE或fn_dump_dblog或某些第三方工具。但是，本机函数没有文档记录，很难理解它们提供的结果。对于第三方工具，您可以查看在线文章，以了解更多详细信息和对读取事务日志信息所需的更深入分析

---

免责声明：我在ApexSQL担任产品支持工程师

我们每晚做一次完整备份，每3小时做一次增量备份（我有点偏执）。。。就交易而言。。我们的应用程序大多是只读的（电子商务），因此不知道它为什么如此庞大。我认为日志备份部分是可选的，因此可能是备份计划中没有打开它（gbn的回答是：这&其他可能性，如恢复模型也很有帮助）。