主页 / dba / 问题 / 217768
Accepted
Lee Hill
Asked: 2018-09-18 00:42:40 +0800 CST

SQL Server 事务日志 VLF 未在日志传送数据库上发布（状态 2）

  • 772

看过一些与我的情况类似的帖子，但没有任何内容能真正解决我的问题。

设想：

  • 例行索引重建发生，每周一次，星期六凌晨 2 点。
  • 日志文件增长到通常大小的 15 倍左右。
  • 进行事务日志备份（每 10 分钟，24 x 7）。
  • 每天凌晨 3 点进行完整备份。
  • 当我查看时，VLF 仍处于“活动”状态（状态 2）dbcc loginfo
  • log_reuse_wait_desc正在报告“LOGBACKUP ”sys.databases
  • dbcc opentran报告没有活跃的交易
  • @@version: Microsoft SQL Server 2005 - 9.00.5069.00 (X64) Aug 22 2012 18:02:46 版权所有 (c) 1988-2005 Microsoft Corporation Standard Edition（64 位）在 Windows NT 6.1（Build 7601：Service Pack 1）上

问题：

所以，我的问题很简单，因为硬件限制和时间参数，我需要让事务日志的大小尽可能小。我相信它不释放空间的原因是因为 VLF 处于活动状态并且它认为它需要一个 LOGBACKUP 来释放，但是在无数次日志备份之后，log_reuse_wait_desc仍然报告等待日志备份！

我可以将恢复模型更改为简单、缩小并改回，但这会破坏我的 LSN 链和我的日志传送实现，所以它不是一个真正可行的解决方案！

TIA。

sql-server sql-server-2005

3 个回答

  1. Best Answer

    经过更多调查后，我发现当需要进行大型日志备份时，生成 trn 备份文件所花费的时间超过了lanmanserver服务设置的 5 分钟超时时间。

    所报告的错误error 64 (error not found)实际上是一个很常见的问题，显然如此处所述；因此即使正在创建日志备份，SQL 引擎也无法验证备份是否成功。

    反过来，VLF 未设置为 0，因此会看到问题中描述的问题。

    谢谢你们的帮助，但我认为问题的根源是报告的错误（我没有提到，因为我可以看到备份文件和日志传送仍在处理它们，所以我认为这不是一部分同样的问题！）

    • 2

  2. 您需要调查您的 VLF。你有多少？在您拥有的那些中，有多少正在使用（状态 = 2）？而且，在使用的那些中，它们在哪里？

    不要太担心“LOGBACKUP”状态，只要您不在简单恢复模式中，您就会拥有它，并且您还有不止一个使用过的 VLF（这很正常）。此处提供更多信息：http: //karaszi.com/large-transaction-log-file

    • 0

  3. 首先：您使用的是不受支持的 SQL Server 版本。你应该强烈考虑升级。我确定您可能已经厌倦了听到这些 =) 但这是一个真正的问题，并且可能与此问题相关（换句话说，它可能是您使用的 SQL Server 2005 版本中的错误）重新开始）。

    VLF 可能未被清除，因为：

    1. 您系统上的事务吞吐量相对较低，因此未发生 CHECKPOINT，因此无法清除 VLF。您可以通过在数据库上运行手动 CHECKPOINT 来查看这是否是您的问题，然后查看 VLF 是否在下一次日志备份后被清除（状态 0）。请注意，这可能是 I/O 密集型操作：

      USE YourDatabaseName;
GO

CHECKPOINT;

    2. 另一种可能性是 VLF 很大，因此在正常操作下，您的日志记录可以在移动到下一个 VLF 之前在一个 VLF 中停留很长时间

    它也可以是上面 1 和 2 的组合，或者完全是其他东西。

    如果您可以发布详细信息（DBCC LOGINFO您已经在几个地方提到了摘要信息，但此时我认为需要详细信息），这将很有帮助。

    请注意，您的问题的一个可能解决方案是简单地不执行此 INDEX REBUILD，因此不会首先导致大量日志增长。如果由于感知到的性能问题而进行重建，您可以考虑其他解决方案（例如更新统计信息）。

    • 0

相关问题