监视SQL日志文件

Question

在客户端机器上部署项目后，sql db日志文件已增长到450 g，尽管db大小小于100 db，但日志记录模式设置为简单模式，事务从每30秒发送一次插入和更新事务的windows服务发送。我的问题是，如何知道数据库日志文件增长的原因？我想知道如何监视日志文件，知道导致问题的确切事务是什么。我应该调试前端吗？或者公开导致db日志文件增长的事务。谢谢。

Answer 1

请注意，简单的恢复模型不允许日志备份，因为它保存的信息量最少，并且依赖于CHECKPOINT，因此如果这是一个关键数据库，请考虑使用完全恢复计划保护客户端。是的，您必须使用更多的空间，但是磁盘空间很便宜，您可以更好地控制时间恢复和管理日志文件的时间点。力求简明扼要：

• ( A)简单模式下的数据库只会截断事务日志中的事务，就像创建CHECKPOINT时一样。
• ( B)不幸的是，大量/大量的uncommitted transactions (包括BACKUP、创建SNAPSHOT和LOG SCANs等)将阻止数据库创建这些检查点，在这些事务完成之前，数据库将不受保护。
• 您的当前系统依赖于您的.bak文件的正确版本，这取决于大小可能意味着小时的潜在损失。

换句话说，这是荒谬的大小，因为您的数据库无法创建一个检查点来截断这些事务.

日志文件上的一点注释

最重要的是，日志文件不会在每次提交事务时自动截断(否则，您将只有最后一个提交的事务要返回)。频繁地进行日志备份将确保保持相关的更改(时间点)，SHRINKFILE将将日志文件压缩到最小的可用大小/指定大小。

使用DBCC SQLPERF(日志空间)查看您的日志文件中有多少正在使用，它有多大。执行完整备份后，日志文件将被截断为剩余的未提交/活动事务。(不要将此与缩小大小混淆)

关于研究你的交易的几点建议：

• 您可以使用系统表查看最昂贵的缓存、频繁和活动计划。
• 您可以使用无文档的扩展存储过程( fn_dblog )搜索日志文件。
• 皮纳尔有关于这个主题的很好的信息，你可以在这个网页和链接上阅读：开始读取事务日志

Answer 2

日志文件是文本，取决于日志级别和接收这些文件的错误和消息的数量，这些文件的增长非常快。

您需要使用类似于对数旋转的东西来旋转日志，尽管从您的问题中听起来您使用的是Windows，所以不确定解决方案是什么。

日志轮转的基础是每天/每周版本的日志，并使用gzip或类似的方法压缩日志，并破坏未压缩版本。

由于这是大量重复的文本，这将使文件相比非常小，并应解决您的存储问题。

Answer 3

日志文件空间不会被重用，如果有打开的transaction..You，可以验证日志空间重用的原因。

select log_reuse_wait_desc,database_id from sys.databases

在你的例子中，你的数据库被设置为简单，数据库是100 MB..but，日志已经增长到450 GB..which是非常巨大的。

我的理论是，可能有一些开放的事务，这阻止了日志空间的reuse..log文件不会收缩，一旦它增长。

据了解，您可以运行在DMV以上，并看到，什么是阻止日志空间重用在这一点上，您不能回到过去，以了解是什么阻止了日志空间重用