oracle real application clusters 11g release 2 - microsoft ... · oracle...

Oracle ホワイト・ペーパー 2009 年 12 月

Oracle Real Application Clusters 11g Release 2 - Microsoft SQL Server 2008 との

技術比較

Oracle ホワイト・ペーパー - Oracle Real Application Clusters 11g Release 2 - Microsoft SQL Server 2008 との技術比較

はじめに ................................................................................................................................ 1 Oracle Real Application Clusters アーキテクチャ ................................................................ 2 Microsoft SQL Server 2008 のフェデレーテッド・データベース ........................................ 3

Microsoft SQL Server 2008 のフェデレーテッド・データベースのレイアウト .............. 4 Microsoft SQL Server 2008 のフェデレーテッド・データベースの概要......................... 6 Oracle Real Application Clusters が優れている理由 ........................................................ 7

Microsoft SQL Server 2008 のフェイルオーバー・クラスタリング .................................... 8 Microsoft SQL Server 2008 のフェイルオーバー・クラスタ・データベースのレイアウト .......................................................................................................................................... 9 Microsoft SQL Server 2008 のフェイルオーバー・クラスタ・データベースの概要 ...... 9 Oracle Real Application Clusters が優れている理由 ...................................................... 10

SQL Server 2008 Mirror Database ..................................................................................... 11 Microsoft SQL Server 2008 のデータベース・ミラーリングのレイアウト ................... 11 Microsoft SQL Server 2008 のデータベース・ミラーリングの概要 .............................. 12 Oracle Real Application Clusters が優れている理由 ...................................................... 13

SQL Server 2008 Peer-To-Peer Replication ....................................................................... 13 Microsoft SQL Server 2008 のピア・ツー・ピア・レプリケーションの概要 ............... 14 Oracle Real Application Clusters が優れている理由 ...................................................... 14

まとめ ................................................................................................................................. 15


1

はじめに

クラスタ・データベース市場では競合する宣伝文句が飛び交っており、各ベンダーは自社アーキテ

クチャの利点を盛んに宣伝しています。顧客は、急速に進化する大量のベンチマークの結果や、相

反するアナリストの批評記事、一様に肯定的な顧客の事例広告を取捨選択して、ミッション・クリ

ティカルなソフトウェア・プラットフォームを選択する必要があります。このホワイト・ペーパーでは、Microsoft SQL Server 2008 のアーキテクチャとなる Microsoft の次の

4 つのデータベース・テクノロジーを技術的に評価します。

1. フェデレーテッド・データベース 2. フェイルオーバー・クラスタリング（Microsoft Cluster Server で管理） 3. データベース・ミラーリング 4. ピア・ツー・ピア・レプリケーション

各テクノロジーをオラクルのクラスタ・アーキテクチャである Oracle Real Application Clusters（Oracle RAC）またはオラクルの各テクノロジーと比較します。Oracle RAC と関連テクノロジー

は、オラクルの Maximum Availability Architecture（MAA）を形成し、データベースの障害保護を強

化します。上記アーキテクチャはすべて、Microsoft SQL Server の旧バージョンにも存在します。そ

のため、Microsoft SQL Server 2008 の機能のほとんどは単なる改良版となっています。このホワイト・ペーパーで取り上げるすべての Microsoft ソリューションを、Oracle Database 11g Release 2とOracle Real Application Clusters 11g Release 2 について順を追って比較していきます。


2

Oracle Real Application Clusters アーキテクチャ

ここで重要なことは、Microsoft SQL Server 2008 が提供する機能には、高可用性とスケーラビリティ

を併せもつ Oracle Real Application Clusters に匹敵する機能がないということです。

図 1：Oracle Real Application Clusters の概要

Oracle RAC アーキテクチャは、Unix、Windows、Linux サーバー領域では独自のものです。上記の例

では、4 つのノードのすべてが、1 つのデータベースにあるデータに対するクライアントのリクエス

トを処理できます。Oracle RAC の差別化要因の 1 つは、ノードの障害にシームレスに対処できるアー

キテクチャ固有の機能です。

上記の状況でノードに障害が発生すると、障害が発生したノードに接続されたセッションは存続す

るノードに移行され、接続が分散されて、残りの 4 つのノードで使用可能なリソースが有効活用さ

れます。クラスタ内のほかのノードはリクエストの処理を継続し、存続するノードに接続されたセッ

ションは切断されません。

クラスタ内のノードを全く同じ構成にする必要がないことも注目に値します。例として、複合ワー

クロード環境があります。複合ワークロード環境では、データベースが OLTP と意思決定支援との

ユーザー間で共有されます。データベース・インスタンスを適に構成して、接続ユーザーのリク

エストを処理できます。

また、Oracle RAC を使用すると、クラスタ内のすべてのマシンを同時に使用して、パフォーマンス

をさらに向上できます。たとえば、この環境では、クラスタ内で使用可能なすべての CPU を使用し

てデータ・ウェアハウスへの問合せを自動的にパラレル処理し、意思決定支援アプリケーションの

パフォーマンスを向上できます。高度なロードバランシング・アルゴリズムとアドバイザを使用す

れば、ユーザー・セッションをクラスタ内の' 小負荷'のノードにルーティングできます。


3

Oracle Automatic Storage Management（Oracle ASM）と Oracle Clusterware は、Oracle Real Application Clusters アーキテクチャを補完します。Oracle Database 11g Release 2 に以前からある独立した 2 つの

製品、Oracle Clusterware と Oracle Automatic Storage Management は、Oracle Grid Infrastructure と呼ば

れる新しい製品のバンドルに組み込まれています。

Microsoft SQL Server 2008 のフェデレーテッド・データベース

Microsoft SQL Server のフェデレーテッド・データベースは、独立したサーバーの集合であり、リソー

スを共有せずに LAN で接続されます。また、フェデレーテッド・データベースの実装は複雑です。

フェデレーテッド・データベース・モデルは、Microsoft SQL Server 2005 ですでに使用可能です。こ

の領域については、本書でとくに記すべき新機能はありません。そのため、次の図には、6 ノードの

フェデレーテッド・データベースの従来構成を示します。

この図では、6 つの独立した Microsoft SQL Server データベースがあり、それぞれが別個のバックアッ

プとリカバリを必要とします。クライアント・アプリケーションからのリクエストを満たすには、

これらのデータベースすべてがオンラインである必要があります。このアーキテクチャをサポート

するパッケージ・アプリケーションはごくわずかです。

図 2：Microsoft SQL Server 2008 のフェデレーテッド・データベース - 概要


4

Microsoft SQL Server 2008 のフェデレーテッド・データベースのレイアウト

次に、フェデレーテッド・データベースを設定するプロセスについて簡単に説明します。

データは、クラスタに参加している各サーバーに分散されます。DBA とアプリケーション開発者の

両方にとって、特定のサーバーに接続されたディスク上の"ローカル"データと、フェデレーテッド・

データベースの他のサーバーが所有する"リモート"データは明らかに違います。

アプリケーションは、UNION ALL ビューと分散 SQL を使用して、データの論理的な単一のビュー

を参照します。Microsoft はこのテクノロジーを、分散パーティション・ビュー（DPV）と呼びます。

DPV は、各ノードで異なる方法により構成され、ローカルのパーティションとリモートのパーティ

ションを明示的に考慮する必要があります。

次の図は、Microsoft SQL Server の複数のサーバーにまたがる'顧客'表のパーティション化方法を示し

ています。それぞれのアプリケーションの各表に対して、次の手順が必要になります。

• まず、各ノードで独立した表を作成します。

-- On Server1: CREATE TABLE Customers_33 (CustomerID INTEGER PRIMARY KEY CHECK (CustomerID BETWEEN 1 AND 32999), ... -- Additional column definitions) -- On Server2: CREATE TABLE Customers_66 (CustomerID INTEGER PRIMARY KEY CHECK (CustomerID BETWEEN 33000 AND 65999), ... -- Additional column definitions) -- On Server3: CREATE TABLE Customers_99 (CustomerID INTEGER PRIMARY KEY CHECK (CustomerID BETWEEN 66000 AND 99999), ... -- Additional column definitions)

このコード例は、http://msdn.microsoft.com/en-us/library/ms188299.aspxに掲載されています。

• 次に、接続性情報を作成します。

各参加サーバーに、リンクされたサーバー定義と問合せ適化オプションが必要です。

• 後に、各ノードで DPV を作成します。ビューは各ノードで異なることに注意してくだ

さい。

CREATE VIEW Customers AS SELECT * FROM CompanyDatabase.TableOwner.Customers_33 UNION ALL SELECT * FROM Server2.CompanyDatabase.TableOwner.Customers_66 UNION ALL SELECT * FROM Server3.CompanyDatabase.TableOwner.Customers_99

このコード例は、http://msdn.microsoft.com/en-us/library/ms188299.aspxに掲載されています。


5

ベンチマーク

これまで、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 アプリケーションしかフェデ

レーテッド・データベースに移植して実行することはできません。


6

Microsoft SQL Server 2008 のフェデレーテッド・データベースの概要

'実環境'のアプリケーションへのフェデレーテッド・データベースのアプローチが失敗する理由は、

次のように数多くあります。

ホット・ノード

DBA は、'ホット'ノードが生じないように注意してデータをパーティション化する必要があります。

データベースの割合に基づいて単純にパーティション化することはできません。問合せの分散が実

行されず、ホット・ノードが生じる場合があるためです。このホット・ノードがボトルネックとな

り、スループットが制限されます。

さらに、初に完全なパーティション化がおこなわれて負荷が全ノードに分散されても、時間の経

過とともに、データの追加や変更により問合せプロファイルが変更されて、初は完全に分散され

ていたシステムがホット・ノードによって不均衡なシステムになる場合があります。

データの不整合性

データベース・データのパーティション化は簡単な作業ではないため、大きな表のみがパーティショ

ン化され、小さな表は全ノード間で複製される傾向にあります。つまり、各ノードには独自のデー

タベースがあるため、小さい表に対するすべての変更をクラスタ内の全ノードで複製することが必

要になります。この複製により、データの複数コピーが複数の Microsoft SQL Server データベースに

格納されることになります。

ノードの追加

ワークロードが増加すると、Microsoft SQL Server フェデレーテッド・データベースへの新しいノー

ドの追加が必要となります。そのプロセスは、OS のインストール、Microsoft SQL Server のインストー

ル、新しいパーティション化スキームの決定、既存のノードからのデータのアンロード、データの

再パーティション化、新しいノード集合へのデータのロード、データベースのオンラインへの復帰、

必要に応じたアプリケーションの変更となります。

一貫性バックアップ

Microsoft SQL Server DPV データベースは、実際には多数のデータベースで構成されており、各デー

タベースを個別にバックアップする必要があります。さらに、DPV データベースのリカバリが必要

な場合、独立した各データベースを同時点までリカバリして、終的にはすべてのデータベースを

オンラインに復帰させる必要があります。

ノード障害の処理

ノード障害時に、そのノードのデータはアプリケーションで使用できなくなります。実環境のアプ

リケーションのほとんどは、データの一部がオフラインになることを許容できません。


7

ベンチマーク

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 のフェイルオーバーが行われ、障害が発生したノードへの接続は、残存するノードに自

動的に再接続されます。


8

アプリケーション層には、'高速接続フェイルオーバー'によりノードの停止がタイムリーに通知され、

障害が発生したノードに関連する接続プール内の接続を無効にできます。

ベンチマーク

オラクルは、定期的に多様なプラットフォームで 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 Cluster Server（MSCS）は、Microsoft SQL Server で Microsoft がサポートするテクノロジー

であり、スタンドアロン・ノードに比べてやや高レベルの可用性を提供します。Microsoft はこれを'フェイルオーバー・クラスタリング'と呼んでいます。

図 3 は、Microsoft SQL Server データベースをフェイルオーバー・クラスタリングで管理する場合に

使用する MSCS システムを簡単に示したものです。

図 3：Microsoft のフェイルオーバー・クラスタリングのアーキテクチャ

ハードウェアのアーキテクチャは、Oracle RAC 環境と似ています。ノードは 2 つあり、ネットワー

ク・インターコネクトで接続されています。'共有ディスク'のようなものもあります。しかし実際に

は、フェイルオーバー・クラスタ・データベース内のディスクは共有されず、Microsoft SQL Serverデータベースはノードの 1 つで特定の時点に実行されるだけです。2 番目のノードは、初のノード

に障害が発生した場合のバックアップとして提供されています。


9

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 データベースの再

起動手順を実行する間、遅延が生じます。この手順の概要は、次のとおりです。


10

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 RAC では、同一データベースのインスタンスがクラスタ内の全ノードで実

行され、ワークロードをクラスタ内の全ノードで共有できます。つまり、Oracle Real Application Clusters では、クラスタ内の新しいノードを使用して、ワークロードを全ノードにただちに拡張でき

ます。

Oracle RAC クラスタには MSCS（Oracle Clusterware にクラスタ・ソフトウェア・ソリューションと

して付属）が不要のため、MSCS のノード制限による制約はありません。Oracle RAC 10g Release 2以降、大 100 のノードと Oracle データベースが認定するほとんどのオペレーティング・システム

をサポートしています。

1 つのノードに障害が発生すると、クラスタ内のほかのノードが既存の接続へのサービスを継続しま

す。'実行中'のトランザクションは、クラスタ内のほかのノードによって自動的に即時ロールバック

されます。そのため、リソースの再起動やほかのノードでのデータベースのオープンを待つ必要が

ありません。データベースは常時オープンとなり、残存ノードの残存インスタンスでアクセスでき

ます。

Oracle RAC では、フェイルオーバーは分単位ではなく秒単位で行われます。障害が発生したノード

への接続は、残存するノードに自動的に再接続されます。アプリケーション層には、'高速接続フェ

イルオーバー'によりノードの停止がタイムリーに通知され、接続プール内の障害が発生したノード

への接続を無効にできます。


11

Oracle Automatic Storage Management（Oracle ASM）を使用すれば、ストレージ・サブシステム内また

は複数のストレージ・システム間のデータを Oracle RAC データベースに完全透過的にミラー化でき

ます。Oracle ASM には、単一のミラー化（別のディスクまたは別のストレージ・システムへのミラー

化）をおこなう標準的な冗長化と、異なる場所で 2 つのデータ・コピーを維持する高レベルの冗長

化の 2 つがあります。

Oracle ASM では、データが全ノードにストライプ化され、I/O 使用率が適化されます。さらに、ク

ラスタの全ノードから、いつでも全 ASM ディスク・グループ（Oracle ASM で使用できるディスク

を体系化する論理ユニット）を開いてアクセスできます。あらゆるノードから全データにアクセス

できているため、ノード障害時に別のノードからのデータ参照を可能にする必要がありません。ス

トレージ障害時には、サービスを中断させることなく、Oracle RAC データベースの完全運用を継続

できます。

SQL Server 2008 Mirror Database

Microsoft のデータベース・ミラーリングは Microsoft SQL Server 2005 の新機能であり、Microsoft SQL Server 2005 の初期リリースの一部として、初期バージョンに搭載されました。Microsoft はこのステー

タスを変更し、SP1 アップグレードの一部としました。

Microsoft SQL Server 2008 では、データベース・ミラーリング機能がさらに拡張されました。たとえ

ば、Microsoft SQL Server 2008 バージョンでのみ、データベースを再起動することなく手動フェイル

オーバーを実行できます。

また、ミラー化による保護がデータ・ページにも拡張されており、プライマリ・サーバーまたはミ

ラー・サーバーのいずれかでページの破損が検出されると、パートナー・サーバーから該当ページ

が取得されるため、データベース処理をシームレスに継続できます。新たに導入された圧縮技術を

使用すれば、プライマリ・サーバーとミラー・サーバー間のデータ・フローを圧縮できるため、ネッ

トワーク・トラフィックを削減できます。

従来のデータベース・ミラーリング方法では、配置可能なミラー・サーバーは 1 つのみであったの

に対し、Microsoft SQL Server 2008 に導入された改良版では、複数のウォーム・スタンバイ・サイト

間で定期的なログ送信を実行できます。ログ送信は定期的に実行されるため、マスター・サーバー

で発生したデータ変更がセカンダリ・サーバーに転送される間、遅延が生じます。

Microsoft SQL Server 2008 のデータベース・ミラーリングのレイアウト

Microsoft は通常、データベース・ミラーリング・テクノロジーを高可用性ソリューションとして説

明しています。次の図に示すように、この機能を大限に活用するには、3 つの Microsoft SQL Serverデータベースが必要です。


12

1 つ目は本番データベース、2 つ目はミラー・データベース、3 つ目はモニター（'ウィットネス・サー

バー'）として機能するデータベースです。ウィットネス・サーバーは定義ごとに選択可能であり、

プライマリ・データベースとミラー・データベース間の自動フェイルオーバーを可能にする唯一の

方法です。ウィットネス・サーバーがない場合は、フェイルオーバーを常に手動で初期化する必要

があります。

図 4 では、Microsoft SQL Server のプライマリ・データベースとミラー・データベースとの間でログ

が送信されます。ウィットネス・データベースは、システム・モニターとして機能します。従来の

データベース・ミラーリング・テクノロジーでサポートされるミラー・サーバーは 1 台のみです。

図 4：Microsoft のデータベース・ミラーリング・アーキテクチャ

Microsoft SQL Server 2008 のデータベース・ミラーリングの概要

データベース・ミラーリングでは、いかなる種類のスケーラビリティも提供されません。Microsoft SQL Server 2008 のこの機能で提供される可用性は、Oracle Data Guard のフィジカル・スタンバイ・

データベースに類似しているように思われます。ミラー・データベースは、フェイルオーバーが実

行されるか、または手動で初期化されるまで'使用不可能'となります。

ミラー化による保護のデータ・ページへの拡張、2 台のサーバー間のデータ・フローの圧縮、非同期

の定期的なログ送信をベースにした複数のセカンダリ・サーバーのサポートといった新機能は、Oracleデータベースの多数のリリースにすでに搭載されている機能と言えます。


13


データベース・ミラーリングは、Oracle RAC に匹敵するものではありません。これは、Oracle Data Guard テクノロジーに類似した機能です。Oracle RAC と Oracle Data Guard の組み合わせにより、比

類なきレベルの可用性とスケーラビリティが実現します。これについては、『Oracle Maximum Availability Architecture』1で説明されています。

SQL Server 2008 Peer-To-Peer Replication

レプリケーション機能は 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 のピア・ツー・ピア・レプリケーションを補完します。

1 オラクルの Maximum Availability Architecture（MAA）に関する情報は、次の Web サイトでご覧になれます。 http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm 2 次の Oracle SQL Server 2005 文書からの引用です。 http://technet.microsoft.com/en-us/library/bb934199%28SQL.100%29.aspx


14

Microsoft SQL Server 2008 のピア・ツー・ピア・レプリケーションの概要

ピア・ツー・ピア・レプリケーションはワークロードのロードバランシングに使用できますが、ス

ケーラビリティは提供しません。概して、Microsoft SQL Server 2008 のこの機能は、Oracle データベー

スの非常に多くのリリースに搭載されているオラクルのマルチマスター・レプリケーションや Oracle Streams のレプリケーションに類似しているように思われます。Microsoft SQL Server 2008 の新しい競

合検出機能を考慮すれば、注目すべき点は"競合発生時に、競合が解消されてトポロジ間のデータ一

貫性が確立されるまで、トポロジの非一貫性が維持される"3という点です。


ピア・ツー・ピア・レプリケーションは、Oracle RAC に匹敵するものではありません。これは、オ

ラクルの多数のリリースに搭載済みの Oracle レプリケーション・テクノロジーに類似した機能です。

3 次の Oracle SQL Server 2008 文書からの引用です。 http://technet.microsoft.com/en-us/library/bb934199%28SQL.100%29.aspx


15

まとめ

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 11g Release 2

- Microsoft SQL Server 2008 との技術比較

2009 年 12 月

著者：Markus Michalewicz

共著者：Philip Newlan

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 © 2009, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告

なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙示を問わ

ず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の保証や条件も提供するものではありません。オラク

ル社は本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書

はオラクル社の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成

または送信することはできません。

Oracle は米国 Oracle Corporation およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

0109

oracle real application clusters 11g release 2 - microsoft ... · oracle...

Documents