Oracle Database 10gとIBM DB2 UDB v8.2:高可用性分野での技術比較

Oracle Database 10g と IBM

DB2 UDB v8.2 :高可用性分野

での技術比較

オラクル・ホワイト・ペーパー

Oracle Database 10g と IBM DB2 UDB v8.2 :高可用性

分野での技術比較

概要 ... 3

はじめに ... 3

計画外停止と計画停止 ... 4

概要: Oracle の高可用性ソリューション... 4

計画外停止の最小化... 5

計画停止の最小化... 6

HA に関する比較事項: Oracle と DB2 ... 6

ORACLE と DB2 – 計画外停止への対応 ... 10

システム障害への対応... 10

Fast Start Fault Recovery ... 10

実際のクラスタリングでの耐障害性の強化 ... 12

データ障害への対応... 15

包括的なバックアップ機能とリカバリ機能 ... 16

パーティション化によるメンテナンスの削減と障害の分離... 19

ASM – 統合化されたデータのミラー化... 20

エンドツーエンドのデータ整合性 ... 20

障害時リカバリへの対応... 21

Oracle Data Guard ... 21

DB2 HADR ... 21

DB2 – 以前のリリースの機能... 21

v8.2 HADR と v8.1 ログ・シッピングの相違点 ... 22

Data Guard: 長所の比較... 22

人為的エラーへの対応... 31

データベース・リカバリ ... 31

トランザクション・リカバリ ... 32

Point-in-Time リカバリ... 32

ORACLE と DB2 – 計画停止への対応 ... 35

システム・メンテナンスへの対応 ... 35

クラスタ・ノードの追加 ... 35

オンラインでのディスクの追加または削除 ... 36

メモリーの構成 ... 36

パラメータの構成 ... 37

データ・メンテナンスへの対応 ... 37

スケーラブルなメンテナンス ... 37

オンラインでのデータ再定義とデータ再編成... 38

高可用性のベスト・プラクティス... 40

高可用性を実現した顧客 ... 41

まとめ ... 43

参照 ... 44

Oracle Database 10g と IBM DB2 UDB v8.2 :高可用性

分野での技術比較

概要

今日のビジネスは、データベースに大きく依存しています。アプリケーションや データが使用不可能になると、ビジネス全体が中断してしまいます。利益や顧客 を失い、不利益を被ります。報道で悪評が立つと、顧客と株価には長期間の影響 がでます。実際、データ可用性を維持することは、今日のビジネスにとって不可 欠です。 Oracle Database 10g には、ビジネスに影響する様々な停止時間を最小限にすること により、組織のビジネス継続性を確保する高可用性（HA）機能を統合したセット が用意されています。これらの機能は、システム障害、データ障害、災害、人為 的エラー、システム保守作業、データ保守作業など、データが使用不可能になる シナリオのほとんどに対応しています。このホワイト・ペーパーに示すように、 IBM DB2 Universal Database（DB2 UDB）は高可用性とデータ保守の基本的な機能 を提供しますが、HA 機能の幅と深さという点では、複数のリリースにおいて Oracle が先行しています。 Oracle は、有名なグローバル企業におい て稼働しているミッション・クリティカ ルな高可用性エンタープライズ・アプリ ケーション・データベースです。

Oracle は、Merrill Lynch、Citigroup、Southwest Airlines、British Telecom、General Motors、 Best Buy、Lufthansa、Priceline、eBay および Amazon.com などの有名なグローバル 企業で稼働している、ミッション・クリティカルな高可用性エンタープライズ・ アプリケーション・データベースです。

はじめに

組織が企業データ用のデータベース・ソリューションを評価する場合は、データ ベースの高可用性についても評価する必要があります。データは、組織の最重要 ビジネス資産の 1 つです。企業のデータが使用できなくなったり保護されていな かったりすると、ビジネスの停止時間によって何百万ドルもの損失が生じたり、 不評を被る可能性があります。現在の激変する経済環境で、企業が成功し健全な 状態を維持するには、高可用性インフラストラクチャの構築が不可欠です。 このホワイト・ペーパーでは、市場における 2 つの主導的なデータベース・ソ リューション、Oracle Database 10g Release 2 と IBM DB2 Universal Database（DB2 UDB）バージョン 8.2 で利用可能な、HA 機能を詳細に比較し評価します。このホ ワイト・ペーパーが対象とするのは、これら 2 つのデータベースのビジネス利用 を評価しようとする IT 管理者、設計者および管理職、これらのデータベースの HA 機能がどの程度データやビジネス継続性を保持できるかに興味のある読者で す。

計画外停止と計画停止

高可用性の IT インフラストラクチャを設計する場合の課題の 1 つは、考えられる あらゆる停止時間の原因を調べて解消することです。停止時間は、計画外停止と 計画停止の 2 つに分類されます。IT 企業が耐障害性と障害回復力がある IT インフ ラストラクチャを設計する場合、計画外停止と計画停止両方の要因を考慮する必 要があります。 計画外停止は、主にコンピュータ障害またはデータ障害（人為的エラー、災害、 データ破損など）に起因します。このような障害は頻繁に発生しないかもしれま せんが、障害が発生すると通常業務に大きな悪影響を与えるため停止時間コスト が高くなります。これに対して計画停止は、スケジュールされたメンテナンス操 作（データ変更、システムのアップグレードなど）であるため、どのようなデー タ・センターでも通常操作の一部として行われます。この場合、メンテナンス操 作を可能な限り透過的に行うことによって、通常業務が中断する可能性を最小限 に留める必要があります。 ビジネス要件を満たす高可用性ソリューションに関心がある IT マネージャは、次 のような基準に基づいてソリューションを評価する必要があります。 • 様々な停止時間の原因に対処できる包括的な HA 機能 • 変化するビジネス要件にこれらのソリューションの適用、管理が容易で ある • 業務に効率的に使用し投資の回収を最大限にするために、冗長コンポー ネントを利用する能力 個別の技術セットで構成された HA 問題に対するソリューションは、統合された ものではなく孤立した方法であり、多くの冗長性があるものの基本的にアイドル 状態のコンポーネント群になるため、今日の企業の HA 要件を満たせません。以 降の各セクションでは、こうした視点から IBM と Oracle のデータベースを HA に 基づいて評価します。

概要: Oracle の高可用性ソリューション

Oracle Database 10g（図 1 を参照）には、ビジネスに影響する様々な停止時間を最 小限に抑える高可用性（HA）機能の統合されたセットが用意されています。次の いくつかのセクションでは、これらの機能の概要を説明します。各機能の詳細は、 [1]および[2]を参照してください。

Oracle Database 10g には、ビジネスに影 響する様々な停止時間を最小限に抑える 高可用性（HA）機能を統合したセットが 用意されています。 図 1: Oracle Database 10g の統合化された高可用性機能

計画外停止の最小化

Oracle では、クラスタ環境下の複数のサーバーが単一の Oracle データベースにア クセスできる Real Application Clusters（RAC）を提供することで、サーバー障害を 防止します。このようなアプローチの利点は、アプリケーションのコード変更を 行わずに拡張性と高可用性が得られることです。 たとえば、Oracle データベースはストレージ障害、人為的エラー、破損およびサ イト障害など、様々なデータ障害からの保護のための機能一式を提供します。そ の中に、Oracle に対して統合ボリューム・マネージャ機能を提供する Automatic Storage Management（ASM）があります。ASM は、データベース・ファイルのネ イティブなミラー化により保護機能を追加します。Oracle データベースでは、人 為的エラーからの保護に、フラッシュバック機能一式（フラッシュバック・デー タベース、フラッシュバック表など）を提供します。これは、データベースの状 態をきわめて容易に既知の安全な時点に巻き戻し、人為的エラーの影響を短時間 で元に戻します。 また様々なメディア障害からのデータの保護に、Oracle データベースは、包括的 なバックアップ、リストアおよびリカバリを行う Recovery Manager（RMAN）を 提供します。RMAN を使用すると、高コストとなる停止時間を発生させずに、 Oracle データベースのバックアップをオンラインで実行できます。さらに、Oracle Database 10g のフラッシュ・リカバリ領域は、統一されたディスク・ベースのスト レージであり、Oracle データベース内のすべてのリカバリ関連ファイルとアク ティビティを格納します。RMAN とフラッシュ・リカバリ領域との間を自動化お よび統合することにより、拡張ディスク・ベースのバックアップとリカバリ・ソ リューションを Oracle Database 10g に統合できます。これにより管理者は、表領 域、データ・ファイルおよびデータ・ブロックなどのレベルにおいても、Oracle データベースのバックアップおよびリストアを超高速で実行できるため、メンテ ナンス時間を大幅に短縮できます。 Oracle では、データを破損からエンドツーエンドで保護するために、データ破損 を未然に防止する Hardware Assisted Resilient Data（HARD）機能を提供します。こ の機能を使用すると、選択したストレージ・パートナーからストレージ・デバイ ス内に Oracle のデータ妥当性チェック・アルゴリズムを実装することにより、破

損データの永続ストレージ上のデータベース・ファイルへの書込みを防止します。

最後に、火事、地震、台風、犯罪など、地域的または局所的な災害によるサイト 障害やストレージ障害からの保護には、Oracle は Data Guard を提供します。Data Guard 構成では、複数のスタンドバイ状態のデータベースがネットワーク経由で 実働データベースまたはプライマリ・データベースに接続されます。Data Guard は、プライマリ・データ・センターでの不測の災害などのイベント発生時にスタ ンバイ・データベースとプライマリ・データベースのトランザクションの一貫性 を保つため、処理をスタンバイ・データベースの 1 つに容易に切り替えることが できます。Data Guard では、このプロセスでデータが消失しないように設定でき ます。また、スタンバイ・データベースをレポートやバックアップなどの作業に 利用できます。

計画停止の最小化

ルーチン操作、定期メンテナンスおよび新規デプロイメントなどによる計画停止 でも、業務の中断に他なりません。特に、これは、異なるタイムゾーンに属する ユーザーをサポートするグローバル企業では問題です。Oracle データベースでは、 計画外停止を最小化すると同時に、計画停止を排除または最小化する機能スイー トを提供します。 Oracle データベースのオンライン再定義機能を使用すると、データベース運用ま たはユーザーによるデータ更新やデータ・アクセスを中断せずに、様々なデータ・ メンテナンス作業を実行できます。たとえば、表タイプの変更、列の追加、削除 または名前変更およびストレージ・パラメータの変更などの表の再定義は、基盤 となるデータの表示または更新などのエンド・ユーザー操作を中断せずに実行で きます。ローリング・アップグレード機能では、Data Guard SQL Apply を使用し てデータベース・パッチセットまたはメジャー・リリース（Oracle Database 10g Release 1 以降）のアップグレードをローリング方式で実行できるため、アプリケー ションの停止時間を最短化できます。最後に、Oracle データベースは、動的なハー ドウェア構成の変更に対応しています。たとえば、SMP サーバーからのプロセッ サの追加および削除、RAC クラスタのノードの追加および削除、共有メモリ割当 ての動的な拡張および縮小などに加えて、データベース・アクティビティを中断 せずにオンラインでデータベース・ディスクを追加および削除できます。

HA に関する比較事項: Oracle と DB2

IBM DB2 は、最新のバージョン 8.2 リリースでも、深く幅広い Oracle の高可用性 機能にはおよびません。このホワイト・ペーパーでは、Oracle Database と IBM DB2

UDB1の高可用性の特性を取り上げて、それぞれの取組みを比較します。この分析 によれば、最新の DB2 バージョン 8.2 リリースは、高可用性に関し技術的および 構造的な欠点を補うための IBM の試みです。この点において依然として、DB2 は、 明らかに Oracle から大きく遅れています。 1 _{IBMはDB2 UDBを単一の製品として販売していますが、実際には、まったく異なる機能を持つ3つの} コード・ベースです。このホワイト・ペーパーでは、特に指定しない限り、すべてDB2 UDBのUnix/Windows バージョンを意味します。

このホワイト・ペーパーの残りの部分では、Oracle とは Oracle Database 10g Release 2 Enterprise Edition を指し、特に指定がない限り、DB2 は IBM DB2 Universal Database Enterprise Server Edition（DB2 ESE）バージョン 8.2 を指します。 次の表に、Oracle と DB2 の停止時間の主な違いを各カテゴリに分けて、わかりや すく示します。これらの違いについては、以降のセクションで詳しく説明します。 表 1: 主要な高可用性の違い − Oracle と DB2 システム障害への対応 Oracle DB2 リカバリ時間の予測 あり なし リカバリのアドバイス あり なし ロールバック中のデータ可用性 あり なし クラスタリングによる透過的なアプリケーションの拡張性 あり なし 高コストの 2 フェーズ・コミットによる書込みでのオーバーヘッド の回避 あり なし すべてのノードへの高コストの同報通信による問合せの回避 あり なし ノードにキャッシュされたデータの利用によるディスク・アクセス の回避 あり なし 問合せのパフォーマンスはパーティション内のデータの偏りによる 影響を受けない あり なし ノード障害後のロード・バランシング あり なし 統合されたクラスタウェア あり なし 自動ワークロード管理 あり なし 中間層接続の高速フェイルオーバー あり なし データ障害への対応 Oracle DB2 包括的なバックアップおよびリカバリ用ツール あり なし 集中管理リポジトリに保存されるバックアップ情報 あり なし ディスク上のリカバリ関連ファイルの自動管理 あり なし 事前定義されたバックアップ方針 あり なし 増分更新バックアップ あり なし リカバリ中の自動データ・ファイル作成 あり なし リストアするファイルのプレビュー あり なし 破損または紛失したバックアップからのリストアが可能 あり なし バックアップの妥当性チェック あり なし 悪影響を与えないスプリット化されたミラーリング あり なし ブロックレベル・メディア・リカバリ あり なし 読込み専用表領域 あり なし 再利用可能なバックアップとリストア あり なし LOB の増分バックアップ あり なし

レンジ/リストのパーティション化 あり なし 情報ライフサイクル管理（ILM）の固有サポート あり なし ローリング・ウィンドウのデータ管理 あり なし グローバル・パーティション索引 あり なし 統合されたミラーリング あり なし 破損を防止するストレージ・レベルでの統合 あり なし 障害時リカバリへの対応 Oracle DB2 読込み/書込みおよびレポートを行う継続的なオープン・スタンバイ あり なし 統合化された自動フェイルオーバー あり なし 古いプライマリの統合化された自動回復 あり なし スタンバイ・データベースを読込み専用としてオープンする機能 あり なし 読込み/書込みデータベースとスタンバイ・データベース間のシーム レスな相互変換 あり なし スタンバイ状態でのバックアップ実行機能 あり なし 人為的エラー（適用遅延またはフラッシュバック・データベースに よる）に起因するデータ破損の防止 あり なし クラスタリングのサポート あり なし プライマリに影響しない非同期ログ・データの転送 あり なし 同一構成内の複数スタンバイ あり なし 柔軟なログ・データの転送 あり なし 透過的ですぐ使えるログ・ギャップの解消 あり なし 増分バックアップによるログ・ギャップの解消 あり なし データベースのメジャー・リリース間のローリング・アップグレー ド あり なし 関連パラメータの動的再構成 あり なし フェイルオーバー後にプライマリを再作成する必要がない あり なし すべてのケースにおけるアプリケーションの接続時フェイルオー バー あり なし ストアド・プロシージャのレプリケーション あり なし 組込みの認証/暗号化 あり なし RAW デバイスのサポート あり なし カスケード・スタンバイ あり なし 無制限の CLOB/BLOB レプリケーション あり なし 人為的エラーへの対応 Oracle DB2 SQL 問合せを使用した過去データの取得 あり なし ごみ箱(recycle bin) あり なし トランザクション・レベルでのデータベースの変更の確認 あり なし 行バージョン間の変更表示 あり なし

SQL インタフェースを使用したログのマイニングと監査の変更 あり なし トライアル・リカバリ あり なし Point-in-Time リカバリ中の問合せ あり なし 表領域の柔軟な Point-in-Time リカバリ あり なし 過去の Point-in-Time への表のフラッシュバック あり なし バックアップのリストアを行わずに以前の時点にデータベースをフ ラッシュバックできる あり なし システム・メンテナンスへの対応 Oracle DB2 オンラインでのクラスタへのノード追加 あり なし オンラインでのディスクの追加または削除 あり なし オンラインでのメモリー調整の拡張サポート あり なし メモリー管理に関する有用なアドバイス あり なし ほとんどの構成パラメータをオンラインで変更可能 あり なし データ・メンテナンスへの対応 Oracle DB2 ローリング・ウィンドウを使用したスケーラブルなデータ・メンテ ナンス あり なし 再開可能領域割当て あり なし ロックを使用せずに一貫性を保持した表のエクスポート あり なし オンラインでの表のロード あり なし 個別の索引の再編成 あり なし オンラインでの列の追加、名前の変更、マージ あり なし オンライン再定義機能の拡張セット あり なし

ORACLE と DB2 – 計画外停止への対応

システム障害への対応

システム障害は、ハードウェア障害、電源障害、およびオペレーティング・シス テムまたはサーバーのクラシッシュにより発生します。このような障害による運 用中断の規模は、影響を受けるユーザーの数とサービスを復旧するまでの時間で 決まります。システム障害への対応では、素早いリカバリの確保、またさらには、 高レベルの耐障害性が重要です。 次の表に示すように、Oracle は、効果的にシステム障害に対処する点において、 DB2 と明確に差別化する一連の機能を提供します。 表 2: システム障害への対応 − Oracle と DB2 システム障害への対応 Oracle DB2 リカバリ時間の予測 あり なし リカバリのアドバイス あり なし ロールバック中のデータ可用性 あり なし クラスタリングによる透過的なアプリケーションの拡張性 あり なし 高コストの 2 フェーズ・コミットによる書込みでのオーバーヘッド の回避 あり なし すべてのノードに対する高コストの同報通信問合せの回避 あり なし ノードにキャッシュされたデータ利用によるディスク・アクセスの 回避 あり なし 問合せのパフォーマンスはパーティション内のデータ偏りによる影 響を受けない あり なし ノードの障害後のロード・バランシング あり なし 統合クラスタウェア あり なし 自動ワークロード管理 あり なし

Fast mid-tier connection failover あり なし

次の項では、これらの相違点を詳細に説明します。

Fast Start Fault Recovery

Oracle Fast-Start™ Fault Recovery スキームは、システム障害に関連する停止時間を 最小限に留めるように設計されています。これには、2 つのコンポーネントがあ ります。まず、Fast Start Checkpointing は、継続的および増分としてチェックポイ ントを繰上げることでロールフォワード・リカバリを最適化します。また、Fast Start Rollback は、リカバリのロールバック・フェーズに関連する遅延を削減しま す。 ファスト・スタート・チェックポイント − 平均リカバリ時間の予測 システム障害からのリカバリ時間を制御するために、Oracle では、動的パラメー タ FAST_START_MTTR_TARGET により直接平均リカバリ時間（MTTR）を指定し ます。Oracle では、継続的にリカバリ時間を推測し、自動的にチェックポイント・ Oracle では、動的パラメータにより直接 平均リカバリ時間（MTTR）を指定しま す。

レートとターゲットのリカバリ時間が一致するように調整します[3]。DB2 は、リ カバリ時間を効果的に予測または制御します。DB2 では、チェックポイント間に 入力されるリカバリ・ログ・ファイルのパーセンテージは、static な SOFTMAX パ ラメータが制御します。次に DBA は、これを実際のリカバリ時間に換算する方法 を推測します。 頻繁なチェックポイントにより追加オーバーヘッドが生じるため、Oracle では、 動的ビューv$instance_recovery を通じてターゲットの MTTR のコストをリ アルタイムにフィードバックし、Oracle Enterprise Manager を通じて GUI ベースの アドバイスを提供します。DB2 を使用すると、SOFTMAX パラメータの調整に必要 な実行時コストを判断できます。 また Oracle では、v$mttr_target_advice ビューでアドバイスを提供し、これ により一連のリカバリ・シナリオのコストをシミュレートします。このシミュレー ションは、現在の実働ワークロードに基づいてリアルタイムで実行されます。管 理者は、アドバイスの出力に基づいて、非常に高速なリカバリ時間と追加 I/O オー バーヘッド間で最良のトレードオフを選択できます。これにより、高速なリカバ リの構成を予測し、リスクを考慮します。 DB2 には、表領域のロールフォワード・リカバリに不要なリカバリ・ログ・ファ イルをスキップする機能があります。しかし、Fast-Start™ Fault Recovery が提供す る包括的で豊富な機能にはおよびません。 ファスト・スタート・ロールバック − 最悪ケースでのリカバリ時間の短縮化 Oracle のクラッシュ・リカバリ時間は、ロング・トランザクションに影響されま せん。Oracle では、独自のオンデマンド・ロールバック技術により、インスタン スのリカバリ・ロールバック操作が完了しなくても、ユーザーがデータベースに アクセスできるからです。Oracle では、ロールフォワード処理が完了すると、デー タベースがオープンになりユーザーがアクセス可能です。DB2 とは異なり、Oracle ではすべてのトランザクションのロールバック完了まで待機しません。そのかわ り、新しいユーザーのトランザクションがデータにアクセスする間、トランザク ションはバックグラウンドでロールバックされます。このような新しいユーザー のトランザクションの 1 つが、デッド・トランザクションによりロックされたデー タに遭遇すると、このユーザー・トランザクションは、デッド・トランザクショ ンによって行われたデータの変更を直ちにロールバックして続行されます。 Oracle のクラッシュ・リカバリ時間は、 ロング・トランザクションの影響を受け ません。これに対して、DB2 のクラッ シュ・リカバリは、ロング・トランザク ションの影響を大きく受けます。 これに対して、DB2 のクラッシュ・リカバリは、ロング・トランザクションの影 響を大きく受けます。DB2 は、すべてのアクティブなトランザクションのロール バックが完了するまでアクセスできないため、クラッシュ・リカバリ時間は最も 長い実行中のトランザクションに依存します。さらに、DB2 は非コミット・トラ ンザクションを含むログに切り替えることができないため、リカバリ時間はロン グ・トランザクションによって長引きます。 クラッシュ・リカバリの詳細は、[4]を参照してください。

実際のクラスタリングでの耐障害性の強化

Oracle と DB2 は、どちらもクラスタ化されたデータベース・ソリューションを提 供します。Oracle は、共有キャッシュ・クラスタ・ソリューションである Real Application Clusters（RAC）を提供します。DB2 は、Database Partitioning Feature（DPF） によってシェアード・ナッシング・クラスタ化データベースを提供します。DPF は、DB2 Universal Database Enterprise Server Edition の上位オプションとして使用で きます。DB2 のクラスタ化モデルは、このデータ・パーティション化機能に依存 します。DB2 クラスタの各ノードは、1 つまたは複数のデータベース・パーティ ションを格納します。 予想外のノード障害などのイベントが発生すると、RAC と DB2/DPF の両方とも 透過的にデータベースをリカバリできます。ただし、前述および次の機能により、 リカバリ時間は RAC の方が高速です。 「私たちは、重要なアプリケーションの高 可 用 性 を 保 証 す る Oracle9i Real Application Clustersを選択しましたが、 パフォーマンスの増加に伴い、Oracleの クラスタリング技術に切り替えるに足る 理由があると確信しました。」 – John Kerin、シカゴ株式取引所技術主任 • DB2 は、クラスタ・マネージャのみを使用して障害が発生していないノー ドのパーティションを再起動します。このためには、DB2 プロセスを開 始し、共有メモリを初期化し、さらにデータベース・ファイルをオープ ンする必要があります。 • 今日の大規模なシステムでは、ギガバイトまたは数十ギガバイトのバッ ファ・キャッシュの使用は珍しくありません。この大きさのバッファ・ キャッシュのウォーミング・アップには、長時間かかります。Oracle Real Application Clusters では、ウォーム・キャッシュのあるインスタンスにフェ イルオーバーします。DB2/DPF のフェイルオーバーでは、常にコールド・ キャッシュで新しいインスタンスを初めから開始します。データベース のリカバリが完了すると、アプリケーションが必要とするデータおよび パッケージは障害が発生していないノードにキャッシュされているため、 RAC では、DB2/DPF に比較して高速な応答時間をアプリケーションが取 得できるようになります。 • DB2/DPF におけるこの欠点を補うため、IBM では、新しい DB2 v8.2 から High Availability Disaster Recovery（HADR）機能を搭載しています。これ

はフェイルオーバー操作（DB2 の用語ではテイクオーバー）を行う場合、 スタンバイ・データベースの再起動を必要としないため、スタンバイ・ データベースはフェイルオーバー中もホットであり続けます。このよう なスタンバイでは、RAC とは異なり、すべて最近変更されたバッファを 使用するため、最近読み込まれたバッファは使用しません。たとえば、 索引ブランチおよびルート・ブロックはキャッシュには含まれません。 これは、IBM Redbook ドキュメントの HADR [5]の説明にある次の文章に 反映されています。

フェイルオーバー直後のDB2のパフォーマンスは、フェイルオーバー直 前のパフォーマンスと同一ではありません。これはどの程度のキャッチ アップが必要かに依存します。起動時間は、DB2データベースを最初に 起動したときにアプリケーションが経験した起動時間と同じです。

ノード障害が発生すると、RAC では障害が発生した接続は、障害が発生していな いノード間に均等に分散されます。DB2/DPF では、基盤となるクラスタ・マネー ジャが、障害が発生したパーティションに属するディスクを障害の発生していな いどのノードが引き継ぐかを決定します。負荷の偏りを避けるために、障害の発 生していないノードが同一量のデータの所有権を持つように DB2/DPF を設定す る必要があります。これは、データベース内に複数の論理パーティションを作成 し、各ノードに同数のパーティションを割り当てることによって達成されます。 たとえば、4 つのノードがある場合、各ノードに 3 つのパーティションを作成し て合計 12 のパーティションを作成します[6]。n 個のノードがある場合、すべての 障害発生シナリオでは、障害が発生していないノードにパーティションを均等に 分散させるために、パーティションの数は n、n-1∼1 の公倍数の最も小さい値と 等しくなります。各パーティションには、クラスタ・ソフトウェア（HACMP、 MSCS など）を使用して、優先的な所有者またはテイクオーバー・リストが作成 されるため、ノード間でパーティションが均等に再分散されます。 高可用性構成では、ノード数の増加に伴ってパーティション数も急増します。こ れにより、操作上の問題が発生します。 • クラスタ管理に、より多くの作業が必要になります。各パーティション には、管理が必要な固有の設定パラメータ、データベース・ファイル、 および REDO ログがあります。 • 各物理ノードのリソースが活用されない場合があります。複数のパー ティションは同一の物理ノードが所有しますが、このパーティションは バッファ・プール、パッケージ・キャッシュなどとメモリーを共有でき ません。これにより、フラグメント化されたメモリーの一部を使用する かわりに 1 つのメモリーを活用できるため、リソースが活用されない場 合があります。 複数のパーティション間でデータ量と負 荷処理を再調整する場合、DB2 では管理 者 が 手 動 で Redistribute Database Partition ユーティリティを実行し、その 実行中にデータベースへのアクセスを低 減します。 • いくつかのパーティションで、負荷やデータの偏りが増加する可能性が 高まります。 DB2 は、複数のパーティション間でデータ量と処理負荷を再調整し、データ分散 の偏りに対処するために、必要に応じて手動で実行できる Redistribute Database Partition ユーティリティを提供します。これは、少なくとも 15 の個別の内部ステッ プ[7]からなる扱いにくいユーティリティですが、データベースの実行中にデータ ベースへのアクセスを低減しながら、内部で生成されたソースおよびターゲット のパーティショニング・マップを変更します。 さらに、DB2/DPF では、WHERE 句にパーティション化キーを指定しない問合せま たは更新のコストが、いくつかのパーティションでリニアに増加します。たとえ ば、顧客表が CustomerNumber をパーティション化キーとしてパーティション化さ れている場合、CustomerName による問合せは、パーティションのないシステムよ り、12 個にパーティション化されたシステムのほうが 12 倍コストがかかります。 つまり、問合せには 12 倍の CPU と 12 倍の I/O が必要になります。この驚くべき 事実は、DB2/DPF がパーティションを実装する方法に内在しています。各表には、 パーティション化キーが 1 つだけあります。パーティション化キーを指定する SQL 操作は、コーディネータ・ノードから正しいパーティションにルーティング されて実行されます。DB2 では、データを保持しているパーティションを知る方

法がないため[8]、[9]、パーティション化キーを指定しない SQL 操作は、すべて のパーティションに同報通信されます。 図 2 に、DB2 の構造的な欠点を示します。この場合、CustomerNumber がパーティ ション化キーであるため、これを含まない問合せはパフォーマンスと拡張性が不 足します。 図 2: DB2 のパーティション化機能の制限 IBM では、DB2/DPF の基本的な拡張性の問題を回避するため、すべてのノード間 で表をレプリケートするよう推奨する場合があります。たとえば、すべてのノー ド間の顧客表のレプリケートなどを推奨しています。これは、顧客表（およびそ の索引）が消費するディスク領域の量が、4 ノードのシステムでは 4 倍になり、 ノードの追加ごとに増加するため、スケーラブルで効率的なソリューションでは ありません。また、レプリケーションが実行された場合、すべての挿入、更新お よび削除がすべてのノードで実行されます。したがって、問合せは、更新時の大 規模な速度低下を引き換えとしてのみ高速化されます。さらに、どのノードが低 速化またはクラッシュしてもシステム全体の変更に影響があるため、高可用性は 得られません。

「 我 々 が Oracle Database と Real Application Clustersを選択したのは、そ れが、我が社の厳しいな稼働時間要件を 満たすことがわかっていたからで、まさ にその通りでした。」Oracleは、高可用 性のデータベース・サービスに対してス タンダードを提供し、重要なアプリケー ションの配置を簡単にしました。」 − Southwest Airlines社Operations for Interactive MarketingのSenior Manager、

Kerry Schwab氏 これらの理由から、IBM では適切なパーティション化キーの選択を強く推奨して います。ただし、これにも欠点があります。たとえば、データベースおよびアプ リケーションの設計が複雑なため、今日のデータベース管理者やアプリケーショ ン開発者は、（a）表へのアクセス方法、（b）問合せのワークロードの性質、お よび（c）データベース・システムで採用する結合方法を考慮する必要があります [8]、[9]。さらに不適切なパーティション化キーによりデータ分散が不均等になる ため、アプリケーションのパフォーマンスも不均等になります。最後に、各問合 せや更新は、パーティション化ハッシュ・アルゴリズムを使用して適用する必要 があるため、パーティション化キーのサイズにコストが比例し、問合せや更新の コストが増加します。 また、DB2/DPF では、所定のワークロードのプロセス間通信は、パーティション の数により増加します。たとえば、4 つの論理ノードに拡張されるアプリケーショ ンであっても、12 の論理ノードには拡張されない場合があります。ただし、高可 用性の点から、DB2/DPF は強制的に 12 のパーティションでアプリケーションを 実行します。

RAC はパーティション化が不要な共有ディスク・システムをベースにして、拡張 性や高可用性を得るため、Oracle では、このような設計上およびパフォーマンス 上の欠点の影響を受けません。さらに、Oracle Database 10g の RAC には、RAC と DB2 間のクラスタリング機能の格差をさらに広げる他の重要な拡張機能がありま す。

たとえば、RAC は、Oracle Database 10g を実行するすべてのプラットフォーム上 の完全な統合クラスタウェア管理ソリューションを提供します。クラスタウェア の機能には、クラスタの接続、メッセージ交換とロック、クラスタ管理とリカバ リ、ワークロード管理フレームワーク（後述）などのメカニズムが含まれます。 サード・パーティのクラスタウェア管理ソフトウェアの購入および統合は必要あ りません。一方、DB2 は、BM の別個のクラスタリング製品である HACMP と統 合する必要があります。

Oracle Database 10g の RAC には、RAC と DB2 間のクラスタリング機能の格差を さらに広げる他の重要な拡張機能があり ます。 RAC では、アプリケーション・ワークロードをサービスとして定義し、個別に管 理および制御できます。ルールを動的に定義して、処理中のリソースを自動的に サービスに割り当て、変化するビジネスや高可用性のニーズを満たすことができ ます。これらのルールは、たとえば、四半期末に変更して、重要な財務機能を遅 延なく完了できるだけの十分な処理リソースを確保できます。また、重要なサー ビスを実行するインスタンスが失敗した場合、比較的重要でないワークロードを 実行するインスタンスに自動的にワークロードを移行するよう、ルールを定義で きます。DB2 は、これと同等の機能を提供できません。

また、RAC では、Fast Application Notification 機能により、データベースとアプリ ケーション中間層の高速の調整式リカバリが可能です。適合力の高い通知システ ムを使用することにより、アプリケーションの中間層コンポーネント（JDBC、OCI、 ODP.NET）は、システム固有の TCP/IP タイムアウトを待たずに、1 つ以上のサー バー障害に素早く対応できます。Fast Application Notification 機能は、中間層のコ ネクション・プールから不要な接続をクリーン・アップし、アプリケーションの 作業要求に対して不要な接続や無効な接続が渡されることを防止し、障害が発生 したインスタンスでロールバック・トランザクションを起動し、インスタンス・ リカバリ時にはコネクション・プール・キャッシュ内の接続のロード・バランシ ングを開始します。DB2 では、このような統合化された通知メカニズムやリカバ リ・メカニズムをクラスタリング・ソリューションに提供していません。 Oracle では、DB2 が提供していないクラスタ診断機能も提供します。たとえば、 Oracle Database 10g Release 2 の Oracle Clusterware に含まれる Cluster Verification Utility は、クラスタ環境を構築する際の様々な段階でクラスタ構成に重要なすべ てのコンポーネントを確認します。この確認機能は、既存アプリケーションを変 更せずに、システム・オペレーションに影響を与えることなく実行できます。 詳細は、[10]を参照してください。

データ障害への対応

データおよびメディアの障害に対する保護および障害からのリカバリを可能にす るソリューションを設計することは、非常に重要です。システムまたはネットワー クの障害は、ユーザーのデータ・アクセスを阻害しますが、適切なバックアップ を行わない状態でメディアに障害が発生すると、データが失われてリカバリが不

能になります。 次の表に示すように、Oracle は、効果的にデータ障害に対処する方法において、 DB2 と明確に差別化する一連の機能を提供します。 表 3: データ障害への対応 − Oracle と DB2 データ障害への対応 Oracle DB2 包括的なバックアップおよびリカバリ用ツール あり なし 集中管理リポジトリに保存されるバックアップ情報 あり なし ディスク上のリカバリ関連ファイルの自動管理 あり なし 事前定義されたバックアップ方針 あり なし 増分更新バックアップ あり なし リカバリ中の自動データ・ファイル作成 あり なし リストアするファイルのプレビュー あり なし 破損または紛失したバックアップからのリストアが可能 あり なし バックアップの妥当性チェック あり なし 悪影響を与えないスプリット化ミラーリング あり なし ブロックレベル・メディア・リカバリ あり なし 読込み専用表領域 あり なし 再利用可能なバックアップとリストア あり なし LOB の増分バックアップ あり なし レンジ/リストのパーティション化 あり なし

Information Lifecycle Management（ILM）の固有サポート あり なし

ローリング・ウィンドウのデータ管理 あり なし グローバル・パーティション索引 あり なし 統合されたミラーリング あり なし 破損を防止するストレージ・レベルでの統合 あり なし 次の項では、これらの相違点を詳細に説明します。

包括的なバックアップ機能とリカバリ機能

Oracle も DB2 も、基本的なオンラインとオフラインのバックアップおよびリカバ リを実行できます。しかし、Oracle の広範なバックアップおよびリカバリ機能は、 DB2 が提供する基本的な機能を上回っています。これらの機能は、Oracle Recovery Manager（RMAN）によって統合されます。これは、データベースのバックアップ およびリカバリを自動化し管理する包括的なツールで、操作上の煩雑さを排除し、 データベースの最高のパフォーマンスと可用性を提供します。 「バックアップ障害が 90%以上削減され たのは言うまでもなく、サード・パーティ 製ソフトウェアを使用し続けるかわりに RMAN実装により、ライセンスとメンテ ナンスの費用を$500,000節約しました。 これは大きな成功です。」 – CSX Technology社、データ管理IT設 計者、Charles Pack RMAN は、バックアップ・メタデータをバックアップ・データベースの制御ファ イルまたはリカバリ・カタログに保存します。リカバリ・カタログなどのセント ラル・リポジトリを使用して、バックアップ情報の回復力を高めることで、バッ クアップ情報の問合せが容易になり管理ポイントが単一化されます。DB2 では、

セントラル・リポジトリにバックアップ情報を格納できません。

ディスク・ベースのバックアップは、従来のテープへの直接のバックアップより 高いパフォーマンスと信頼性を提供します。テープへのバックアップは、主にアー カイブ化を目的としていましたが、ATA ドライブなどのより低コストのディスク を使用することで、ディスクへのバックアップは主要なリカバリ・ソースになり ました。Oracle Database 10g Release 1 から導入されたフラッシュ・リカバリ領域機 能は、ディスク上のすべての RMAN バックアップおよびリカバリ関連ファイルを、 ファイル・システムまたは Automatic Storage Management（ASM）ディスク・グルー プの単一ストレージ位置に整理統合します。Oracle は、スペース使用率を監視お よび管理し、不要なバックアップを自動的に削除して、最新のバックアップ用の スペースを確保します。DB2 は、自動化されたディスク・バックアップ管理機能 を提供しません。

Oracle には、Enterprise Manager による事前定義済バックアップ方針が用意されて います。オラクル推奨のバックアップ方針は、適切なバックアップおよびアーカ イブ・ログを維持して、直前の 24 時間以内の Point-in-Time リカバリをサポートし ます。この方針では、初日にバックアップのフル・イメージ・コピーを作成し、 その後は毎日の増分バックアップと最新の増分イメージ・コピーによる毎日の ロールフォワードを行います。DB2 では、バックアップの自動メンテナンスを行 いますが、事前定義済バックアップ方針はありません。 高速な増分更新バックアップにより、RMAN は増分バックアップを適用してイ メージ・コピーをロールフォワードします。イメージ・コピーは、増分バックアッ プが行われた SCN までのすべてのブロック変更を含み、更新されます。増分更新 バックアップは、毎日データベースのフル・バックアップを行う必要性、および これによるオーバーヘッドを削減します。DB2 には、この機能はありません。 自動データ・ファイル作成により、データ・ファイルの作成日までのアーカイブ・ ログがすべて使用可能である限り、RMAN はリカバリ操作中のデータ・ファイル を自動的に再作成します。これにより、表領域またはデータ・ファイルを新規に 追加後、バックアップを行う必要がなくなります。DB2 の場合、IBM では新しく 表領域を追加後、フル・バックアップまたは増分バックアップを行うように薦め ています。「既存のデータベースに表領域を追加して表領域のバックアップのみ を行うことにはリスクがあります。表領域のバックアップ中に、バックアップし た表領域の外部が変更されないという補償がないからです。」[11] データベースのリストア操作前に、DBA では、操作の完了に必要なバックアッ プ・ファイルのリスト表示を要求できます。RMAN のリストア・プレビュー機能 を使用すると、必要なバックアップがすべて使用可能かどうかの確認や、特定の バックアップの使用または回避を RMAN に指示する状況かどうかを識別できま す。DB2 には、この機能はありません。 リストア中、RMAN がバックアップで破損を見つけた場合、またはバックアップ にアクセスできないことがわかった場合、RMAN はすべてのバックアップから必 要なファイルをリストア後、エラーを元に戻します。これは、RMAN が RESTORE コマンドまたは RECOVER コマンド中にファイルをリストアする場合は、常に自動 で行われます。リストア障害が発生した場合、有効なバックアップを探し、操作 を再試行する必要はありません。DB2 には、この機能はありません。 バックアップが物理的および論理的に破 損されないことは重要です。RMAN では、 バックアップおよびリストア操作中は、 通常の検証を実行するだけでなく、いつ でもバックアップを検証できます。

バックアップが物理的にも論理的にも破損されないことは重要です。RMAN では、 バックアップおよびリストア操作中に、通常の検証を実行するだけでなく、いつ でもバックアップを検証できます。この検証機能は、既存のすべてのデータベー ス・ファイルをチェックして、それらが正しい場所に格納されているかを確認し ます。DB2 は、このタイプのデータ一貫性チェック機能は提供していません。 RMAN は、アーカイブ・ログがバックアップされているかを検証します。アーカ イブ・ログの破損という稀なイベントでは（ディスク I/O エラーなど）、Oracle LogMiner を使用して破損したアーカイブ・ログを収集することにより、ログ・ファ イルに記録されたトランザクションの一部を回復します。DB2 では、アーカイブ・ ログ・ファイルが破損すると、そのログ・ファイルおよび破損したログ・ファイ ルの後に作成されたアーカイブ・ログ・ファイルのすべてのトランザクションが 失われます。 ミラースプリットによるバックアップは、インスタント・バックアップを生成す るため、便利です。Oracle と DB2 は、いずれもミラースプリットによるバックアッ プ機能を提供します。ただし、Oracle ではデータベースの実行中にミラーを分割 し、ディスクへ書込みます。DB2 ではミラーを分割するためにデータベース I/O を一時停止する必要があるため、分割中はデータベースで I/O 書込みができませ ん。 効率的な VLDB バックアップとリカバリ データ・ウェアハウスなどの大規模データベース（VLDB）には、効率的なバッ クアップ、リストアおよびリカバリの方法が必要です。この目的を達成するため に、Oracle では、ブロックレベル・メディア・リカバリや読込み専用表領域など 複数の先進テクノロジを RMAN によって統合しています。 Oracle のブロックレベル・メディア・リ カバリ機能を使用すると、単一のブロッ クが破損した場合、そのブロックのみを リカバリできます。 Oracle のブロックレベル・メディア・リカバリ機能を使用した場合、単一のブロッ クが破損すると、そのブロックのみをリカバリできます。残りのファイルとその ブロックを含む表は、オンラインのままアクセス可能であるため、データ可用性 が向上します。DB2 では、1 つのブロック・ユニットでデータをリカバリできな いため、ファイル全体をオフラインにしてリストアおよびリカバリする必要があ ります。 Oracle では、読込み専用表領域を使用してバックアップ時間を最小限に保ちます。 読込み専用表領域のバックアップの実行は、1 回のみ必要です。DB2 は、読込み 専用表領域をサポートしていないため、表領域を読込み専用モードにできないこ とから、表領域のバックアップを頻繁に行う必要があります。 この他に、Oracle が RMAN により提供する時間節約の機能は、再開可能なバック アップおよびリストアの操作です。Oracle では、これらの操作が失敗した場合、 失敗した時点から再開できます。DB2 にはこのような機能がないため、バックアッ プまたはリストア中に問題が発生すると、操作全体を最初からやり直す必要があ り、時間のロスになります。さらに問題を複雑にしているのは、DB2 では、「表 領域のバックアップ操作および表領域のリストア操作は、異なる表領域が対象の 場合でも同時実行はできません。」[12] LOB は非常に大規模で、イメージ・ファイルやサウンド・ファイルなど、決して 変更されないファイルを保存します。これらには、増分バックアップが重要にな

ります。Oracle では LOB の増分バックアップを実行できますが、DB2 ではできま せん。「表領域にロング・フィールドやラージ・オブジェクト・データを含む状 態で増分バックアップを実行すると、その表領域のページが直前のバックアップ により変更されている場合、ロング・フィールドまたはラージ・オブジェクト・ データはバックアップ・イメージにコピーされます。」[11]

パーティション化によるメンテナンスの削減と障害の分離

データベースが大きくなるにつれ、その管理作業が極端に増大します。データの パーティション化により、管理者はベースのアプリケーション・コードを変更す ることなく、大きな表を小さくて管理の容易なパーティションに分割できます。 これにより、より小さなパーティション・レベルでメンテナンス作業を実行でき、 メンテナンス中に大量のデータに影響を与えません。パーティションの他の利点 としては、障害の伝播防止です。メディア障害や破損などの障害は、障害が発生 したディスク上のパーティション以外には伝播されません。影響を受けリカバリ が必要なのは、そのパーティションのみです。パーティションのリカバリ・プロ セス中は、リカバリ時間を短縮し、障害が発生していない他のパーティションを オンラインに保ちます。これにより、全体的なデータ可用性が向上します。 Oracle も DB2 もデータのパーティション化をサポートしていますが、Oracle はよ り広いパーティション化のオプションを提供します。Oracle は、レンジ、ハッシュ、 リスト、コンポジット（ハッシュと組み合せたレンジおよびリストと組み合せた レンジ）、パーティション化の方法もサポートしていますが、DB2 は、ハッシュ のパーティション化のみをサポートします。IBM では、DB2 はパーティション化 の利点としてメンテナンスの削減や障害の分離を提供するとしていますが、実際 には DB2 では、ハッシュのパーティション化への制限のために管理者は影響を受 けるデータと操作を正確に判断できないため、この相違は重大です。ハッシュの パーティション化により、データベース・サーバーがデータの配置を決定します。 ユーザーはレンジ・パーティション化とリスト・パーティション化によりデータ 配置を制御します。たとえば、物理的な地域によりデータがパーティション化さ れている場合、障害から影響を受けるのは単一の物理的地域です。さらに、地域 と時間によってデータをパーティション化すると、障害からの影響は単一の地域 の小さい時間枠のみになります。 このような組込みストレージ階層メカニ ズムにより、Oracle データベースではビ ジ ネ ス 固 有 の サ ポ ー ト と し て 柔 軟 な Information Lifecycle Management（ILM） を実装できます。 一般に、大きい表の中の全データが、同じアクセス特性を持っているわけではあ りません。通常、保留中のオーダーはクローズされたオーダーよりも頻繁にアク セスされ、前四半期の販売実績は 3 年前の四半期の販売実績よりも頻繁に分析さ れます。レンジまたはリスト（あるいは両方）によるパーティション化により、 インテリジェント・ストレージ管理やデータの階層化が可能なため、頻繁にアク セスするデータは、最もパフォーマンスの高いディスク・サブシステムにある別 個のパーティションに格納し、アクセス回数の少ないデータや履歴データは、ATA ドライブ・ベースの低コストのモジュール型ストレージ配列に格納できます。こ のような組込みストレージ階層メカニズムにより、Oracle データベースでは、ビ ジネス固有のサポートとして柔軟な Information Lifecycle Management（ILM）を実 装できます[13]。DB2 は、このような機能を提供していません。

Oracle のパーティション化機能は、データ・ウェアハウス環境のローリング・ウィ ンドウもサポートします。ローリング・ウィンドウを使用すると、あまり頻繁に

アクセスしないデータより頻繁にアクセスするデータのバックアップ回数を増や すことができます。リストア操作も高速化できます。管理者は、リストア操作中 に直前 3 か月のデータのみを素早くリストアし、バックグラウンドで古いデータ をリストアしながらシステムをオンラインに戻せます。ただし、DB2 ではパーティ ション化能力に制限があるため、ローリング・ウィンドウによるデータ管理はサ ポートしていません。DB2 のハッシュ・パーティション化スキームでは、すべて のパーティションでデータの再分散が必要なため、新しいデータのロード時間が 増すだけでなくデータ再分散処理中に表がロックしてデータの可用性も低減しま す。 DB2 には、パーティション上で UNION ALL ビューからローリング・ウィンドウ をシミュレートする方法[14]がありますが、この方法には拡張性がなく管理も容易 ではありません。 また Oracle では、グローバル・パーティション索引を実装して、問合せの効率性 を保ちながら索引の障害を分離します。DB2 はローカル索引のみをサポートして いるため、問合せの述語でパーティション化キーを指定しない限り、すべてのパー ティションに問合せをブロードキャストします。

ASM – 統合化されたデータのミラー化

Oracle Database 10g の新しい Automatic Storage Management（ASM）は、垂直統合 されたファイル・システムとボリューム・マネージャ機能を Oracle カーネルに直 接提供するため、データベース・ストレージのプロビジョニング作業が大幅に軽 減されます。また、高可用性が実現し、特別なストレージ製品の購入、インストー ルおよびメンテナンスは不要です。ASM は、ASM ファイルを使用可能な全スト レージに分散してパフォーマンスを最適化し、ストレージ・ディスクの追加や削 除にも、これを自動的に実行します。

Oracle Database 10g の新しい Automatic Storage Management（ASM）は、Oracle カーネルに直接的に垂直統合されたファ イル・システムとボリューム・マネージャ 機能を提供します。 さらに、ASM が提供するディスク障害グループの概念に基づいたシステム固有の ミラー化メカニズムを使用すると、ストレージ障害を防止できます。ASM の障害 グループとは、その障害に対しての耐性がある共通リソース（ディスク・コント ローラまたはディスク・アレイ全体）を共有する一連のディスクです。ASM のミ ラー化を使用することにより、データベースのエクステントが割り当てられた場 合、プライマリ・コピーとセカンダリ・コピーが作成され、セカンダリ・コピー 用に選択されたディスクは、プライマリ・コピーとは異なる障害グループに入れ られます。これにより、データは使用可能使用可能な状態で、ストレージ・サブ システム内の任意のコンポーネントの障害から透過的に保護されます。 DB2 には、このような統合化されたミラー化メカニズムによる追加のデータ保護 機能はありません。

エンドツーエンドのデータ整合性

Oracle の Hardware Assisted Resilient Data (H.A.R.D.) イニシアティブ [16]を使用す ることにより、ストレージ・ベンダーは Oracle ブロックのディスクへの書込み前 に検証する追加手順を使用できるため、破損されたブロックのディスクへの書込 みを防止できます。Oracle HARD が対処するデータの破損は、次のように分類さ れます。

• 物理的および論理的に破損したブロックの書込み Oracle の Hardware Assisted Resilient

Data (H.A.R.D.) イニシアティブを使用 すると、ストレージ・ベンダーは Oracle ブロックのディスクへの書込み前に検証 する追加手順を使用できます。 • 不正な場所へのブロックの書込み • Oracle 以外のプログラムから Oracle データへの不正な書込み • 部分的に書込まれたブロック • 書込みの喪失 • 破損したサード・パーティのバックアップ HARD イニシアティブには、これらの破損すべてを防止するために、選択したス トレージ・ベンダーからストレージ・デバイスに組込み可能な複数のテクノロジ が含まれています。DB2 では、破損したブロックのディスクへの書込みを防止す るストレージ・テクノロジを同様の方法で統合することはできません。

障害時リカバリへの対応

Data Guard は、実働データベースまたは プライマリ・データベースのトランザク ション一貫性コピーである 1 台または複 数のスタンバイ・データベースを使用し て、障害の分離、高可用性および障害リ カバリを確保します。

Oracle Data Guard

Oracle Data Guard [17]は、Oracle データベースの障害時リカバリ・ソリューション です。この機能は、Oracle Database Enterprise Edition に統合化された機能として、 実働データベースまたはプライマリ・データベースのトランザクション一貫性コ ピーである 1 台または複数のスタンバイ・データベースを使用して、障害の隔離、 高可用性および障害リカバリを確保します。実働サイトでの計画停止または計画 外停止のイベントでは、Data Guard により選択したデータベースを容易にプライ マリ・データベース・ロールに切り替えられるため、継続して企業のデータ要件 を満たします。

DB2 HADR

DB2 バージョン 8.2 の新しい高可用性機能を「高可用性障害時リカバリ」または HADR [18]と呼びます。HADR は、IBM の Informix Dynamic Server 取得以降、High Availability Data Replication（HDR）と呼ばれる同様の機能をベースにしています

[19]。プライマリと呼ばれるソース・データベースから、スタンバイと呼ばれるター

ゲット・データベースにデータ変更をレプリケートする点では、Oracle Data Guard と同じです。部分的または完全なサイト障害が発生した場合、スタンバイ・デー タベースがプライマリ・データベースを引き継ぎます。

DB2 – 以前のリリースの機能

バージョン 8.1 には、DB2ログ・シッピング[20]という機能があり、手動管理とカ スタム・スクリプトが可能でした。このログ・シッピング・メカニズムは、指定 したロケーションでユーザー・イグジット・プログラム（具体的には「db2uxt2」） を設定し、データベース構成パラメータ「userexit」を「Yes」に設定する必要 があります[21]。これらの設定完了後、DB2 サーバーは、5 分ごとにユーザー・イ グジット・プログラムを呼び出し、プログラムが指定した特別なディレクトリ/ロ ケーションにアーカイブ化されたログ・ファイルをチェックします。ユーザー・ イグジット・プログラムでは、スタンバイ・サーバーがアクセス可能なディレク トリにアーカイブ・ログをコピーするか、単純にログをスタンバイ・サーバーに FTP 送信するように記述できます。

またこのメカニズムでは、スタンバイ・システムにスケジュールされたジョブを 設定して、定期的に db2 ロールフォワード・コマンド（たとえば「db2 rollforward db <dbname> to end of logs」）を発行する必要がありま す。スタンバイ・サーバーで rollforward db コマンドを起動すると、DB2 ロ ガーは後続のログ・ファイルをターゲットのアーカイブ・パスから自動的に取得 します。ロールフォワード操作は、処理が必要なファイルがなくなるまでログ・ ファイルの取得を続けます。このジョブを実行する頻度によって、アーカイブ・ ログがピックアップされスタンバイ・データベースに適用される速度が決まりま す。 明らかに、このスクリプト駆動型のアプローチには煩雑でエラーが発生しやすい 傾向があります。IBM は、バージョン 8.2 の HADR で、このアプローチに伴う複 雑さを多少軽減しています。

v8.2 HADR と v8.1 ログ・シッピングの相違点

DB2 バージョン 8.1 のログ・シッピング機能は、バージョン 8.2 にも搭載されてい ます。HARD とログ・シッピングとの相違は、IBM が Infomix から取得したテク ノロジを使用してこの概念の周囲に自動化された機能を構築する点です。手動 ユーザー・イグジット・プログラムと明示的なロールフォワード・コマンドへの 依存は、「START HADR」および「STOP HADR」コマンドによって削減されまし た。ただし、ここで注意することは、既存の「rollforward database」コマ ンドを HARD 構成で使用すると非一貫性が生じる場合があるため、このコマンド を使用できないことです。IBM では、このかわりに「start hadr on db <dbname> as standby」の使用を薦めています。 初期のログ・シッピングと比較すると、HARD のデータ保護はよりきめ細かくなっ ています。完全なアーカイブ・ログが生成されて送信を待つかわりに、プライマ リ・データベースでログ・ページが生成されスタンバイ・データベースに送信さ れます。レプリケーションの状態は、HADR_SYNCMODE 構成パラメータで SYNC、 NEARSYNC および ASYNC 値を使用することにより、よりきめ細かく制御できます。

これは、Data Guard の保護モードと類似部分があります。また、HADR は、ロー ルの推移に関しても TAKEOVER HADR コマンドにより自動化されています。 HADR は、新しい機能です。これに対し て、Data Guard は発売後数年経ってお り、いくつかの Oracle データベース・リ リースを通して進化し拡張され、世界中 の主要な顧客の基幹業務アプリケーショ ンに配置されています。

Data Guard: 長所の比較

HADR は、新しい機能です。これに対して、Data Guard は発売後数年経っており、 いくつかの Oracle データベース・リリースを通して進化し拡張され、世界中の主 要な顧客の基幹業務アプリケーションに配置されています。次の表では、HADR と Data Guard の長所を簡単に比較して示します。