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

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

在那里如何如何大的事务日志应该是相对于你的数据库文件大小的任何指引？

编辑：我不是说我的事务日志是巨大的（我知道有些数据库管理员会在我的威尼大小DB笑），只是相对于DB文件，我认为这是巨大的。

来源

2008-11-17 Kyle West

呃......原谅出血明显，但你已经计划以“BACKUP LOG”

备份如果恢复模式是FULL那么这需要发生。

有，我会包括（不是全部）等，罕见选项：

大表索引重建/维护。但是，备份日志将清除此问题。
打开的事务防止备份日志中删除条目（因此它的增长）
与SET IMPLICIT_TRANSACTIONS ON（见前面的点）

来源

2008-11-17 20:49:22 gbn

如果你有很多的交易行为，这并不罕见。但是，您可能应该调查使其更小的手段。对此有很多选择，但是如果不知道你的恢复模式，我绝不会推荐。从MSDN link开始，这个knowledge base article，然后从那里移动。小心。 :)

来源

2008-11-17 20:47:23

如果你有一些代码做了很多交易的（相对于数据库的实际大小），它肯定臃肿的日志。

如果你没有一个现在，我肯定会推荐建立一个数据库维护计划做的夜间备份（或许更频繁的事务日志备份）。通常，备份过程会在备份完成后将日志大小降低到合理的程度。

至于一般准则，我尽量保持它在数据库大小的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)

来源

2008-11-17 20:47:57 Otus

我们每3小时进行一次全备份和每3小时增量备份（我是偏执狂）...就交易而言..我们的应用程序大多是只读的（电子商务），所以不知道它为什么如此之大。 – 2008-11-17 20:50:06

来讲“这是正常的”，记住，交易积累的连接永远记录日志，直到您正确设置备份和检查点。例如，如果你不这样做，数据库中的每个记录至少有一个插入事务。

来源

2008-11-17 21:08:05 dkretz

再说什么恢复模型的数据库上使用的检查，你可以更进一步关于“发生了什么事弄得这么大” - 你可以阅读一下，看看交易的是什么类型和多少他们被保存在日志中。此外，您可以检查时，交易发生，谁执行他们

要做到这一点，您可以使用原生的SQL Server功能fn_dblog，DBCC PAGE或fn_dump_dblog或一些第三方工具。但是，原生函数没有记录，很难理解它们提供的结果。至于第三方工具，你可以查询详细的什么需要读取事务日志信息

免责声明Open LDF file and view LDF file content网上的文章，更深入的分析：我作为ApexSQL

产品支持工程师工作

来源

2014-02-07 17:45:32

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

回答

相关问题