トラブルシューティング:可用性グループ接続の超過 RTO

  • [アーティクル]

適用対象:SQL Server

可用性グループのデータ損失のない自動フェールオーバーまたは計画された手動フェールオーバーの後に、フェールオーバー時間が回復時刻の目標 (RTO) を超えていることに気づく場合があります。 または、「Always On 可用性グループのパフォーマンスを監視する」の方法を使用して同期コミット セカンダリ レプリカのフェールオーバー時間を推定したとき (自動フェールオーバー パートナーなど)、RTO を超過していることが判明します。

自動フェールオーバーが完了していない場合、「Troubleshooting automatic failover problems in SQL Server 2012 Always On environments」(SQL Server 2012 AlwaysOn の環境での自動フェールオーバーに関する問題のトラブルシューティング) を参照してください。

次のセクションでは、フェールオーバー時間が RTO を超える一般的な原因について説明します。

  1. レポート ワークロードが再実行スレッドの実行をブロックする

  2. リソースの競合のために再実行スレッドが遅れる

レポート ワークロードが再実行スレッドの実行をブロックする

セカンダリ レプリカの再実行スレッドが、実行時間の長い読み取り専用クエリによるデータ定義言語 (DDL) の変更をブロックしています。

説明

セカンダリ レプリカで、読み取り専用のクエリが、スキーマ安定度 (Sch-S) ロックを取得します。 これらの Sch-S ロックは、DDL の変更を実行するためのスキーマ変更 (Sch-M) ロックを再実行スレッドが取得できないようにブロックします。 ブロックされた再実行スレッドは、ブロック解除されるまで、ログ レコードを適用できません。 ブロックが解除されると、ログの末尾に追いつき、後続の元に戻すプロセスとフェールオーバー プロセスを続行することができます。

診断と解決

再実行スレッドがブロックされると、sqlserver.lock_redo_blocked と呼ばれる拡張イベントが生成されます。 さらに、DMV sys.dm_exec_request をクエリして、どのセッションが再実行スレッドをブロックしているかを調べ、是正措置を行うことができます。 次のクエリでは、再実行スレッドをブロックしている読み取り専用クエリのセッション ID を返します。

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'

レポート ワークロードを完了させて、その時点で再実行スレッドをブロック解除させるか、ブロックしているセッション ID で 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 の競合がある場合、リソース ガバナーを使用して、レポート ワークロードによって使用される CPU サイクルを制御し、取得される I/O サイクルを間接的にある程度制御することができます。 たとえば、レポート ワークロードが CPU の 10% を消費していても、ワークロードが I/O バウンドになっている場合は、リソース ガバナーを使用して、CPU リソースの使用率を 5% に制限し、読み取りワークロードを制限して、I/O への影響を最小限に抑えることができます。

次のステップ

SQL Server (SQL Server 2012 に適用されます) のパフォーマンスに関する問題のトラブルシューティング