码迷,mamicode.com
首页 > 其他好文 > 详细

[AlwaysOn Availability Groups]排查:AG超过RTO

时间:2015-11-20 17:30:39      阅读:137      评论:0      收藏:0      [点我收藏+]

标签:

排查:AG超过RTO

自动故障转移或者手动转移之后,没有数据都是,你可能会发现切换时间超过了你的RTO。或者当你评估切换时间同步提交secondary副本,发现超过了你的RTO

1. 通常原因

通常引起故障转移超过RTO的原因:

1.报表负荷堵塞了Redo线程。

2.因为资源争用,Redo线程被落下。

2. 报表负荷堵塞了Redo线程

Redo线程在secondary副本被一个只读长运行语句堵塞。

原因:
secondary副本,只读查询获得Sch-s锁,这些sch-s锁会堵塞redo线程获得sch-m锁执行DDL修改。被堵塞的redo线程不能应用log记录,直到被释放。一旦被释放,可以执行redo。并且允许执行随后的undofailover过程执行。

诊断和解决:
redo线程被堵塞,扩展时间会生产,sqlserver.lock_redo_blocked。另外你可以查询sys.dm_exec_request,查看那个会话堵塞了redo

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource

from sys.dm_exec_requests where command = ‘DB STARTUP‘

可以通过kill会话,强制释放锁。

3. 因为资源争用,Redo线程被落下。

大报表行为降低了secondary的性能,导致redo线程被落下

原因:
当应用log记录,redo线程读取log记录,并且应用这些log访问数据pagePage访问可能造成IO瓶颈,如果page不在内存中。如果还有IO密集型的负荷,照成IO资源争用,会降低redo线程的性能。

诊断和解决:
你可以通过DMV查看被落下了多少,通过对比last_redone_lsnlast_received_lsn

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,

   last_redone_lsn, last_redone_time

from sys.dm_hadr_database_replica_states

如果redo线程被真的落下了,就需要研究secondary上的性能问题,是否有IO争用问题。可以通过Resource Governor 来限制其他会话的资源使用

 

[AlwaysOn Availability Groups]排查:AG超过RTO

标签:

原文地址:http://www.cnblogs.com/Amaranthus/p/4981217.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!