適用於：
SQL Server
Always On 可用性群組的效能層面，對於維護關鍵任務資料庫的服務等級協定 (SLA) 來說非常重要。 了解可用性群組如何將記錄傳送至次要複本，可協助您 預估可用性實作的復原時間目標 (RTO) 與復原點目標 (RPO)，以及針對效能不佳的可用性群組或複本來識別其中的瓶頸。 本文章會說明同步處理程序，示範如何計算一些關鍵計量，並提供某些常見效能疑難排解案例的連結。
資料同步處理程序
若要預估完整同步處理的時間並找出瓶頸，您需要了解同步處理程序。 效能瓶頸可能會在程序中的任何位置，而找出瓶頸可以協助您挖掘更深入的底層問題。 下圖和下表說明資料同步處理程序：
| 順序 | 步驟描述 | 註解 | 實用的計量 |
|---|---|---|---|
| 1 | 記錄檔產生 | 記錄檔資料會排清至磁碟。 此記錄檔必須複寫到次要複本。 日誌記錄會進入傳送佇列。 | SQL Server：資料庫> 日誌位元組刷新/每秒 |
| 2 | 擷取 | 系統會擷取每個資料庫的記錄，並傳送至對應的夥伴佇列（每個資料庫複本配對一個）。 只要可用性複本已連線且數據移動沒有因任何原因暫停，此擷取程式就會持續執行，而且資料庫複本對會顯示為同步中或已同步。 如果擷取捕捉過程無法足夠快地掃描並排入佇列訊息，記錄傳送佇列就會堆積。 |
SQL Server：可用性複本 > Bytes Sent to Replica/sec，這是針對該可用性複本排入佇列之所有資料庫訊息的總和匯總。 主要複本上為 log_send_queue_size (KB) 和 log_bytes_send_rate (KB/秒)。 |
| 3 | 發送 | 每個資料庫複本佇列中的訊息都會出列，並通過網路發送至相應的次要複本。 | SQL Server：可用性復本 > 每秒傳輸的位元組數 |
| 4 | 接收並快取 | 每個次要副本會接收並快取訊息。 | 效能計數器 SQL Server:可用性複本 > 每秒接收的位元組數 |
| 5 | 強化 | 這會刷新次要複本上的記錄檔，以使資料持久化。 在記錄排清後，會將確認傳送回主要複本。 一旦記錄檔被保護，就可以避免資料遺失。 |
效能計數器 SQL Server:資料庫 > 每秒刷寫的記錄檔位元組數 等候類型 HADR_LOGCAPTURE_SYNC |
| 6 | 重做 | 在次要複本上重新處理已清空的頁面。 頁面等候重做時會保留在重做佇列中。 |
SQL Server:資料庫複本 > 重做位元組數/秒 redo_queue_size (KB) 和 redo_rate。 等候類型 REDO_SYNC |
流量控制閘門
可用性群組是以主要複本上的流程控制閘道設計，以避免所有可用性複本上過多的資源耗用，例如網路和記憶體資源。 這些流量控制門不會影響可用性複本的同步健康狀態，但可能會影響您的可用性資料庫的整體效能，包括 RPO。
在主要複本上擷取記錄檔後，記錄檔會受限於兩個層級的流控。 一旦達到其中一個閘道的訊息閾值，記錄檔訊息便不會再傳送至特定複本，或是針對特定資料庫傳送。 當收到已傳送訊息的確認訊息後，才能發送新的訊息，藉此讓已傳送的訊息數量維持在閾值以下。
除了流量控制閘道之外，還有另一個因素可防止傳送記錄訊息。 複本的同步處理可確保訊息會以記錄序號 (LSN) 的順序傳送並套用。 傳送記錄訊息之前，其 LSN 也會根據最低認可的 LSN 號碼進行檢查，以確保其小於閾值的其中一個（視訊息類型而定）。 如果兩個 LSN 數位之間的間距大於臨界值，則不會傳送訊息。 一旦間距再次低於閾值，則會傳送訊息。
SQL Server 2022 （16.x） 會提高每個閘道允許的訊息數目限制。 藉由使用追蹤旗標 12310，增加的限制也適用於以下版本的 SQL Server：SQL Server 2019（15.x）CU9、SQL Server 2017（14.x）CU18、SQL Server 2016（13.x）SP1 CU16。
下表比較訊息限制：
針對啟用追蹤旗標 12310 的 SQL Server 版本，也就是 SQL Server 2022 （16.x）、SQL Server 2019 （15.x） CU9、SQL Server 2017 （14.x） CU18、SQL Server 2016 （13.x） SP1 CU16 和更新版本，請參閱下列限制：
| 等級 | 閘道數目 | 訊息數目 | 實用的計量 |
|---|---|---|---|
| 運輸 | 每個可用性複本 1 個 | 16384 | 擴充事件 database_transport_flow_control_action |
| 資料庫 | 每個可用性資料庫各 1 個 | 7168 |
DBMIRROR_SEND 擴充事件 hadron_database_flow_control_action |
兩個實用的效能計數器 SQL Server:可用性複本 > 每秒的流量控制和 SQL Server:可用性複本 > 每毫秒/秒的流量控制時間，會為您顯示上一秒內已啟動多少次流量控制，以及花費多少時間等候流量控制。 較高的流程控制等候時間意謂著較高的 RPO。 如需有關可能導致流量控制等待時間過長的問題類型的詳細資訊，請參閱疑難排解：異步提交可用性群組複本的潛在資料遺失。
預估故障轉移時間 （RTO）
您的 SLA 中的 RTO 取決於 Always On 系統於特定時刻的容錯切換時間，可以用下列公式表示：
重要
如果可用性群組包含多個可用性資料庫，則包含最高 Tfailover 的可用性資料庫會變成 RTO 合規性的限制值。
失敗偵測時間（Tdetection）是系統偵測到失敗所需的時間。 此時間取決於叢集層級設定，而不是個別可用性複本。 根據已設定的自動故障轉移條件，當出現關鍵的 SQL Server 內部錯誤時，例如孤立自旋鎖，可能會立即觸發故障轉移以做出快速響應。 在此情況下，偵測速度可能和 sp_server_diagnostics 錯誤報告傳送至 Windows Server 故障轉移叢集（WSFC）一樣快。 默認間隔為健康情況檢查逾時 1/3。故障轉移也可能因為逾時而觸發，例如叢集健康情況檢查逾時已過期（預設為 30 秒），或資源 DLL 與 SQL Server 實例之間的租用已過期（預設為 20 秒）。 在此情況下，偵測時間和超時間隔一樣長。 如需詳細資訊，請參閱可用性群組自動容錯移轉的彈性容錯移轉原則 (SQL Server)。
次要複本為了準備好進行容錯移轉而必須做的一件事，就是讓重做趕上記錄檔的結尾。 重做時間，Tredo，是使用下列公式計算的：
其中 redo_queue 是 redo_queue_size 中的值，而 redo_rate 是 redo_rate 中的值。
容錯移轉開銷時間 Toverhead 包括將 WSFC 叢集容錯移轉並使資料庫上線所需的時間。 此時間段通常較短且穩定。
估計潛在的資料遺失量 （RPO）
您的 SLA 中的 RPO 取決於您的 Always On 實作在任何給定時間可能的資料遺失。 這個可能的資料遺失可以用下列公式來表示：
其中 log_send_queue 是 log_send_queue_size 的值，而記錄檔產生速率是 SQL Server:資料庫 > 每秒排清的記錄檔位元組數的值。
警告
如果可用性群組包含多個可用性資料庫，則包含最高 Tdata_loss 的可用性資料庫會變成 RPO 合規性的限制值。
記錄檔傳送佇列代表在發生重大故障時可能會遺失的所有資料。 乍一看，使用記錄產生速率而不是記錄傳送速率會很奇怪（請參閱 log_send_rate）。 不過，請記住，使用記錄傳送速率只會讓您有時間進行同步處理，而 RPO 會根據產生的數據速度測量數據遺失，而不是根據同步處理的速度來測量數據遺失。
估算 Tdata_loss 更簡單的方法是使用 last_commit_time。 在主複本上的 DMV 會回報此值給所有複本。 您可以計算主要複本的值和次要複本的值之間的差異，以預估次要複本上的記錄檔趕上主要複本的速度。 如先前所述，此計算不會根據記錄產生的速度來告訴您潛在的數據遺失，但應該是接近近似值。
使用 SSMS 儀表板估算 RTO 和 RPO
在AlwaysOn可用性群組中，會針對裝載於次要複本的資料庫計算 RTO 和 RPO 並加以顯示。 在 SQL Server 管理 Studio （SSMS） 儀錶板中，主副本上的 RTO 和 RPO 會根據次要副本分組。
若要檢視儀錶板內的 RTO 和 RPO，請執行下列步驟：
在 SQL Server Management Studio 中，展開 [Always On 高可用性] 節點，並以滑鼠右鍵按一下您的可用性群組名稱，然後選取 [顯示儀表板] 。
在 [群組依據] 索引標籤中，選取 [新增/移除欄]。檢查 [估計復原時間 (秒數)] [RTO] 和 [估計資料遺失 (時間)] [RPO]。
計算備援資料庫 RTO
復原時間的計算可以判斷發生故障轉移後需要多少時間來復原「次要資料庫」。 容錯移轉時間通常簡短且一致。 偵測時間取決於叢集層級設定，而不是個別可用性複本。
針對輔助資料庫 （DB_sec），其 RTO 的計算和顯示是根據其 redo_queue_size 和 redo_rate為基礎。
除了邊角案例之外，用來計算次要資料庫 RTO 的公式是：
計算次要資料庫 RPO
針對輔助資料庫 （DB_sec），其 RPO 的計算和顯示是以 其 is_failover_ready、 last_commit_time及其相互關聯的主資料庫 （DB_pri） last_commit_time 值為基礎。 當的值 DB_sec.is_failover_ready 是 1時，主要和次要之間的數據會同步處理，且故障轉移時不會遺失任何數據。 不過，如果此值為 0，則主資料庫上的last_commit_time與輔助資料庫上的last_commit_time之間有差距。
對於主資料庫，last_commit_time 是最新交易已提交的時間戳記。 對於輔助資料庫而言，last_commit_time 是主資料庫之交易在輔助資料庫中已成功寫入的最新認可時間戳。 主資料庫和輔助資料庫的這個數位都相同。 不過，這兩個值之間的差距是暫止交易未在輔助資料庫中加固的時間，而在故障轉移事件中可能會遺失。
RTO/RPO 公式中使用的效能計量
redo_queue_size（KB）：RTO 中使用的重做佇列大小是其last_received_lsn與last_redone_lsn之間的事務歷史記錄大小。 值為last_received_lsn記錄區塊標識碼，可識別裝載此輔助資料庫之次要複本已接收所有記錄區塊的點。 的值last_redone_lsn是輔助資料庫上重做之最後一筆記錄檔記錄的記錄序號。 根據這兩個值，我們可以找到起始記錄檔區塊 （） 和結束記錄區塊 （last_received_lsnlast_redone_lsn） 的識別碼。 然後，這兩個記錄區塊之間的空間可以代表尚未重做多少事務歷史記錄區塊。 這是以 KB 來測量。redo_rate（KB/秒）：用於 RTO 計算中，這是一個累計值，顯示每秒在輔助資料庫上重做或重新執行多少事務歷史記錄（KB）。last_commit_time（datetime）：在 RPO 中使用，這個值在主資料庫和輔助資料庫之間有不同的意義。 針對主資料庫，last_commit_time是最新交易完成的時間。 對於輔助資料庫而言，last_commit_time是主資料庫上完成的交易已經在輔助資料庫中同樣成功確認的最新提交。 因為次要複本上的這個值應該與主要複本上的相同值同步，所以這兩個值之間的任何差距就是預估資料遺失 (RPO)。
使用 DMVs 估算 RTO 和 RPO
可以查詢 DMV sys.dm_hadr_database_replica_states 和 sys.dm_hadr_database_replica_cluster_states 來估計資料庫的 RPO 和 RTO。 下列查詢會建立可完成這兩個事項的預存程序。
注意
請務必先建立並執行預存程序來預估 RTO，因為需要有它所產生的值才能執行預存程序來預估 RPO。
建立預存程序來預估 RTO
在目標次要複本上，建立預存程式
proc_calculate_RTO。 如果此預存程序已經存在，請先將它卸除後再重新建立。IF object_id(N'proc_calculate_RTO', 'p') IS NOT NULL DROP PROCEDURE proc_calculate_RTO; GO RAISERROR ('creating procedure proc_calculate_RTO', 0, 1) WITH NOWAIT; GO -- name: proc_calculate_RTO -- -- description: Calculate RTO of a secondary database. -- -- parameters: @secondary_database_name nvarchar(max): name of the secondary database. -- -- security: this is a public interface object. -- CREATE PROCEDURE proc_calculate_RTO @secondary_database_name NVARCHAR (MAX) AS BEGIN DECLARE @db AS sysname; DECLARE @is_primary_replica AS BIT; DECLARE @is_failover_ready AS BIT; DECLARE @redo_queue_size AS BIGINT; DECLARE @redo_rate AS BIGINT; DECLARE @replica_id AS UNIQUEIDENTIFIER; DECLARE @group_database_id AS UNIQUEIDENTIFIER; DECLARE @group_id AS UNIQUEIDENTIFIER; DECLARE @RTO AS FLOAT; SELECT @is_primary_replica = dbr.is_primary_replica, @is_failover_ready = dbcs.is_failover_ready, @redo_queue_size = dbr.redo_queue_size, @redo_rate = dbr.redo_rate, @replica_id = dbr.replica_id, @group_database_id = dbr.group_database_id, @group_id = dbr.group_id FROM sys.dm_hadr_database_replica_states AS dbr INNER JOIN sys.dm_hadr_database_replica_cluster_states AS dbcs ON dbr.replica_id = dbcs.replica_id AND dbr.group_database_id = dbcs.group_database_id WHERE dbcs.database_name = @secondary_database_name; IF @is_primary_replica IS NULL OR @is_failover_ready IS NULL OR @redo_queue_size IS NULL OR @replica_id IS NULL OR @group_database_id IS NULL OR @group_id IS NULL BEGIN PRINT 'RTO of Database ' + @secondary_database_name + ' is not available'; RETURN; END ELSE IF @is_primary_replica = 1 BEGIN PRINT 'You are visiting wrong replica'; RETURN; END IF @redo_queue_size = 0 SET @RTO = 0; ELSE IF @redo_rate IS NULL OR @redo_rate = 0 BEGIN PRINT 'RTO of Database ' + @secondary_database_name + ' is not available'; RETURN; END ELSE SET @RTO = CAST (@redo_queue_size AS FLOAT) / @redo_rate; PRINT 'RTO of Database ' + @secondary_database_name + ' is ' + CONVERT (VARCHAR, ceiling(@RTO)); PRINT 'group_id of Database ' + @secondary_database_name + ' is ' + CONVERT (NVARCHAR (50), @group_id); PRINT 'replica_id of Database ' + @secondary_database_name + ' is ' + CONVERT (NVARCHAR (50), @replica_id); PRINT 'group_database_id of Database ' + @secondary_database_name + ' is ' + CONVERT (NVARCHAR (50), @group_database_id); END使用目標輔助資料庫名稱執行
proc_calculate_RTO：EXECUTE proc_calculate_RTO @secondary_database_name = N'DB_sec';輸出會顯示目標次要複本資料庫的 RTO 值。 儲存 group_id、replica_id 和 group_database_id，以與 RPO 預估預存程序搭配使用。
範例輸出：
RTO of Database DB_sec' is 0 group_id of Database DB4 is F176DD65-C3EE-4240-BA23-EA615F965C9B replica_id of Database DB4 is 405554F6-3FDC-4593-A650-2067F5FABFFD group_database_id of Database DB4 is 39F7942F-7B5E-42C5-977D-02E7FFA6C392
建立預存程序來預估 RPO
在主要復本上，建立預存程式
proc_calculate_RPO。 如果它已經存在，請先將它卸除後再重新建立。IF object_id(N'proc_calculate_RPO', 'p') IS NOT NULL DROP PROCEDURE proc_calculate_RPO; GO RAISERROR ('creating procedure proc_calculate_RPO', 0, 1) WITH NOWAIT; GO -- name: proc_calculate_RPO -- -- description: Calculate RPO of a secondary database. -- -- parameters: @group_id uniqueidentifier: group_id of the secondary database. -- @replica_id uniqueidentifier: replica_id of the secondary database. -- @group_database_id uniqueidentifier: group_database_id of the secondary database. -- -- security: this is a public interface object. -- CREATE PROCEDURE proc_calculate_RPO @group_id UNIQUEIDENTIFIER, @replica_id UNIQUEIDENTIFIER, @group_database_id UNIQUEIDENTIFIER AS BEGIN DECLARE @db_name AS sysname; DECLARE @is_primary_replica AS BIT; DECLARE @is_failover_ready AS BIT; DECLARE @is_local AS BIT; DECLARE @last_commit_time_sec AS DATETIME; DECLARE @last_commit_time_pri AS DATETIME; DECLARE @RPO AS NVARCHAR (MAX); SELECT @db_name = dbcs.database_name, @is_failover_ready = dbcs.is_failover_ready, @last_commit_time_sec = dbr.last_commit_time FROM sys.dm_hadr_database_replica_states AS dbr INNER JOIN sys.dm_hadr_database_replica_cluster_states AS dbcs ON dbr.replica_id = dbcs.replica_id AND dbr.group_database_id = dbcs.group_database_id WHERE dbr.group_id = @group_id AND dbr.replica_id = @replica_id AND dbr.group_database_id = @group_database_id; SELECT @last_commit_time_pri = dbr.last_commit_time, @is_local = dbr.is_local FROM sys.dm_hadr_database_replica_states AS dbr INNER JOIN sys.dm_hadr_database_replica_cluster_states AS dbcs ON dbr.replica_id = dbcs.replica_id AND dbr.group_database_id = dbcs.group_database_id WHERE dbr.group_id = @group_id AND dbr.is_primary_replica = 1 AND dbr.group_database_id = @group_database_id; IF @is_local IS NULL OR @is_failover_ready IS NULL BEGIN PRINT 'RPO of database ' + @db_name + ' is not available'; RETURN; END IF @is_local = 0 BEGIN PRINT 'You are visiting wrong replica'; RETURN; END IF @is_failover_ready = 1 SET @RPO = '00:00:00'; ELSE IF @last_commit_time_sec IS NULL OR @last_commit_time_pri IS NULL BEGIN PRINT 'RPO of database ' + @db_name + ' is not available'; RETURN; END ELSE BEGIN IF DATEDIFF(ss, @last_commit_time_sec, @last_commit_time_pri) < 0 BEGIN PRINT 'RPO of database ' + @db_name + ' is not available'; RETURN; END ELSE SET @RPO = CONVERT (VARCHAR, DATEADD(ms, datediff(ss, @last_commit_time_sec, @last_commit_time_pri) * 1000, 0), 114); END PRINT 'RPO of database ' + @db_name + ' is ' + @RPO; END -- secondary database's last_commit_time -- correlated primary database's last_commit_time使用目標輔助資料庫的group_id、replica_id和group_database_id來執行
proc_calculate_RPO。EXECUTE proc_calculate_RPO @group_id = 'F176DD65-C3EE-4240-BA23-EA615F965C9B', @replica_id = '405554F6-3FDC-4593-A650-2067F5FABFFD', @group_database_id = '39F7942F-7B5E-42C5-977D-02E7FFA6C392';輸出會顯示目標次要複本資料庫的 RPO 值。
監視 RTO 和 RPO
本節示範如何監視可用性群組的 RTO 和 RPO 指標。 此示範類似下列文章中提供的 GUI 教學課程：Always On 健康情況模型，第 2 部分：Extending the health model (Always On 健全狀況模型第 2 部分：擴充健全狀況模型)。
在 估計故障轉移時間 （RTO） 和 估計潛在資料丟失 （RPO） 中，故障轉移時間和潛在資料丟失計算的元素，被方便地提供作為政策管理層面的效能指標，在資料庫複製狀態中顯示。 如需詳細資訊，請參閱 在 SQL Server 物件上檢查策略式管理層面。 您可以依排程監視這兩個計量，並在計量分別超過您的 RTO 和 RPO 時收到警示。
示範指令碼會建立依照其個別排程執行的兩個系統原則，具有下列特性：
如果預估的容錯移轉時間超過 10 分鐘（並且每 5 分鐘評估一次），RTO 原則將會失敗。
當預估的資料遺失超過 1 小時 (每 30 分鐘進行評估) 時會失敗的 RPO 原則
這兩個原則在所有可用性複本上具有相同的設定
策略會在所有伺服器上進行評估，但僅限於本機可用性複本是主要複本的可用性群組。 如果本機可用性複本不是主要複本，則不會評估政策。
當您在主要複本上檢視時，政策失敗將會被方便地顯示在 "Always On" 儀表板中。
若要建立原則，請在參與可用性群組的所有伺服器實例上遵循下列指示：
如果尚未啟動 SQL Server Agent 服務，請啟動它。
在 SQL Server Management Studio 中，從 [工具] 功能表中，選取 [[選項]。
在 [ SQL Server Always On ] 索引標籤中，選取 [ 啟用使用者定義的 AlwaysOn 原則 ]，然後選取 [ 確定]。
此設定可讓您在 Always On 儀表板中顯示已正確設定的自訂原則。
使用下列規格建立以原則為基礎的管理條件：
-
名稱：
RTO - Facet：資料庫複本狀態
-
欄位：
Add(@EstimatedRecoveryTime, 60) - 運算子: <=
-
值：
600
當潛在的故障轉移時間超過10分鐘時，此狀況會失敗，包括失敗偵測和故障轉移的60秒額外負荷。
-
名稱：
使用下列規格建立第二個以原則為基礎的管理條件：
-
名稱：
RPO - Facet：資料庫複本狀態
-
欄位：
@EstimatedDataLoss - 運算子: <=
-
值：
3600
當潛在資料遺失超過 1 小時時，此條件會失敗。
-
名稱：
使用下列規格建立第三個以原則為基礎的管理條件：
-
名稱：
IsPrimaryReplica - Facet：可用性群組
-
欄位：
@LocalReplicaRole - 運算子：=
-
值：
Primary
此條件會檢查給定可用性群組的本機可用性複本是否為主要複本。
-
名稱：
使用下列規格建立以原則為基礎的管理原則：
一般 頁面：
名稱：
CustomSecondaryDatabaseRTO檢查條件：
RTO針對目標：IsPrimaryReplica AvailabilityGroup 中的每個DatabaseReplicaState
此設定可確保政策僅在具有本地主要複本的可用性群組中進行評估。
評估模式：按計劃進行
排程：CollectorSchedule_Every_5min
已啟用：選取
[描述] 頁面：
類別：可用性資料庫警告
此設定可讓原則評估結果在 Always On 儀表板中顯示。
描述：目前複本的 RTO 超過 10 分鐘，且假設用於探索和容錯移轉的時間額外負荷為 1 分鐘。您應該立即調查個別伺服器執行個體的效能上的問題。
要顯示的文字：RTO 已超過！
使用下列規格建立第二個以原則為基礎的管理原則：
一般 頁面：
-
名稱：
CustomAvailabilityDatabaseRPO -
檢查條件：
RPO - 針對目標：IsPrimaryReplica AvailabilityGroup 中的每個DatabaseReplicaState
- 評估模式：按計劃進行
- 排程：每30分鐘_收集器排程
- 已啟用：選取
-
名稱：
描述頁面：
類別：可用性資料庫警告
描述：可用性資料庫已超過您的 1 小時復原目標時間 (RPO)。您應該立刻調查可用性複本的效能上的問題。
顯示文本：RPO 已超出限制！
完成後，將創建兩個新的 SQL Server Agent 工作，分別對應於每項策略評估排程。 這些作業的名稱應該以 開頭 syspolicy_check_schedule。
您可以檢視作業記錄以檢查評估結果。 評估失敗也會記錄在事件識別碼為 34052 的 Windows 應用程式記錄檔中 (位於 [事件檢視器])。 您也可以設定 SQL Server Agent 在原則失敗時傳送警示。 如需詳細資訊，請參閱 設定警示以通知原則系統管理員關於原則失敗。
效能疑難排解案例
下表列出常見的效能相關疑難排解案例。
| 情境 | 描述 |
|---|---|
| 疑難排解：可用性群組已超過 RTO | 在自動故障轉移或手動故障轉移計畫中如果沒有資料遺失，故障轉移時間可能會超過您的 RTO。 或者，當您評估同步提交次要複本（例如自動容錯移轉夥伴）的容錯移轉時間時，發現它超過您的 RTO。 |
| 疑難排解：可用性群組已超過 RPO | 在您執行強制手動容錯移轉之後，遺失的資料超過您的 RPO。 或者，當您計算非同步提交的次要副本的潛在資料遺失時，發現它超過您的 RPO。 |
| 疑難排解：對主要複本的變更未反映在次要複本上 | 用戶端應用程式會順利完成主要複本上的更新，但查詢次要複本會顯示變更並未反映。 |
實用的延伸事件
當針對同步處理中狀態的複本進行疑難排解時，下列擴充事件很有用。
| 活動名稱 | 類別 | 管道 | 可用性複本 |
|---|---|---|---|
redo_caught_up |
交易 | 除錯 | 次要 |
redo_worker_entry |
交易活動 | 除錯 | 次要 |
hadr_transport_dump_message |
alwayson |
除錯 | Primary |
hadr_worker_pool_task |
alwayson |
除錯 | Primary |
hadr_dump_primary_progress |
alwayson |
除錯 | Primary |
hadr_dump_log_progress |
alwayson |
除錯 | Primary |
hadr_undo_of_redo_log_scan |
alwayson |
分析 | 次要 |