役割の交代中に発生するサービスの中断時間の算出
役割の交代中、データベース ミラーリングを使用できない時間の長さは、役割の交代の形式、および原因によって異なります。
自動フェールオーバーの場合、サービスが中断される時間には 2 つの要因が影響します。ミラー サーバーがプリンシパル サーバー インスタンスに障害が発生したことを認識するのに必要な時間 (エラー検出)、およびデータベースのフェールオーバーに必要な時間 (フェールオーバー時間) です。
強制的なサービスの操作の場合、障害が発生しても、障害を検出し対応するのは人間の応答時間に依存します。しかし、ミラー サーバーが強制的なサービス コマンドを発行した後で役割を交代する時間を算出するだけで、サービスが中断した場合の時間を算出することができます。
.gif "注意")
注意エラーの種類などの特定の条件を検出するのに必要な時間を減らすには、条件の警告を定義できます。
手動フェールオーバーでは、フェールオーバー コマンドの発行以降にデータベースをフェールオーバーするために必要な時間だけになります。
エラー検出
システムにエラーが通知されるまでの時間は、エラーの種類によって異なります。たとえば、ネットワーク エラーは発生した直後に通知されます。サーバーが応答しなくなった場合は、既定で 10 秒かかります。これは既定のタイムアウト期間です。
データベース ミラーリング セッション中に障害が発生する原因と考えられるエラー、および自動フェールオーバーを伴う高い安全性モードでのタイムアウト検出の詳細については、「データベース ミラーリング中に発生する可能性のあるエラー」を参照してください。
フェールオーバー時間
フェールオーバー時間の内訳は、以前のミラー サーバーが再実行キューに残っているすべてのログをロールフォワードするために必要な時間を主とし、これにわずかな時間を加えたものです (ミラー サーバーでログ レコードが処理される方法の詳細については、「データベース ミラーリング セッション」を参照してください)。フェールオーバー時間の測定方法の詳細については、このトピックの「フェールオーバーの再実行速度の測定」を参照してください。
.gif "重要な注意事項") 重要 |
|---|
インデックスまたはテーブルを作成し、変更するトランザクション中にフェールオーバーが発生した場合、フェールオーバーには通常より長い時間がかかる可能性があります。たとえば、BEGIN TRANSACTION、テーブルに対する CREATE INDEX、SELECT INTO という一連の操作では、フェールオーバーの時間が増加する場合があります。このようなトランザクションでは、COMMIT TRANSACTION ステートメントまたは ROLLBACK TRANSACTION ステートメントを使用してトランザクションを完了するまで、フェールオーバーの時間が増加する可能性は残ります。 |
再実行キュー
データベースのロールフォワードでは、現在ミラー サーバー上の再実行キューにあるすべてのログ レコードが適用されます。再実行キューは、ミラー サーバー上のディスクに再実行用として書き込まれていて、ミラー データベースへはロールフォワードされていないログ レコードで構成されています。
データベースのフェールオーバー時間は、再実行キュー内のログがミラー サーバーからロールフォワードされる速度によって決まります。つまり、主にシステムのハードウェアと現在のワークロードによって決まります。場合によっては、プリンシパル データベースがビジーになり、ミラー サーバーからログがロールフォワードされる速度よりも、プリンシパル サーバーからミラー サーバーにログが送信される速度の方が大幅に速くなることがあります。この状況では、ミラー サーバーが再実行キューのログをロールフォワードする間、フェールオーバーに相当な時間がかかる場合があります。再実行キューの現在のサイズを調べるには、データベース ミラーリング パフォーマンス オブジェクトの Redo Queue カウンタを使用します。詳細については、「SQL Server:Database Mirroring オブジェクト」を参照してください。
フェールオーバーの再実行速度の測定
実稼働データベースのテスト コピーを使用して、ログ レコードのロールフォワードに必要な時間 (再実行速度) を測定できます。
フェールオーバー時のロールフォワード時間を測定する方法は、再実行フェーズ中にミラー サーバーによって使用されるスレッドの数によって異なります。スレッドの数は以下の条件によって異なります。
SQL Server 2008 Standard の場合、データベースのロールフォワードにミラー サーバーが使用するスレッドは常に 1 つです。
SQL Server 2008 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 で自動フェールオーバーが完了するのに必要な時間に、エラー検出とフェールオーバー時間がどのように影響しているのかを示します。フェールオーバーには、データベースをロールフォワードする (再実行フェーズ) ための時間に加え、データベースをオンラインにするための短い時間が必要です。コミットされていないトランザクションのロールバックを実行する元に戻すフェーズは、新しいプリンシパル データベースがオンラインになった後に発生し、フェールオーバー後に続行します。元に戻すフェーズの間、データベースは使用できます。
.gif "エラー検出とフェールオーバー時間")