[AlwaysOn Availability Groups]排查：Primary上的修改無法在Secondary展現 排查：Primary上的修改無法在Secondary展現 1.通常原因

用戶端程序在primary上修改成功，但是在Secondary上卻無法看到修改結果。這個case假設你的可用性組有同步的健康問題。很多情況下這個情況會在幾分鐘之後自動解決。

如果幾分之後依然看不到，那麼可能在同步的工作流上有瓶頸問題。這個瓶頸會因為是不是同步送出的而不同。

Commit Mode

Possible Bottleneck

Explanation

Synchronous Commit

Primary上長運作事務

secondary上的redo線程

每個在primary上成功的更新，都同步到了secondary或者日志記錄已經為固話重新整理。是以瓶頸應該在redo線程上，如果一旦redo跟上，secondary上的讀取負荷都是快照隔離級别的。

Asynchronous Commit

網絡延遲或者吞吐量

secondary中的日志固話

secondary上的redo

因為一部送出一旦事務被寫入到磁盤就會被通知，瓶頸可能在這個點之後任意位置出現。

導緻primary修改後沒有反映到secondary上原因：

1.長運作活動事務

2.高網絡延遲，網絡吞吐量低導緻，Primary的日志堆高

3.有一個Report負荷堵塞了Redo線程

4.因為資源争用導緻redo落後

primary的長運作事務阻止了從secondary上讀取。

原因：

所有secondary上的讀負荷都是快照隔離級别的。在快照隔離下，隻讀用戶端隻能看到secondary的可用資料庫中在redone log中最早的活動事務開始點之前的資料。如果事務幾個小時沒有送出，事務會block所有隻讀查詢可以看到新的更新資料。

診斷和解決：

在primary，使用dbcc opentran檢視最老的活動事務，檢視是否可以復原。一旦最老的事務被復原并且同步到secondary，在secondary上的讀負荷就能之後更新的資料了。

高網絡延遲或者低吞吐量會阻止日志被發送到secondary。

如果未響應資訊發送超過最大允許值，primary會激活flow control，不再發送資訊到secondary。直到有些資訊有了回報。這種狀态會嚴重影響資料丢失能力，甚至超過RPO。

如果DMV的log_send_queue_size很大，表示log被堵塞在primary上。如果值除以log_send_rate可以初略的評估多久之後才能趕上primary。

·  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

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會話，強制釋放鎖。

大報表行為降低了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

    本文轉自 Fanr_Zh 部落格園部落格，原文連結：http://www.cnblogs.com/Amaranthus/p/4982563.html，如需轉載請自行聯系原作者