监控SQL日志文件

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

来源

2016-12-25 Hassanation

改变了我的答案，以反映我的简单恢复如何截断日志文件的修正。从本质上讲，它依赖于CHECKPOINTS，它会截断不活动的事务......这是它发展到可怕的规模的原因。 –

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

A）你在简单模式的数据库只能在事务日志截断事务创建CHECKPOINT时。
B）不幸的是，大/很多uncommitted transactions，包括BACKUP，创造SNAPSHOT，和LOG SCANs，除其他事项外将创建检查点那些阻止你的数据库，直到这些交易完成你的数据库将得不到保护。
您目前的系统依赖于您的.bak文件的正确版本，这取决于大小可能意味着数小时的潜在损失。

换句话说，它是荒谬的大小，因为你的数据库是无法创建检查点，以截断这些交易往往不够....

上的日志文件稍微注意一下

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

使用DBCC SQLPERF(logspace)查看您的日志文件有多少使用中，以及它有多大。一旦执行完整备份，日志文件将被截断为剩余的未提交/活动事务。在研究你的交易（不要与缩小尺寸相混淆）

几点建议：

您可以使用系统表看到最昂贵的高速缓存，频繁和活跃的计划。
您可以使用未公开的扩展存储过程fn_dblog来搜索日志文件。
皮纳尔对这个话题伟大的信息，你可以在这个网页和链接阅读： Beginning Reading Transaction Log

来源

2016-12-25 07:23:26

改变了答案，因为事实证明SIMPLE RECOVERY确实会截断日志文件....但是只有在创建CHECKPOINT之后....在这种情况下，由于数据库活动，这是不可能的。 –

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

你需要旋转你的日志，像logrotate，尽管从你的问题，它听起来像你使用的Windows，所以不知道这是什么解决方案。

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

因为它是与很多重复的文本，这将使文件非常小，比较，并应解决您的存储问题。

来源

2016-12-25 07:01:14

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

select log_reuse_wait_desc,database_id from sys.databases

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

我的理论是，可能有一些打开的交易，这阻止了日志空间的重用..log文件不收缩，一旦它变大..

由于知道你可以在DMV上面跑，并看到，此时阻止重新使用日志空间的原因是，您无法及时知道防止重复使用日志空间的原因

来源

2016-12-25 07:08:26 TheGameiswar

监控SQL日志文件

回答

相关问题