监视SQL日志文件

Question

在客户端计算机上部署项目后，sql db日志文件已增长到450G，尽管db大小小于100MB，日志记录模式设置为Simple模式，并且事务处理是从每隔30秒发送插入和更新事务的Windows服务发送。 我的问题是，如何知道db日志文件增长的原因？ 我想知道如何监视日志文件以了解导致问题的确切事务是什么。 我应该调试前端吗？或者存在暴露导致db日志文件增长的事务的地方。 谢谢。

Answer 1

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

• A）简单模式下的数据库只会截断事务日志中的事务，就像创建FULL RECOVERY时一样。

• B）不幸的是，大量/大量uncommitted transactions，包括BACKUP，SNAPSHOT和LOG SCANs的创建等等都将阻止您的数据库创建这些检查点，您的数据库将不受保护，直到完成这些交易。

• 您当前的系统依赖于您的.bak文件的正确版本，具体取决于尺寸可能意味着可能会有数小时的损失。

换句话说，这是荒谬的大小，因为您的数据库无法创建CHECKPOINT来经常截断这些事务....

  

关于日志文件的一点说明

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

使用CHECKPOINT查看您的日志文件的使用量和大小。执行完整备份后，日志文件将被截断为剩余的未提交/活动事务。 （不要混淆缩小尺寸）

关于研究交易的一些建议：

• 您可以使用系统表查看最昂贵的缓存，频繁和活动计划。
• 您可以使用未记录的扩展存储过程fn_dblog搜索日志文件。
• Pinal有关于此主题的精彩信息，您可以在此网页和链接中阅读： DBCC SQLPERF(logspace)

Answer 2

日志文件是文本，根据您的日志级别以及您收到的错误和消息的数量，这些文件可以非常快速地增长。

您需要使用logrotate之类的内容轮换日志，但是从您的问题来看，这听起来像是您正在使用Windows，因此不确定解决方案是什么。

日志轮换的基础知识是每日/每周版本的日志，并使用gzip或类似方法压缩它们并删除未压缩的版本。

由于文本有很多重复，因此这会使文件非常小，并且可以解决您的存储问题。

Answer 3

如果存在打开的事务，则

日志文件空间不会被重用。您可以使用以下DMV验证日志空间重用的原因..

select log_reuse_wait_desc,database_id from sys.databases

在您的情况下，您的数据库设置为简单，数据库为100 MB ..但日志已增长到450 GB ..这是非常巨大的..

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

据了解，您可以在DMV之上运行并查看此时阻止日志空间重用的内容，您无法及时回过头来了解阻止日志空间重用的原因