Oracle Real Application Clusters 11g
Microsoft SQL Server 2008
との技術比較
オラクル・コンペティティブ・ホワイト・ペーパー
Oracle Real Application Clusters 11g
Microsoft SQL Server 2008
との技術比較
はじめに ... 3
Oracle Real Application Clusters アーキテクチャ ... 4
Microsoft SQL Server 2008 のフェデレーテッド・データベース ... 5
Microsoft SQL Server 2008 のフェデレーテッド・データベースのレイア
ウト... 5
Microsoft SQL Server 2008 のフェデレーテッド・データベースの概要 7
Oracle Real Application Clusters が優れている理由 ... 8
Microsoft SQL SERVER 2008 のフェイルオーバー・ クラスタリング ... 10
Microsoft SQL Server 2008 のフェイルオーバー・クラスタ・データベー
スのレイアウト... 10
Microsoft SQL Server 2008 のフェイルオーバー・クラスタ・データベー
スの概要... 11
Oracle Real Application Clusters が優れている理由 ... 12
Microsoft SQL SERVER 2008 のデータベース・ミラーリング... 13
Microsoft SQL Server 2008 のデータベース・ミラーリングのレイアウト13
Microsoft SQL Server 2008 のデータベース・ミラーリングの概要... 14
Oracle Real Application Clusters が優れている理由 ... 14
Microsoft SQL Server 2008 のピア・ツー・ピア・レプリケーション 15
Microsoft SQL Server 2008 のピア・ツー・ピア・レプリケーションの概
要... 15
Oracle Real Application Clusters が優れている理由 ... 15
まとめ ... 16
Oracle Real Application Clusters 11g
Microsoft SQL Server 2005
との技術比較
はじめに
クラスタ・データベース市場では競合する宣伝文句が飛び交っており、各ベンダー は自社アーキテクチャの利点を盛んに宣伝しています。顧客は、急速に進化する 大量のベンチマークの結果や、相反するアナリストの批評記事、一様に肯定的な 顧客の事例広告を取捨選択して、ミッション・クリティカルなソフトウェア・プ ラットフォームを選択する必要があります。 このホワイト・ペーパーでは、Microsoft SQL Server 2008 のアーキテクチャとなる Microsoft の次の 4 つのデータベース・テクノロジーを技術的に評価します。 • フェデレーテッド・データベース• フェイルオーバー・クラスタリング（Microsoft Cluster Server で管理） • データベース・ミラーリング
• ピア・ツー・ピア・レプリケーション
各テクノロジーをオラクルのクラスタ・アーキテクチャである Oracle Real Application Clusters（Oracle RAC）またはオラクルの各テクノロジーと比較します。 Oracle RAC と関連テクノロジーは、オラクルの Maximum Availability Architecture （MAA）を形成し、データベースの障害保護を強化します。上記アーキテクチャ はすべて、Microsoft SQL Server の旧バージョンにも存在します。そのため、 Microsoft SQL Server 2008 の機能のほとんどは単なる改良版となっており、フェデ レーテッド・データベース・サーバーについては、旧バージョンと比較して著し い改良点は見られません。 このホワイト・ペーパーで取り上げるすべての Microsoft ソリューションを、Oracle Database 11g Release 1 および Oracle Real Application Clusters 11g と順を追って比較 します。
Oracle Real Application Clusters アーキテクチャ
ここで重要なことは、Microsoft SQL Server 2008 が提供する機能には、高可用性と スケーラビリティを併せもつ Oracle Real Application Clusters に匹敵する機能がな いということです。
図 1：Oracle Real Application Clusters アーキテクチャ
Oracle RAC アーキテクチャは、Unix、Windows、Linux サーバー領域では独自のも のです。上記の例では、5 つのノードのすべてが、1 つのデータベースにあるデータ に対するクライアントのリクエストを処理できます。Oracle RAC の差別化要因の 1 つは、ノードの障害にシームレスに対処できるアーキテクチャ固有の機能です。 上記の状況でノードに障害が発生すると、障害が発生したノードに接続されたセッ ションは存続するノードに移行され、接続が分散されて、残りの 4 つのノードで使 用可能なリソースが有効活用されます。クラスタ内のほかのノードはリクエストの 処理を継続し、存続するノードに接続されたセッションは切断されません。 クラスタ内のノードを全く同じ構成にする必要がないことも注目に値します。例 として、複合ワークロード環境があります。複合ワークロード環境では、データ ベースが OLTP と意思決定支援とのユーザー間で共有されます。データベース・ インスタンスを最適に構成して、接続ユーザーのリクエストを処理できます。 また、Oracle RAC を使用すると、クラスタ内のすべてのマシンを同時に使用して、 パフォーマンスをさらに向上できます。たとえば、この環境では、クラスタ内で 使用可能なすべての CPU を使用してデータ・ウェアハウスへの問合せを自動的に パラレル処理し、意思決定支援アプリケーションのパフォーマンスを向上できま す。高度なロードバランシング・アルゴリズムとアドバイザを使用すれば、ユー ザー・セッションをクラスタ内の'最小負荷'のノードにルーティングできます。 Oracle Automatic Storage Management（Oracle ASM）と Oracle Clusterware が Oracle Real Application Clusters アーキテクチャを補完することにより、グリッド・インフ ラストラクチャにストレージ管理とクラスタ・ソフトウェア・ソリューションを 提供します。
Microsoft SQL Server のフェデレー テッド・データベースでは、一定レベ ルのスケーラビリティが提供されま すが、可用性は低下します。
Microsoft SQL Server 2008 のフェデレーテッド・データベース
Microsoft SQL Server のフェデレーテッド・データベースは、独立したサーバーの 集合であり、リソースを共有せずに LAN で接続されます。また、フェデレーテッ ド・データベースの実装は複雑です。 Microsoft SQL Server データベースに ノードを追加すると、可用性の低下が 見込まれます。これは、Microsoft SQL Server データベースが、使用可能なす べてのノードに依存してリクエスト を処理しているためです。 フェデレーテッド・データベース・モデルは、Microsoft SQL Server 2005 ですでに 使用可能です。この領域については、本書でとくに記すべき新機能はありません。 そのため、次の図には、6 ノードのフェデレーテッド・データベースの従来構成 を示します。 この図では、6 つの独立した Microsoft SQL Server データベースがあり、それぞれ が別個のバックアップとリカバリを必要とします。クライアント・アプリケーショ ンからのリクエストを満たすには、これらのデータベースすべてがオンラインで ある必要があります。 図 2：Microsoft のフェデレーテッド・データベース・アーキテクチャ このアーキテクチャをサポートするパッケージ・アプリケーションはごくわずか です。Microsoft SQL Server 2008 のフェデレーテッド・データベースの
レイアウト
次に、フェデレーテッド・データベースを設定するプロセスについて簡単に説明 します。 データは、クラスタに参加している各サーバーに分散されます。DBA とアプリ ケーション開発者の両方にとって、特定のサーバーに接続されたディスク上の" ローカル"データと、フェデレーテッド・データベースのほかのサーバーが所有す る"リモート"データは明確に異なります。 アプリケーションは、UNION ALL ビューと分散 SQL を使用して、データの論理 的な単一のビューを参照します。Microsoft はこのテクノロジーを、分散パーティ ション・ビュー（DPV）と呼びます。DPV は、各ノードで異なる方法により構成 され、ローカルのパーティションとリモートのパーティションを明示的に考慮す る必要があります。 次の図は、Microsoft SQL Server の複数のサーバーにまたがる'顧客'表のパーティ ション化方法を示しています。アプリケーションで、各表に対して次の作業をおこないます。 • まず、各ノードで独立した表を作成します。 このコード例は、http://msdn.microsoft.com/en-us/library/ms188299.aspxに掲載されて います。 • 次に、接続性情報を作成します。 各参加サーバーに、リンクされたサーバー定義と問合せ最適化オプションが必要 です。 • 最後に、各ノードで DPV を作成します。ビューは各ノードで異なること に注意してください。 このコード例は、http://msdn.microsoft.com/en-us/library/ms188299.aspxに掲載され ています。 ベンチマーク これまで、Microsoft は、DPV を使用して TPC-C ベンチマークを測定していまし た。TPC-C スキーマは、実環境のアプリケーションとは異なり、9 つの表のみで 構成され、このうち 7 つが Warehouse_ID を主キーの一部としています。各表に DPV を提供して関連する索引を作成するのは単純な作業です。ただし、こうし た単純な OLTP スキーマと実環境のアプリケーションを比較した場合、そうし た印象は異なってきます。 表 主キー索引 代替キー索引 Peoplesoft 7,493 6,438 900 Oracle E-Business（ERP）* 8,155 800 5,100 SAP 16,500 16,329 2,887
* Oracle E-Business Suite は、Microsoft SQL Server をサポートしていません。ここ では、企業規模のアプリケーションのサポートに使用するスキーマのサイズの尺 度として使用しています。
表に挙げたアプリケーションでは、すばやいデータ・アクセスとデータの整合性 を確保するため、非主キー列にグローバル一意索引が必要です。
グローバルな一意索引の例として、Oracle E-Business Suite の RA_Customers 表の Customer_Number への一意索引があります。この索引では、一意のビジネス・キー の各値に対して顧客が 1 件しか存在しないようにします。ビジネス・キーは、表 の主キーではありません。この索引がない場合、ミッション・クリティカルなア プリケーション・データに破損、複製、または紛失が生じるおそれがあります。 また、アプリケーションでは通常、データ・アクセスをきれいにパーティション 化できません。一般的に、"ローカル"データに頻繁にアクセスするアプリケーショ ン表のパーティション・キーを見つけることは不可能です。ローカル・アクセス では、単一パーティションのデータの内容のみを使用して、問合せ要件を満たす ことができます。
SAP、PeopleSoft、Oracle E-Business Suite では、ほとんどの重要な問合せが複数の 表を結合し、問合せごとに異なる代替キーを結合条件に使用します。非ローカル・ データへのアクセスでは、分散トランザクションが頻繁に発生するため、許容で きないパフォーマンス・オーバーヘッドを招きます。 適切なパーティション・キーが見つかったとしても、何千ものアプリケーション 表のパーティション化が必要です。そのため、PeopleSoft や SAP をフェデレーテッ ド・データベースに移植するには、Microsoft SQL Server の構成で何千もの DPV （パーティション化された各表に 1 つ）を作成し、管理することが必要ですが、こ れはきわめて困難な作業です。 また、DPV では、代替キーでのグローバルな一意索引をサポートできないため、 重要なビジネス情報の整合性が甚だしく侵害されます。したがって、非常に単純 な OLTP アプリケーションしかフェデレーテッド・データベースに移植して実行 することはできません。
Microsoft SQL Server 2008 のフェデレーテッド・データベースの概要
'実環境'のアプリケーションへのフェデレーテッド・データベースのアプローチが 失敗する理由は、次のように数多くあります。 ホット・ノード DBA は、'ホット'ノードが生じないように注意してデータをパーティション化す る必要があります。データベースの割合に基づいて単純にパーティション化する ことはできません。問合せの分散が実行されず、ホット・ノードが生じる場合が あるためです。このホット・ノードがボトルネックとなり、スループットが制限 されます。 さらに、最初に完全なパーティション化がおこなわれて負荷が全ノードに分散さ れても、時間の経過とともに、データの追加や変更により問合せプロファイルが 変更されて、最初は完全に分散されていたシステムがホット・ノードによって不 均衡なシステムになる場合があります。データの不整合性 データベース・データのパーティション化は簡単な作業ではないため、大きな表 のみがパーティション化され、小さな表は全ノード間で複製される傾向にありま す。つまり、各ノードには独自のデータベースがあるため、小さい表に対するす べての変更をクラスタ内の全ノードで複製することが必要になります。この複製 により、データの複数コピーが複数の Microsoft SQL Server データベースに格納さ れることになります。 ノードの追加 ワークロードが増加すると、Microsoft SQL Server フェデレーテッド・データベー スへの新しいノードの追加が必要となります。そのプロセスは、OS のインストー ル、Microsoft SQL Server のインストール、新しいパーティション化スキームの決 定、既存のノードからのデータのアンロード、データの再パーティション化、新 しいノード集合へのデータのロード、データベースのオンラインへの復帰、必要 に応じたアプリケーションの変更となります。 一貫性バックアップ Microsoft SQL Server DPV データベースは、実際には多数のデータベースで構成さ れており、各データベースを個別にバックアップする必要があります。さらに、 DPV データベースのリカバリが必要な場合、独立した各データベースを同時点ま でリカバリして、最終的にはすべてのデータベースをオンラインに復帰させる必 要があります。 ノード障害の処理 ノード障害時に、そのノードのデータはアプリケーションで使用できなくなりま す。実環境のアプリケーションのほとんどは、データの一部がオフラインになる ことを許容できません。 ベンチマーク Microsoft の DPV アーキテクチャは、ベンチマーク専用のものとして有名になりま した。Microsoft が TPC-C ベンチマーク用のデータを取得し、問合せがすべて事前 定義されているため、TPC-C 結果を巧みに処理することが可能です。しかし、こ のテクノロジーを使用して現在公開されている TPC（-C または-H）ベンチマーク はありません。
Oracle Real Application Clusters が優れている理由
Oracle Real Application Clusters アーキテクチャは、Microsoft SQL Server のフェデ レーテッド・データベース・アーキテクチャとは根本的に異なっています。 オラクルが提供する共有ディスク・アプローチは、上述の問題に次のように対処 します。 ホット・ノード Oracle RAC データは、ノードごとにパーティション化されません。接続は、最小 負荷のノードにルーティングされます。そのため、Oracle RAC データベースでは、 ホット・ノード問題は発生しません。
データの整合性
Oracle が必要とするデータベースのコピーは 1 つのみです。Oracle RAC アーキテ クチャを使用すれば、追加のコピーは必要ありません。'データのコピーは 1 つの みである'ということは、'データの整合性'を意味します。 ノードの追加 ワークロードに対して、Oracle RAC データベースのノード数が足りなくなる時期 が来ることが考えられます。Oracle RAC の場合、対処の手順は次のとおりです。 OS のインストール、Oracle RAC のインストール、新規インスタンスのオンライ ン化の手順を実行します。これでインスタンスは自動的にデータベース・リスナー に登録され、アプリケーション・スキーマやアプリケーション自体を変更するこ となく、アプリケーションですぐに新しいノードを使用できます。 一貫性バックアップ Oracle RAC データベースは、ノード数に関係なく単一データベースのイメージで す。そのため、単一のバックアップとリストアで、データベースの一貫したバッ クアップおよびリカバリができます。 ノード障害の処理 データの一部を管理するのは 1 つのノードだけではありません。そのため、Oracle RAC クラスタで 1 つのノードが使用不可能になっても、データにアクセスできな くなることはありません。数秒で Oracle RAC のフェイルオーバーがおこなわれ、 障害が発生したノードへの接続は、残存するノードに自動的に再接続されます。 アプリケーション層には、'高速接続フェイルオーバー'によりノードの停止がタイ ムリーに通知され、障害が発生したノードに関連する接続プール内の接続を無効 にできます。 ベンチマーク オラクルは、定期的に多様なプラットフォームで Oracle RAC クラスタ・データ ベースのベンチマークをおこなっています。オラクルの場合、このベンチマーク で各ノードへのデータの分割は不要です。 http://www.oracle.com/corporate/press/2007_nov/tpcc-hp-ow.html (Linux) http://www.oracle.com/solutions/performance_scalability/11g-windows.html.
Microsoft SQL SERVER 2008 のフェイルオーバー・
クラスタリング
Microsoft SQL Server のフェイルオー バー・クラスタ・データベースは、"スタ ンドアロン"データベースに比べてやや 高レベルの可用性を提供しますが、ス ケーラビリティは提供しません。Microsoft Cluster Server（MSCS）は、Microsoft SQL Server で Microsoft がサポート するテクノロジーであり、スタンドアロン・ノードに比べてやや高レベルの可用 性を提供します。Microsoft はこれを'フェイルオーバー・クラスタリング'と呼んで います。図 3 は、Microsoft SQL Server データベースをフェイルオーバー・クラス タリングで管理する場合に使用する MSCS システムを簡単に示したものです。 図 3：Microsoft のフェイルオーバー・クラスタリングのアーキテクチャ ハードウェアのアーキテクチャは、Oracle RAC 環境と似ています。ノードは 2 つ あり、ネットワーク・インターコネクトで接続されています。'共有ディスク'のよ うなものもあります。しかし実際には、フェイルオーバー・クラスタ・データベー ス内のディスクは共有されず、Microsoft SQL Server データベースはノードの 1 つ で特定の時点に実行されるだけです。2 番目のノードは、最初のノードに障害が 発生した場合のバックアップとして提供されています。
Microsoft のフェイルオーバー・クラスタリングは、Microsoft SQL Server の複数の バージョンで使用可能です。Microsoft SQL Server 2008 ではこのソリューションが 拡張され、1 クラスタにつき 16 ノードをサポートしています。 さらに、'地理的に分散したフェイルオーバー・クラスタリング'をサポートしてい るため、フェイルオーバー・クラスタを 2 カ所に設定して、各サイトに 1 つまた は複数のストレージ・アレイを配置し、単一共有ディスク・システムによるリス クを回避できます。また、クラスタ検証ツールを使用して、Microsoft のフェイル オーバー・クラスタ・ソリューションの実行に適したハードウェア・リソースが あることを確認できます。
Microsoft SQL Server 2008 のフェイルオーバー・クラスタ・データ
ベースのレイアウト
このアーキテクチャでインストールされた Microsoft SQL Server データベースは、 単一の Microsoft SQL Server データベースのように機能します。このデータベース には、ハードウェアやオペレーティング・システムと同様の制限事項が課されま単一サーバーのスケーラビリティによって制限されます。データベースは一度に 特定の 1 つのノードでしか実行できないため、クラスタに 2 つを超えるノードが ある場合でも、データベースで追加ノードをすぐには使用できません。16 ノード をサポートするクラスタは 8 つのデータベースに対しては有効ですが、1 つのデー タベースの場合、とくに役立つということはありません。 データベースを構成するファイルは、中央のディスクのファイル・システムに配 置され、Microsoft SQL Server データベースを実行するノードはこのディスクを使 用できます。新しい‘地理的に分散したフェイルオーバー・クラスタリング'機能を 使用すれば、セカンダリ・ストレージにデータをコピーして、プライマリ・スト レージに障害が発生した場合の完全なデータ損失から保護できます。ただし、障 害発生後にセカンダリ・ストレージでデータを使用可能にする必要があるため、 中断が発生しないわけではありません。
Microsoft SQL Server 2008 のフェイルオーバー・クラスタ・データ
ベースの概要
このクラスタリング・テクノロジーは、スケーラビリティを向上するものではあ りません。各データベースは 1 つのノードのみで実行され、単一ノードのスケー ラビリティによって制限されます。1 クラスタにつき 16 ノードをサポートしても、 データベースは一度に 1 つのノードでしか実行できないため、可用性が向上する わけではありません。このノードに障害が発生すると、このデータベースへの接 続はすべて失われます。 フェイルオーバーによるアプリケーションのブラックアウト クラスタ内のノード数に関係なく、Microsoft SQL Server データベースをホストす るノード（例：ノード 1）に障害が発生すると、残存ノード（例：ノード 2）での Microsoft SQL Server データベースの再起動手順を実行する間、遅延が生じます。 この手順の概要は、次のとおりです。 1. ノード 1 の'停止'がノード 2 で認識されます。 2. ノード 1 が参照していたディスク（ファイル・システム）を、ソフトウェ アを使用してノード 2 で参照できるようにします。 3. ノード 1 で使用していた IP アドレスをノード 2 で作成します。 4. ノード 1 で使用していたネットワーク名をノード 2 で作成します。 5. ノード 1 で管理されているサービス（ここでは Microsoft SQL Server デー タベースと関連サービス）をノード 2 で起動します。 6. ノード 2 で Microsoft SQL Server データベースをリカバリして、データ ベースを開き、完全運用を再度開始します。 7. アプリケーションが再接続され、トランザクションが再開します。 注：上記手順は、記載された順に実行する必要があります。Microsoft SQL Server は、ディスクとネットワークが起動するまで起動できません。また、ネットワー ク名は、IP アドレスがインスタンス化されるまで作成できません。Oracle Real Application Clusters が優れている理由
概して、フェイルオーバー・クラスタ・ソリューションと Oracle Real Application Clusters との差は歴然としています。Oracle RAC では、同一データベースのイン スタンスがクラスタ内の全ノードで実行され、ワークロードをクラスタ内の全 ノードで共有できます。つまり、Oracle Real Application Clusters では、クラスタ内 の新しいノードを使用して、ワークロードを全ノードにただちに拡張できます。 Oracle RAC クラスタには MSCS（Oracle Clusterware にクラスタ・ソフトウェア・ ソリューションとして付属）が不要のため、MSCS のノード制限による制約はあ りません。Oracle RAC 10g Release 2 以降、最大 100 のノードと Oracle データベー スが認定するほとんどのオペレーティング・システムをサポートしています。 1 つのノードに障害が発生すると、クラスタ内のほかのノードが既存の接続への サービスを継続します。'実行中'のトランザクションは、クラスタ内のほかのノー ドによって自動的に即時ロールバックされます。そのため、リソースの再起動や ほかのノードでのデータベースのオープンを待つ必要がありません。データベー スは常時オープンとなり、残存ノードの残存インスタンスでアクセスできます。 Oracle RAC では、フェイルオーバーは分単位ではなく秒単位でおこなわれます。 障害が発生したノードへの接続は、残存するノードに自動的に再接続されます。 アプリケーション層には、'高速接続フェイルオーバー'によりノードの停止がタイ ムリーに通知され、接続プール内の障害が発生したノードへの接続を無効にでき ます。
Oracle Automatic Storage Management（Oracle ASM）を使用すれば、ストレージ・ サブシステム内または複数のストレージ・システム間のデータを Oracle RAC デー タベースに完全透過的にミラー化できます。Oracle ASM には、単一のミラー化（別 のディスクまたは別のストレージ・システムへのミラー化）をおこなう標準的な 冗長化と、異なる場所で 2 つのデータ・コピーを維持する高レベルの冗長化の 2 つがあります。
Oracle ASM では、データが全ノードにストライプ化され、I/O 使用率が最適化さ れます。さらに、クラスタの全ノードから、いつでも全 ASM ディスク・グループ （Oracle ASM で使用できるディスクを体系化する論理ユニット）を開いてアクセ スできます。あらゆるノードから全データにアクセスできているため、ノード障 害時に別のノードからのデータ参照を可能にする必要がありません。ストレージ 障害時には、サービスを中断させることなく、Oracle RAC データベースの完全運 用を継続できます。
Microsoft SQL SERVER 2008 のデータベース・ミラーリング
Microsoft のデータベース・ミラーリングは Microsoft SQL Server 2005 の新機能で あり、Microsoft SQL Server 2005 の初期リリースの一部として、初期バージョンに 搭載されました。Microsoft はこのステータスを変更し、SP1 アップグレードの一 部としました。 Microsoft SQL Server 2008 では、データベース・ミラーリング機能がさらに拡張さ れました。たとえば、Microsoft SQL Server 2008 バージョンでのみ、データベース を再起動することなく手動フェイルオーバーを実行できます。 Microsoft SQL Server のデータベース・ミ ラーリングは、Oracle Data Guard に相当 します。 データベース・ミラーリングは一定レベ ルの保護を提供しますが、Microsoft SQL Server データベース自体のスケーラビリ ティは向上しません。 また、ミラー化による保護がデータ・ページにも拡張されており、プライマリ・ サーバーまたはミラー・サーバーのいずれかでページの破損が検出されると、パー トナー・サーバーから該当ページが取得されるため、データベース処理をシーム レスに継続できます。新たに導入された圧縮技術を使用すれば、プライマリ・サー バーとミラー・サーバー間のデータ・フローを圧縮できるため、ネットワーク・ トラフィックを削減できます。 従来のデータベース・ミラーリング方法では、配置可能なミラー・サーバーは 1 つのみであったのに対し、Microsoft SQL Server 2008 に導入された改良版では、複 数のウォーム・スタンバイ・サイト間で定期的なログ送信を実行できます。ログ 送信は定期的に実行されるため、マスター・サーバーで発生したデータ変更がセ カンダリ・サーバーに転送される間、遅延が生じます。
Microsoft SQL Server 2008 のデータベース・ミラーリングのレイアウト
Microsoft は通常、データベース・ミラーリング・テクノロジーを高可用性ソリュー ションとして説明しています。次の図に示すように、この機能を最大限に活用す るには、3 つの Microsoft SQL Server データベースが必要です。 1 つ目は本番データベース、2 つ目はミラー・データベース、3 つ目はモニター （'ウィットネス・サーバー'）として機能するデータベースです。ウィットネス・ サーバーは定義ごとに選択可能であり、プライマリ・データベースとミラー・ データベース間の自動フェイルオーバーを可能にする唯一の方法です。ウィッ トネス・サーバーがない場合は、フェイルオーバーを常に手動で初期化する必 要があります。 図 4：Microsoft のデータベース・ミラーリング・アーキテクチャ図 4 では、Microsoft SQL Server のプライマリ・データベースとミラー・データベー スとの間でログが送信されます。ウィットネス・データベースは、システム・モ ニターとして機能します。従来のデータベース・ミラーリング・テクノロジーで サポートされるミラー・サーバーは 1 台のみです。
Microsoft SQL Server 2008 のデータベース・ミラーリングの概要
データベース・ミラーリングでは、いかなる種類のスケーラビリティも提供され ません。Microsoft SQL Server 2008 のこの機能で提供される可用性は、Oracle Data Guard のフィジカル・スタンバイ・データベースに類似しているように思われま す。ミラー・データベースは、フェイルオーバーが実行されるか、または手動で 初期化されるまで'使用不可能'となります。 ミラー化による保護のデータ・ページへの拡張、2 台のサーバー間のデータ・フ ローの圧縮、非同期の定期的なログ送信をベースにした複数のセカンダリ・サー バーのサポートといった新機能は、Oracle データベースの多数のリリースにすで に搭載されている機能といえます。Oracle Real Application Clusters が優れている理由
データベース・ミラーリングは、Oracle RACに匹敵するものではありません。こ れは、Oracle Data Guardテクノロジーに類似した機能です。Oracle RACとOracle Data Guardの組み合わせにより、比類なきレベルの可用性とスケーラビリティが実 現します。これについては、『Oracle Maximum Availability Architecture』1で説明さ れています。
1オラクルの
Maximum
Availability Architecture（MAA）に関する情報は、次のWebサイトでご覧になれます。
Microsoft SQL Server 2008 のピア・ツー・ピア・レプリケー
ション
レプリケーション機能は Microsoft SQL Server のかなり多くのリリースに搭載され ていますが、ピア・ツー・ピア・レプリケーションは Microsoft SQL Server 2005 の新機能の 1 つであり、Microsoft SQL Server 2008 でもっとも拡張された機能の 1 つです。 Microsoft によれば、ピア・ツー・ピア・レプリケーションは、独立した複数のデー タベース・サーバー間でワークロードのロードバランシングを実行できる高可用 性ソリューションです。ピア・ツー・ピア・レプリケーションの基本概念は、各 サブスクライバがパブリッシャも兼ねているため、データを両方向に移動（双方 向レプリケーション）できるというものです。 Microsoft SQL Server 2008 のピア・ツー・ピア・レプリケーションにおける新機能 は、オンラインでのノード追加機能です。旧バージョンの機能では、ノード追加 時にレプリケーション・プロセスを一定時間静止させることが必要でした。 もう 1 つの拡張機能は、'競合検出'テクノロジーです。この機能により、複数のレ プリケーション・ノードで同じ行を更新する場合の不測の競合から保護できます。 Microsoft SQL Serverの旧バージョンでは、同じ行の同時更新の検出さえ不可能で あったため、"行がほかのノードに伝播される際に競合、さらには更新の損失が発 生する" 2可能性がありました。競合検出機能では、これらの更新の損失を重大な エラーとして扱うことで回避できます。 レプリケーション・ノードの管理と監視に使用できるグラフィカルな新トポロ ジ・ビューアが、Microsoft SQL Server 2008 のピア・ツー・ピア・レプリケーショ ンを補完します。Microsoft SQL Server 2008 のピア・ツー・ピア・レプリケーションの
概要
ピア・ツー・ピア・レプリケーションはワークロードのロードバランシングに使 用できますが、スケーラビリティは提供しません。概して、Microsoft SQL Server 2008 のこの機能は、Oracle データベースの非常に多くのリリースに搭載されてい るオラクルのマルチマスター・レプリケーションや Oracle Streams のレプリケー ションに類似しているように思われます。Microsoft SQL Server 2008 の新しい競合 検出機能を考慮すれば、注目すべき点は"競合発生時に、競合が解消されてトポロ ジ間のデータ一貫性が確立されるまで、トポロジの非一貫性が維持される"という 点です。Oracle Real Application Clusters が優れている理由
ピア・ツー・ピア・レプリケーションは、Oracle RAC に匹敵するものではありま せん。これは、オラクルの多数のリリースに搭載済みの Oracle レプリケーション・ テクノロジーに類似した機能です。 2 次のOracle SQL Server 2005 文書からの引用です。 http://technet.microsoft.com/enus/library/bb934199%28SQL.100%29.aspx 3 次のOracle SQL Server 2008 文書からの引用です。 Microsoft SQL Server のピア・ツー・ピ ア・レプリケーションは、オラクルのレ プリケーション・テクノロジーに相当し ます。 ピア・ツー・ピア・レプリケーションは 一定レベルのロードバランシングを提供 しますが、Microsoft SQL Server データ ベース自体のスケーラビリティは向上し ません。
まとめ
Microsoft のフェデレーテッド・データベースでは、可用性は向上しません。事実、 ノードの追加により、実際の可用性は低下します。このソリューションのスケー ラビリティは、TPC-C スタイルのベンチマークには有効な場合がありますが、エ ンタープライズ・アプリケーションにスケーラブルなソリューションを提供する 可能性は非常に限られています。Oracle Real Application Clusters を使用すると、アプリケーションのコードやスキー マを変更することなく、高可用性とスケーラビリティをアプリケーションに提供 できます。単一ノード上の CPU 数を 2、4、8 と拡張した際にスケールするアプリ ケーションでは、ノード数を 2、4、8 と拡張してもスケールできます。 Microsoft のフェイルオーバー・クラスタリング・ソリューションは、一定レベル の可用性と'コールド・リスタート'機能を提供しますが、スケーラビリティについ ては提供しません。Microsoft SQL Server データベースは、単一ハードウェア・サー バーの制限による制約を受けます。 Oracle RAC を使用すると、複数のサーバーを組み合わせて、単一クラスタで最大 100 ノードという高いスケーラビリティと可用性を提供します。 Microsoft の比較的新しい機能である'データベース・ミラーリング'は、長年にわた り Oracle Data Guard 製品で提供してきたテクノロジーの一部を模倣したものです。 データベース・ミラーリング・ソリューションは、単独サーバーのハードウェア 制限による制約を受けます。
Oracle Data Guard と Oracle RAC は、相互補完の関係にあります。Oracle RAC は、 システムやインスタンスの障害に対応します。たとえば、ノード障害など、デー タに影響しない障害からの迅速な自動リカバリを提供します。また、アプリケー ションのスケーラビリティを強化し、コモディティ価格のサーバーを利用できる ようにします。
Oracle Data Guard は、Oracle RAC を補完し、トランザクションの一貫性のあるプ ライマリ・データベースとスタンバイ・データベースを使用してデータを保護し、 共有ディスクやロック手順での実行を不要にします。そのため、サイト障害やデー タ破損からのリカバリが可能になります。
Microsoft のピア・ツー・ピア・レプリケーションは、Microsoft SQL Server 2008 でもっとも拡張された機能ですが、旧バージョンよりも高いスケーラビリティや 可用性は提供しません。オンラインでのノード追加機能や競合検出機能などは、 オラクルの多数のリリースのレプリケーション・テクノロジーにすでに搭載され ています。 Oracle RAC は、ほかのレプリケーション環境と比較しうるものではありません。 レプリケーション・データベースや分散データベース向けのソリューションは、 長年にわたり市場に出回っており、一部の用途では定評を博しています。一方、 Oracle RAC を使用すれば、アプリケーションを変更することなくスケーラビリ ティと高可用性を実現できます。
Oracle Real Application Clusters 11gMicrosoft SQL Server 2008 との技術比較 2008 年 5 月、バージョン 1.1
著者：Markus Michalewicz
共著者：Philip Newlan、Barb Lundhild Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口： 電話：+1.650.506.7000 ファクシミリ：+1.650.506.7200 www.oracle.com
Copyright © 2007, Oracle.All rights reserved.
本文書は情報提供のみを目的として提供されており、ここに記載される内容 は予告なく変更されることがあります。 本文書は、その内容に誤りがないことを保証するものではなく、また、口頭 による明示的保証や法律による黙示的保証を含め、商品性ないし特定目的適 合性に関する黙示的保証および条件などのいかなる保証および条件も提供す るものではありません。 オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によっ て直接的または間接的に確立される契約義務はないものとします。 本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目 的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成 または送信することはできません。
Oracle、JD Edwards、PeopleSoft、および Siebel は、米国 Oracle Corporation およびその子会社、関連会社の登録商標です。そのほかの名称はそれぞれの 会社の商標です。
