为什么我不能缩小事务日志？

Question

我正在将一些历史数据库转换为只读并尝试清理它们。我想将事务日志缩小到 1MB。我意识到缩小事务日志通常被认为是不好的做法，但我认为这可能是规则的例外。

数据库在 SQL Server 2012 Standard 上设置为 SIMPLE 恢复。因此，我本希望在发出 CHECKPOINT 语句后事务日志的内容可能会缩小，但这是行不通的。

我试过了：

• 手动发出 CHECKPOINT 命令。
• 分离/附加文件。
• 备份/恢复数据库。
• 从简单切换到完整，再回到简单恢复。
• 用威胁的方式向它挥舞我的拳头。

在每次尝试之后，我都尝试运行：

• DBCC SHRINKFILE (N'MYDATABASE_2010_log', 0)
• DBCC SHRINKFILE (N'MYDATABASE_2010_log', 0, TRUNCATEONLY)
• DBCC SHRINKFILE (N'MYDATABASE_2010_log', 1)

我已经多次看到此错误消息：

无法收缩日志文件 2 (MYDATABASE_2010_log)，因为逻辑日志文件的总数不能少于 2。

有一次，我尝试创建一个虚拟表并向其中添加记录，试图让事务日志滚动并移动到文件末尾，但这只是一个疯狂的猜测。

下面是 DBCC SQLPERF(LOGSPACE) 的结果

Database Name   Log Size (MB)   Log Space Used (%)  Status
MyDatabase_2010 10044.13    16.71015    0

以下是 DBCC LOGINFO 的结果：

RecoveryUnitId  FileId  FileSize    StartOffset FSeqNo  Status  Parity  CreateLSN
0   2   5266014208  8192    15656   0   64  0
0   2   5266014208  5266022400  15673   2   128 0

有谁知道我做错了什么？

Answer 1

如果您无法截断和收缩日志文件，您应该做的第一件事是检查是否存在避免截断日志的真正原因。执行此查询：

SELECT  name ,
    log_reuse_wait ,
    log_reuse_wait_desc ,
FROM sys.databases AS D

您可以按数据库名称过滤

如果值为 ，log_reuse_wait则0可以截断数据库日志。如果该值不是 0，则可以避免截断。请参阅sys.databases文档中日志重用等待值的描述。或者在这里更好：可以延迟日志截断的因素。如果值为 ，1您可以等待检查点，或手动运行它：CHECKPOINT。

一旦您确定没有理由避免日志文件截断，您就可以执行通常的备份序列（日志，充满增量）和DBCC SHRINKDATABASE或DBCC SHRINKFILE。并且文件应该收缩与否。

如果此时文件没有缩小，不用担心，原因是日志文件的物理结构，可以解决：

日志文件用作循环缓冲区，只能通过删除文件末尾来截断。如果循环缓冲区的使用部分在文件末尾，则不能截断。您只需等待事务日志的已用部分前进，并从文件末尾移动到文件开头。一旦发生这种情况，您可以运行其中一个收缩命令，您的文件就会收缩而不会出现故障。本页对此进行了很好的解释：如何缩小 SQL Server 日志。

如果要强制日志文件活动部分从缓冲区的末尾移动到缓冲区的开头：

• 对事务内的 DB 执行一些相当繁重的操作并将其回滚，以进一步移动事务日志指针
• 重复备份，截断日志
• 缩小文件。如果日志的活动部分移动得足够远，文件将缩小