Question

我有一个5GB的数据库和一个20GB的事务日志（SQL Server 2005）。不知道为什么它如此之大或者发生了什么使它变大，它曾经是数据库大小的1/2。 DB增长约1GB /月。

是否有关于事务日志相对于数据库文件大小有多大的指导方针？

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

Answer 1

呃......请原谅明显的流血，但你有“BACKUP LOG”的预定备份

如果恢复模型已满，则需要进行此操作。

我还会包含其他罕见选项（并非详尽无遗）：

大表索引重建/维护。但是，备份日志将清除此信息。
打开事务，阻止备份日志删除条目（因此增长）
与SET IMPLICIT_TRANSACTIONS ON的连接（请参阅上一点）

Answer 2

除了检查数据库中使用的恢复模型之外，您还可以进一步了解“发生了什么事情以使其变得那么大” - 您可以阅读它并查看什么类型的交易以及它们中有多少都保存在日志中。此外，您可以检查交易发生的时间以及执行交易的人员

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

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

Answer 3

如果你有很多交易行为，那根本不常见。但是，您可能应该研究将其缩小的方法。有很多选择，但不知道你的恢复模型，我永远不会推测提出建议。从这个MSDN link开始，这个knowledge base article，然后从那里移动。小心。：）

Answer 4

就“这是正常的”而言，请记住，在您正确设置备份和检查点之前，事务会永久累积在日志中。例如，如果不这样做，数据库中的每条记录都至少有一个插入事务。

Answer 5

如果你的代码执行了很多事务（相对于数据库的实际大小），它肯定会使日志膨胀。

如果您现在没有，我肯定建议设置数据库维护计划来进行夜间备份（也许更频繁的事务日志备份）。通常，备份过程将在备份完成后将日志大小恢复到合理的状态。

就一般指南而言，我尽量将其保持在数据库大小的50％以下，尽管有了备份计划，我通常看不到我们的日志甚至接近它。

如果您不关心保留事务记录，这种类型的查询会缩小它，但我首先阅读了Shrinkfile。

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)

巨大的交易日志 - 这是正常的吗？

5 个答案: