疑難排解：可用性群組已超過 RTO
適用於：
SQL Server
在可用性群組上進行自動容錯移轉或規劃的手動容錯移轉之後沒有資料遺失，您可能會發現容錯移轉時間超過您的復原時間目標 (RTO)。 或者，當您在使用監視 Always On 可用性群組的效能中的方法評估同步認可次要複本的容錯移轉時間時，發現它超過您的 RTO。
如果您的自動容錯移轉仍未完成，請參閱針對 SQL Server 2012 Always On 環境中的自動容錯移轉問題進行疑難排解 \(機器翻譯\)。
下節說明造成容錯移轉的時間超過 RTO 的常見原因。
報告工作負載封鎖重做執行緒因而無法執行
在次要複本上的重做執行緒被長時間執行的唯讀查詢封鎖，因而無法進行資料定義語言 (DDL) 變更。
說明
在次要複本上，唯讀查詢取得結構描述穩定性 (Sch-S) 鎖定。 這些 Sch-S 鎖定可以封鎖重做執行緒，使它無法取得結構描述修改 (Sch-M) 鎖定以進行任何 DDL 變更。 除非解除重做執行緒的封鎖，否則被封鎖的重做執行緒將無法套用任何記錄檔記錄。 一旦解除封鎖，它就能繼續跟上記錄的結尾，並允許後續的復原和容錯移轉流程繼續處理。
診斷和解決方案
當重做執行緒被封鎖時，會產生稱為 sqlserver.lock_redo_blocked 的擴充事件。 此外，您可以查詢次要複本上的 DMV sys.dm_exec_request，以找出封鎖重做執行緒的工作階段，然後採取修正措施。 以下查詢傳回唯讀查詢的工作階段識別碼，而此唯讀查詢正在封鎖重做執行緒。
select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource
from sys.dm_exec_requests where command = 'DB STARTUP'
您可以讓報告工作負載完成，屆時重做執行緒便會解除封鎖。或者，您可以對造成封鎖的工作階段識別碼執行 KILL (Transact-SQL) 命令，以立即解除封鎖重做執行緒。
重做執行緒因資源競爭而落後
次要複本上的大型報告工作負載造成次要複本的效能緩慢，且重做執行緒已經落後。
說明
當在次要複本上套用記錄檔記錄時，重做執行緒會從記錄檔磁碟讀取記錄檔記錄，然後它會針對每個記錄檔記錄存取資料分頁以套用記錄檔記錄。 如果分頁尚未在緩衝集區中，分頁存取可能會具有 I/O 界限 (存取實體磁碟)。 如果有具有 I/O 界限的報告工作負載，報告工作負載會與重做執行緒競爭取得 I/O 資源，因此可能使重做執行緒緩慢。
診斷和解決方案
您可以使用以下的 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
如果重做執行緒確實落後，則您需要調查次要複本效能降低的根本原因。 如果和報告工作負載有 I/O 競爭，您可以使用 Resource Governor 來控制報告工作負載使用的 CPU 週期，進而間接地在某種程度上控制 I/O 週期。 例如，如果您的報告工作負載取用百分之 10 的 CPU，但它是以 I/O 為主的工作負載，則您可以使用 Resource Governor 將 CPU 資源使用量限制為百分之 5，以限制讀取工作負載，進而降低對 I/O 的影響。