sql-server - 为什么我无法缩小事务日志？

Question

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

数据库在 SQL Server 2012 Standard 上设置为简单恢复。所以我本来期望在发出 CHECKPOINT 语句后事务日志的内容可以缩小，但这不起作用。

我已经尝试过:

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

在每次尝试之后，我尝试运行:

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

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

Cannot shrink log file 2 (MYDATABASE_2010_log) because total number of logical log files cannot be fewer than 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 文档中日志重用等待值的描述。 。或者更好的是:Factors That Can Delay Log Truncation 。如果值为1，您可以等待检查点，或手动运行它:CHECKPOINT .

一旦检查没有原因避免日志文件截断，您就可以执行通常的备份顺序(日志，完整增量)和DBCC SHRINKDATABASE或DBCC SHRINKFILE 。文件应该缩小。

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

日志文件作为循环缓冲区工作，只能通过删除文件末尾来截断。如果循环缓冲区的已使用部分位于文件末尾，则无法将其截断。您只需等待事务日志的已使用部分前进，并从文件末尾移动到文件开头。一旦发生这种情况，您可以运行收缩命令之一，您的文件将毫无故障地收缩。此页面对此进行了很好的解释:How to shrink the SQL Server log .

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

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