排查：Primary上的修改无法在Secondary体现
客户端进程在primary上修改成功，但是在Secondary上却无法看到修改结果。这个case假设你的可用性组有同步的健康问题。很多情况下这个情况会在几分钟之后自动解决。
如果几分之后依然看不到，那么可能在同步的工作流上有瓶颈问题。这个瓶颈会因为是不是同步提交的而不同。
|
Commit Mode |
Possible Bottleneck |
Explanation |
|
Synchronous Commit |
|
每个在primary上成功的更新，都同步到了secondary或者日志记录已经为固话刷新。因此瓶颈应该在redo线程上，如果一旦redo跟上，secondary上的读取负荷都是快照隔离级别的。 |
|
Asynchronous Commit |
|
因为一部提交一旦事务被写入到磁盘就会被通知，瓶颈可能在这个点之后任意位置出现。 |
1.通常原因
导致primary修改后没有反映到secondary上原因：
1.长运行活动事务
2.高网络延迟，网络吞吐量低导致，Primary的日志堆高
3.有一个Report负荷堵塞了Redo线程
4.因为资源争用导致redo落后
2. 长运行活动事务
primary的长运行事务阻止了从secondary上读取。
原因：
所有secondary上的读负荷都是快照隔离级别的。在快照隔离下，只读客户端只能看到secondary的可用数据库中在redone log中最早的活动事务开始点之前的数据。如果事务几个小时没有提交，事务会block所有只读查询可以看到新的更新数据。
诊断和解决：
在primary，使用dbcc opentran查看最老的活动事务，查看是否可以回滚。一旦最老的事务被回滚并且同步到secondary，在secondary上的读负荷就能之后更新的数据了。
3. 高网络延迟，网络吞吐量低导致，Primary的日志堆高
高网络延迟或者低吞吐量会阻止日志被发送到secondary。
原因：
如果未响应信息发送超过最大允许值，primary会激活flow control，不再发送信息到secondary。直到有些信息有了反馈。这种状态会严重影响数据丢失能力，甚至超过RPO。
诊断和解决：
如果DMV的log_send_queue_size很大，表示log被堵塞在primary上。如果值除以log_send_rate可以初略的评估多久之后才能赶上primary。
也可以检查 SQL Server:Availability Replica > Flow Control Time (ms/sec)和 SQL Server:Availability Replica > Flow control/sec。这2个值相乘可以得到每秒至少花多少时间来等待flow control。flow control等待时间越长，速度越慢。
以下是有用的网络延迟和吞吐的诊断值。也可以使用windows工具，比如ping， Resource Monitor 来评估网络使用率。
· DMV log_send_queue_size
· DMV log_send_rate
· Performance counter SQL Server:Database > Log Bytes Flushed/sec
· Performance counter SQL Server:Database Mirroring > Send/Receive Ack Time
· Performance counter SQL Server:Availability Replica > Bytes Sent to Replica/sec
· Performance counter SQL Server:Availability Replica > Bytes Sent to Transport/sec
· Performance counter SQL Server:Availability Replica > Flow Control Time (ms/sec)
· Performance counter SQL Server:Availability Replica > Flow Control/sec
· Performance counter SQL Server:Availability Replica > Resent Messages/sec
4. 有一个Report负荷堵塞了Redo线程
Redo线程在secondary副本被一个只读长运行语句堵塞。
原因：
在secondary副本，只读查询获得Sch-s锁，这些sch-s锁会堵塞redo线程获得sch-m锁执行DDL修改。被堵塞的redo线程不能应用log记录，直到被释放。一旦被释放，可以执行redo。并且允许执行随后的undo和failover过程执行。
诊断和解决：
当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会话，强制释放锁。
5. 因为资源争用导致redo落后
大报表行为降低了secondary的性能，导致redo线程被落下
原因：
当应用log记录，redo线程读取log记录，并且应用这些log访问数据page。Page访问可能造成IO瓶颈，如果page不在内存中。如果还有IO密集型的负荷，照成IO资源争用，会降低redo线程的性能。
诊断和解决：
你可以通过DMV查看被落下了多少，通过对比last_redone_lsn和last_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 来限制其他会话的资源使用
本文转自 Fanr_Zh 博客园博客，原文链接：http://www.cnblogs.com/Amaranthus/p/4982563.html，如需转载请自行联系原作者