Oracle Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 オラクル コンペティティブ ホワイト ペーパー 2008 年 5 月
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 2008 との技術比較 2
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 11g Microsoft SQL Server 2008 との技術比較 3
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 アーキテクチャを補完することにより グリッド インフラストラクチャにストレージ管理とクラスタ ソフトウェア ソリューションを提供します Oracle Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 4
Microsoft SQL Server のフェデレーテッド データベースでは 一定レベルのスケーラビリティが提供されますが 可用性は低下します Microsoft SQL Server データベースにノードを追加すると 可用性の低下が見込まれます これは Microsoft SQL Server データベースが 使用可能なすべてのノードに依存してリクエストを処理しているためです Microsoft SQL Server 2008 のフェデレーテッド データベース Microsoft SQL Server のフェデレーテッド データベースは 独立したサーバーの集合であり リソースを共有せずに LAN で接続されます また フェデレーテッド データベースの実装は複雑です フェデレーテッド データベース モデルは 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 の複数のサーバーにまたがる ' 顧客 ' 表のパーティション化方法を示しています Oracle Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 5
アプリケーションで 各表に対して次の作業をおこないます まず 各ノードで独立した表を作成します このコード例は 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 Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 6
表に挙げたアプリケーションでは すばやいデータ アクセスとデータの整合性を確保するため 非主キー列にグローバル一意索引が必要です グローバルな一意索引の例として 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 は ' ホット ' ノードが生じないように注意してデータをパーティション化する必要があります データベースの割合に基づいて単純にパーティション化することはできません 問合せの分散が実行されず ホット ノードが生じる場合があるためです このホット ノードがボトルネックとなり スループットが制限されます さらに 最初に完全なパーティション化がおこなわれて負荷が全ノードに分散されても 時間の経過とともに データの追加や変更により問合せプロファイルが変更されて 最初は完全に分散されていたシステムがホット ノードによって不均衡なシステムになる場合があります Oracle Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 7
データの不整合性データベース データのパーティション化は簡単な作業ではないため 大きな表のみがパーティション化され 小さな表は全ノード間で複製される傾向にあります つまり 各ノードには独自のデータベースがあるため 小さい表に対するすべての変更をクラスタ内の全ノードで複製することが必要になります この複製により データの複数コピーが複数の 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 Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 8
データの整合性 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. Oracle Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 9
Microsoft SQL Server のフェイルオーバー クラスタ データベースは " スタンドアロン " データベースに比べてやや高レベルの可用性を提供しますが スケーラビリティは提供しません 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 番目のノードは 最初のノードに障害が発生した場合のバックアップとして提供されています Microsoft のフェイルオーバー クラスタリングは Microsoft SQL Server の複数のバージョンで使用可能です Microsoft SQL Server 2008 ではこのソリューションが拡張され 1 クラスタにつき 16 ノードをサポートしています さらに ' 地理的に分散したフェイルオーバー クラスタリング ' をサポートしているため フェイルオーバー クラスタを 2 カ所に設定して 各サイトに 1 つまたは複数のストレージ アレイを配置し 単一共有ディスク システムによるリスクを回避できます また クラスタ検証ツールを使用して Microsoft のフェイルオーバー クラスタ ソリューションの実行に適したハードウェア リソースがあることを確認できます Microsoft SQL Server 2008 のフェイルオーバー クラスタ データベースのレイアウト このアーキテクチャでインストールされた Microsoft SQL Server データベースは 単一の Microsoft SQL Server データベースのように機能します このデータベースには ハードウェアやオペレーティング システムと同様の制限事項が課されます Oracle Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 10
単一サーバーのスケーラビリティによって制限されます データベースは一度に特定の 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 11g Microsoft SQL Server 2008 との技術比較 11
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 データベースの完全運用を継続できます Oracle Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 12
Microsoft SQL SERVER 2008 のデータベース ミラーリング Microsoft のデータベース ミラーリングは Microsoft SQL Server 2005 の新機能であり Microsoft SQL Server 2005 の初期リリースの一部として 初期バージョンに搭載されました Microsoft はこのステータスを変更し SP1 アップグレードの一部としました Microsoft SQL Server のデータベース ミラーリングは Oracle Data Guard に相当します データベース ミラーリングは一定レベルの保護を提供しますが Microsoft SQL Server データベース自体のスケーラビリティは向上しません Microsoft SQL Server 2008 では データベース ミラーリング機能がさらに拡張されました たとえば Microsoft SQL Server 2008 バージョンでのみ データベースを再起動することなく手動フェイルオーバーを実行できます また ミラー化による保護がデータ ページにも拡張されており プライマリ サーバーまたはミラー サーバーのいずれかでページの破損が検出されると パートナー サーバーから該当ページが取得されるため データベース処理をシームレスに継続できます 新たに導入された圧縮技術を使用すれば プライマリ サーバーとミラー サーバー間のデータ フローを圧縮できるため ネットワーク トラフィックを削減できます 従来のデータベース ミラーリング方法では 配置可能なミラー サーバーは 1 つのみであったのに対し Microsoft SQL Server 2008 に導入された改良版では 複数のウォーム スタンバイ サイト間で定期的なログ送信を実行できます ログ送信は定期的に実行されるため マスター サーバーで発生したデータ変更がセカンダリ サーバーに転送される間 遅延が生じます Microsoft SQL Server 2008 のデータベース ミラーリングのレイアウト Microsoft は通常 データベース ミラーリング テクノロジーを高可用性ソリューションとして説明しています 次の図に示すように この機能を最大限に活用するには 3 つの Microsoft SQL Server データベースが必要です 1 つ目は本番データベース 2 つ目はミラー データベース 3 つ目はモニター (' ウィットネス サーバー ') として機能するデータベースです ウィットネス サーバーは定義ごとに選択可能であり プライマリ データベースとミラー データベース間の自動フェイルオーバーを可能にする唯一の方法です ウィットネス サーバーがない場合は フェイルオーバーを常に手動で初期化する必要があります 図 4:Microsoft のデータベース ミラーリング アーキテクチャ Oracle Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 13
図 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 サイトでご覧になれます http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm Oracle Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 14
Microsoft SQL Server のピア ツー ピア レプリケーションは オラクルのレプリケーション テクノロジーに相当します ピア ツー ピア レプリケーションは一定レベルのロードバランシングを提供しますが Microsoft SQL Server データベース自体のスケーラビリティは向上しません 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 文書からの引用です http://technet.microsoft.com/enus/library/bb934199%28sql.100%29.aspx Oracle Real Application Clusters 11g Microsoft SQL Server 2008 との技術比較 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 Microsoft SQL Server 2008 との技術比較 16
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 およびその子会社 関連会社の登録商標です そのほかの名称はそれぞれの会社の商標です