在简单恢复模式下使用SQL Server数据库的巨大事务日志

Question

我有一个相当大的SQL Server数据库正在使用SIMPLE恢复模式。我们真的不需要第二次恢复，所以我更希望我们继续使用这种模式。

由于某种原因，此数据库的事务日志很大（410 GB），其中99％的空间未分配。

我尝试使用（DBCC SHRINKFILE（MyDatabase_log，20000））缩小文件，但它似乎不起作用。

任何人都有关于为什么SIMPLE恢复模式数据库会有如此庞大的文件的任何提示？我真的很想让它缩小。

Answer 1

这意味着您曾经拥有一个持续时间太长的单个事务，它强制日志增长410GB。如果存在活动事务，则无法重用日志，因为无法删除回滚信息。这样的例子是，如果有人打开SSMS查询，启动事务，更新记录然后去度假。事务将处于活动状态并强制日志增长，直到最终提交或回滚。当事务最终结束时，最终可以回收使用的空间，留下一个巨大的空日志文件。

另一种情况是，如果您在单个事务中更新了大约200GB的数据。日志将存储更改的前后图像，因此占用了两倍的空间，并且无法重复使用，因为这是一次性事务。

<强>更新

我忽略了复制，这也是一个可以阻止日志截断的因素。镜像是一种分布式交易（技术上与“活动交易”相同，但DTC含义使其成为一个独特的案例）。完整列表和说明位于Factors That Can Delay Log Truncation。

Answer 2

你错过了dbcc shrinkfile中的一个论点：

dbcc shrinkfile (MyDatabase_log, 20000, TRUNCATEONLY)

NOTRUNCATE是默认值，它将已分配的块移动到未分配空间的开头。 TRUNCATEONLY删除未分配的空间。因此，如果您执行NOTRUNCATE后跟TRUNCATEONLY，则会得到一个精简的日志。

Answer 3

如果您只有一个mdf文件和一个日志文件，最简单的方法可能是分离数据库，重命名日志并重新连接数据库。 SQL Server将创建一个新的日志文件。之后，您可以安全地删除巨大的日志文件。

如果您有多个数据文件，这将无效。

Answer 4

Replication Publisher？这可能是巨额交易日志的原因吗？

Answer 5

如其他回复中所述，活动交易和复制是此问题的典型原因。 另一个不太明显的是更改数据捕获（CDC）。

我最近遇到了类似的问题，允许我释放日志的程序如下：

• 禁用CDC：EXEC sys.sp_cdc_disable_db
• 在相关数据库中的任意表上创建发布
• 删除此/所有出版物。 EXEC sp_removedbreplication 'my_db'是一种方便的方式。
• 根据需要缩小日志

我不确定为什么创建/删除此虚拟/从未使用过的出版物是必要的，但事实确实如此。暂时数据库可能有以前的出版物没有正确处理（据说经常发生从以前的备份恢复的数据库）。

另一个有用的诊断习惯是检查sys.databases中 log_reuse_wait_desc 的违规数据库。在我完成上述过程之前，此字段为REPLICATION。

SELECT log_reuse_wait_desc, * FROM sys.databases where name = 'my_db'

Answer 6

我在本地dev db上遇到了类似的问题，只能在db上运行CHECKPOINT几次后才能缩小它，不确定是什么导致它处于锁定状态。