次の方法で共有

役割の交代中に発生するサービスの中断時間の算出 (データベース ミラーリング)

  • [アーティクル]

適用対象 SQL Server

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

  • 自動フェールオーバーの場合、サービスが中断される時間には 2 つの要因が影響します。ミラー サーバーがプリンシパル サーバー インスタンスに障害が発生したことを認識するのに必要な時間 (エラー検出)、およびデータベースのフェールオーバーに必要な時間 (フェールオーバー時間) です。

  • 強制的なサービスの操作の場合、障害が発生しても、障害を検出し対応するのは人間の応答時間に依存します。 しかし、ミラー サーバーが強制的なサービス コマンドを発行した後で役割を交代する時間を算出するだけで、サービスが中断した場合の時間を算出することができます。

    注意

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

  • 手動フェールオーバーでは、フェールオーバー コマンドの発行以降にデータベースをフェールオーバーするために必要な時間だけになります。

エラー検出

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

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

フェールオーバー時間

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

重要

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

再実行キュー

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

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

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

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

フェールオーバー時のロールフォワード時間を測定する方法は、再実行フェーズ中にミラー サーバーによって使用されるスレッドの数によって異なります。 スレッドの数は以下の条件によって異なります。

  • SQL Server Standard エディションの場合、データベースのロールフォワードにミラー サーバーが使用するスレッドは常に 1 つです。

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

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

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

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

並列再実行速度の測定

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

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

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

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

参照

Database Mirroring Operating Modes
データベース ミラーリング セッション中の役割の交代 (SQL Server)
データベース ミラーリングの監視 (SQL Server)