oracle real application clusters 11gとibm db2 v9.5(linux ... · oracle...

19
Oracle Real Application Clusters 11g IBM DB2 v9.5LinuxUnixWindows 向け)の技術比較 Oracle ホワイト・ペーパー 2008 1

Upload: others

Post on 09-Jul-2020

3 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

Oracle Real Application Clusters 11g と

IBM DB2 v9.5(Linux、Unix、Windows向け)の技術比較

Oracle ホワイト・ペーパー 2008 年 1 月

Page 2: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

はじめに .............................................................................................................. 3 エンタープライズ・グリッド・コンピューティング ............................. 3 エンタープライズ・グリッドの有効化 ..................................................... 4

エンタープライズ・グリッドの配置............................................................... 5 シェアード・ナッシング・アーキテクチャ ............................................. 5

IBM DB2 のシェアード・ナッシング .................................................. 5 共有ディスク・アーキテクチャ ................................................................. 6 Oracle RAC 11g の共有キャッシュ・アーキテクチャ ............................. 6 配置用の最適な選択..................................................................................... 7 IBM DB2 のパーティション化.................................................................... 8

Nodegroup ................................................................................................. 8 IBM DB2 Design Advisor ......................................................................... 9

スケーラビリティとパフォーマンス............................................................... 9 ノードの追加................................................................................................. 9 パフォーマンス:OLTP アプリケーション ............................................ 10 パフォーマンス:データ・ウェアハウスおよびビジネス・ インテリジェンス・アプリケーション ................................................... 11

ワークロード管理 ............................................................................................ 11 パフォーマンス管理およびチューニング ............................................... 13

Oracle Database 11g アドバイザ ........................................................... 13 IBM DB2 Design Advisor ....................................................................... 14

高可用性 ............................................................................................................ 14 計画外停止時間........................................................................................... 14

Oracle Database 11g Automatic Storage Management............................ 14 ファスト・スタート障害リカバリ ..................................................... 15 Fast Connection Failover......................................................................... 15

計画停止時間............................................................................................... 16 停止時間ゼロのパッチ適用とアップグレード.................................. 16

データベース外部のクラスタリング............................................................. 16 機能比較マトリックスのまとめ..................................................................... 17 結論 .................................................................................................................... 18

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

2

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 3: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

はじめに

多くの企業はグリッド・コンピューティングを追求し、変化するビジネス状況に

対応するための経済の効率性と柔軟性を得ようとしています。これに伴い、さま

ざまなテクノロジを決定する問題に直面することになります。グリッド・コン

ピューティングが広く使用され、基本となるデータベース・テクノロジがグリッ

ド・コンピューティングの利点を得る能力を持っているかを評価する場合、ベン

ダーの提案を注意深く検討する必要があります。

このホワイト・ペーパーでは、Oracle Database Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術を比較します。また、パフォーマ

ンス、柔軟なスケーラビリティ、リソース利用、管理性、および可用性の観点か

ら、IBM DB2 v9.5よりもOracle Real Application Clustersが推奨されるソリューショ

ンであるという理由を説明します。IBM は、IBM DB2 v9.x for z/OS という別のデー

タベース製品も提供している点に注意してください。このホワイト・ペーパーは、

IBM DB2 v9.5(Linux、Unix、Windows 向け)にだけ適用されます。IBM DB2 v9.x for z/OS には適用されません。

エンタープライズ・グリッド・コンピューティング

グリッド・コンピューティングの多くの定義が市場に存在しています。高度なエ

ンタープライズ・グリッド・コンピューティングは、さまざまな IT リソースをプー

ルする機能を提供し、必要に応じて自動的にプロビジョニング可能な、単一の統

合された接続先として動作します。

基本的なグリッドとは、アプリケーション・サービスを提供し、データベース、

アプリケーション、データベース・サーバー、ストレージ・システム、ネットワー

クなどのさまざまなリソースを統合するコンポーネントの相互接続されたシステ

ムです。すべてのリソースを単一のシステム・イメージとして管理し、各アプリ

ケーションのサービス要件に基づいてオンデマンドでプロビジョニングできる方

法で統合することが目的です。

グリッド・コンピューティングは、2 つの中心的な原理によって、他のタイプの

コンピューティングと区別されます。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

3

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 4: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

仮想化:個々のリソース(コンピュータ、ディスク、アプリケーション・

コンポーネント、情報ソースなど)が種類別にプールされ、抽象的な概

念を介してリクエストを行っているアプリケーションが使用できるよう

になります。これは、データの存在する場所、リクエストを処理するサー

バー、またはデータを格納する物理ディスクを心配する必要がないこと

を意味します。

プロビジョニング:仮想化レイヤーを介してリソースが要求された場合、

その要求を満たすために水面下で特定のリソースを識別し、リクエスト

を行っている要素に割り当てます。グリッド・コンピューティングの一

部としてのプロビジョニングとは、特定のリクエストを満たす方法をシ

ステムが決定し、全体としてシステムの動作が最適化されることを意味

します。グリッドのプロビジョニングは、リソースの割当て、情報の共

有、および高可用性に関するものです。リソースの割当てによって、リ

ソースの要求元すべてが必要なリソースを取得し、サービスが提供され

ずにリクエストが処理される場合でもリソースがアイドル状態になりま

せん。情報の共有によって、ユーザーおよびアプリケーションが必要と

する情報を任意の場所と時間で使用できます。高可用性機能は、すべて

のデータと計算が常に利用できることを保証します。

仮想化とプロビジョニングがコンピューティング・インフラストラクチャの向上

の重要な目的である場合、Oracle Real Application Clusters 11g は、IBM DB2 製品よ

りも統合、機能、パフォーマンス、および費用効率において優れたソリューショ

ンです。

エンタープライズ・グリッドの有効化

Oracle Real Application Clusters(Oracle RAC)11g は、エンタープライズ・グリッ

ド・コンピューティングの基盤を提供します。エンタープライズ・グリッドは、

標準の汎用サーバー、共有ストレージ、およびネットワーク・コンポーネントか

ら構築されます。Oracle RAC は、クラスタ・インターコネクトで接続された複数

のサーバーと共有ストレージ・サブシステムで実行される共有キャッシュ・アー

キテクチャを備えたクラスタ・データベースです。Oracle RAC 11g によって、サー

バーのクラスタで単一データベースを透過的に配置できます。また、Oracle RAC 11g は、最高レベルの可用性とスケーラビリティを提供します。システムをオン

ラインにしたまま、ノード、ストレージ、CPU、およびメモリーをすべて動的に

プロビジョニングできます。このため、総所有コスト(TCO)を削減して簡単か

つ効率的にサービス・レベルを維持できます。Oracle RAC は、ワークロードの動

的な分散およびシステム障害からの透過的な保護を実現します。

Oracle RAC は、従来のシェアード・ナッシングおよび共有ディスクのアプローチ

に関する限界を克服し、すべてのビジネス・アプリケーションに高いスケーラビ

リティと可用性を備えたデータベース・ソリューションを提供する、共有キャッ

シュ・アーキテクチャを持ったクラスタ・データベースです。

Oracle RAC 11g には、すべての Oracle Database 11g プラットフォームで使用でき

る、統合された完全なクラスタウェア管理ソリューションの Oracle Clusterware が

含まれます。Oracle Clusterware の機能には、クラスタ・メッセージ、ロック、障

害検出、およびリカバリのメカニズムが含まれます。サード・パーティ製のクラ

スタウェア管理ソフトウェアを購入する必要はありません。Oracle RAC によって、

Oracle Database は、革新的なデータベース・テクノロジのリーダーシップを維持

して、競合他社との差を拡大しています。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

4

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 5: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

エンタープライズ・グリッドの配置

グリッド環境を配置するために使用されるアーキテクチャは、総所有コスト

(TCO)に大きな影響を与えます。Oracle RAC 11g と IBM DB2 の主要な違いの 1つに、以下に示す共有ディスク・アーキテクチャとシェアード・ナッシング・アー

キテクチャの実装があります。

シェアード・ナッシング・アーキテクチャ

単純なシェアード・ナッシング実装で、クラスタ・システムのノード間でデータ

ベースがパーティション化されます。各ノードには、異なるサブセットのデータ

所有権があり、この"所有"ノードはそのデータへのすべてのアクセスを排他的に

実行します。単純なシェアード・ナッシング・システムは、複数の処理ノード間

で作業を分割するために、パーティション化または制限されたアクセスのスキー

ムを使用します。

図 1 - シェアード・ナッシング・アーキテクチャ

シェアード・ナッシング・アーキテクチャのパラレル実行は、データ・パーティ

ション化スキームに基づいています。パフォーマンスは、正確にパーティション

化されているデータに依存します。

シェアード・ナッシング・データベース・システムでは、ディスクの各セットが

クラスタの 2 つのノードへの物理的な接続を確立できるように、デュアル・ポー

トのディスク・サブシステムを使用します。これは、ノード障害によってシステ

ムが使用できなくなることを防止します。ただし、単一ノードの障害が大幅なパ

フォーマンスの低下を発生させる可能性があります。

IBM DB2 のシェアード・ナッシング

IBM DB2 は、シェアード・ナッシング・アーキテクチャと考えられています。た

だし、データの可用性を提供するため、共有ディスクにデータベースを作成する

必要があります。シェアード・ナッシングは、物理的な接続ではなく実行中のデー

タの所有権を参照します。IBM DB2 では、パーティション・データの 2 番目の所

有者として使用できるノードのサブセットだけにディスクを接続できます。サブ

セットだけを使用している場合、一部のノードで他よりも多くのワークロードが

実行され、全体のシステム・スループットとパフォーマンスが低下します。Oracle

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

5

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 6: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

RAC 11g は IBM DB2 とは異なり、ディスクからすべてのノードへの完全な接続が

必要です。このため、上述の問題が回避されます。

共有ディスク・アーキテクチャ

共有ディスク・データベースのデータベース・ファイルは、すべてのデータにア

クセスできる各インスタンスを使用した疎結合システムのノード間で論理的に共

有されます。ハードウェアの直接接続またはすべてのノードのデバイスを表示す

る単一のビューを提供するオペレーティング・システムの抽象化レイヤーを使用

すると、共有ディスク・アクセスが実現します。共有ディスク・アプローチで、

複数のノードから実行される更新アクティビティの同期を行うノード内通信を使

用して、インスタンスで実行されるトランザクションは、データの読取りおよび

変更を直接実行できます。2 つ以上のノードで同じデータ・ブロックが競合して

いる場合、従来の共有ディスク・データベース・システムは、複数のノード間で

データ・アクセスを同期するディスク I/O を使用します。つまり、データをロッ

クしているノードは、他のノードが同じデータ・ブロックにアクセスする前にそ

のブロックをディスクに書き込みます。同期にディスク I/O を使用すると、従来

の共有ディスク・データベース・システムのパーティション化されていないワー

クロードまたは競合の多いワークロードを増加する大きな課題が発生します。

共有ディスク・クラスタは、真のフォル

ト・トレランスを提供します。共有ディ

スク・クラスタのノードで障害が発生し

た場合、システムは、存続しているすべ

てのクラスタ・ノード間のワークロード

を動的に再分散します。これによって、

中断のないサービスおよびバランスの取

れたクラスタ全体のリソース利用が保証

されます。存続しているノードが 1 つだ

けの場合でも、すべてのデータにアクセ

スできます。

図 2 - 共有ディスク・アーキテクチャ

共有ディスク・クラスタ・システムは、マルチノードのスケーラビリティを提供

しているので、更新用のデータをパーティション化できるアプリケーションに適

しています。一貫性のあるキャッシュを維持するコストが増加するので、パーティ

ション化が正しく実行されない場合はパフォーマンスが大幅に低下します。

Oracle RAC 11g の共有キャッシュ・アーキテクチャ

Oracle RAC 11g は、キャッシュの一貫性を維持するために、高速のインターコネ

クトを使用する共有キャッシュ一貫性テクノロジのキャッシュ・フュージョンを

使用します。キャッシュ・フュージョンは、データベース・トランザクションを

処理するクラスタの全ノードのキャッシュを使用します。多くの場合、Oracle RAC 11g の更新操作で同期用のディスク I/O は必要ありません。ローカル・ノードで任

意のクラスタ・データベース・ノード・キャッシュから直接必要なデータ・ブロッ

クを取得できるためです。これは、低速のディスク I/O ソリューションを超える

重要な改善で、従来の共有ディスク・クラスタに起因する根本的な脆弱性を克服

します。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

6

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 7: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

図 1 - Oracle RAC の共有キャッシュ・アーキテクチャ

配置用の最適な選択

Oracle RAC 11g は、エンタープライズ・グリッド環境を配置する最初で唯一実行

可能な選択肢です。IBM DB2 とは異なり、配置および管理が容易です。Oracle RACデータベースは、ユーザーに対して単一で標準の Oracle Database 11g のように表

示されます。また、単一の Oracle Database 11g に使用される保守ツールとプラク

ティスをクラスタ全体に使用できます。すべての標準のバックアップおよびリカ

バリ操作は、Oracle RAC で透過的に動作します。また、データ定義言語と整合性

の制約を含むすべての SQL 操作は、単一のインスタンスと Oracle RAC の構成で

同じです。

単一インスタンスの Oracle Database から Oracle RAC データベースへの移行は、ク

ラスタが作成されて Oracle RAC がインストールされた後に、Oracle Enterprise Manager 11g を使用して簡単に行われます。変更することなく引き続きデータベー

ス・ファイルにアクセスできます。もっとも重要な点として、バランスの取れた

ワークロードの管理(クラスタに対するノードの追加または削除)でデータの変

更やパーティション化を行う必要がありません。

一方、単一ノード環境からクラスタ環境への IBM DB2 の配置は、複雑な作業にな

ります。また、クラスタの追加のノードを活用するためにデータベースの移行が

必要です。これは、各論理ノード(パーティション)が所有するディスクにデー

タをアンロードしてリロードする必要があることを意味します。また、ノードが

クラスタに追加されるたびにパーティション化が必要です。これは、多くの時間

や労力が必要で、エラーが起こりやすくなります。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

7

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 8: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

IBM DB2 のパーティション化

パーティションという用語は、IBM DB2 と Oracle データベースでは意味が異なり

ます。IBM DB2 でのパーティションという用語は、論理ノードとその論理ノード

が所有するデータを示します。各パーティションには、固有のバッファ・プール

とパッケージ・キャッシュなどがあります。IBM DB2 パーティションでは、デー

タのサブセットの直接アクセスだけ実行できます。

アプリケーションに数千の表がある環境での最適なパーティション化は、複雑な

作業になります。一部のアプリケーションを少ない頻度で変更してこの分析を最

小限に抑えることができますが、アプリケーション・プロファイルを頻繁に変更

する多くのアプリケーションが他にあります。すべての表をパーティション化す

る必要がなくても、いくつかの頻繁にアクセスする表のパーティション化につい

ては、アプリケーションとデータ・アクセス方法を広範に理解する必要がありま

す。最適なパーティション化の決定は重要です。IBM DB2 クラスタ環境で全ノー

ドのワークロード・バランスを維持するには、多くの場合再パーティション化が

必要です。

Nodegroup

IBM DB2 のノード/パーティションは、nodegroup に割り当てられます。各表領域

が nodegroup に割り当てられます。表が作成されると、1 つ以上の列で構成される

パーティション・キーが割り当てられます。行が表に挿入されると、行のパーティ

ション化の値は、現在のパーティション・マップに基づいて特定のパーティショ

ンに割り当てられるハッシュ表にハッシュされます。デフォルトのパーティショ

ン・マップは、nodegroup のパーティション間でデータを均等に分散します。

IBM DB2 は、主キーまたはパーティション・キーの指定のない表の最初の長くな

い列に基づいて表を自動的にパーティション化しますが、頻繁にアクセスする表

の最適なパーティション化のパーティション・キーの決定は、次の競争要素に依

存します。

• パーティション・キーによって、データをすべての論理ノード(パー

ティション)に均等に分散する必要があります。これには、表の定義

および列の使用方法を理解する必要があります。場合によっては、こ

れを理解してもデータを均等に分散できない可能性があります。

• 列の結合では、同じ場所に存在する結合を許可する(つまり、パーティ

ション間通信を行わずに同じノードで結合を実行できる)際に、パー

ティション・キーの選択に注意する必要があります。同一の場所への

配置は、IBM DB2 のパフォーマンスに重要です。一部のスキーマで

は、すべての結合を同一の場所に配置できません。高速のインターコ

ネクトによってこの重要性は低下しましたが、メッセージ・トラ

フィックの削減はクラスタ・データベース・パフォーマンスにとって

重要です。

• パーティション・キーを決定するには、データ・アクセス・パターン

(表のサイズと使用される問合せの頻度)を考慮する必要があります。

適切な同一の場所に配置される列が表にない場合、各ノードにレプリ

ケートされたコピーを作成できます。ただし、レプリケートされた表

を更新すると、パフォーマンスに悪影響を与えます。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

8

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 9: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

• 最後に、一意な索引または主キーをパーティション・キーのスーパー

セットにする必要があります。これは、パーティション化列以外の列

に一意な制約を適用する必要がある場合、アプリケーションの変更が

必要であることを意味します。

IBM DB2 Design Advisor

IBM DB2 v8 では、データベースを作成する場合またはパーティション化されてい

ない DB2 データベースからパーティション化された DB2 データベースに移行す

る場合に、データをパーティション化する方法の推奨事項とアドバイスを提供す

る"Design Advisor"と呼ばれる新機能が導入されました。アドバイザリに関係なく、

DBA がこの複雑な作業を手動で実行する必要があります。上述のように、パ

フォーマンスに影響を与えるデータの偏りやホット・スポットを防止するために

ワークロードを変更する場合、Design Advisor の推奨事項では、DBA による調整

が必要な場合もあります。

スケーラビリティとパフォーマンス

共有キャッシュ・アーキテクチャを備えた Oracle RAC には、アプリケーションを

拡張する柔軟性があります。Oracle RAC は、すべてのタイプのアプリケーション

に柔軟かつ簡潔なスケーラビリティを提供します。アプリケーション・ユーザー

は、単一の高パフォーマンスの仮想クラスタ・サーバーにログオンできます。Oracle RAC に実装されているキャッシュ・フュージョン・テクノロジによって、アプリ

ケーションを変更することなく容量をほぼリニアに拡張できます。アプリケー

ションが複雑になりワークロードが動的になるほど、Oracle RAC 11g の使用が効

果的になります。

IBM DB2 とは異なり、共有キャッシュ・アーキテクチャを備えた Oracle RAC 11gでは、データ・パーティション化スキーマを拡張する必要がありません。Oracle RAC 11g は、変更することなく標準ですべてのアプリケーションにクラスタ・ス

ケーラビリティを提供します。

グリッドは、標準の汎用サーバー、ストレージ、およびネットワーク・コンポー

ネントから構築できます。より高い処理能力が必要な場合は、ユーザーをオフラ

インにすることなく、新しいサーバーを追加できます。現在のハードウェアの容

量が制限に達した場合、Oracle RAC で同じようなサーバーをクラスタに追加する

だけで、グリッド環境の水平スケーラビリティを実現できます。これによって、

既存のシステムを新しく大きいノードに置き換えた場合と比べて、費用効率の高

いスケーラビリティが実現します。IBM DB2 とは対照的に、グリッドへのノード

の追加が簡単で、プロセッサ・ノードが追加される場合またはビジネス要件が変

更される場合に、データをパーティション化するための手動の介入が必要ありま

せん。

ノードの追加

シェアード・ナッシング環境のデータのパーティション化では、クラスタへ新し

いサーバーを追加すると時間とコストがかかります。これは、新しいパーティショ

ン・マップに従ってパーティション化されたデータの再分散を行う必要があるか

らです。DBA またはシステム管理者が行う必要のある作業は、ノードを IBM DB2 ESE データベースに追加することです。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

9

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 10: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

ハードウェアの追加

新しいパーティションの構成(パーティション固有のパラメータの設定

など)

多くのパーティション間におけるデータの再分散 IBM DB2 ESEシステム

のデータの再分散には、影響を受ける表に対する DBA の作業と停止時間

が含まれます。

一方、ノードを Oracle RAC クラスタに追加する場合、DBA またはシステ

ム管理者は以下の手順を実行する必要があります。

ハードウェアの追加

新しいインスタンスの構成(インスタンス固有のパラメータの設定など)

データの再パーティション化はありません。シームレスな拡張だけでオフラ

インのメンテナンスは必要ありません。Oracle RAC によって、データベース・

アクセスを中断しないでノードを追加できます。

パフォーマンス:OLTP アプリケーション

スケーラビリティとパフォーマンスは、アプリケーションのタイプとアプリケー

ションが実行するワークロードにも依存します。

OLTP アプリケーションで、スループット(時間単位で処理されるトランザクショ

ン数)または応答時間(所定のトランザクションに必要な時間の量)によってパ

フォーマンスが測定されます。

Oracle RAC で、データを変更するトランザクションのコミットは、トランザクショ

ンを実行しているノードのログ書込みに依存します。トランザクションでは、ク

ラスタの他のノードで変更されたデータにアクセスする必要がある場合、これら

のブロックが、ディスク I/O を発生することなく高速のインターコネクトを使用

して転送されます。キャッシュ・フュージョンによって、Oracle RAC は、ノード

間キャッシュの競合を解決するために、メッセージ・トラフィックを透過的に最

適化します。

IBM DB2 ESE システム上の複数パーティションのデータを変更するトランザク

ションは、2 フェーズ・コミット・プロトコルを使用して複数マシン間のトラン

ザクションの整合性を保証する必要があります。これは、トランザクションをコ

ミットする前に 2 フェーズ・コミット・プロセスの一部として、少なくとも 2 つ

のログ書込みと 1 つのラウンドトリップ・メッセージを待機する必要があること

を意味します。したがって、IBM DB2 のトランザクションのコミットはさらに時

間がかかり、応答時間が増加します。また、IBM DB2 ESE によって、索引が表に

等価パーティション化されます。パーティション・キー(またはパーティション・

キーの接頭辞)以外の索引の問合せは、すべてのパーティションにブロードキャ

ストされます。これによって、パーティション・プルーニングにならない問合せ

の複数パーティション探査が発生します。IBM DB2 システムでは、最後のアクセ

スから変更されていない場合でも、ノード間通信を使用して別のパーティション

からデータにアクセスします。ノード間通信を少なくするため、各パーティショ

ンの表をレプリケートしたコピーを作成できます。ただし、レプリケートした表

には、追加の領域が必要です。これらの表の更新は、パフォーマンスに影響しま

す。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

10

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 11: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

図 2 - 例 - パーティション・プローブおよび IBM DB2 ハッシュ・パーティション化

パフォーマンス:データ・ウェアハウスおよびビジネス・インテリジェ

ンス・アプリケーション

ビジネス・インテリジェンス処理は、世界中のユーザーから大幅に増加している

情報リクエストを処理するデータ・リポジトリで作成されます。また、データの

場所に関係なく即座に情報を顧客に提供します。通常、ワークロードは、長時間

実行している複雑な問合せで構成されます。このため、クラスタのすべてのノー

ドに渡り最適なパラレル処理を各問合せで実行することに重点を置いています。

これは、全体の問合せ経過時間を削減するためです。

IBM DB2 ESE とは異なり、Oracle 内の問合せのパラレル処理は、基本となる表の

パーティション化スキーマによって並列度が決定され、CPU 数、アクセスするファ

イル数、および他の変数に基づいてインテリジェントに決定されます。Oracle は、

並列度を使用してパーティション化スキームに関係なく、常に問合せのパラレル

処理を実行できます。

Oracle RAC のパラレル問合せアーキテクチャには、各問合せの並列度を動的に決

定する一意な機能があります。並列度を選択する場合にデータ・ウェアハウスの

現在のロードを考慮します。Oracle RAC は、同時のパラレル問合せを実行する大

規模なデータ・ウェアハウスのスループットを改善します。また、すべての使用

可能なリソースを最大限に利用できます。

Oracle の動的なパーティション内のパラレル実行によって、サーバーは、複数の

プロセッサまたはノード間にワークロードを分散できます。問合せを局所化する

この機能によって、問合せ実行中のノード内通信が最小限に抑えられて、問合せ

のパフォーマンスが向上します。Oracle は、強力なマルチノード機能を備えた動

的なパラレル問合せアーキテクチャを提供する唯一のデータベースです。

ワークロード管理

IBM DB2 ESEでは、データ・パーティション化に基づいてトランザクションをルー

ティングする必要があります。このため、リクエストをルーティングする柔軟性

が低くなります。IBM DB2 で機能ごとにトランザクションをルーティングするに

は、トランザクションでアクセスするデータの場所に関する知識が必要です。ま

た、データの再分散なしで多いまたは少ない論理ノード(パーティション)でト

ランザクションを実行すると、パフォーマンスに影響するため柔軟性の低い環境

となります。IBM DB2 のハッシュ・パーティション化スキームには、データ分散

が変更されるたびに再分散されるすべてのパーティションのデータが必要です。

データの再分散プロセス中に表がロックされるため、メンテナンス時間が増加し

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

11

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 12: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

てデータの可用性が低下します。同様に、古いデータがアーカイブまたは削除さ

れる場合、すべてのパーティションを処理する必要があります。これによって、

定期的な挿入操作が妨げられ、領域の断片化が発生する場合があります。

対照的に、Oracle RAC では、基本となるデータをパーティション化する必要があ

りません。Oracle RAC 11g は、接続プーリング・メカニズムに基づいてさらに動

的なアプローチを提供します。Oracle RAC には、サービス用のデータベースで実

行されるワークロードを監視するロード・バランシング・アドバイザが含まれま

す。また、最適なサービス・レベルのワークロード・リクエストを送信する場所

に関する推奨事項を提供します。アプリケーション・トランザクションの最適な

スループットを提供するため、Oracle Database 11g JDBC 暗黙的な接続キャッシュ

の ODP.NET 接続プールは、アプリケーションのインテリジェントなロード・バラ

ンシングを提供します。この機能は、接続プールとロード・バランシング・アド

バイザを統合する Runtime Connection Load Balancing と呼ばれます。アプリケー

ションが接続プールからの接続をリクエストする場合、ランダムでフリーな接続

を受け取る代わりに、クラスタの現在の処理アクティビティに基づいて最適な応

答を返すフリーな接続が提供されます。

Oracle Database 11g Services は、異なるワークロードを管理する課題に対して簡潔

なソリューションを提供します。また、グリッド環境のアプリケーション・ワー

クロードの管理では柔軟性が得られます。さらに、ワークロードを個別に管理お

よび制御できます。DBA は、通常処理中と障害対応時に、各 Service に割り当て

られる処理リソースを制御します。Service に接続しているユーザーには、クラス

タ間で自動的にロード・バランシングが実行されます。たとえば、異なるビジネ

ス優先順位の複数バッチ処理によるワークロードを使用できます。優先順位の高

いワークロードは、大量の処理リソースに割り当てられます。優先順位が変更さ

れると、ビジネス・ニーズを満たすためにリソースの割当てが変化します。障害

が発生した場合、必要に応じて優先順位の高いワークロードを優先順位の低いリ

ソースと置き換えることができます。

Oracle Database 11g の汎用機能である Services は、単一インスタンスおよび Oracle RAC の配置に使用できます。Oracle RAC を配置すると、Services の完全な機能が

わかります。Services によって、異なる時間に異なる Services に割り当てられるク

ラスタのノードを制御できます。これによって、処理リソースがアプリケーショ

ン・ワークロードに適用される方法を制御して、ビジネスの優先順位を満たすき

わめて有効なメカニズムが提供されます。

Services を使用する場合、IBM DB2 と同様に、ピークを考慮して割り当てるので

はなく、実際の使用に基づいてすべてのサーバー間でアプリケーションのロード

を均等に分散できます。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

12

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 13: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

パフォーマンス管理およびチューニング

一度エンタープライズ・グリッド・コンピューティング・インフラストラクチャ

を配置すると、インフラストラクチャによるアプリケーションのサービス・レベ

ル目標の達成を維持するために、エンドツーエンドのパフォーマンス管理と自己

チューニングが重要になります。これには、高度な自動化が必要です。

Oracle Database 11g では、Automatic Database Diagnostics Monitor(ADDM)、

Automatic Workload Repository(AWR)、Oracle Enterprise Manager などのツールを

使用して、この自動化を実現できます。Oracle Database 11g に組み込まれたサー

バー生成アラート、Oracle Enterprise Manager の伝播フレームワーク、およびブラ

ウザ・ベースのインタフェースによって、システム・パフォーマンスの問題とデー

タベースのメンテナンス・タスクを管理する基盤が提供されます。Oracle Database 11g が提供するさまざまな自己管理構想は、Oracle システムの自動化を支援するこ

とで、手動での介入を軽減し、コストを削減し、サービス品質を向上します。

Oracle Database 11g を使用する場合、チューニングは Service および SQL に基づき

ます。この手法には、それぞれのビジネス・プロセスをデータベース・サービス

として実装し、それらの各ワークロードを自動的に単独で測定できる利点があり

ます。また、ビジネス・トランザクションによるリソース消費が測定可能になり、

重要度に応じてそのワークロードの優先順位付けができます。

Oracle Database 11g アドバイザ

グリッド環境での自己チューニング機能は重要です。グリッド内のすべてのコン

ポーネントを統合するには、高度な自動化が必要になります。この高度な自動化

は、Oracle Database 11g の各種アドバイザによってサポートされます。

アドバイザはサーバー中心のモジュールであり、特定のデータベース・サブコン

ポーネントのリソース使用とパフォーマンスを改善するための推奨事項を提供し

ます。アドバイザは、発生している問題に関連するコンテキスト・センシティブ

な必須情報を DBA に提供します。これらは、アラート機構を補完するものです。

アドバイザは、推奨事項を生成するために、現在のメモリー上のデータだけでは

なく、履歴データを参照する場合があります。アドバイザが提供するチューニン

グ情報はきわめて重要であり、別の方法では取得できません。

SQL Tuning、SQL Access、Memory、Undo、Segment などのパフォーマンス・アド

バイザは、システムのボトルネックを識別し、解決のための特定の領域に関する

チューニング・アドバイスを得るために不可欠です。SQL アドバイザは、SQL 文

のチューニングに役立ちます。

対照的に、IBM DB2 v9.5 は、独自のパフォーマンスの評価、問題の根本原因の識

別、およびソリューションの推奨を行う自己診断コンポーネントがありません。

パフォーマンス監視用に IBM DB2 v9.5 が提供する機能は、問題の症状が検出され

るたびに DBA に通知するヘルス・モニター・アラートのみです。これらのアラー

トには、特定の問題を解決する方法に関する推奨事項があります。ただし、これ

らのすべての症状を調査して問題の根本原因を識別するインフラストラクチャは

ありません。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

13

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 14: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

IBM DB2 Design Advisor

IBM DB2 v8 の新機能の Design Advisor は、パフォーマンスの問題の根本原因分析

と自己チューニング・メカニズムを提供するには不十分です。Design Advisor は、

データベースを作成する場合またはパーティション化されていない DB2 データ

ベースからパーティション化されている DB2 データベースに移行する場合に、

データをパーティション化する方法に関する推奨事項とアドバイスを提供します。

アドバイザリに関係なく、DBA がこの複雑な作業を手動で実行する必要がありま

す。Design Advisor の推奨事項では、データの偏りやホット・スポットを防止する

ために調整を必要とする場合もあります。

高可用性

可用性の高いグリッド環境設計の課題の 1 つに、停止時間のあらゆる潜在的な原

因の対処があります。フォルト・トレラントでリジリエンスを備えた IT インフラ

ストラクチャを設計する場合、計画外停止時間と計画停止時間の原因を考慮する

ことは重要です。

計画外停止時間

計画外停止時間は、おもにコンピュータ(ハードウェア)障害またはデータ障害

のいずれかに起因します。Oracle Database 11g は、可能性のあるストレージ障害、

人的エラー、破損、およびサイト障害によるデータ障害からの保護を実現します。

Oracle RAC 11g によって、企業は、高い可用性とスケーラビリティを備えた複数

のシステムにまたがったデータベース・サーバーで構成されるグリッド・インフ

ラストラクチャを構築できます。クラスタの 1 つ以上のノードで障害が発生した

場合、Oracle RAC 11g を使用すると、存続しているクラスタ・ノードで処理を続

行できます。これによって、システムを使用できなくなることを防止する透過的

な保護を実現します。システムがクラッシュした場合、Oracle RAC 11g は、1 つ

のノード以外のすべてが停止しても、データベース・サービスを継続して提供し

ます。

Oracle Database 11g Automatic Storage Management

Oracle Database 11g Automatic Storage Management(Oracle ASM)によって、ストレー

ジ障害から保護するネイティブ・ミラー化メカニズムが提供されます。デフォル

トで、ミラー化は有効です。また、三重のミラー化も使用できます。Oracle ASMのミラー化を使用すると、障害グループの使用によって追加レベルのデータ保護

を提供できます。障害グループは、ディスク・コントローラまたはディスク・ア

レイ全体などの一般的なリソースを共有する一連のディスクです。Oracle ASMは、

個別の障害グループにデータの冗長なコピーを配置して、ストレージ・サブシス

テムのコンポーネントの障害からデータを透過的に保護して使用可能な状態に維

持します。また、破損からデータを保護する Hardware Assisted Resilient Data(HARD)機能をサポートします。

IBM DB2 は、このタイプの保護を提供する基本となるオペレーティング・システ

ムまたは追加のソフトウェアに依存します。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

14

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 15: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

ファスト・スタート障害リカバリ

ファスト・スタート障害リカバリの場合、Oracle Database 11g は、チェックポイン

ト処理を自動調整し、目標とされるリカバリ時間を守ります。Oracle のファスト・

スタート障害リカバリ機能は、高負荷のデータベースのリカバリ時間を数 10 分か

ら 10 秒未満へと短縮できます。このため、リカバリ時間が短縮され予測可能にな

り、サービス・レベルの目標を達成する能力が向上します。また、Oracle Database 11g は、フラッシュバック・スイート機能を通じて人的エラーに対する追加の保

護を提供します。

Fast Connection Failover

Oracle RAC 11g には、高速で調整されたリカバリを実現する高可用性(HA)アプ

リケーション・フレームワークが含まれます。Oracle RAC 11g には、Oracle Application Server 11g と、Oracle JDBC、Oracle Data Provider for .NET、Oracle Call Interface などの他の統合クライアントと統合を構築する機能があります。

Oracle RAC 環境の適応性の高い通知システムである Fast Application Notification(FAN)は、適切な自己修正式のリカバリ手順を適用できるように、アプリケーショ

ンの中間層に直接 UP および DOWN 信号を送信します。これは、ネットワークの

呼出しの障害を検出するよりもはるかに効率的です。また、リカバリ時間が大幅

に削減されます。TCP タイムアウトを何分も待機することなく、アプリケーショ

ンは迅速に適切なリカバリ・アクションを実行できます。これによって、他の使

用できるサーバーにロードが分散されます。追加のリソースがクラスタに追加さ

れる場合(インスタンスが起動する場合)、UP 信号は新しい接続を使用できるの

で、追加されたリソースをアプリケーションで透過的に活用できます。

対照的に、IBM DB2 クラスタ環境では、障害が発生したパーティションに属する

ディスクを、存続しているノードの中のどれが引き継ぐかをクラスタ・マネージャ

(HACMP など)が決定します。ロードの偏りを回避するため、IBM DB2 は、存続

している各ノードが同じ量のデータの所有権を引き継ぐように構成する必要があ

ります。各ノードに複数のパーティションを作成すると、これが実現します。

IBM DB2 のパーティションはメモリーを共有しません。パーティションの数が増

加すると、メモリーの断片化も増加します。クラスタ環境の管理にこのタスクが

追加されます。また、特定のワークロードのプロセス間通信は、パーティション

の数とともに増加します。

ノードに障害が発生した場合の IBM DB2 では、存続しているノードのパーティ

ションをクラスタ・マネージャが再起動します。これには、IBM DB2 プロセスの

起動、共有メモリーの初期化、およびデータベース・ファイルのオープンが必要

になります。したがって、データベース・リカバリにさらに時間がかかります。

データベース・リカバリの後、アプリケーションは、IBM DB2 よりもはるかに高

速に Oracle RAC で元の応答時間を取得します。これは、アプリケーションに必要

なデータとパッケージが、存続しているノードにすでにキャッシュされている可

能性があるからです。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

15

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 16: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

計画停止時間

計画停止時間は、本番システムに適用する必要があるデータ変更またはシステム

変更におもに依存します。定期的なメンテナンスと新しい配置によってこれが実

行されます。グローバル企業の計画停止時間は、計画外停止時間と同程度の運用

の妨げになります。計画的な中断を最小限に抑えるシステムを設計することが重

要です。

停止時間ゼロのパッチ適用とアップグレード

Oracle Clusterware および Oracle ASM は、パッチ適用とアップグレード用のローリ

ング・アップグレードをサポートします。これらのリリースでは、クラスタのノー

ドへのアップグレードまたはパッチ適用をローリング方式で停止時間なく実行で

きます。Oracle RAC 環境では、新しいソフトウェアは 1 ノードごとに適用され、

その間、他のノードは稼働を続けます。クラスタのすべてのノードがパッチ適用

またはアップグレードされると、ローリング・アップグレードが完了してすべて

のノードが Oracle Clusterware または Oracle ASM ソフトウェアの同じバージョン

を実行します。また、パッチまたはアップグレードをアンインストールしたり、

クラスタ全体を停止することなくロールバックしたりできます。特定のデータ

ベース・パッチは、ローリング方式でも適用できます。Oracle は、ローリング・

アップグレードを適用できるデータベース・パッチを明記します。

Oracle Clusterware、Oracle ASM、および Oracle RAC は、オペレーティング・シス

テムの両方のリリースで Oracle Database のバージョンが認定される場合にオペ

レーティング・システムのローリング・アップグレードをサポートします。

データベース外部のクラスタリング

最近、IBM は、ミドルウェアで DB2 サーバーのクラスタを作成できるパートナと

連携したソリューションを発表しました。ミドルウェアは、クラスタのさまざま

なデータベースにデータをレプリケートします。次に、コピー間で問合せのバラ

ンスが取られます。障害が発生した場合、作業がコピーのいずれかにリダイレク

トされます。データベース外部のクラスタリングを実装する IBM パートナ・ソ

リューションには、Avokia apLive および xkoto GRIDSCALE が含まれます。

Oracle RAC は、Oracle Database のカーネルに統合されます。データベース外部の

クラスタリング・ソフトウェアを使用するソリューションは、各データベースの

内部処理を常に制御したり効率的に監視したりできません。この点が、データベー

ス内の同じような機能と比べると不利になります。

データベース外部のクラスタリング(アクティブ/アクティブ・クラスタリングと

も呼ばれます)は、特定の状況で利点があります。ただし、この手法はアーキテ

クチャとして欠点があります。このようなソリューションでは、レプリケーショ

ンを使用して冗長性および問合せの拡張のためにデータの複数のコピーを作成し

ます。これらのレプリカでは、各更新を何度も繰り返す必要があります。これに

よって、読取り集中型アプリケーション以外の総合的なスケーラビリティが低下

します。大規模なデータベースの場合、ディスク領域の観点から、データの冗長

なコピーの保存にはコストがかかります。また、データが非同期にレプリケート

される場合、トランザクションの待機時間が問題になります。一部のアプリケー

ションが陳腐化したデータを読取る可能性があります。これらのクラスタを統合

するミドルウェア・コントローラは、複数のコピーが配置されない限りシングル・

ポイント障害になります。このため、より複雑になって追加のリソースが使用さ

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

16

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 17: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

れます。

これらのソリューションはサード・パーティのソリューションなので、このホワ

イト・ペーパーで詳細を説明することはありません。参考資料のホワイト・ペー

パー『Oracle Real Application Clusters vs. Active/Active Clustering』では、このよう

なサード・パーティのクラスタリング・ソリューションが詳細に説明され、この

アプローチと Oracle RAC のクラスタ化されたデータベース・ソリューションが比

較されています。

機能比較マトリックスのまとめ

カテゴリ Oracle Real Application Clusters 11g

IBM DB2 v9.5

アーキテクチャ 共有キャッシュ シェアード・ナッシング - データ

がパーティション化されます - DBA や開発者はパーティション

化スキームを十分に理解する必

要があります。

単一ノードからク

ラスタへの移行 Oracle Database 11g - Oracle Enterprise Manager 機能によって

簡単に実行できます。

複雑 - データをアンロードおよ

びリロードしてパーティション

化スキームを確立する必要があ

ります。

パフォーマンスの

維持、 バランスの取れた

ワークロード

Automatic Workload Manager や

Runtime Connection Load Balancingなどの機能によって自動的に行

われます。

パーティション化スキームに対

するワークロードを評価して変

更に基づき再調整するには、手作

業が必要です。

ノードの追加 - スケールアウト

Oracle RAC は、追加の容量をデー

タベース・リソースのプールに自

動的に組み込みます。

手動の再パーティション化には、

データベースの停止または中断

が必要です。

パフォーマンス:

OLTP コミットされたトランザクショ

ンによってノードのログが強制

されます。他のノードから転送さ

れたトランザクションに必要な

データを含むブロック - ディス

ク I/O は必要ありません。

すべてのノード間の 2 フェーズ・

コミットが必要になります。少な

くとも 2 つのログ強制書込みと 1つのラウンドトリップ・メッセー

ジを待機します。

パフォーマンス:

データ・ ウェアハウス

データ・ウェアハウスのロードを

評価し、ノード間通信を最小限に

抑えてノード間のパラレル問合せ

作業を最大限に利用するために

インテリジェントに分散します。

パーティション化スキームに

よって決定されるパラレル処理

を実行すると、パーティション化

スキームによってリソースの使

用が過剰/不十分になります。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

17

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 18: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

ワークロード管理 Runtime Connection Load Balancingの作業は、現在のクラスタ・アク

ティビティに基づく最適な応答

時間を提供できるノードに自動

的にルーティングされます。

トランザクションは、パーティ

ション化スキームに基づいて

ルーティングされます。このた

め、柔軟性が低く、バランスの取

れていない環境になる可能性が

あります。

高可用性 共有キャッシュのアクティブ/アクティブ・アーキテクチャによっ

て、クラスタの単一ノードが稼働

している限り処理が続行されます。

Oracle Automatic Storage Managementによって、データのミラー化が可

能です。

クラスタ・ノードが停止すると、

スタンバイが起動してアクティ

ブになるまで、データベース・ア

クティビティは、データがその

ノードにパーティション化され

る間停止します。オペレーティン

グ・システムまたは追加のソフト

ウェアを使用して、ミラー化を実

現します。

計画停止時間 クラスタ・ノードにローリング・

パッチおよびアップグレード

(Oracle Clusterware および Oracle ASM)を適用する機能によって最

小限に抑えられます。 - クラスタ

全体は停止しません。

パーティション化またはパッチ

の変更に計画停止が必要です。

結論

Oracle RAC 11g と比較すると、IBM DB2 v9.5 にはエンタープライズ・グリッド環

境の配置、パフォーマンス、および管理で多くの欠点があります。

IBM DB2 は、シェアード・ナッシング・ソリューションの多くの実装の負荷をユー

ザーに課しています。対照的に、共有キャッシュ・アーキテクチャを備えた Oracle RAC 11g は、エンタープライズ・グリッド・コンピューティング・インフラスト

ラクチャの配置および管理におもな利点があります。IBM DB2 v9 と比較すると、

Oracle RAC 11g は以下の機能を提供します。

すべてのタイプのアプリケーションに対する柔軟なスケーラビリティ

より高い可用性ソリューション

単一の自動管理エンティティ

総所有コストの削減

IBM DB2 v9.5 と比較すると、Oracle RAC 11g は、より統合されて優れた機能を備

えた製品です。また、グリッド・コンピューティングの利点を得るソリューショ

ンを容易に配置および管理します。

Oracle Real Application Clusters 11g と IBM DB2 v9.5(Linux、Unix、Windows 向け)の技術比較

18

Oracle Corporation 発行「Technical Comparison of Oracle Real Application Clusters 11g vs.IBM DB2 v9.5」の翻訳版です。

Page 19: Oracle Real Application Clusters 11gとIBM DB2 v9.5(Linux ... · Oracle Databaseは、革新的なデータベース・テクノロジのリーダーシップを維持 して、競合他社との差を拡大しています。

ホワイト・ペーパー・タイトル:Oracle Real Application Clusters 11g と IBM DB2 v9.5 の技術の比較 2008 年 1 月 著者:Bob Thome、Barb Lundhild、Zahra Afrookhteh、Randy Hietter バージョン 2.2 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 © 2008, Oracle. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容

は予告なく変更されることがあります。本文書は一切間違いがないことを保

証するものではなく、さらに、口述による明示または法律による黙示を問わ

ず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含

み、いかなる他の保証や条件も提供するものではありません。オラクル社は

本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的ま

たは間接的に確立される契約義務はないものとします。本文書はオラクル社

の書面による許可を前もって得ることなく、いかなる目的のためにも、電子

または印刷を含むいかなる形式や手段によっても再作成または送信すること

はできません。Oracle、JD Edwards、および PeopleSoft は、米国 Oracle Corporation およびその子会社、関連会社の登録商標です。その他の名称はそ

れぞれの会社の商標です。