无法缩小 SQL Server 中的事务日志文件

Ram*_*mya 5 sql-server sql-server-2012

我最近搬到了一家新公司,他们在一个 20-25 GB 的 SQL 服务器中有 2 个数据库。我无法缩小数据库的日志文件。
数据库的事务日志备份设置为从早上 6 点到晚上 7 点每 30 分钟运行一次。
它们的大小分别为 10 和 2 Gb。
昨晚我试图在晚上 8-9 点左右缩小它,但我无法做到。

log_reuse_wait 列表示它正在等待 log_backup。
我尝试进行几次日志备份,但没有帮助。
我运行了 DBCC OPENTRAN 但没有打开的事务。

此外,今天早上即使在 Tlog 备份从早上 6:00 开始到现在(10:30)它仍然在 log_reuse_wait 列中显示 LOG_BACKUP。
也没有 OPEN TRAN。

当我对此进行研究时,我发现了 Paul Randal 的这篇文章:http : //www.sqlskills.com/blogs/paul/why-is-log_reuse_wait_desc-saying-log_backup-after-doing-a-log-backup/

它指出,如果数据库很小并且 tlog 文件的所有内容都在同一个 VLF 中,则无法截断。
我在数据库中有大约 300-400 个 VLF。
所以这在这里也没有意义。

我注意到一件事,每天早上 6 点,tlog 比其他的要大一点。
因此,我正在考虑与首席 DBA 核实以全天候运行 tlog。
除此之外,我想看看为什么会发生这种情况,我是否遗漏了什么。

我尝试使用以下命令缩小:

Use DB1
go
DBCC SHRINKFILE(2,10) 
GO
Run Code Online (Sandbox Code Playgroud)

注意:它是运行 0n 2012 兼容性的 SQL 2012 实例

Ran*_*est 11

您的进程不工作的原因是它正在等待使用事务日志备份释放日志的非活动部分。切换到简单恢复模型绕过了这个问题。

如果你真的需要缩小事务日志,以便你可以重新增长它(例如,减少 VLF 的数量),这是一个过程:

1) 切换到简单恢复模式

2) 运行 CHECKPOINT 和 DBCC DROPCLEANBUFFERS(以防万一)

3) 收缩日志文件

4) 切换回完全恢复模式

5)以合理的增量增长日志(我使用 4000MB 增量)

6) 将自动增长设置为您的 I/O 子系统可以处理的值

7) 运行完整或差异备份以重新启动日志备份链。

  • @ Hybris95 Ha,不得不查找“dissponibility”(这意味着*可用性*)。但是,是的,在没有用户活动的计划维护窗口期间执行上述所有操作,否则如果出现问题并且您必须恢复,您可能会丢失用户事务。实际上,我会交换第 4 步和第 5 步 - 在切换回完全恢复模式之前手动增加日志。 (2认同)