症状

请考虑以下情况:

  • 您具有 Microsoft SQL Server 2012年或更高版本的服务器上安装。

  • SQL Server 的实例是 AlwaysOn 可用性组环境中的主副本。

  • 在 SQL Server 设置为事务日志文件自动增长选项。

在这种情况下,事务日志可能会变得非常大,并且运行磁盘空间不足或超过 MaxSize 选项在主副本设置事务日志,您会收到类似于以下内容的错误消息:

错误: 9002,严重性: 17 日状态: 9。 数据库的事务日志 %。 * ' 是完全由于 AVAILABILITY_REPLICA

原因

这发生在主副本上的日志记录的更改不强化辅助副本上。AlwaysOn 环境中的数据同步过程有关的详细信息,您可以查看:

疑难解答

有两个方案,可能会导致增长登录可用性数据库和 'AVAILABILITY_REPLICA' log_reuse_wait_desc:方案 1: 延迟交付更改登录辅助交易记录更改的主副本中的数据时,这些更改封装到日志记录块和这些记录的块的传递和强化到数据库在辅助副本日志文件。主副本无法覆盖日志块在其自己的日志文件,直到这些日志块已交付和强化到相应的数据库日志文件中所有的辅助副本。交付或强化这些块到可用性组中的任何副本中的任何延迟将防止截断的主副本的数据库中的日志记录更改,并导致其日志文件使用率增长。

详细信息,请参阅 Microsoft 文档的以下主题:

高网络延迟或低网络吞吐量上的主副本将导致日志累积

方案 2: 恢复延迟 一旦强化到辅助数据库日志文件,辅助副本实例中的专用的恢复线程将适用于相应的数据文件所包含的日志记录。主副本无法覆盖日志块在其自己的日志文件,直到所有从属副本中的所有恢复线程都应用了包含的日志记录。 如果不能及时获得日志块得到强化的辅助副本的速度上任何辅助副本的恢复操作,它将导致日志在主副本的增长。主副本只能截断和重用自己事务日志应用了所有辅助副本恢复线程为止。如果有多个第二,比较 sys.dm_hadr_database_replica_states 动态管理的 truncation_lsn 列查看最跨多个辅助副本以标识哪些辅助数据库将延迟操作日志截断。 您可以使用 AlwaysOn 仪表板和 sys.dm_hadr_database_replica_states 动态管理视图来帮助监视日志发送队列和恢复队列。某些键字段是:

字段

说明

log_send_queue_size

在辅助副本未到达的日志记录的数量

log_send_rate

RRate 在日志记录发送到辅助数据库

redo_queue_size

中已经没有尚未被恢复了,千字节 (KB) 的辅助副本日志文件的日志记录的数量

redo_rate

在给定的辅助数据库,以千字节 (KB) 恢复日志记录的速率 / 秒

last_redone_lsn

最后在辅助数据库已恢复的日志记录实际的日志序列号。last_redone_lsn 是始终小于 last_hardened_lsn

last_received_lsn

日志模块 ID 标识的所有日志块已接收都到承载此辅助数据库的辅助副本的点。反映了用零填充日志块 ID。它不是实际的日志序列号。

例如,以下对执行查询的主副本以便报告副本与最早的 truncation_lsn,是主可以收回自己的事务日志中的上限:

SELECT
	ag.name AS [availability_group_name]
	, d.name AS [database_name]
	, ar.replica_server_name AS [replica_instance_name]
	, drs.truncation_lsn
	, drs.log_send_queue_size
	, drs.redo_queue_size
FROM
	sys.availability_groups ag
	INNER JOIN sys.availability_replicas ar
		ON ar.group_id = ag.group_id
	INNER JOIN sys.dm_hadr_database_replica_states drs
		ON drs.replica_id = ar.replica_id
	INNER JOIN sys.databases d
		ON d.database_id = drs.database_id
WHERE drs.is_local=0
ORDER BY
	ag.name ASC, d.name ASC, drs.truncation_lsn ASC, ar.replica_server_name ASC

纠正措施可能包括但不是限于以下:

  • 请确保在辅助站点,没有任何资源或性能瓶颈。

  • 请确保恢复线程未在辅助站点被阻止。使用 lock_redo_blocked 扩展的事件以确定在这种情况和上哪些对象恢复线程被阻塞。

解决方法

后确定辅助数据库这发生,请尝试以下方法来暂时解决此问题:

  • 需要数据库可用性组退出违犯的辅助。 注意: 此方法将导致丢失的辅助阵列的高可用性/灾难恢复方案。您可能需要设置可用性组以后。

  • 如果经常阻止恢复线程,禁用通过更改的副本为 no。 SECONDARY_ROLE 的 ALLOW_CONNECTIONS 参数可读辅助功能 注意: 这将会阻止用户读取这是阻塞的根本原因的辅助副本中的数据。一旦恢复队列已转至可接受的大小,请考虑重新启用相应的功能。

  • 启用自动增长设置,如果它处于禁用状态,并且没有可用的磁盘空间。

  • 如果已达到并且没有可用的磁盘空间,增加事务日志文件的 MaxSize 值。

  • 如果当前已达到系统最多 2 TB 或另一个可用的卷上的其他空间添加其他事务日志文件。

状态

Microsoft 已确认这是在“适用范围”部分中列出的 Microsoft 产品存在的问题。

更多信息

有关事务日志意外增长或在 SQL Server 中已满的原因的详细信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:

317375事务日志意外增长或在 SQL Server 中满重做操作阻塞问题有关的详细信息,请转到以下:

AlwaysON-HADRON 学习系列: lock_redo_blocked/恢复工作人员辅助副本上受阻有关基于 AVAILABILITY_REPLICA 的log_reuse_wait列的详细信息,请访问以下 MSDN 网站:

可延迟的因素日志截断关于sys.dm_hadr_database_replica_states视图的详细信息,请访问以下 Microsoft TechNet 网站:

Sys.dm_hadr_database_replica_states 函数简介有关如何监视并排除不到达且未被及时应用日志记录的更改的详细信息,请转到以下 TechNet 网站:

AlwaysOn 可用性组监视性能

Need more help?

Expand your skills
Explore Training
Get new features first
Join Microsoft Insiders

Was this information helpful?

How satisfied are you with the translation quality?
What affected your experience?

Thank you for your feedback!

×