无法追踪事务日志空间

SKL*_*TFZ 1 sql-server transaction-log

我是 sql server 的新手。其中一个实例遇到了事务日志已满的场景,数据库需要进行备份才能解决问题。

我想再次复制该场景以显示事务日志可能会变满,并建议我的客户增加事务日志空间和增长因子。(数据库正在使用完全恢复模式)

然而,该场景无法复制任何要求执行的查询(40000次删除然后40000次插入,重复),我发现事务日志占用空间只是通过查询而颤抖

DBCC SQLPERF(LOGSPACE)
Run Code Online (Sandbox Code Playgroud)

我希望事务日志在执行批量插入和删除时会不断增长(查询之间没有备份或检查点)。但事实是日志空间并没有真正按预期运行。

我想知道

  1. 当数据库抛出异常事务日志已满时 - 是否由于硬盘存储空间不足?还是因为日志大小超过了配置的大小?

  2. 为什么批量插入和删除操作没有减少日志空间,但它的大小却在颤抖(上下而不是连续增加)?

Jos*_*ell 5

为什么批量插入和删除操作没有减少日志空间,但它的大小却在颤抖(上下而不是连续增加)?

您可能在测试设置中错过了以下两个步骤之一:

  • 测试数据库未使用完整恢复模式
ALTER DATABASE [TestDB] SET RECOVERY FULL WITH NO_WAIT;
Run Code Online (Sandbox Code Playgroud)
  • 您尚未对测试数据库执行完整备份
BACKUP DATABASE  [TestDB] TO DISK = N'NUL';
Run Code Online (Sandbox Code Playgroud)

在您进行完整备份之前,即使数据库设置为使用完整恢复模型,它本质上仍然使用简单模型。这是 Paul Randal 讨论这种情况的帖子:

关于日志和日志备份的误解:如何说服自己

如果您将恢复模式切换为 FULL 或 BULK_LOGGED,则在进行第一次完整备份之前,您基本上仍处于 SIMPLE 恢复模式,因此日志将在检查点处截断。

由于您的问题是“在查询之间完成检查点) ”,因此第二点可能是您的问题。

回答你的另一个问题:

当数据库抛出异常事务日志已满时 - 是否由于硬盘存储空间不足?还是因为日志大小超过了配置的大小?

有关该主题的许多详细信息,请参阅此站点上的相关问题:为什么事务日志不断增长或空间不足?

可能是磁盘空间不足,或者日志无法增长,因为它已达到最大大小并且无法再增长。对此问题的一些解决方案是更频繁地进行日志备份、更改为不同的恢复模式、增加日志文件所在磁盘的大小等。


关于对这个答案的一些评论:

抱歉,我漏掉了一个重要问题,您说得对,实际上我的数据库并未处于完全恢复模式,但在 SSMS UI 中,它确实显示数据库处于完全恢复模式。在这种情况下,我在哪里可以检查实际的恢复模式?

由于缺少备份(除了查询上次备份日期),有没有办法查看恢复模式是否完全处于活动状态。在切换到完全恢复模式之前进行完全备份算不算?

我所知道的判断自数据库切换到完整以来是否尚未执行备份的唯一方法是尝试日志备份。它将失败并显示错误“由于没有当前数据库备份,无法执行 BACKUP LOG。

这在实践中真的不应该成为问题,因为您正在备份真正的生产数据库,对吧?=P 但是在测试环境中,我只是运行它看看情况:

BACKUP LOG NCEB_DMS TO DISK = N'NUL';
Run Code Online (Sandbox Code Playgroud)