延遲是AlwaysON的最大敵人之一。對AlwaysON而言，其首要目標就盡量減少（無法避免）主副本、輔助副本的數據延遲，實現主副本、輔助副本的“數據同步”。只有主副本、輔助副本的同步延遲越小越高，只讀訪問的實性性才會越高，數據庫的RTO（Estimating Failover Time ）和RPO（Estimating Potential Data Loss）也才會越小。
但延遲可能存在于AlwaysON同步的各個環節中，因此，在分析現延遲情況時，應該首先理解AlwaysON的同步過程，然后切分到每個過程中進行監控和分析。
AlwaysON同步的6大步驟在我的上篇文章《AlwaysON的同步原理及同步模式》中，曾介紹過AlwaysON的同步過程。歸結起來，主要包括如下六個步驟：
① log flush(PRimary)
② log capture(primary)
③ send(primary and secondary)
④ log receive and cache(secondary)
⑤ log hardened(secondary)
⑥ redo(secondary)
前兩個步驟發生在主副本，最后三個步驟發生在輔助副本，中間的第三個步驟發生主副本和輔助副本之間。
另外，如果是同步提交模式，還需要增加一個步驟：輔助副本在步驟5之后，會發送一個（日志硬化）確認信息給主副本，然后才能進入redo階段。
Log Flush就是將log buffer中的日志刷入到磁盤中。在SQL Server中，log buffer的大小固定為60KB，當發生事務提交時、checkpoint、或者buffer可用空間不足時，日志就會被flush磁盤中。
AlwaysON只有待主副本的日志刷入磁盤后才能繼續后面的步驟（為了保護主副本的數據一致性）。因此，log flush的越快，AlwaysON后續步驟進入的就越早，延遲就越小，反之亦然。
那么，在這個階段中，如何監控log flush的速度和性能呢？通常，我們使用如下兩個性能計數器：
這是一個磁盤的性能計數器，這個指標反映的是flush期間磁盤的寫操作的平均響應時間，如果10ms以內，說明磁盤性能非常好，如果在10ms到20ms，說明性能較好，如果在20ms到50ms說明性能較差，如果在50ms以上，說明性能很差。
這個指標直接反映了每秒flush的日志大小，因在不同的時段、不同的業務中日志產生的大小可能不同，因此不能提供一個標準值用來衡量flush性能的好壞，不過，當這個值很大時，說明數據庫操作（增、刪、改）比較頻繁，需要引起注意，結合后續步驟中的其他指標一起分析。
log capture(primary)log capture發生在log flush之后，是AlwaysON中最重要的階段（個人認為）。在這個階段中，主副本上會為每個輔助副本維護一個發送隊列，隊列的內容就是從日志緩沖或者磁盤中capture的日志，而隊列的大小則反映了主副本和輔助副本數據不同步的差量。
顯然，在這個階段最可能影響AlwaysON同步性能的兩個關鍵因素就是：capture日志的來源（是磁盤還是內存）和隊列的大小。
在上述兩個因素中，我需要著重解釋下capture日志的來源：是磁盤還是內存？我們自導，從內存中讀取數據效率要遠遠高于從磁盤中讀取，所以在AlwaysON中，SQL Server會盡可能多將日志緩沖到內存中。但緩沖的大小是有限的，如果日志量太大、緩沖的大小不足，則不得不讀取磁盤。
下面我們來熟悉下如何監控日志的來源和發送隊列的大小：
監控日志的來源：
日志到底是讀取自內存還是磁盤，通過如下性能計數器可窺見一斑：
解釋：前者表示每秒中從內存中請求日志塊的數量；后者表示log pool memory的大?。?/p>
說明：對于這兩個值，我們希望越高越好，則說明越多的日志可以從內存中讀取到。
解釋：兩個性能計數器其實都表示內存中找不到要讀取的日志，必須從磁盤中讀取；
說明：如果兩個值越高，說明內存性能不足，SQL Server沒法緩沖更多的日志。
監控日志發送隊列：
在主副本上執行如下語句即可：
SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server, dr_state.database_id as database_id,
dr_state.log_send_queue_size, is_ag_replica_local = CASE
WHEN ar_state.is_local = 1 THEN N'LOCAL'
ELSE 'REMOTE'
END ,
ag_replica_role = CASE
WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
ELSE ar_state.role_desc
END
FROM (( sys.availability_groups AS ag JOIN sys.availability_replicas AS ar ON ag.group_id = ar.group_id )
JOIN sys.dm_hadr_availability_replica_states AS ar_state ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state on
ag.group_id = dr_state.group_id and dr_state.replica_id = ar_state.replica_id;
log_send_queue_size表示主數據庫中尚未發送到輔助數據庫的日志記錄量 (KB)，也就是上文說的發送隊列，如果某個輔助副本的發送隊列持續增加，說明此副本與主副本同步的數據差量就越大。
在上例中，server1是主副本，server2是輔助副本。主副本的log_send_queue_size始終為null，server2的log_send_queue_size為154067KB。顯然，此時server2明顯落后于主副本。
send(primary and secondary)send階段是 AlwaysON同步過程中最簡單的一個步驟（個人認為）。在這個階段中，我們主要關注網絡性能就好了，因為主副本必須借助網絡才能把發送隊列的日志傳輸到到對應的輔助副本。如果網絡不好，AlwaysON就會產生延遲，更有甚者，如果是在同步提交模式下，還會導致主副本的事務遲遲不能提交。
對網絡的監控主要通過如下兩個性能計數器即可：
解釋：網卡每秒發送的字節數；
說明：對于這個指標我們不能孤立來看，需結合發送隊列的大小，當發送隊列很大，但此性能指標持續比較低時，有可能是網絡有問題（當然，如果是同步模式，需要考慮輔助副本log harden的速度才能決定是否一定跟網絡有關）。
解釋：網卡的發送隊列大小；
說明：一般來說，網卡的隊列大于2時，說明網絡存在擁堵，可能出現了網絡問題。
Log Receive and cache(sencondary)log receive and cache發生在輔助副本上，表示輔助副本接受來自主副本發送的日志塊、并緩沖起來的過程。
這個階段其實跟網絡速度和內存大小有關，兩者在上文中均有介紹，這里不做過多闡述，只跟大家介紹下這個階段中AlwaysON專有性能計數器。
解釋：每秒接受的日志大小（單位為KB）；
說明：接受的速度越快，說明網絡性能和內存性能均越好。
Log Hardened(sencondary)介紹log hardened時不得不談一談第一個步驟的log flush，兩者其實是一個東西，只是表述不一樣。因為它們無論是工作原理還是對事務提交的影響都非常類似，因此對log hardened的監控，直接參考步驟一就好了。
redo(secondary)redo的對象是輔助副本中已經固化的日志（該日志可能是內存中副本，也可能來自磁盤上），是AlwaysON中“實現”數據同步的步驟，其他步驟都是為此做鋪墊，即便是上個步驟的日志固化，它也只能保證主副本和輔助副本的數據一致，而真正的數據同步必須等待輔助副本的redo完成。
在這個階段中，有兩個因素決定了數據延遲的大?。簉edo的日志大小和redo的速度。下面我們從這兩個角度來了解下redo階段的性能監控：
監控redo日志大小
SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server, dr_state.database_id as database_id,
dr_state.redo_queue_size, is_ag_replica_local = CASE
WHEN ar_state.is_local = 1 THEN N'LOCAL'
ELSE 'REMOTE'
END ,
ag_replica_role = CASE
WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
ELSE ar_state.role_desc
END
FROM (( sys.availability_groups AS ag JOIN sys.availability_replicas AS ar ON ag.group_id = ar.group_id )
JOIN sys.dm_hadr_availability_replica_states AS ar_state ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state on
ag.group_id = dr_state.group_id and dr_state.replica_id = ar_state.replica_id;
監控redo的速度
redo的速度通過如下性能計數器即可：
解釋：輔助副本每秒完成redo的字節數；
說明：在分析此指標時，必須結合redo的日志大小，將兩者的結果相除可得到一個大致的同步延遲時間。
結尾我們知道AlwaysON是SQL Server 2012才開始引入的技術，目前筆者做的案例還不是很多，本文所表述的內容都是基于我有限的實踐經驗總結而來，如有不妥之處還請批評指正。
附上我的新浪微博二維碼，希望我的分享能夠為您帶來一些價值。
新聞熱點
疑難解答
