
HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING 等待事件产生的条件:
主副本上一直有关于可用性组数据库的活动事务。
满足条件1下,辅助副本被踢出然后再加入或者是辅助副本的可读性状态从No变成Yes。
环境描述
========
AlwaysOn架构:
等待事件复现
条件1必须要满足,条件2有两种情况。因此,该等待事件有两大种情况如下。一.复现辅助副本被踢出然后加入
-------------------------------------------------
在主副本tux12-node1上的实例运行一个事务。begin tran
update person.person set Title='Mr.' where BusinessEntityID=1
在群集管理器中将tux12-node2从failover cluster中踢出。在群集管理器中将tux12-node2从filover cluster中加入。 在tux12-node2的辅助副本上的一个会话中运行如下查询会陷入等待。该表只是adventureworks2012下的一个任意表。如下会话为51:
use adventureworks2012
select * from person.personphone
在tux12-node2的辅助副本上的另一个会话中运行如下查询。此时可以看到会话51上有目标等待事件。select * from sys.sysprocesses where status = 'suspended'
二.复现辅助副本可读性状态从No变Yes
------------------------------------------------------------
将辅助副本tux12-node3的可读性状态确认为No。右击AlwaysOn架构图中的可用性组‘node1-2-3-ag’ ->‘属性’ -> ‘General’ -> 右边对话框处如下:将辅助副本tux12-node3的可读性状态变为Yes。
在tux12-node3的辅助副本上的一个会话中运行如下查询会陷入等待。该表只是adventureworks2012下的一个任意表。如下会话为53:
use adventureworks2012
select * from HumanResources.Department
在tux12-node3的辅助副本上的另一个会话中运行如下查询。此时可以看到会话53上有目标等待事件。
三.定位主副本上活动的事务
-------------------------------------------
您可以通过如下语句查看主副本上活动的事务是否正常提交或回滚
select * from sys.sysprocesses whereopen_tran>0 anddbID=db_ID('adventureworks2012')
在正常运行的AlwaysOn环境中,当一个辅助副本被意外踢出然后加入时,这些定向到辅助副本上的业务很有可能会陷入阻塞。这时可以考虑将业务暂时先放在主副本上运行,等待状态变更时运行的语句运行完即可。如果要定位这些语句您可以查看主副本上活动事务和涉及的可用性组数据库来定位。 在正常运行的AlwaysOn环境中,变更辅助副本的可读状态也有可能会遇到如上等待事件。因此,在变更状态前应该有一个充分的准备。 总结以上是内存溢出为你收集整理的SQLSERVER 2012 HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING 等待事件全部内容,希望文章能够帮你解决SQLSERVER 2012 HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING 等待事件所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)