データベース ミラーリングのベスト プラクティスおよびパフォーマンスに関する考慮事項

このページはアーカイブです。記載されている内容は情報提供のみを目的としており、ページ内のリンクは有効でない可能性がありますが、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

公開日: 2006年3月10日

SQL Server に関するテクニカル記事

著者 :     Sanjay Mishra、Microsoft Corp.

テクニカルレビューア **:    **Brian Goldstein、Microsoft Corp.

    Lubor Kollar、Microsoft Corp.

    Mike Ruthruff、Microsoft Corp.

    Steven Wort、Microsoft Corp.

    Prem Mehra、Microsoft Corp.

    Peter Byrne、Microsoft Corp.

    Mark Wistrom、Microsoft Corp.

    Jakub Kulesza、Microsoft Corp.

    Juergen Thomas、Microsoft Corp.

    Michael Raheem、Microsoft Corp.

    Allan Hirt、Avanade, Inc.

対象 : SQL Server 2005

概要 : データベースの可用性を最大化することは、世界中の多くのデータベース管理者にとって最優先事項です。データベース ミラーリングは、予定的および予定外のダウンタイムを最小限に抑え、データベースの可用性を最大化できるようにする SQL Server 2005 の新機能です。データベース ミラーリングは、同期的または非同期的に、運用データベースからミラー データベースに変更内容を転送します。ミラー データベースは、同じデータ センター内に配置して高可用性ソリューションを提供することも、リモート データ センターに配置して障害回復ソリューションを提供することもできます。ログの生成速度、ネットワーク スループット、I/O スループットなどの技術的な要因と共に、サービス レベル契約やパフォーマンスなどのビジネスの要件もデータベース ミラーリングの展開に影響します。このホワイト ペーパーでは、データベース ミラーリングを実装する場合のベスト プラクティスおよびパフォーマンスに関する考慮事項について説明します。

トピック

はじめに
データベース ミラーリングの概念
テスト方法と作業負荷
トランザクションの安全性レベル
フェールオーバーに関する考慮事項
セキュリティに関する考慮事項
ネットワーク構成のベスト プラクティス
ミラーのフェールオーバーの準備
プリンシパルとミラーの初回の同期
複数のデータベースのミラーリング
ミラーリング情報の表示
まとめ
付録 A テスト環境

はじめに

ビジネス クリティカルなアプリケーションの最も重要な要件の 1 つにデータベースの可用性があります。データベースの可用性を最大化することは、多くのデータベース管理者にとって最優先事項です。Microsoft SQL Server™  2005 の新機能であるデータベース ミラーリングによって、SQL Server の可用性を向上させるための新しい手段が追加されます。

データベースの可用性を最大化するには、計画外および計画的なダウンタイムを最小限に抑える必要があります。計画外のダウンタイムは、主にハードウェア障害 (コンピュータの障害や記憶域の障害)、ディスクの破損、停電、通信障害、自然災害、テロリズム、人為的なミス、およびプライマリ運用データベース、運用サーバー、運用データ センターを使用不可能にするその他の要因によって発生します。計画的なダウンタイムは、主に運用システムに変更を適用するために発生します。このような変更にはハードウェアのアップグレード、ソフトウェアのアップグレード、およびデータベースの記憶域や構成の変更などがあり、これによってプライマリ データベースやサーバーが短時間使用不可能になります。

データベース ミラーリングでは、以下の処理によって計画的なダウンタイムと計画外のダウンタイムの両方を最小限にします。

• 同期的または非同期的に運用データベースの最新の状態に保たれたミラー データベースを保持します。

• 自動および手動のフェールオーバーを実行する方法を提供します。

• ミラー データベースをリモート データ センターに配置できるようにすることで、障害回復の基盤を提供します。

このホワイト ペーパーでは、データベース ミラーリングのベスト プラクティスおよびパフォーマンスに関する考慮事項について説明します。このホワイト ペーパーの対象読者は次のとおりです。

• データベース ミラーリングを実装するデータベース管理者。

• 高可用性のデータベース アプリケーションや障害回復のフレームワークを設計するデータベース アナリストおよびシステム管理者。

このホワイト ペーパーを読む前に、前提条件として以下の資料に目を通しておいてください。

• SQL Server 2005 Books Online の「Database Mirroring」

• Microsoft TechNet のホワイト ペーパー「SQL Server 2005 データベース ミラーリング」

• マイクロソフト サポート技術情報の「SQL Server 2005 のデータベース ミラーリング機能を使用する場合の注意事項」

データベース ミラーリングの概念

データベース ミラーリングでは、プリンシパル データベースが機能を停止した場合にクライアント接続を即座に引き受けることができるホット スタンバイ データベース (ミラー データベースと呼ばれる) が保持されます。データベース ミラーリングでは、1つのデータベースについて 2 つのコピーが異なるコンピュータに配置されます。どの時点でも、クライアントが使用できるデータベースのコピーは 1 つだけです。このコピーをプリンシパル データベースと呼びます。完全なトランザクション ログ バックアップをウォーム スタンバイ データベースに適用するログ配布とは異なり、データベース ミラーリングはデータベース ログ レコードのストリームをプリンシパル データベースからデータベースのもう 1 つのコピー (ミラー データベース) に転送および適用することによって機能します。データベース ミラーリングでは、プリンシパル データベースに対して行われたすべてのデータベースの変更がミラー データベースにも適用されます。これには、データの変更と共に、データベース ファイル、テーブル、インデックスなど、データベースの物理的および論理的構造に対する変更も含まれます。

データベース ミラーリングの概念の詳細については、SQL Server 2005 Books Online を参照してください。データベース ミラーリングに関連する基本的な用語を以下に示します。

プリンシパル: データベース ミラーリング構成では、1 つのデータベースについて 2 つのコピーが存在しますが、クライアントがアクセスできるコピーは常に 1 つだけです。アプリケーションが接続するデータベースのコピーを "プリンシパル データベース" と呼びます。プリンシパル データベースをホストするサーバーを "プリンシパル サーバー" と呼びます。

ミラー: "ミラー" はプリンシパル データベースのコピーです。ミラーは常に復元状態ですが、アプリケーションからアクセスすることはできません。このデータベースを最新の状態に保つために、ログ レコードがプリンシパルから転送され、ミラー データベースに適用されます。ミラー データベースをホストするサーバーを "ミラー サーバー" と呼びます。

ミラーリング監視: オプションの "ミラーリング監視" は、データベース ミラーリング構成での SQL Server インスタンスです。このインスタンスは、プリンシパル インスタンスおよびミラー インスタンスとは別のインスタンスです。データベース ミラーリングを同期モードで使用する場合、ミラーリング監視によって自動フェールオーバーのメカニズムが提供されます。

送信キュー: プリンシパルからミラーにログ レコードを送信するときに、生成される速度でログ レコードを送信できない場合、プリンシパルにキューが作成されます。これを "送信キュー" と呼びます。送信キューは追加の記憶域やメモリを使用しません。送信キューはすべてプリンシパルのトランザクション ログ内に存在します。送信キューは、ログのまだミラーに送信されていない部分を指します。

再実行キュー: ログ レコードをミラーに適用する際に、受信速度でログ レコードを適用できない場合、ミラーにキューが作成されます。これを "再実行キュー" と呼びます。送信キューと同様に、再実行キューも追加の記憶域やメモリを必要としません。再実行キューはすべてミラーのトランザクション ログ内に存在します。再実行キューは、固定されたログのミラー データベースに適用してロールフォワードする必要がある部分を指します。

エンドポイント: エンドポイントは SQL Server がネットワーク経由で通信できるようにする SQL Server のオブジェクトです。エンドポイントは、トランスポート プロトコルとポート番号をカプセル化します。

フェールオーバー: プリンシパル データベース (またはプリンシパル データベースをホストするサーバー) に障害が発生した場合、データベース ミラーリングはミラー データベースにフェールオーバーするメカニズムを提供します。

データベース ミラーリングの重要なポイントのいくつかを以下に示します。

• データベース ミラーリングの最小の単位はデータベースです。ミラーリングは一度に 1 つのデータベースについて構成されます。インスタンス全体はミラーリングされません。

• データベース ミラーリングでは同じデータベースの 2 つのコピーが使用されますが、アプリケーションからアクセスできるデータベースは常に 1 つだけです。ミラーリングのスナップショットを作成し、読み取り専用 (レポートの要件に適したソリューション) として使用することができます。ただし、ミラー データベースに直接アクセスしたり、ミラー データベースをバックアップしたりすることはできません。

• master、msdb、temp、または model データベースをミラーリングすることはできません。

• データベース ミラーリングを使用するには、データベースで完全復旧モデルを使用する必要があります。単純復旧モデルや一括ログ復旧モデルを使用することはできません。

• SQL Server 2005 では、各プリンシパル データベースについてミラー データベースを 1 つだけ使用できます。

• 1 つのインスタンスで、あるデータベースのプリンシパル、別のデータベースのミラー、また別のデータベースのミラーリング監視を処理することができます。

• インスタンス内の複数のデータベースをミラーリングすることができます。

• ADO.NET または SQL Native Client (SNAC) を使用してデータベースに接続しているアプリケーションでは、データベースがミラーにフェールオーバーしたときに自動的に接続をリダイレクトすることができます。

• プリンシパルとミラーの間で転送されるデータは既定で暗号化されます。

• 別のサーバーにミラーリングされたデータベースを、ログ配布シナリオのソース データベースとして使用することもできます。

テスト方法と作業負荷

マイクロソフトでは、ローカル エリア ネットワーク (LAN)、メトロポリタン エリア ネットワーク (MAN)、およびワイド エリア ネットワーク (WAN) (シミュレーションと実際の環境の両方) を使用して、さまざまなアプリケーション プロファイルの作業負荷で一連のテストを実施し、同期および非同期操作でデータベース ミラーリングを構成する際のベスト プラクティスを特定しました。データベース ミラーリングのパフォーマンスは、アプリケーションの特性と環境の特性によって決まります。ログの生成速度、トランザクションのコミット速度、および同時データベース接続の数などのアプリケーションの特性は、データベース ミラーリングのパフォーマンスに影響します。また、トランザクションの安全性レベル、I/O のスループット、およびネットワーク パフォーマンスなどの環境の特性もデータベース ミラーリングのパフォーマンスに影響します。

このドキュメントで説明するテストでは、マイクロソフトのハードウェア パートナーである NEC から提供されたデータベース サーバーおよび記憶装置を使用しています。テスト環境の詳細については、付録 A を参照してください。

メモ: このドキュメントで公開された結果は、必ずしも、記述されているハードウェアでのデータベース ミラーリング機能の最適なパフォーマンスというわけではありません。使用する環境で最適な構成を決定するには、使用するアプリケーションとハードウェアを使用してデータベース ミラーリングをテストし、サービス レベルの要件を満たしていることを検証する必要があります。

テストは 2 つの作業負荷で実施されました。これらの作業負荷は、データベースのサイズ、ユーザー接続の数、トランザクション速度、および生成の再実行速度が異なります。どちらの作業負荷にも SELECT、INSERT、UPDATE、および DELETE 操作が含まれています。2 つの作業負荷のアプリケーション プロファイルを表 1 に示します。

特性	作業負荷 1	作業負荷 2
データベース サイズ (GB)	40	20
同時ユーザー接続の数	1,000	20
トランザクション間の最大待ち時間 (秒)	4	0
ベースライン (ミラーリングなし) の CPU 使用率 (%)	4	40
データ ディスクへの書き込み速度 (KB/秒)	4,500	1,500
ログ ディスクへの書き込み速度 (KB/秒)	720	12,000
ベースライン (ミラーリングなし) のトランザクション数/秒	241	215
ベースライン (ミラーリングなし) のログ生成速度 (KB/秒)	720	12,000

表 **1: ** 作業負荷のアプリケーションプロファイル

作業負荷 1 および作業負荷 2 は、いずれもオンライン トランザクション処理 (OLTP) アプリケーションです。作業負荷 1 は、注文、支払、配送、および関連情報を追跡する注文管理システムです。このシステムでは、ランダムな I/O が大量に発生し、CPU 使用率は非常に低く、同時接続ユーザー数は多くなっています。作業負荷 2 は株式取引アプリケーションです。このアプリケーションは、株価と株式の注文を取得します。このアプリケーションでは、データベースのサイズは小さくなりますが、ログ生成速度が速くなります。

表 1 に示した特性のうちで、最初の 3 つはアプリケーションの設定を通して測定および管理されます。残りは、Windows のシステム モニタ (perfmon) のカウンタによって測定されます。データベース ミラーリングに関して最も重要なアプリケーションの特定はログの生成速度です。アプリケーションのログの生成速度は、システム モニタでデータベースの Log Bytes Flushed/sec カウンタを監視することによって測定できます。アプリケーションによって生成されるログの量は、ネットワーク経由でミラー データベースに送信される情報の量であるため、パフォーマンスに最も大きな影響があります。

トランザクションの安全性レベル

データベース ミラーリングの構成で最も重要な決定事項の 1 つが、適切なトランザクションの安全性レベルを選択することです。トランザクションの安全性レベルによって、プリンシパル データベースに対する変更が、ミラー データベースに同期的に適用されるか、非同期的に適用されるかが決まります。SQL Server 2005 には、OFF と FULL の 2 つの安全性レベルがあります。

安全性 OFF は、通常 "非同期ミラーリング" と呼ばれます。非同期ミラーリングでは、パフォーマンスが高くなるようにデータベース ミラーリングを設定します。安全性が OFF の場合、プリンシパル サーバーがログ レコードをローカル ログに書き込み、そのログ レコードをミラーに送信すると同時に、ミラー サーバーからの確認応答を待たずに、トランザクションがコミットされます。データベースは、ミラー サーバーがプリンシパル サーバーに追いついた時点で同期されます。ただし、トランザクションは、ミラー サーバーがログ レコードをログ ファイルに書き込む (トランザクション ログの "固定" とも呼ばれる) のを待たずにコミットされます。プリンシパルが、ログ レコードが生成される速度でミラーにログ レコードを送信できない場合、プリンシパルにキューが作成されます。これを送信キューと呼びます。送信キューは、プリンシパルでシステム モニタの Log Send Queue KB カウンタを使用して監視されます。プリンシパルに障害が発生すると、ミラーで一部のログ レコードが受信されない場合があり、これによってデータが失われる可能性があります。非同期ミラーリングを使用する場合、プリンシパル データベースに対するパフォーマンス上の影響は無視できる程度であることに注意してください。

安全性 FULL は、通常 "同期ミラーリング" と呼ばれます。これによって高い安全性が提供されます。プリンシパル データベースでコミットされた各トランザクションは、同期的にミラー サーバーでもコミットされ、データの安全性が保証されます。これを実現するために、プリンシパル サーバーでは、ミラー サーバーからトランザクションのログを固定したという確認応答を受信した後にのみ各トランザクションをコミットします。トランザクションの安全性レベルを FULL に設定すると、パフォーマンス上の影響があります。

メモ : SQL Server 2005 Standard Edition では、トランザクションの安全性レベルは FULL にのみ設定できます。SQL Server 2005 のさまざまなエディションでサポートされるデータベース ミラーリング機能については、ホワイト ペーパー「SQL Server 2005 データベース ミラーリング」を参照してください。

表 2a は、安全性 OFF、安全性 FULL、およびミラーリングなしの場合の作業負荷 1 のパフォーマンスを比較したものです。

パフォーマンス特性	ミラーリングなし	安全性 OFF	安全性 FULL
CPU 使用率 (%)	4.0	6.0	6.4
データ ディスクへの書き込み速度 (KB/秒)	4,500	4,500	4,500
ログ ディスクへの書き込み速度 (KB/秒)	720	720	709
トランザクション数/秒	241	241	238
トランザクションの応答時間 (秒)	0.13	0.13	0.19

表 2a: 安全性 OFF および安全性 FULL の場合の作業負荷 1 ( プリンシパル上 ) のパフォーマンス特性

表 2a に示されているように、作業負荷 1 の場合、安全性を OFF にしても、トランザクションのスループットおよび応答時間には影響はありません。トランザクションの安全性レベルを FULL に設定すると、安全性 OFF の場合と比較して、トランザクションのスループットが若干減少し、応答時間が若干増加します。表 2b はミラー サーバーのパフォーマンス特性を示したものです。

パフォーマンス特性	ミラーリングなし	安全性 OFF	安全性 FULL
CPU 使用率 (%)	該当なし	3.9	4.0
データ ディスクへの書き込み速度 (KB/秒)	該当なし	19,640	19,300
ログ ディスクへの書き込み速度 (KB/秒)	該当なし	720	709

表 2b: 安全性 OFF および安全性 FULL の場合の作業負荷 1 ( ミラー上 ) のパフォーマンス特性

表 2a と 表 2b のディスクへの書き込み速度を比較すると、ミラーがプリンシパルと同じ量の書き込みをログ ディスクに対して行っていることがわかります。一方で、ミラーのデータ ディスクへの書き込みはプリンシパルよりも多くなっています。これは、プリンシパル上のデータ ページはチェックポイントでのみディスクに書き込まれますが、ミラー上のページはディスクに連続して書き込まれるからです。ミラー上のデータ ページは頻繁に書き込みキューに配置され、フェールオーバー時に多くのデータをフラッシュする必要がありません。フェールーオーバー時に発生するイベントについては、このホワイト ペーパーの「フェールオーバーに関する考慮事項」を参照してください。

トランザクションの安全性レベルのパフォーマンスに対する影響はアプリケーションによって異なります。作業負荷 2 の場合、アクティブなデータベースへの同時接続は 20 のみですが、ログの生成速度は作業負荷 1 の場合よりも速いので、表 3a に示すように、パフォーマンスへの影響はより大きくなります。

パフォーマンス特性	ミラーリングなし	安全性 OFF	安全性 FULL
CPU 使用率 (%)	39.6	47.4	37.7
データ ディスクへの書き込み速度 (KB/秒)	1,500	1,175	1217
ログ ディスクへの書き込み速度 (KB/秒)	12,000	11,850	8720
トランザクション数/秒	215	211	158
トランザクションの応答時間 (秒)	6.4	6.7	8.8

表 3a: 安全性 OFF および安全性 FULL の場合の作業負荷 2 ( プリンシパル上 ) のパフォーマンス特性

作業負荷 2 の場合、安全性を OFF にすると、ミラーリングなしのシナリオに比べて、トランザクションのスループットが 2% 減少し、応答時間が 0.3 秒長くなります。一方、安全性を FULL にすると、トランザクションのスループットは 25% 減少し、応答時間は 2.4 秒長くなります。表 3b はミラー サーバーのパフォーマンス特性を示したものです。

パフォーマンス特性	ミラーリングなし	安全性 OFF	安全性 FULL
CPU 使用率 (%)	該当なし	13.6	10.841
データ ディスクへの書き込み速度 (KB/秒)	該当なし	37143	30036
ログ ディスクへの書き込み速度 (KB/秒)	該当なし	11856	8727

表 3b: 安全性 OFF および安全性 FULL の場合の作業負荷 2 ( ミラー上 ) のパフォーマンス特性

表 2a と表 3a から、トランザクションの安全性レベルのパフォーマンスに対する影響は、アプリケーションに大きく依存することがわかります。同時接続数の多いアプリケーションでは、同時接続数の少ないアプリケーションに比べて、安全性 OFF の場合と安全性 FULL 場合とでスループットの差は小さくなります。これは、安全性 FULL モードで接続数が多い場合、他の接続がミラーからの確認応答を待っている間、いくつかの接続が処理を継続できる可能性があるからです。これには、接続プールを使用して SQL Server や SAP などの ISV アプリケーションに接続する Web ファームが該当します。接続数が少ない場合、いくつかの接続がミラーからの確認応答待ちになると、トランザクション全体のスループットに対する影響が比例的に大きくなります。

同様に、安全性 FULL の場合、短時間のトランザクションでは、長時間のトランザクションよりも応答時間に対する営業が大きくなります。これは、トランザクションがミラーからの確認応答を待っている場合、待ち時間は短時間のトランザクションの応答時間に対して比例的に大きくなるからです。

長時間のログを多用するトランザクションの影響

長時間のログを多用するトランザクションは、パフォーマンスおよびフェールオーバー時間に影響を与える場合があります。長時間のログを多用するトランザクションの一般的な例として、大規模なテーブルに対するインデックスの作成や再構築、および大量のデータの一括読み込みなどがあります。

例 1: インデックスの作成

図 1 は、さまざまなミラーリングの安全性レベルについて、クラスタ化インデックスと非クラスタ化インデックスのインデックス作成時間を示したものです。大規模なテーブルのインデックスの作成では、安全性 OFF の場合よりも、安全性 FULL の場合の方が時間がかかります。同期ミラーリングのパフォーマンスに対する影響は、非クラスタ化インデックスを作成する場合よりも、クラスタ化インデックスを作成する場合の方が顕著になります。これは、クラスタ化インデックスを作成するときには、非クラスタ化インデックスを作成するときよりも多くのトランザクション ログが生成されるからです。

図 1: さまざまな安全性レベルでのインデックス作成時間

例 2: インデックスの再構築

インデックスの再構築にかかる時間は、安全性を OFF にしたときよりも、安全性を FULL にしたときの方が長くなります。同期ミラーリングでは、非クラスタ化インデックスを再構築する場合よりも、クラスタ化インデックスを再構築する場合の方がオーバーヘッドが大きくなります。図 2 は、さまざまな安全性レベルについて、クラスタ化インデックスと非クラスタ化インデックスのインデックス再構築の時間を示したものです。図 2 では、さまざまな安全性レベルについて、オンラインおよびオフラインでインデックスを再構築する際のパフォーマンスも比較しています。オンラインでインデックスを再構築するときには、テーブルおよびインデックスをクエリやデータ修正で使用できますが、オフラインでインデックスを再構築するときには、テーブルのロックが取得され、テーブルに対して他の操作は許可されません。

図 2: さまざまな安全性レベルでのインデックス再構築の時間

インデックスの作成や再構築など、時間のかかるトランザクションでは、安全性を OFF にした方が安全性を FULL にした場合よりもパフォーマンスがよくなるように見えます。ただし、安全性を OFF にすると、プリンシパルの送信キューおよびミラーの再実行キューのサイズが増大する可能性があります。図 3 は、図 2 で示したクラスタ化インデックスをオンラインで再構築するシナリオで、時間経過に伴う送信キューと再実行キューのサイズの変化を示しています。

図 3: 安全性 OFF でクラスタ化インデックスをオンラインで再構築する場合の送信キューと再実行キュー

図 3 に示されているように、送信キューと再実行キューは、インデックスの再構築処理の間、絶えず増大しています。再構築が完了した後、ミラーが同期するために長い時間がかかります。実際に同期にかかる時間は、プリンシパルとミラーの I/O およびネットワークのパフォーマンスによって異なります。前に示した例では、インデックスの再構築が完了した後、送信キューが 0 になるまでに 3 分 40 秒かかっています。再実行キューが 0 になるにはさらに長い時間がかかります。

例 3: 一括挿入

テーブルに対して 9,300 万行の一括挿入を実行しました。さまざまなバッチ サイズとさまざまな安全性レベルを使用しました。一括挿入では、データを挿入する際にコミットする頻度を制御できます。バッチ サイズは各コミットの前に挿入する行数です。バッチ サイズによって各トランザクションのサイズが決まります。このテストで使用したバッチ サイズは、100、1,000、および 100 万です。このテストでは、単一のデータ ファイルから単一のテーブルへのデータの読み込みを行いました。並列ストリームは使用していません。図 4 は、ミラーリングなし、安全性 OFF、安全性 FULL の各設定で、前述のバッチ サイズで一括挿入を行った場合のパフォーマンスを示しています。

図 4: さまざまなバッチサイズおよび安全性レベルでの一括挿入のパフォーマンス

図 4 に示されているように、バッチ サイズが小さいほど、読み込みが完了するまでの時間が長くなります。さらに興味深い結果として、バッチ サイズが 100 の場合、安全性レベルを FULL にすることによるパフォーマンスの低下が、バッチ サイズが大きい場合に比べて顕著になっています。バッチ サイズが小さい場合、トランザクション サイズは小さくなり、あるデータ量に対するトランザクションの総数は多くなります。各トランザクションで、ミラーからの確認応答を待つためのオーバーヘッドが発生します。したがって、コミットの頻度が高いほど、読み込みを完了するまでの累積的なオーバーヘッドは大きくなります。

作業負荷 2、一括挿入、インデックス作成、およびインデックス再構築などの、ログに関連する作業負荷 (大量のログ トラフィックを生成する作業負荷) について注意するべき点は、データベース ミラーリング環境下のパフォーマンスが、ネットワークのパフォーマンスとログの I/O のパフォーマンスに大きく依存するということです。ネットワーク パフォーマンスとログの I/O パフォーマンスのいずれかがボトルネックである場合、データベース ミラーリングの作業負荷に対するパフォーマンスは、安全性を FULL に設定すると大幅に低下する可能性があります。ネットワーク パフォーマンスとログの I/O パフォーマンスのいずれかがボトルネックである場合、安全性を OFF にした操作では、データ損失の可能性が高くなることがあります。

フェールオーバーに関する考慮事項

トランザクションの安全性レベルとミラーリング監視があるかどうかによって、自動フェールオーバー、手動フェールオーバー、またはその両方を実行できます。表 4 に、さまざまな安全性レベルでのフェールオーバー オプションを示します。

トランザクションの安全性レベル	ミラーリング監視	動作モード	サポートされるフェールオーバー モード
FULL	あり	高安全性、自動フェールオーバー (同期)	自動または手動
FULL	なし	高安全性 (同期)	手動
OFF	該当なし	高パフォーマンス (非同期)	強制されたサービス (データ損失の可能性あり)

表 4: 安全性レベルとフェールオーバーのオプション

障害が発生し、自動フェールオーバーが実行されるときには、次の順序で複数のイベントが発生します。

1. 障害の発生: プリンシパル データベースが使用不可能になります。この原因として、プリンシパル サーバーのハードウェア、記憶域、ネットワーク、または電源の障害などがあります。

2. 障害の検出: ミラーおよびミラーリング監視によって障害が検出されます。ハード障害 (サーバーの電源障害など) は迅速に (通常、約 1 秒で) 検出されます。ソフト障害 (記憶域の障害など) は検出により時間がかかります。プリンシパル、ミラー、およびミラーリング監視の間での通信 (Ping メッセージ) において、既定のタイムアウトは 10 秒です。このタイムアウトは、ALTER DATABASE SET PARTNER TIMEOUT コマンドを使用して変更できます。プリンシパルがタイムアウト時間内に Ping メッセージに応答しなくなった場合、プリンシパルは停止していると見なされます。このタイムアウトの設定を変更する場合、ベスト プラクティスでは 10 秒以上に設定することが推奨されています。10 秒未満に設定すると、負荷が大きいあるいは散発的なネットワークの状況下で、誤って障害と検出される可能性があります。

3. ミラーでの再実行の完了: ミラー データベースはこれまで復元状態であったので、再実行は継続的にミラー データベースに適用されます。プリンシパルの障害の発生時点でミラーの再実行キューに残っていたログは、ミラー データベースに適用され、完全に回復されます。

4. フェールオーバーの決定: ミラーはミラーリング監視と調整して、データベースをミラーにフェールオーバーするかどうかを決定します。この決定処理には通常、約 1 秒かかります。手順 3. の再実行フェーズが完了する前にプリンシパルが回復した場合、フェールオーバーは必要ありません。

5. ミラーからプリンシパルへの切り替え: 残りのすべての再実行が適用された後、ミラー データベースはオンラインになり、プリンシパルの役割を引き継ぎます。データベースが使用可能になり、クライアントは新しいプリンシパルに接続して操作を続行できます。

6. 元に戻す: トランザクション ログ内のコミットされていないトランザクションがロールバックされます。

図 5 に、自動フェールオーバーの際に発生するイベントを示します。

図 5: 自動フェールオーバー時のイベント

拡大表示する

サーバーの観点からすると、データベースのフェールオーバー時間は、プリンシパルの障害が検出されてから、ミラーがプリンシパルの役割を引き継ぐまでの時間です。データベースのフェールオーバー時間の主な構成要素に再実行フェーズがあります。このフェーズで、ミラーの再実行キュー内のログがミラー データベースに適用されます。ミラーが既にプリンシパルに追いついている場合は、再実行フェーズによる時間のずれは発生しません。再実行レコードを適用するための時間は、ミラーの再実行キューの長さと再実行速度によって異なります。これらはそれぞれ、システム モニタの Redo Queue KB カウンタと Redo Bytes/sec カウンタで測定されます。再実行キューの値を特定の時点の再実行速度で除算することによって、ミラーの再実行キュー内のログを適用するのにかかる時間を概算できます。SQL Server Books Online では、再実行の適用およびフェールオーバー時間の予測を詳細に説明しています。

実際のフェールオーバー時間を測定する方法の 1 つとして、プリンシパルおよびミラーで SQL Server Profiler を使用する方法があります。SQL Server Profiler で、トレースを作成し、Database Mirroring State Change イベントを選択して監視することができます。—StartTime と TextData の 2 つの列を見てください。StartTime はイベントの発生時刻を示すタイムスタンプです。TextData はデータベース ミラーリングの状態変更イベントの説明です。ミラー サーバーの状態がプリンシパルに変化すると、SQL Server Profiler はトレースにメッセージを出力します。表 5 は、サンプルのフェールオーバー シナリオでの StartTime と Textdata です。

StartTime	TextData
2005-10-22 12:39:17.960	DBM: Synchronized Mirror with Witness -> DBM: Connection with Principal Lost
2005-10-22 12:39:18.570	DBM: Connection with Principal Lost -> DBM: Automatic Failover
2005-10-22 12:39:20.590	DBM: Automatic Failover -> DBM: Principal Running Exposed

表 5: トレースのイベントのタイムスタンプと説明

フェールオーバー時間の長さは、障害の種類およびデータベースに対する負荷によって異なります。さまざまな種類の障害、および負荷なしと通常の負荷の条件下でのフェールオーバーについて、フェールオーバー時間が測定されました。負荷をかけた状態でフェールオーバー時間を測定するために、作業負荷 1 を 1 時間実行しました。次に、障害のシナリオを作成しました。サンプルのフェールオーバー時間を表 6 に示します。

障害/フェールオーバーの種類	負荷なしの場合のフェールオーバー時間 (秒)	通常の負荷の場合のフェールオーバー時間 (秒)
ALTER DATABASE FAILOVER (手動フェールオーバー)	20.5	32.2
SHUTDOWN WITH NOWAIT	5.7	8.5
プリンシパルでの SQL Server サービスの停止	3.2	10.8
プリンシパル サーバーのシャットダウン	10.2	15.8
プリンシパル サーバーの電源オフ	2.2	2.6
ミラーおよびミラーリング監視に接続しているプリンシパルのネットワーク ケーブルの取り外し	1.9	3.1

表 6: 作業負荷 1 のフェールオーバー時間 ( ミラーリング監視ありの同期ミラーリング )

表 6 に示されているように、同じ障害の種類では、フェールオーバーを完了するのにかかる時間は、負荷なしのシナリオに比べて、負荷がある場合の方が長くなります。これは、障害が検出された場合、ミラーがプリンシパルの役割を引き継ぎ、データベースを使用できるようにするには、再実行キュー内のトランザクションを適用する必要があるからです。

手動でのフェールオーバーは、自動フェールオーバーよりも時間がかかります。手動フェールオーバー時に、ミラー (フェールオーバーが完了した後、最終的にはプリンシパルになる) の ERRORLOG に次のようなメッセージが記録されます。

Starting up database '<db_name>'.Analysis of database '<db_name>' (<dbid>) is 100% complete (approximately 0 seconds remain).  Recovery of database '<db_name>' (<dbid>) is 100% complete (approximately 0 seconds remain).Phase 3 of 3.

このような分析や回復での追加の手順によって、手動フェールオーバーは所要時間が長くなります。

以下のセクションでは、さまざまな障害のシナリオとその結果について説明します。

プリンシパルの停止

プリンシパルに障害が発生した場合、フェールオーバーのシナリオは、トランザクションの安全性レベルと、ミラーリング監視を使用しているかどうかによって異なります。

シナリオ 1: 安全性 FULL、ミラーリング監視あり

このシナリオでは、自動フェールオーバーによる高い安全性が実現されます。プリンシパルに障害が発生すると、ミラーはミラーリング監視と共にクォーラムをを形成します。自動フェールオーバーが実行されるので、データベースのダウンタイムは最小化されます。

たとえば、障害が発生するまで、Server_A と Server_B がそれぞれプリンシパルとミラーとして機能しているとします。Server_A に障害が発生します。自動フェールオーバーが実行された後、Server_B がプリンシパルの役割を引き継ぎます。ただし、フェールオーバー後はミラーがないので、ミラーリングの状態は DISCONNECTED になり、プリンシパルは公開されています。Server_A 上のデータベースが機能するようになると、自動的にミラーの役割を引き継ぎます。

シナリオ 2: 安全性 FULL、ミラーリング監視なし

このシナリオでは、高安全性が実現されますが、自動フェールオーバーは許可されません。プリンシパルに障害が発生すると、データベース サービスが使用不可能になります。手動でデータベース サービスを使用可能にする必要があります。ミラーリング セッションを終了し、ミラー データベースを回復しなければなりません。

たとえば、障害が発生するまで、Server_A と Server_B がそれぞれプリンシパルとミラーとして機能しているとします。Server_A に障害が発生します。データベース サービスを使用可能にするには、Server_B で次のコマンドを実行する必要があります。

ALTER DATABASE <database name> SET PARTNER OFF 
RESTORE DATABASE <database name> WITH RECOVERY

Server_A が使用可能になったら、再びミラーリング セッションを確立する必要があります。

シナリオ 3: 安全性 OFF

安全性レベルが OFF の場合、ミラーリング監視はデータベース ミラーリングのシナリオに付加価値を提供しません。したがって、安全性レベルが OFF の場合にデータベース ミラーリングを実行する予定がある場合は、ミラーリング監視を構成しないことをお勧めします。プリンシパルに障害が発生すると、データベース サービスが使用不可能になります。強制サービスを実行して、ミラーリング上でデータベース サービスを使用可能にすることができます。ただし、安全性レベルが OFF であるため、プリンシパルに障害が発生した時点で、ミラーに反映されていないトランザクションが存在していた可能性があります。このようなトランザクションは失われます。したがって、安全性が OFF の場合に手動でフェールオーバーを実行する場合、データ損失の可能性があることに注意する必要があります。

たとえば、障害が発生するまで、Server_A と Server_B がそれぞれプリンシパルとミラーとして機能しているとします。Server_A に障害が発生します。データベース サービスを使用可能にするには、Server_B で次のコマンドを実行する必要があります。

ALTER DATABASE <database_name> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

Server_A 上のデータベースが機能するようになると、自動的にミラーの役割を引き継ぎます。ただし、ミラーリング セッションは SUSPENDED のままになっているので、手動でミラーリング セッションを再開 (RESUME) する必要があります。

プリンシパルで障害が発生した場合のもう 1 つの選択肢として、「シナリオ 2: 安全性 FULL、ミラーリング監視なし」のように、ミラーリング セッションを終了し、ミラーリング データベースを回復する方法もあります。ミラーリング セッションの終了と強制サービスのどちらを選択するかに関係なく、障害発生の時点でミラーに反映されていないトランザクションは失われます。

ミラーの停止

ミラーに障害が発生した場合、プリンシパルは機能し続けますが、ミラーリングの状態は DISCONNECTED になり、プリンシパルは公開された状態で実行されます。ミラー データベースが機能するようになると、自動的にミラーの役割を引き継いで、プリンシパルとの同期を開始します。ミラーリングの状態は DISCONNECTED である間は、トランザクション ログをバックアップしている場合でも、プリンシパルのトランザクション ログ領域は再利用できません。ログ ファイルが増大し、最大サイズの制限に達するか、ディスクに空き領域がなくなると、データベース全体が停止します。これを防止するために 2 つの選択肢があります。増大するトランザクション ログに十分なディスク領域を計画して領域がいっぱいになる前にミラー データベースを復旧するか、データベース ミラーリング セッションを終了します。

ミラーリング監視の停止

ミラーリング監視サーバーに障害が発生した場合、データベース ミラーリングは中断することなく機能し続けますが、自動フェールオーバーは実行できなくなります。ミラーリング監視が機能するようになると、自動的にデータベース ミラーリング セッションに参加します。

ミラーとミラーリング監視の停止

ミラーリング監視付きのデータベース ミラーリングを構成しているとします。ミラーが使用できなくなると、プリンシパルは公開された状態で実行されます。ミラーリングが使用できない間に、ミラーリング監視も停止した場合は、プリンシパルは孤立し、クライアントにサービスを提供できなくなります。プリンシパル データベースは実行されていますが、クライアントが利用することはできません。このデータベースに接続しようとすると、"データベース <dbname> のデータベース ミラーリングは有効になっていますが、パートナーとミラーリング監視サーバーのインスタンスはどちらも使用できません。データベースを開けません。" というメッセージが表示されます。

ミラーまたはミラーリング監視を即座にオンラインに戻すことができない場合、データベース サービスを再開するには、データベース ミラーリング セッションを終了するしかありません。そのためには、プリンシパル サーバーのマスタ データベースに接続した後、次のコマンドを実行します。

ALTER DATABASE <db_name> SET PARTNER OFF

SET WITNESS OFF ではなく、SET PARTNER OFF コマンドを実行する必要があることに注意してください。この場合、SET WITNESS OFF は機能しません。

ミラーが利用できるようになったら、再びデータベース ミラーリング セッションを確立することができます。プリンシパルはミラーへのログ情報の送信を開始し、ミラーは最終的に追いつきます。データベース ミラーリング セッションを終了した後でトランザクション ログをバックアップした場合は、データベース ミラーリング セッションを再確立する前に、ミラー上でトランザクション ログのバックアップを復元する必要があります。データベースのフル バックアップ/復元を実行する必要はありません。ミラーリング監視が利用できるようになったら、ミラーリング監視も追加することができますが、ミラーリング監視が参加する前に、ミラーとの間でミラーリング セッションを確立する必要があります。

計画的なダウンタイム中のデータベースの可用性

安全性を FULL に設定してデータベース ミラーリングを構成している場合、プリンシパルでハードウェアやソフトウェアのメンテナンスを行う間、ミラー サーバーに切り替えてクライアントが利用できるようにすることができます。この "ローリング アップグレード" の手法を使用し、次の手順に従って、プリンシパルおよびミラー サーバーでハードウェアやソフトウェアを変更することができます。

1. 最初にミラー サーバーでハードウェアやソフトウェアを変更します。ミラーで SQL Server サービスを再起動したり、ミラー サーバーを再起動したりする必要がある場合は、必要な操作を実行できます。ミラー データベースが再び稼動し始めると、ミラーリング セッションが自動的に再確立され、ミラーがプリンシパルとの同期を開始します。ミラー データベースが停止している間、または稼動しているがまだ完全にはプリンシパルと同期していない間、プリンシパルは公開されています。

2. ミラーリングの状態が SYNCHRONIZED になったら、(ALTER DATABASE FAILOVER コマンドを実行して) プリンシパルとミラーを切り替えます。アプリケーションは新しいプリンシパル データベースに接続して、サービスを続行できます。プリンシパルとミラーを切り替える際に、未処理または処理中のトランザクションはロールバックされます。アプリケーションの種類に応じて、手動のフェールオーバーを実行する間アプリケーションを停止し、フェールオーバーが正常に完了した後で再起動することをお勧めします。この場合、アプリケーションが新しいプリンシパル データベース サーバーを指すように指定する必要があります。ここで、古いプリンシパル サーバーでハードウェアおよびソフトウェアを変更できます。変更が終了してデータベースが利用できるようになるとすぐに、ミラーリング セッションが自動的に再確立され、ミラーの役割が引き継がれます。

3. ミラーリング監視サーバーがある場合は、そのサーバーで必要な変更を実行できます。

4. ここで 2 つの選択肢があります。プリンシパルとミラーをそのままにするか、ミラーリングの状態が SYNCHRONIZED になった後で (ALTER DATABASE FAILOVER コマンドを実行して) プリンシパルとミラーを入れ替えます。ミラーとプリンシパルの処理能力が同じである場合は、データベースをそのままにすることをお勧めします。プリンシパルとミラーを切り替えると、アプリケーションでもう一度再接続が発生する可能性があるからです。

安全性を OFF にしてデータベース ミラーリングを構成している場合は、安全性を FULL に切り替えた後で、ローリング アップグレードの手法を使用することができます。オフピーク時に、安全性レベルを FULL にし、ミラーがプリンシパルに追いついて、同期されるまで待ちます。これで、計画的なダウンタイム中に、データを失うことなく、手動でフェールオーバーを実行できます。負荷のピーク時に安全性を OFF から FULL に切り替えると、ミラーがプリンシパルに追いついて同期されるまでに非常に時間がかかる場合があります。ミラーが同期されるまで、手動でのフェールオーバーを実行できません。

メモ : ローリング アップグレードの手法は、ほとんどのハードウェアおよびソフトウェアのアップグレードで使用できます。ただし、例外もあります。ベスト プラクティスでは、運用環境でローリング アップグレードを実行する前に、テスト環境でテストすることを推奨しています。

ミラーリング セッションの中断と再開

ミラーリング セッションを中断し、後で再開することができます。データベース ミラーリング セッションを中断するには、次のコマンドを実行します。

ALTER DATABASE <db_name> SET PARTNER SUSPEND

データベース ミラーリング セッションを再開するには、次のコマンドを実行します。

ALTER DATABASE <db_name> SET PARTNER RESUME

セッションが中断されている間は、ログ レコードはプリンシパルで蓄積され続けます。セッションを中断している間は、(トランザクション ログをバックアップしている場合でも) プリンシパルのトランザクション ログを切り詰めることはできません。ミラーリング セッションを長時間中断したままにすると、ログ領域がいっぱいになり、データベースが停止する可能性があります。したがって、ミラーリング セッションを数分以上中断状態にする場合は、ログの生成速度に応じて、増大するトランザクション ログ用に十分な領域を確保する必要があります。

プリンシパルのトランザクション ログは、ミラー データベースが長時間利用できない場合にも増大し続ける可能性があります。ミラー データベースが利用できない場合、データベース ミラーリング セッションは DISCONNECTED のままになり、DISCONNECTED 期間中は (トランザクション ログをバックアップしている場合でも) プリンシパルの トランザクション ログを切り詰めることはできません。

ある実験で、ミラーリング セッションを長時間中断しました。この間に、何度か一括読み込みを実行しました。これによって、トランザクション ログがいっぱいになりました。トランザクション ログは自動的に拡張され、最終的にはディスク ボリュームがいっぱいになりました。増大するトランザクション ログ用の領域がなくなったので、データベースは停止しました。大量のデータ読み込みを実行した場合、トランザクション ログ用の 40 GB のディスク領域が 2 時間あまりでいっぱいになりました。

データベース ミラーリングの状態が SUSPENDED または DISCONNECTED であるために、トランザクション ログ領域の切り詰めや再利用が禁止されている場合、そのデータベースについて、sys.databases カタログ ビューの LOG_REUSE_WAIT_DESC 列の値は DATABASE_MIRRORING になります。この場合、2 つの選択肢があります。1 つは、増大するトランザクション ログ用に十分な領域を構成する方法です。ただし、ミラーリング セッションを再開 (RESUME) するか、ミラー データベースをすぐに稼動させない限り、遅かれ早かれ領域の上限に達します。または、次のコマンドを実行してデータベース ミラーリング セッションを終了することもできます。

ALTER DATABASE <db_name> SET PARTNER OFF

セキュリティに関する考慮事項

データベース ミラーリングでは、あるコンピュータから別のコンピュータに、ネットワーク経由で情報を転送します。したがって、情報転送のセキュリティは非常に重要です。既定の場合、データベース ミラーリングでは暗号化された形式で情報が転送されます。信頼されていないネットワーク ドメイン間でデータベース ミラーリングを構成する場合は、接続を認証するために証明書が必要です。

エンドポイントの暗号化

データベース ミラーリングの接続管理はエンドポイントに基づいています。エンドポイントは SQL Server がネットワーク経由で通信できるようにする SQL Server のオブジェクトです。データベース ミラーリングの場合、サーバー インスタンスは、他のサーバー インスタンスからのデータベース ミラーリング接続を受け付けるために専用のデータベース ミラーリング エンドポイントを必要とします。データベース ミラーリング接続に使用されるエンドポイントは、他の用途には使用できません。さらに、各 SQL Server インスタンスで持つことができるデータベース ミラーリング エンドポイントは 1 つだけです。そのインスタンス内でデータベース ミラーリングに関連するすべてのデータベースは、同じエンドポイントを使用する必要があります。

データベース ミラーリング エンドポイントは、データベース ミラーリング セッションで、伝送制御プロトコル (TCP) を使用してサーバー インスタンス間でメッセージを送受信します。サーバー インスタンスのデータベース ミラーリング エンドポイントは、インスタンスがデータベース ミラーリング メッセージをリッスンするポートに関連付けられます。各データベース ミラーリング エンドポイントは、一意の TCP ポート番号でリッスンします。

既定の場合、データベース ミラーリング エンドポイントでは、ミラーリング接続で送信されるデータを暗号化する必要があります。この場合、エンドポイントは、同じく暗号化を使用しているエンドポイントにのみ接続できます。ネットワークがセキュリティで保護されていることを保証できる場合を除き、データベース ミラーリング接続では暗号化を要求することをお勧めします。ただし、セキュリティで保護されていることが保証されたネットワークの場合は、暗号化をオフにすることによって、パフォーマンスが若干向上します。

データベース ミラーリング エンドポイントは、RC4 と AES の 2 つの暗号化アルゴリズムをサポートしています。既定値は RC4 です。図 6 は、作業負荷 1 のトランザクションのスループットに対するエンドポイントの暗号化 (RC4 アルゴリズム) の影響を示しています。

図 6: RC4 アルゴリズムでエンドポイントを暗号化した場合のトランザクションのスループット

図 7 は、作業負荷 1 の応答時間に対するエンドポイントの暗号化 (RC4 アルゴリズム) の影響を示しています。

図 7: RC4 アルゴリズムでエンドポイントを暗号化した場合のトランザクションの応答時間

図 6 および 図 7 の数値は、パフォーマンスに対する影響がわずかであることを示しています。したがって、常に暗号化を使用してデータベース ミラーリング エンドポイントを構成することをお勧めします。

CREATE ENDPOINT ステートメントを使用してデータベース ミラーリング エンドポイントを作成する場合、エンドポイントは既定で暗号化を使用して作成されます。ミラーリングを確立した後、エンドポイントの暗号化を変更する場合は、いくつかの点に注意する必要があります。CREATE または ALTER ENDPOINT ステートメントでは、ENCRYPTION 引数として REQUIRED、SUPPORTED、DISABLED の 3 つの値のいずれかを使用できます (既定値は REQUIRED)。データベース ミラーリングが機能するには、プリンシパル、ミラー、およびミラーリング監視 (存在する場合) のエンドポイントが、すべて互換性を持っている必要があります。ENCRYPTION=REQUIRED に設定されたエンドポイントは、ENCRYPTION=DISABLED に設定されたエンドポイントとは通信できません。また逆の場合も同じです。あるエンドポイントの暗号化を DISABLED から REQUIRED に (またはその逆に) 変更すると、ミラーリング セッションが終了します。したがって、データベース ミラーリング エンドポイントの暗号化の設定を DISABLED から REQUIRED に変更するには、2 つの手順で実行する必要があります。最初に、ミラーリング セッションに関連するすべてのエンドポイント (プリンシパル、ミラー、および存在する場合はミラーリング監視) について、暗号化を DISABLED から SUPPORTED に変更します。次に、すべてのエンドポイントの暗号化を SUPPORTED から REQUIRED に変更します。中間の SUPPORTED の状態によって、エンドポイントは暗号化が REQUIRED または DISABLED であるエンドポイントと通信できます。

証明書

ワシントン州レドモンドとノースカロライナ州シャーロットにある 2 台のデータベース サーバー間でデータベース ミラーリングのテストを実施しました。2 台のデータベース サーバーは信頼されていない異なるドメインに属しています。信頼されていないドメイン間でデータベース ミラーリングを確立するには、接続要求を認証するために証明書が必要です。証明書はパフォーマンスには影響せず、データベース ミラーリング接続を認証するための安全な方法を提供します。各サーバー (プリンシパル、ミラー、およびミラーリング監視) で、ローカルで作成された証明書を使用してエンドポイントが構成されます。次に、証明書が他のサーバーにコピーされます。

異なるドメインのサーバー間で証明書およびデータベースのバックアップをコピーする場合、常にセキュリティで保護されたコピー方法 (winscp など) を使用してください。

証明書の作成方法および証明書を使用したデータベース ミラーリングの構成方法については、SQL Server Books Online を参照してください。

ネットワーク構成のベスト プラクティス

ネットワーク構成は、データベース ミラーリングによって実現されるパフォーマンスと安全性において重要な役割を果たします。ローカル エリア ネットワーク、シミュレートされたワイド エリア ネットワーク、およびメトロポリタン エリア ネットワークにおいて、データベース ミラーリングの広範囲にわたるテストを実施し、プリンシパル データベースのスループットに対するネットワークの待ち時間 (ラウンドトリップ時間) およびネットワークの帯域幅の影響を調べました。表 7 は、ローカル、メトロポリタン、およびワイド エリア ネットワークでの標準的なラウンド トリップ時間 (RTT) を示しています。

ネットワークの種類	ミリ秒 (ms) 単位の標準的なラウンド トリップ時間 (RTT)
ローカル エリア ネットワーク	0 ～ 2
メトロポリタン エリア ネットワーク	2 ～ 20
ワイド エリア ネットワーク	20 ～ 200

表 7: ネットワークの種類と関連するネットワークの待ち時間

ローカル エリア ネットワークでのデータベース ミラーリング

ローカル エリア ネットワークでは、データベース ミラーリングによって、計画的なダウンタイムだけでなく、計画外のダウンタイムも最小限に抑えることができます。ミラーリング監視を使用した同期的なデータベース ミラーリングは、ローカル エリア ネットワークでは重要なオプションです。通常、ネットワークの待ち時間が短く、高可用性の利点を提供して、計画外のダウンタイムを削減できるからです。

このホワイト ペーパーの「計画的なダウンタイム中のデータベースの可用性」で説明したように、データベース ミラーリングを使用して、ハードウェアのアップグレード、ソフトウェアのアップグレード、記憶域の変更、およびデータベース構成の変更による計画的なダウンタイムを最小限に抑えることもできます。

信頼性の高い LAN において、パフォーマンスよりも可用性が重要視される場合は、ミラーリング監視を使用した同期的なミラーリングをお勧めします。ただし、パフォーマンスが最も重要である場合は、非同期的なミラーリングの方が適しています。アプリケーションのパフォーマンスと可用性の要件、およびアプリケーションに対する同期ミラーリングのパフォーマンス上の影響に基づいて、このデザインのトレードオフを決定する必要があります。

メトロポリタン エリア ネットワークまたはワイド エリア ネットワークでのデータベース ミラーリング

メトロポリタン エリア ネットワークやワイド エリア ネットワークでは、データベース ミラーリングは通常、障害回復ソリューションとして使用されます。標準的なメトロポリタン エリア ネットワークではラウンド トリップ時間 (RTT) は 2 ～ 20 ミリ秒 (ms) です。一方、ワイド エリア ネットワークでは、RTT は 200 ms になる場合もあります。MAN または WAN 環境でデータベース ミラーリングを設定して、パフォーマンスを最大化またはデータ損失を最小化する方法を提供できます。

図 8 は、作業負荷 1 の同期ミラーリングのシナリオでネットワークの待ち時間が増加した場合の、トランザクションのスループットと応答時間の変化を示してします。

図 8: 作業負荷 1 でネットワークの RTT が増加した場合の同期ミラーリングのパフォーマンス

図 8 に示されているように、20 ms 未満では、RTT 値に対するトランザクションのスループットおよび応答時間の変化はごくわずかです。RTT 値が 20 ms を超えると、パフォーマンスが低下し始めます。

図 9 は、作業負荷 2 の同期ミラーリングのシナリオでネットワークの待ち時間が変化した場合の、トランザクションのスループットと応答時間の変化を示してします。

図 9: 作業負荷 2 でネットワークの RTT が増加した場合の同期ミラーリングのパフォーマンス

図 9 に示されているように、RTT が増加するにつれて、トランザクションのスループットおよび CPU 使用率 (%) は徐々に低下します。プリンシパル サーバーとミラー サーバーとの間のネットワークの待ち時間が 2 ms 以上になる場合は、アプリケーションのパフォーマンスの目標に関して、テストから得られたパフォーマンスを評価します。次に、特定の環境で、同期ミラーリングが適切な選択肢であるかどうかを判断します。

図 10 は、作業負荷 1 の非同期ミラーリングのシナリオでネットワークの待ち時間が増加した場合の、トランザクションのスループットと応答時間の変化を示してします。

図 10: 作業負荷 1 でネットワークの RTT が増加した場合の非同期ミラーリングのパフォーマンス

図 10 に示されているように、100 ms までは RTT 値に対するトランザクションのスループットは同じですが、RTT 値が 100 ms を超えると徐々にスループットが低下します。この作業負荷の場合、応答時間は同じスループットのままです。ただし、ネットワークの待ち時間が長くなると、作業負荷が大きいときにログ送信キューが大幅に増大する可能性があります。これにより、フェールオーバー時間が長くなり、フェールオーバー時のトランザクションの損失が増加します。作業負荷 1 で非同期ミラーリングを行う場合、RTT 値が 50 ms 以下のときにはログ送信キューは小さいままです。

ただし、RTT 値が 100 ms 以上になると、キューが急速に増大します。図 11 は、非同期ミラーリングのシナリオで、作業負荷 1、RTT = 100 ms の場合のログ送信キューを示しています。

図 11: RTT = 100ms のネットワークで作業負荷 1 の非同期ミラーリングを行う場合のログ送信キュー

図 11 に示されているように、RTT が 100 ms のネットワークで、作業負荷 1 の非同期ミラーリングを行う場合、ログ送信キューは急速に増大します。したがって、待ち時間の長いネットワークで非同期ミラーリングを展開する場合は、ログ送信キューと共にパフォーマンスを検証する必要があります。

図 12 は、作業負荷 2 の非同期ミラーリングのシナリオでネットワークの待ち時間が変化した場合の、トランザクションのスループットと応答時間の変化を示してします。

図 12: 作業負荷 2 でネットワークの RTT が変化した場合の非同期ミラーリングのパフォーマンス

図 12 に示されているように、ネットワークの待ち時間が増加しても、トランザクションのスループットは影響を受けません。ただし、この作業負荷の場合、作業負荷 1 とは異なり、RTT 値が 2 ms 程度の低い値でもログ送信キューが急速に増大します。

低帯域幅のネットワークでのデータベース ミラーリング

データベース ミラーリングに関連するサーバー間は専用のネットワークで接続するのが理想的です。サーバーが他のサーバーと同じネットワークを共有している場合は、ミラーリング接続で利用できる実効帯域幅がパフォーマンスに影響します。データベース ミラーリングは広帯域幅のネットワークで構成することを強くお勧めします。必要なネットワークの帯域幅は、アプリケーションのログ生成速度によって決まります。低帯域幅のネットワークでは、データベース ミラーリングのパフォーマンスに悪影響を及ぼす場合があります。

図 13 は、作業負荷 1 の同期ミラーリングでネットワーク帯域幅を変更した場合の、トランザクションのスループットと応答時間の変化を示しています。

図 13: 作業負荷 1 の同期ミラーリングに対するネットワーク帯域幅の影響

図 13 に示されているように、帯域幅が 10 Mbps (メガビット/秒) 以上のネットワークでは、適切なトランザクションのスループットと応答時間が維持されます。ネットワークの帯域幅が 10 Mbps 未満になると、スループットと応答時間は大幅に低下します。56 Kbps (キロビット/秒) のネットワークは非常に遅いので、同期ミラーリングについてはパフォーマンスを測定しませんでした。ただし、非同期ミラーリングについてはパフォーマンスを測定しました。

図 13 で重要な点は、このアプリケーションは 720 KB/秒の速度でトランザクション ログを生成しており (表 1 を参照)、これが約 5.6 Mbps になるということです。この量のトランザクション ログを、ネットワーク経由でミラー サーバーに転送する必要があります。したがって、ネットワークの帯域幅は、アプリケーションのログ生成速度を大幅に上回っている必要があります。このようになっていない場合、ネットワークのパフォーマンスが、同期ミラーリングのパフォーマンスの主なボトルネックになります。このことは、図 13 で帯域幅が 1 Mbps になると、トランザクションのスループットと応答時間が急激に低下することにも示されています。

図 14 は、作業負荷 1 の非同期ミラーリングでネットワーク帯域幅を変更した場合の、トランザクションのスループットと応答時間の変化を示しています。

図 14: 作業負荷 1 の非同期ミラーリングに対するネットワーク帯域幅の影響

図 14 に示されているように、トランザクションのスループットは、高帯域幅のネットワークでも、低帯域幅のネットワークでも同じです。応答時間は、帯域幅が 100 Mbps 未満のネットワークでごくわずかに増加しています。したがって、非同期ミラーリングは低帯域幅のネットワークでも実行できます。ただし、低帯域幅のネットワークでの非同期ミラーリングでは、トランザクションの負荷が大きくなったときに、ログ送信キューが著しく増大する可能性があることに注意が必要です。プリンシパル データベースに障害が発生した場合に、これによｔって大量のデータが失われる可能性があります。

図 15 は、非同期ミラーリングのシナリオで、ネットワーク帯域幅が 1 Mbps、作業負荷 1 の場合のログ送信キューを示しています。

図 15: 帯域幅が 1 Mbps のネットワークで作業負荷 1 の非同期ミラーリングを行う場合のログ送信キュー

図 15 に示されているように、帯域幅 が 1 Mbps のネットワークで、作業負荷 1 の非同期ミラーリングを行う場合、ログ送信キューは無限に増大します。したがって、低帯域幅のネットワークで非同期ミラーリングを展開する場合は、パフォーマンスとログ送信キューの両方を検証する必要があります。

特定の時点の送信キューは、その時点でプリンシパルに障害が発生した場合に失われるデータの量を表します。非同期ミラーリングでは、許容されるデータ損失の量によって、最適なネットワークの待ち時間および帯域幅の要件が決定されます。

ミラーのフェールオーバーの準備

フェールオーバーを行う場合は、ミラー データベースによってプリンシパル データベースのすべての作業負荷を引き継ぐ必要があります。したがって、プリンシパルとミラー パートナーで同じサーバー (CPU、メモリ、記憶域、およびネットワーク速度) を使用することは理にかなっています。ベスト プラクティスの推奨事項は次のとおりです。

• 同じ条件 (CPU、メモリ、記憶域、ネットワーク速度) のパートナー サーバーを使用します。

• 両方のパートナーで同じレベルのオペレーティング システムおよび SQL Server のサービス パックおよび更新プログラムを使用します。ローリング アップグレードを実行する場合、プリンシパルとミラーでサービス パックおよび更新プログラムのレベルが一時的に異なる可能性があります。ただし、安定状態の動作では、同じレベルを使用する必要があります。

• 両方のパートナーで SQL Server の同じエディションを使用します。

• 両方のパートナーで、SQL Server のインストール ファイルおよびデータベース ファイルについて同じディレクトリ構造を使用します。

• プリンシパル インスタンスとミラー インスタンスで同じ SQL Server の構成 (トレース フラグ、起動オプション、メモリ設定など) を使用します。

プリンシパル サーバーとミラー サーバーで、CPU、メモリ、記憶域、およびネットワーク速度が同じではない場合、フェールオーバーの際にパフォーマンスが低下する可能性があります。両方のパートナーで、SQL Server の同じエディション、SQL Server とオペレーティング システムの同じバージョンおよび同じレベルのサービス パックを使用することによって、SQL Server またはオペレーティング システムの問題が発生するリスクを最小限に抑えることができます。両方のサーバーでディレクトリ構造と SQL Server の構成を同じにすることによって、ミラー パートナーへのフェールオーバー時またはフェールオーバー後に設定を変更する必要がなくなります。

データベース ミラーリングの最小の単位は単一のデータベースです。SQL Server のインスタンス内の各データベースは個別にミラーリングされます。インスタンス全体はミラーリングされません。インスタンス全体の (データベース レベルではない) フェールオーバー機能が必要な場合は、フェールオーバー クラスタリングを検討してください。フェールオーバー クラスタリングの詳細については、SQL Server 2005 Books Online を参照してください。また、ミラーリングできるのはユーザー データベースのみです。master、msdb、tempdb、または model データベースをミラーリングすることはできません。したがって、フェールオーバー時には、いくつかの管理タスクを実行して、ミラー サーバーでプリンシパルの役割を引き継ぐための準備をする必要があります。ミラー サーバーで以下の点を検討します。

• アプリケーションが接続して必要なすべての操作を実行できること、およびプリンシパル サーバー上でアクティブなすべての SQL Server ログイン (およびそのアクセス許可) がミラー サーバーにも存在していることを確認します。SQL Server 2005 Integration Services のログイン転送タスクを使用してこの作業を実行できます。ログイン転送タスクの詳細については、SQL Server 2005 Books Online を参照してください。

• SQL エージェント ジョブ、警告、SSIS パッケージ、サポート データベース、リンク サーバーの定義、バックアップ デバイス、メンテナンス プラン、データベース メール プロファイルなどを、プリンシパル サーバーからミラー サーバーにコピーします。ミラー サーバーでは、通常ジョブは無効になっています。フェールオーバー時には、ジョブを有効にしてください。

• プリンシパル パートナーにディスク ボリュームを追加し、ミラーリングの対象となるデータベースのデータまたはログ ファイルを配置する予定がある場合は、ミラー サーバーにも同じドライブ文字を使用してディスク ボリュームを追加します。プリンシパルの新しいドライブにデータ ファイルを追加すると、データベース ミラーリングはミラーにも同じファイルを追加しようとします。ミラー サーバーに新しいドライブが存在しない場合、この操作は失敗します。

• プリンシパルに対して変更 (ハードウェア、ソフトウェア、SQL Server の設定、データベース サポート オブジェクトに対する変更など) を行った場合に、ミラー サーバーでも変更を繰り返すか、または転送するプロセスを準備します。

• サーバーのフェールオーバーをテストし、すべてのオブジェクト、ログイン、アクセス許可などがミラー上でも、プリンシパル上と同じように機能することを確認します。

プリンシパルとミラーの初回の同期

データベース ミラーリング セッションを確立する前に、ミラー サーバーでデータベースを復元し、復元中の状態にしておく必要があります。そのための最も一般的な方法は、プリンシパルでデータベースのオンライン バックアップを作成し、そのバックアップをミラー サーバーにコピーし、以降のトランザクション ログを適用するオプションを使用してミラー サーバーでバックアップを復元します。

データベースのサイズと 2 台のサーバー間の距離によっては、バックアップをコピーして、ミラー サーバーで復元するのに長い時間がかかる場合があります。この間に、プリンシパル データベースで複数のトランザクション ログのバックアップが生成される場合があります。プリンシパルで多数のトランザクション ログのバックアップが生成される場合は、すべてのトランザクション ログのバックアップをコピーして、ミラーに適用する方法が必要になります。ミラーで多くのトランザクション ログのバックアップをコピーして適用する手間を省略したい場合は、ミラー サーバーでデータベースが復元され、データベース ミラーリング セッションが確立されるまで、プリンシパルでトランザクション ログのバックアップを中断することができます。データベース ミラーリング セッションが確立された後、プリンシパルでトランザクション ログのバックアップを再開します。この方法で 1 つ注意しなければならない点は、トランザクション ログのバックアップを中断している間に、ログ ファイルが増大している可能性があることです。ログ ファイルの増大に対応するのに十分なディスク領域を計画する必要があります。

複数のデータベースのミラーリング

インスタンス内に複数のデータベースがある場合は、各データベースを個別にミラーリングする必要があります。各データベースに別のミラー サーバーを選択することもできますが、ベスト プラクティスとして、1 つのアプリケーションに属するすべてのデータベースについて 1 台のミラー サーバーを選択することをお勧めします。インスタンス内のデータベースが異なるアプリケーションに属する場合は、それぞれのデータベース用に異なるミラー サーバーを選択できますが、この場合、構成が複雑になります。

複数のデータベースが関係する場合は、1 つ考慮しなければならない点があります。1 つのデータベースに障害が発生し、他のデータベースには障害が発生していない場合はどうなるのでしょうか。たとえば、2 つのユーザー データベース DB1 と DB2 について、Server_A がプリンシパル サーバーで、Server_B がミラー サーバーであるとします。データベース DB1 についてフェールオーバーが発生し、データベース DB2 についてはフェールオーバーが発生していない場合、Server_B は DB1 のプリンシパルになり、Server_A は DB2 のプリンシパルになります。データベース DB1 と DB2 が 2 つの異なるアプリケーションに属している場合は、1 つのアプリケーションは Server_A に接続し続け、もう 1 つのアプリケーションは Server_B に再接続します。

しかし、DB1 と DB2 の両方が 1 つのアプリケーションに属している場合、アプリケーションはどちらのサーバーに接続するでしょうか。どちらのデータベースも利用できますが、アプリケーションのサービスは利用できなくなったり、正しく機能しなくなったりする可能性があります。

このような状況は、1 つのデータベースを手動でフェールオーバーし、もう 1 つのデータベースをフェールオーバーしない場合に発生する可能性があります。このシナリオは、自動フェールオーバーを使用している場合は発生しにくくなります。SQL Server サービス、サーバー、またはネットワークの障害が発生した場合、両方のデータベースがほぼ同時にフェールオーバーします。しかし、1 つのデータベースでディスク障害が発生した場合はどうなるでしょうか。この場合は、該当するデータベースのみがフェールオーバーします。または、ネットワークで散発的な問題が発生したか、1 つのデータベースのミラーリング セッションがタイムアウトになったときに、他のデータベースでは問題が発生していない場合、1 つのデータベースはフェールオーバーし、他のデータベースはフェールオーバーしない可能性があります。したがって、アプリケーションが複数のデータベースで構成されている場合は、1 つのデータベースがフェールオーバーし、他のデータベースがフェールオーバーしていないことを検出して警告するメカニズムを作成します。このような状況では、他のデータベースを手動でフェールオーバーする必要があります。

ミラーリング情報の表示

SQL Server 2005 には、ミラーリング情報を表示するために、カタログ ビューと動的管理ビュー (DMV) が用意されています。また、データベース ミラーリングのパフォーマンス情報を表示する、システム モニタのカウンタも用意されています。

ミラーリングの状態、安全性レベル、およびミラーリング監視

sys.database_mirroring カタログ ビューは、SQL Server インスタンスでミラーリングされる各データベースについて、データベース ミラーリング情報を提供します。データベース名を取得するには、このビューを sys.databases に結合します。次のクエリは、最後に使用されたミラーリングのメタデータを表示します。

SELECT d.name, d.database_id, m.mirroring_role_desc, 
       m.mirroring_state_desc, m.mirroring_safety_level_desc,  
       m.mirroring_partner_name, m.mirroring_partner_instance, 
       m.mirroring_witness_name, m.mirroring_witness_state_desc 
FROM   sys.database_mirroring m JOIN sys.databases d 
ON     m.database_id = d.database_id 
WHERE  mirroring_state_desc IS NOT NULL

このクエリはいずれのパートナー (プリンシパルまたはミラー) でも実行することができ、同じ出力が得られます。

sys.database_mirroring_witnesses カタログ ビューは、ミラーリング監視に関する情報を提供します。ミラーリング監視サーバーで次のクエリを実行することによって、このサーバーがミラーリング監視を行っているすべてのミラーリング セッションについて、対応するプリンシパル サーバー名とミラー サーバー名、データベース名、および安全性レベルを表示できます。

SELECT principal_server_name, mirror_server_name,  
       database_name, safety_level_desc 
FROM   sys.database_mirroring_witnesses

エンドポイント

カタログ ビュー sys.database_mirroring_endpoints にクエリを実行すると、エンドポイントの状態や暗号化の設定など、エンドポイントに関する有用な情報が表示されます。

エンドポイントで使用されているポート番号は、sys.database_mirroring_endpoints ではなく、sys.tcp_endpoints に表示されます。sys.database_mirroring_endpoints と sys.tcp_endpoints を結合して、エンドポイントに関する重要なメタデータ情報を取得できます。

SELECT e.name, e.protocol_desc, e.type_desc, e.role_desc, e.state_desc,  
       t.port, e.is_encryption_enabled, e.encryption_algorithm_desc,  
       e.connection_auth_desc  
FROM   sys.database_mirroring_endpoints e JOIN sys.tcp_endpoints t 
ON     e.endpoint_id = t.endpoint_id

データベース ミラーリングのパフォーマンスの監視

データベース ミラーリングのパフォーマンスを監視するために、SQL Server は各パートナー (プリンシパルおよびミラー) についてシステム モニタのパフォーマンス オブジェクト (SQLServer:Database Mirroring) を提供します。Databases パフォーマンス オブジェクトも、スループット情報 (Transactions/sec カウンタ) などの重要な情報を提供します。監視する必要がある重要なカウンタは次のとおりです。

プリンシパルの場合:

• Log Bytes Sent/sec: 1 秒あたりにミラーに送信されるログのバイト数。

• Log Send Queue KB: ミラー サーバーにまだ送信されていないログの合計キロバイト数。

• Transaction Delay: ミラーからのコミット確認応答を待つ場合の遅延 (ミリ秒単位)。このカウンタは、ある時点で処理中のすべてのトランザクションの遅延の合計をレポートします。トランザクションあたりの平均遅延を求めるには、このカウンタの値を Transactions/sec カウンタの値で除算します。非同期ミラーリングを実行している場合は、このカウンタは常に 0 です。

• Transactions/sec: データベースのトランザクションのスループット。このカウンタは Databases パフォーマンス オブジェクトにあります。

• Log Bytes Flushed/sec: ログ レコードがディスクに書き込まれる速度。これは、アプリケーションのログ生成速度です。このカウンタは、データベース ミラーリング パフォーマンスを判断する際に非常に重要な役割を果たします。このカウンタは Databases パフォーマンス オブジェクトにあります。

• Disk Write Bytes/sec: ディスクの書き込み速度。このカウンタは Logical Disk パフォーマンス オブジェクトにあります。データ ディスクおよびログ ディスクについてこのカウンタを監視してください。

ミラーの場合:

• Redo Bytes/sec: 1 秒あたりにミラー データベースに適用されるトランザクション ログのバイト数。

• Redo Queue KB: ミラー データベースに適用してロールフォワードする必要がある固定されたログの合計キロバイト数。

• Disk Write Bytes/sec: ディスクの書き込み速度。このカウンタは Logical Disk パフォーマンス オブジェクトにあります。ミラー上のデータ ディスクおよびログ ディスクについてこのカウンタを監視してください。

トラブルシューティング

データベース ミラーリングが機能しない場合は、以下の項目を調べて、構成が正しいことを確認してください。

• エンドポイントがすべて開始されているかどうか。カタログ ビュー sys.database_mirroring_endpoints の STATE_DESC 列を確認します。エンドポイントを作成したときの既定の状態は STOPPED です。作成時に明示的に STARTED と指定することによってエンドポイントを開始することができます。または、ALTER ENDPOINT コマンドを使用して、エンドポイントを開始することもできます。

• プリンシパル、ミラー、およびミラーリング監視 (存在する場合) のエンドポイントで、暗号化の設定に互換性があるかどうか。プリンシパル、ミラー、およびミラーリング監視のエンドポイントについて、カタログ ビュー sys.database_mirroring_endpoints の IS_ENCRYPTION_ENABLED 列を確認します。この列の値は 0 または 1 です。値が 0 の場合、そのエンドポイントの暗号化は DISABLED です。値が 1 の場合、暗号化は REQUIRED または SUPPORTED です。データベース ミラーリング エンドポイントの暗号化の設定を変更する方法については、このホワイト ペーパーの「エンドポイントの暗号化」を参照してください。

• エンドポイントのポート番号が、SET PARTNER ステートメントで指定した対応するポート番号と同じであるかどうか。エンドポイントで使用されるポート番号は、カタログ ビュー sys.tcp_endpoints の PORT 列に表示されます。データベース ミラーリング セッションを確立するときに SET PARTNER ステートメントで指定したポート番号は、カタログ ビュー sys.database_mirroring の MIRRORING_PARTNER_NAME 列に表示されます。MIRRORING_PARTNER_NAME のポート番号が、対応するエンドポイントのポート番号と一致していることを確認します。

• エンドポイントの種類と役割が正しいかどうか。エンドポイントの種類と役割は、カタログ ビュー sys.database_mirroring_endpoints の TYPE_DESC 列と ROLE_DESC 列にそれぞれ表示されます。種類が DATABASE_MIRRORING であることを確認します。役割は、エンドポイントがプリンシパルまたはミラーとして使用されるサーバーに属している場合は、PARTNER である必要があります。エンドポイントがミラーリング監視として使用されるサーバーに属している場合は、WITNESS である必要があります。

• SQL Server インスタンスが実行されているユーザー アカウントに、必要な CONNECT アクセス許可があるかどうか。ミラーリング セッションに関連するすべてのサーバー (プリンシパル、ミラー、ミラーリング監視) で同じドメイン ユーザーの下で SQL Server が実行されている場合は、アクセス許可を付与する必要はありません。これらのサーバーの 1 つまたは複数で、SQL Server が別のユーザーの下で実行されている場合は、他のサーバーのログイン アカウントに、サーバーのエンドポイントへの CONNECT アクセス許可を付与する必要があります。

• データベース ミラーリング セッションに関連するすべての SQL Server インスタンスで、TCP/IP によるリモート接続が有効になっているかどうか。

• パートナーとミラーリング監視との間にファイアウォールがある場合は、ファイアウォールで、データベース ミラーリング エンドポイント用に使用するポートが開いていることを確認します。

まとめ

データベース ミラーリングのパフォーマンスは、アプリケーションの種類、トランザクションの安全性レベル、およびネットワークのパフォーマンスと密接な関係があります。ログ生成速度、同時接続数、およびトランザクションのサイズなどのアプリケーションの動作を理解することは、最適なパフォーマンスを実現するために重要です。ネットワークはデータベース ミラーリング環境において非常に重要な役割を果たしています。帯域幅が広く、待ち時間が少ないネットワークで使用した場合、データベース ミラーリングは、計画的なダウンタイムや計画外のダウンタイムに対して、信頼性の高い高可用性のソリューションを提供できます。地理的に離れているデータ センター間では、データベース ミラーリングによって障害回復ソリューションの基盤を実現できます。

付録 A テスト環境

データベース サーバー

2 台の NEC Express5800/1080Xe サーバー (日本市場でのモデル名は NEC NX7700i / 3020M-8)。それぞれ以下のハードウェアを搭載しています。

• 8 プロセッサ構成の Intel Itanium2 1.5GHz / 6 MB キャッシュ

• 8 GB の RAM

• 1 Gbps ネットワーク インターフェイス カード

記憶域

各データベース サーバーに装備された記憶域は次のとおりです。

• 2 つのディスク エンクロージャを持つ NEC Storage S2300。

• 各ディスク エンクロージャには 12 の物理ディスク。

• 各ディスクは 36 GB @15000 rpm。

• 各ディスク エンクロージャは、RAID 1+0 で 12 のディスクを持つ 1 つの LUN として構成。

• 1 つの LUN はデータ ファイル用、もう 1 つの LUN はログ ファイル用 (データとログを物理的に分離するため)。

• 各ディスク アレイに 1 つの QLogic QLA2340 PCI Fiber Channel Adapter を接続。

ソフトウェア

• オペレーティング システム: Microsoft Windows 2003 Server  64 ビット版、Service Pack 1 適用済み

• SQL Server: SQL Server 2005 Enterprise Edition、IA64 プラットフォーム版、RC1 (Build 1355)

• ネットワークの待ち時間および帯域幅をシミュレートするための Windows 用ネットワーク エミュレータ

ダウンロード

データベース ミラーリングのベスト プラクティスおよびパフォーマンスに関する考慮事項
376 KB
Microsoft Word ファイル