役割の交代中に発生するサービスの中断時間の算出

[アーティクル]
12/16/2008

更新 : 2005 年 12 月 5 日

役割の交代中、データベースミラーリングを使用できない時間の長さは、役割の交代の形式、および原因によって異なります。

自動フェールオーバーの場合、サービスが中断される時間には 2 つの要因が影響します。ミラーサーバーがプリンシパルサーバーインスタンスに障害が発生したことを認識するのに必要な時間 (エラー検出)、およびデータベースのフェールオーバーに必要な時間 (フェールオーバー時間) です。
強制的なサービスの操作の場合、障害が発生しても、障害を検出し対応するのは人間の応答時間に依存します。しかし、ミラーサーバーが強制的なサービスコマンドを発行した後で役割を交代する時間を算出するだけで、サービスが中断した場合の時間を算出することができます。

メモ :

エラーの種類などの特定の条件を検出するのに必要な時間を減らすには、条件の警告を定義できます。
手動フェールオーバーでは、フェールオーバーコマンドの発行以降にデータベースをフェールオーバーするために必要な時間だけになります。

メモ :
エラーの種類などの特定の条件を検出するのに必要な時間を減らすには、条件の警告を定義できます。

エラー検出

システムにエラーが通知されるまでの時間は、エラーの種類によって異なります。たとえば、ネットワークエラーは発生した直後に通知されます。サーバーが応答しなくなった場合は、既定で 10 秒かかります。これは既定のタイムアウト期間です。

データベースミラーリングセッション中に障害が発生する原因と考えられるエラー、および自動フェールオーバーを伴う高い安全性モードでのタイムアウト検出の詳細については、「データベースミラーリング中に発生する可能性のあるエラー」を参照してください。

フェールオーバー時間

フェールオーバー時間の内訳は、以前のミラーサーバーが再実行キューに残っているすべてのログをロールフォワードするために必要な時間を主とし、これにわずかな時間を加えたものです (ミラーサーバーでログレコードが処理される方法の詳細については、「データベースミラーリングセッション」を参照してください)。フェールオーバー時間の測定方法の詳細については、このトピックの「フェールオーバーの再実行速度の測定」を参照してください。

重要 :
インデックスまたはテーブルを作成し、変更するトランザクション中にフェールオーバーが発生した場合、フェールオーバーには通常より長い時間がかかる可能性があります。たとえば、BEGIN TRANSACTION、テーブルに対する CREATE INDEX、SELECT INTO という一連の操作では、フェールオーバーの時間が増加する場合があります。このようなトランザクションでは、COMMIT TRANSACTION ステートメントまたは ROLLBACK TRANSACTION ステートメントを使用してトランザクションを完了するまで、フェールオーバーの時間が増加する可能性は残ります。

インデックスまたはテーブルを作成し、変更するトランザクション中にフェールオーバーが発生した場合、フェールオーバーには通常より長い時間がかかる可能性があります。たとえば、BEGIN TRANSACTION、テーブルに対する CREATE INDEX、SELECT INTO という一連の操作では、フェールオーバーの時間が増加する場合があります。このようなトランザクションでは、COMMIT TRANSACTION ステートメントまたは ROLLBACK TRANSACTION ステートメントを使用してトランザクションを完了するまで、フェールオーバーの時間が増加する可能性は残ります。

再実行キュー

データベースのロールフォワードでは、現在ミラーサーバー上の再実行キューにあるすべてのログレコードが適用されます。再実行キューは、ミラーサーバー上のディスクに再実行用として書き込まれていて、ミラーデータベースへはロールフォワードされていないログレコードで構成されています。

データベースのフェールオーバー時間は、再実行キュー内のログがミラーサーバーからロールフォワードされる速度によって決まります。つまり、主にシステムのハードウェアと現在のワークロードによって決まります。場合によっては、プリンシパルデータベースがビジーになり、ミラーサーバーからログがロールフォワードされる速度よりも、プリンシパルサーバーからミラーサーバーにログが送信される速度の方が大幅に速くなることがあります。この状況では、ミラーサーバーが再実行キューのログをロールフォワードする間、フェールオーバーに相当な時間がかかる場合があります。再実行キューの現在のサイズを調べるには、データベースミラーリングパフォーマンスオブジェクトの Redo Queue カウンタを使用します。詳細については、「SQL Server:Database Mirroring オブジェクト」を参照してください。

フェールオーバーの再実行速度の測定

実稼働データベースのテストコピーを使用して、ログレコードのロールフォワードに必要な時間 (再実行速度) を測定できます。

フェールオーバー時のロールフォワード時間を測定する方法は、再実行フェーズ中にミラーサーバーによって使用されるスレッドの数によって異なります。スレッドの数は、SQL Server のエディションによって異なります。SQL Server 2005 Enterprise Edition では、次のように CPU の数に依存します。

SQL Server Standard Edition の場合、データベースのロールフォワードにミラーサーバーが使用するスレッドは常に 1 つです。
SQL Server 2005 Enterprise Edition では、5 基未満の CPU が搭載されたコンピュータ上のミラーサーバーでも、1 つのスレッドのみが使用されます。5 基以上の CPU が搭載されている場合、ミラーサーバーでは、フェールオーバー時にロールフォワード操作が複数スレッドに分散されます (これは、並列再実行と呼ばれています)。並列再実行は、4 基の CPU ごとに 1 つのスレッドを使用するように最適化されています。

シングルスレッドでの再実行速度の測定

シングルスレッドでの再実行では、フェールオーバー時にミラーデータベースをロールフォワードすると、ログバックアップの復元で同量のログをロールフォワードするのと同程度の時間がかかります。フェールオーバー時間を測定するには、ミラーリングを実行しようとしている環境にテストデータベースを作成します。次に、実稼働データベースからログバックアップを取得します。そのログのバックアップの再実行速度を測定するには、ログバックアップを WITH NORECOVERY でテストデータベースに復元するのにかかる時間を測定します。

ミラーサーバーの再実行速度がわかったら、特定の時点にデータベースをフェールオーバーするのにかかる時間を測定できます。この値は、(Redo Queue パフォーマンスカウンタで測定した) ミラー上で再実行される現在のログのサイズを、再実行速度で割ることによって取得できます。通常の状況下では、プリンシパルからの読み込みに対してミラーサーバーが遅延していない場合、Redo Queue は小さい値であるかゼロに近く、フェールオーバーには数秒しかかかりません。

並列再実行速度の測定

Enterprise Edition では、並列再実行は、4 基の CPU ごとに 1 つのスレッドを使用するように最適化されています。並列再実行のロールフォワード時間を測定するには、テストデータベースにアクセスするよりも、稼働中のテストシステムにアクセスした方がより正確な値を得られます。ミラーサーバー上の再実行キューを監視している間は、プリンシパルサーバー上の負荷を増やします。通常の運用では、再実行キューはゼロに近くなります。Redo Queue が継続的に増加し始めるまでは、プリンシパルサーバー上の負荷を増やします。そうすると、システムが最大の再実行速度になり、この時点で Redo Bytes/sec パフォーマンスカウンタは、最大の再実行速度を示します。詳細については、「SQL Server:Database Mirroring オブジェクト」を参照してください。

自動フェールオーバー中に発生するサービスの中断時間の算出

下の図は、Partner_B で自動フェールオーバーが完了するのに必要な時間に、エラー検出とフェールオーバー時間がどのように影響しているのかを示します。フェールオーバーには、データベースをロールフォワードする (再実行フェーズ) ための時間に加え、データベースをオンラインにするための短い時間が必要です。コミットされていないトランザクションのロールバックを実行する元に戻すフェーズは、新しいプリンシパルデータベースがオンラインになった後に発生し、フェールオーバー後に続行します。元に戻すフェーズの間、データベースは使用できます。

エラー検出とフェールオーバー時間

参照

変更履歴

リリース	履歴
2005 年 12 月 5 日	変更内容 : 役割の交代の形式ごとにサービスの中断の説明を再構成しました。

次の方法で共有