主页 / dba / 问题 / 196893
Accepted
Alexei
Asked: 2018-02-03 02:35:14 +0800 CST

有没有办法限制 SQL Server 中事务的日志文件使用？

  • 772

这个问题是对这两个问题的跟进：

从第二个开始，我发现一个粗心的 SQL 用户可能会留下一个运行时间很长的事务，并导致为日志文件分配大量磁盘。

第一种表示可以通过job来实现一定时间后kill一个事务，但是不推荐这种方式。

如果我确定针对数据库打开的所有事务都不应该分配超过一定数量的日志，有没有办法找出为 SPID 分配了多少日志，这样我就可以杀死它？

简而言之，我对限制事务的最大日志文件使用量感兴趣。

问题：有没有办法限制 SQL Server 中事务的日志文件使用？

sql-server sql-server-2014

2 个回答

  1. Best Answer

    如果我确定针对数据库打开的所有事务都不应分配超过一定数量的日志，

    长时间运行的事务的问题不在于它生成了太多的日志记录，而在于它阻止了日志truncated。

    因此，即使有办法限制每个事务的日志记录生成，也无法使您免于不受控制的日志增长。

    编写将生成 8-10 条日志记录（取决于服务器版本）就足够了begin tran update myTbl set col =... where key_field = ... ，但是然后让 SSMS 打开并休假一周，如果没有人杀死那个打开的事务，那么从那一刻生成的所有日志都会累积在独立于recovery model. 在这种情况下，日志不能被截断，它将增长以容纳一周内生成的所有日志记录。

    • 4

  2. 简短的回答是否定的：如果事务对数据进行了更改，则所有这些更改都必须写入日志，因为这是 SQL Server 管理原子性的方式。

    更高级的答案是：这取决于您当前的数据库恢复模型。

    如果您将数据库设置为简单恢复模式，那么您可以通过将长进程分解为更小的事务来减少日志增长，但这意味着您的进程不再是原子的，因此您将不得不自己处理部分更新（SQL Server 无法滚动为您后退/前进或管理并发交易看到的内容）。因为在简单恢复中，SQL Server 可以立即重用已提交的事务使用的日志空间，增长受到事务较小的限制。这在完整或批量日志恢复模型中不起作用，因为任何大小事务的日志信息都必须保留到下一个日志或完整备份。有关恢复模型及其影响的更多详细信息，请参阅本文。

    • 2

相关问题