Oracle Database 11g Release 2とIBM DB2 9.7の技術比較：高可用性に重点を置いた比較

IBM DB2 9.7の技術比較：高可用性に

重点を置いた比較

概要 ... 1

はじめに ... 2

計画停止時間と計画外停止時間 ... 2

概要：オラクルの高可用性ソリューション ... 3

計画外停止時間の最小化 ... 3

計画停止時間の最小化 ... 5

OracleとDB2のHA機能の比較 ... 5

OracleとDB2の比較 - 計画外停止への対応 ... 10

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

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

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

人的エラーへの対応 ... 35

OracleとDB2の比較 - 計画停止への対応 ... 39

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

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

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

オラクルの高可用性機能を導入している顧客 ... 47

結論 ... 49

参照資料 ... 50

概要

今日のビジネスは、データベースに大きく依存しています。アプリケーションやデータが使用でき なくなると、ビジネス全体が停止し、収益や顧客を失い、不利益を被る場合があります。また、悪 評によって、顧客や株価に長期的な影響を及ぼすおそれがあります。したがって、継続的なデータ の可用性を確保することは今日のビジネスに不可欠と言えます。 Oracle Database 11gは、ビジネスに影響を及ぼすさまざまな要因による停止時間を最小限に抑えて、 ビジネスの継続性を実現する高可用性（HA）機能の統合セットを備えています。この機能は、シス テム障害、データ障害、災害、人的エラー、システム・メンテナンス作業、およびデータ・メンテ ナンス作業など、データが使用不能になる状況を招く可能性のあるシナリオの大半をカバーしてい ます。本書で示すように、IBM DB2 9.7データベース（Linux、Unix、およびWindows版）は、高可 用性とデータ保護の基本機能は備えていますが、HA機能の幅広さと奥深さの点ではOracleに数リリー ス分遅れています。

Oracleデータベースは、Merrill Lynch、Citigroup、Southwest Airlines、British Telecom、Bharti Airtel、 Best Buy、Lufthansa、Priceline、eBay、およびAmazon.comなどの有名なグローバル企業でミッショ ン・クリティカルな高可用性エンタープライズ・アプリケーションを実行しています。信頼性と高 可用性を備えた継続的なサービスを提供する機能に関して言えば、OracleデータベースはDB2などの 競合ソリューションに勝る最適なデータベースと言えるでしょう。

はじめに

企業データのデータベース・ソリューションを検討中の組織は、データベースの高可用性機能につ いても検討する必要があります。データは組織のもっとも重要なビジネス資産の1つです。データの 可用性や保護が確保されていないと、ビジネスの停止時間やマイナス・イメージにより数百万ドル の損失が発生するおそれがあります。高可用性データ・インフラストラクチャの構築は、動きの速 い今日の経済環境で成功を収めるためにあらゆる組織にとって不可欠と言えます。

本書では、Oracle Database 11g Release 2とIBM DB2 9.7のHA機能を詳細に比較し、その評価について 説明します。本書の対象読者としては、この2つのデータベースの採用を検討中で、これらのデータ ベースのHA機能によってどの程度データを保護し、ビジネスの継続性を維持できるかを把握したい と考えているITマネージャー、アーキテクト、および企業幹部を想定しています。

計画停止時間と計画外停止時間

高可用性ITインフラストラクチャを設計するうえでの課題の1つは、停止時間の要因となり得るもの をすべて調査して、対処することです。停止時間は、おもに計画外停止時間と計画停止時間の2つの カテゴリに分類されます。フォルト・トレラントで回復力があるITインフラストラクチャを設計す ると同時に、計画外停止時間と計画停止時間の要因となり得るものを考慮する必要があります。 計画外停止時間は、おもにシステム障害やデータ障害（人的エラー、災害、データ破損など）によっ て引き起こされます。こうした障害が発生するのはまれですが、業務への悪影響は甚大であり、停 止時間によって高コストへとつながります。これに対し、計画停止時間は、定期的なメンテナンス 作業（データの変更やシステムのアップグレードなど）により発生し、データセンターの日常業務 の一環として組み込まれます。ここでの課題は、業務の中断が最小限で済むように、メンテナンス 作業をできるだけ透過的に完了することです。 ビジネス・ニーズに対応するため、高可用性ソリューションの採用を検討中のITマネージャーは、 以下のような主要メトリックに基づいてソリューションを評価する必要があります。 • さまざまな停止時間の発生要因に対応できるHA機能の包括性 • 変化するビジネス要件に合わせてソリューションを管理し、調整できる簡便性 • 冗長コンポーネントをビジネスで効果的に使用して、投資収益率を最大化できる能力 統合された方法ではなく分離された方法でHAの問題に対応する、相互に関連していないテクノロジー の集まりで、基本的にはアイドル状態の多数の冗長コンポーネントから成るソリューションでは、 今日の企業の厳しいHA要件を満たすことはできません。こうした観点から、以降の項では、DB2と OracleデータベースのHAに基づいた分析を実施します。

概要：オラクルの高可用性ソリューション

Oracle Database 11gは、ビジネスに影響を及ぼすさまざまな要因による停止時間を最小限に抑える高 可用性（図1参照）機能の統合セットを備えています。以下の数項では、これらの機能の概要につい て説明します。各機能の詳細については、[1]および[2]を参照してください。 図1 Oracle Database 11gの統合された高可用性機能

計画外停止時間の最小化

Oracleは、サーバー障害からの保護を目的として、Oracle Real Application Clusters（Oracle RAC）を提 供します。このコンポーネントを使用すれば、複数のサーバーからクラスタ環境内の単一のOracle データベースにアクセスできます。この方法のメリットは、アプリケーション・コードを変更する ことなく、スケーラビリティと高可用性を実現できる点です。

また、さまざまなデータ障害（ストレージ障害、人的エラー、破損、サイト障害など）からの保護を 目的として、Oracleは一連の機能を提供します。そのうちの1つは、Oracleデータベースに統合ボリュー ム・マネージャ機能を提供するOracle Automatic Storage Management（Oracle ASM）です。Oracle ASM は、データベース・ファイルのネイティブ・ミラー化という保護機能を追加で提供します。人的エ ラーから保護する機能としては、一連のフラッシュバック機能（フラッシュバック・データベース やフラッシュバック表など）があります。この機能により、データベースを安全と分かっている時 点まで巻き戻して、長時間に及ぶ停止時間を発生させることなく人的エラーの影響を非常に簡単に 取り消すことができます。

さまざまなメディア障害からデータを保護するための機能としては、Oracle Recovery Manager（Oracle RMAN）があります。この機能は、Oracleデータベースのバックアップ、リストア、およびリカバリ の包括的なソリューションです。Oracle RMANにより、コストのかかる停止時間を発生させることな く、Oracleデータベースのバックアップをオンラインで取得できます。さらにOracle Databaseには、 高速リカバリ領域が確保されています。これは、Oracleデータベース内のリカバリ関連のファイルと アクティビティのすべてを保管するディスクベースの統合ストレージ領域です。Oracle RMANおよび 高速リカバリ領域の自動化と統合により、Oracle Databaseと統合された、高度なディスクベースの バックアップおよびリカバリ・ソリューションを提供します。また、Oracleでは、テープとクラウド によるバックアップ・ソリューションとして、Oracle Secure BackupとOracle Secure Backup Cloud Moduleも用意しています。Oracle Secure BackupはOracle RMANと統合化され、他のソリューション にはないパフォーマンスの最適化と高速なテープ・バックアップ機能を実現します。クラウド・バッ クアップ・モジュールを使用すると、管理者は、使い慣れたOracle RMANインタフェースを使用して、 Oracleデータベースでのデータ変更をAmazon S3ストレージにクラウドを介してバックアップできま す。管理者は、表領域レベル、データファイル・レベル、さらにはデータ・ブロック・レベルで、 さまざまなメディアに対して、Oracleデータベースのバックアップとリストアを非常に高速で実行で きるため、メンテナンス時間をさらに短縮できます。 火災、地震、ハリケーン、悪質行為などの局所的または地域的な惨事により発生するサイト障害や ストレージ障害から保護するための機能としては、Oracle Data Guardが提供されています。Oracle Data Guardは、Oracle RACが未導入の構成においてもサーバー障害から保護します。Oracle Data Guard構 成では、複数のスタンバイ・データベースを本番データベース（プライマリ・データベース）にネッ トワーク経由で接続します。Oracle Data Guardでは、スタンバイ・データベースがプライマリ・デー タベースと同期化されているため、プライマリ・データセンターに不慮の災害が発生した場合に、 処理をスタンバイ・データベースのうちの1つに簡単に切り替えることができます。このプロセスで のデータ損失をゼロにして、必要に応じてフェイルオーバーを自動化するようにOracle Data Guardを 構成できます。Oracle Data Guardのスタンバイ・データベースは、データ保護機能を損なうことなく、 レポート、バックアップ、品質保証テストなどの作業に日常的に活用できます。Oracle Database 11g で導入されているOracle Active Data Guardオプションを使用すれば、フィジカル・スタンバイ・デー タベースを使用してリアルタイムでレポートを作成し、さらにそのフィジカル・スタンバイ・デー タベースを高速増分バックアップに使用することもできます。

これにより、Oracle Data Guardのスタンバイ・データベースを積極的に活用して、Oracle Data Guard への投資を即時回収できます。

オラクルでは、Oracle Data Guardの障害時リカバリ（DR）ソリューションの他にも、情報共有とデー タの統合化に重点を置いたソリューションを用意しています。最高クラスのソリューションとして Oracle GoldenGateがあります。これは、データベースとは別個の製品です。Oracle GoldenGateを使用 すると、データの変更を、1つまたは複数のソース・データベース（OracleまたはOracle以外）から 1つまたは複数のターゲット・データベース（OracleまたはOracle以外）に分散させることができます。 Oracle GoldenGateは他にも、データのサブセット化、データ変換、マルチマスター・レプリケーショ ン、競合検出可能なアクティブ-アクティブ構成、停止時間ゼロのアップグレードなど、柔軟な機能 を備えています。オラクルではGoldenGateと類似の機能を備えたOracle Streamsという情報共有ソリュー ションも提供しています。Oracle StreamsはOracleデータベースの組込み機能であり、Oracleデータベー ス同士でのみ使用できます。

計画停止時間の最小化

計画停止時間には、ルーチン処理、定期メンテナンス、新規導入などの作業が含まれますが、とり わけ複数のタイムゾーンに属するユーザーをサポートするグローバル企業では、計画停止時間は単 なる業務の中断に過ぎません。計画外停止時間の最小化と同様に、Oracleデータベースには、計画停 止時間をゼロまたは最小限に抑えるための一連の機能が搭載されています。 表のオンライン再定義機能により、データベースの処理やユーザーによるデータの更新およびアク セスを中断させることなく、さまざまなデータ・メンテナンス処理を実行できます。たとえば、デー タベース表の再定義（表タイプの変更、列の追加、削除、名前の変更、記憶域パラメータの変更な ど）を、エンドユーザーによる基礎データの表示や更新を中断することなく実施できます。ローリ ング・アップグレード機能により、Oracle Data Guard SQL Apply、Oracle GoldenGate、またはOracle Streamsを使用して、データベースのパッチセットや主要リリースのアップグレードをローリング方 式で実行できるため、アプリケーションの停止時間を最小化できます。また、Oracle Database 11gの オンライン・パッチ機能により、実行中のOracleインスタンスにパッチをオンラインでインストール できます。Oracle Database 11g Release 2には、新たにエディションベースの再定義機能が用意されて います。この機能を使用すると、アプリケーションのデータベース・コンポーネントをコンポーネ ントの使用中にアップグレードできるので、アプリケーションを最小限の停止時間でアップグレー ドできます。

Oracle Databaseは、Oracle ASMなどによるデータベース・アクティビティを中断することなく、SMP サーバーのプロセッサの追加と削除、RACクラスタのノードの追加と削除、共有メモリ割当ての動 的な拡大と縮小、オンラインでのデータベース・ディスクの追加と削除などのハードウェア構成の 変更に動的に対応できます。さらに、Oracle Data Guard、Oracle GoldenGate、またはOracle Streamsを 使用すれば、データセンターの移設、SANへの移行、テクノロジーの更新など、大規模移行時の停 止時間を最小化できます。

OracleとDB2のHA機能の比較

IBM DB2の高可用性機能は、リリース9.7でさえ、Oracleの高可用性機能の幅広さと奥深さに及びま せん。本書では、高可用性に関するさまざまな課題を取り上げ、Oracle DatabaseとIBM DB2 9.7の課 題解決方法を比較して、高可用性の観点から、DB2が依然としてOracleに大幅に後れを取っているこ とを証明していきます。

これ以降本書では、OracleとはOracle Database 11g Release 2 Enterprise Editionを指し、特に明記しない 限り、DB2はIBM DB2 Version 9.7 Enterprise Server Edition for Linux, Unix and Windows（LUW）を指す ものとします。Oracle Database 11g Release 2の機能説明については、Oracle Database 11g Release 2のド キュメンテーション・サイト[3]を参照してください。特に明記しない限り、DB2 9.7に関する記述は、 IBM DB2 Version 9.7オンライン・ドキュメント（Linux、Unix、およびWindows版）[4]に基づいてい ます。

簡単に参照できるように、以下の表に停止時間のカテゴリ別にOracleとDB2のおもな差別化要因を一 覧表示します。本書では、これらの差別化要因について詳しく説明していきます。

表1：おもな高可用性機能の差別化要因 - OracleとDB2 システム障害への対応 ORACLE DB2 予測可能なリカバリ時間 対応 未対応 リカバリ・アドバイザリ 対応 未対応 ロールバック中のデータの可用性 対応 未対応 パーティション内のデータの偏りに影響されない問合せパフォーマンス 対応 未対応 すべての主要なOSおよびサーバー・プラットフォーム用の統合化クラスタリング・テクノロジー 対応 未対応 OLTPおよびデータウェアハウス・アプリケーション向けの統一化クラスタリング 対応 未対応 クラスタ内での高速統合化された中間層接続フェイルオーバー 対応 未対応 クラスタ全体の包括的なロードバランシング機能 対応 未対応 エンタープライズ・グリッドを実現する自動ワークロード管理 対応 未対応 組込みのデータベース障害検出、分析、および修復機能 対応 未対応 増分更新バックアップ計画 対応 未対応 全体バックアップ時の未使用ブロックの圧縮 対応 未対応 拡張されたバックアップ圧縮レベル 対応 未対応 リカバリ時の次のバックアップへの自動リストア・フェイルオーバー 対応 未対応 リストアのプレビュー 対応 未対応 試行リカバリ 対応 未対応 バックアップ作成時の暗号化 対応 未対応 中間ストレージ不要のネットワーク経由での直接的なデータベースのクローン作成 対応 未対応 ブロックレベル・メディア・リカバリ 対応 未対応 読取り専用表領域 対応 未対応 再開可能なバックアップ 対応 未対応 LOBの増分バックアップ 対応 未対応 統合ミラー化 対応 未対応

障害時リカバリへの対応 – データの保護と可用性 ORACLE DB2 スタンバイへの適用が進行してもプライマリのパフォーマンスやデータ保護に影響を与えない 対応 未対応 ネットワークの混雑が発生してもASYNC構成のプライマリ・データベースが決して停止しない 対応 未対応 プライマリ/スタンバイの初期化時、パラメータの変更時に可用性が影響を受けない 対応 未対応 ハードウェア/ソフトウェア障害によるサイレント破損がプライマリとスタンバイの両方で検出される 対応 未対応 破損ブロックが、ユーザーおよびアプリケーションに対して透過的に、オンラインで自動修復される 対応 未対応 人的エラーおよび論理的破損からの高速リカバリ 対応 未対応 データ損失とスプリット・ブレインなしの統合化自動データベース・フェイルオーバー 対応 未対応 ユーザーが構成可能なデータ損失SLAに準拠した、ASYNC用の管理された自動フェイルオーバー 対応 未対応 すべてのケースにおけるアプリケーションの接続時フェイルオーバー（データベース・ロールによる管理） 対応 未対応 フェイルオーバー後のプライマリの高速回復。元のプライマリが修復できる場合は、バックアップからリ ストアせずに済む。これはフェイルオーバー時に、スタンバイがプライマリ・データベースと同期してい たかどうかに関係なく当てはまる 対応 未対応 複数スタンバイによるフェイルオーバー後のノンストップ保護 対応 未対応 メジャー・バージョンおよびサブバージョン間のデータベースのローリング・アップグレード 対応 未対応 スタンバイ・データベースをバックアップからリストア。バージョンのアップグレード後は不要。 対応 未対応 プライマリ/スタンバイの混合構成（例：32ビット/64ビット、Windows/Linuxなど）のサポートにより、テ クノロジーの更新、保守、移行時の計画停止時間を短縮 対応 未対応 効率的なネットワーク使用のための統合されたログ転送の圧縮 対応 未対応 ネットワークおよびスタンバイ・データベースの停止からの高速かつ中断のないリカバリ 対応 未対応 ストアド・プロシージャのスタンバイ・データベースへのレプリケーション 対応 未対応 データベース・パーティション化のサポート 対応 未対応 アクティブ-アクティブ・クラスタのサポート 対応 未対応

障害時リカバリのROI向上のための対応 – スタンバイ・データベースの使用率 ORACLE DB2 アクティブ・スタンバイ・データベースに対する読取り専用の問合せが、プライマリ・データベースに対 して実行された問合せと同じ完全な読取り一貫性を返す。問合せによる未コミットのデータへのアクセス、 非リピータブル・リードや仮読取りは不可能。 対応 未対応 アクティブ・スタンバイ・データベースに対するデータ型制限がない（XML、LOB、LONG、ADTなど） 対応 未対応 ユーザーが、DDL再生中のアクティブ・スタンバイ・データベースに対する継続的な読取り専用アクセス 権を保有 対応 未対応 ローカル・ログ・ファイルを使用して同期化されている最中のアクティブ・スタンバイ・データベースに ユーザー接続からアクセス可能 対応 未対応 管理者はプライマリ・データベースとアクティブ・スタンバイ・データベースの最大適用ラグ（0から’n’ 秒）の目標値を設定できる。適用ラグはアクティブ・スタンバイ・データベースに対して実行中の読取り 専用問合せがビジネス要件を確実に達成できるように、自動的に監視される。手動による介入は不要 対応 未対応 アクティブ・スタンバイ・データベースに対して自動メモリ管理機能がサポートされている。これにより 読取り専用のワークロード、およびフェイルオーバー発生後にスタンバイがプライマリに移行するときの ワークロードのパフォーマンスが最適化される。手動のチューニングは不要 対応 未対応 スタンバイ・データベースに対するバックアップおよびアーカイブ操作がサポートされている 対応 未対応 バックアップとリストアがデータベース・ロールに対して透過的に実行される 対応 未対応 スタンバイ・データベースを二重目的に使用できる。すなわち、すべてのプライマリ・データベース・ト ランザクションについて災害時保護を継続的に提供しながら、QAテストや他の読取り/書込みアクティビ ティに使用できる 対応 未対応

人的エラーへの対応 ORACLE DB2 SQL問合せを使用して過去の時点のデータを取得 対応 未対応 ごみ箱のサポート 対応 未対応 トランザクション・レベルでのデータベース変更の確認およびバックアウト 対応 未対応 行バージョンの変更の表示 対応 未対応 SQLインタフェースを使用したログのマイニングと変更の監査 対応 未対応 柔軟な表領域のポイント・イン・タイム・リカバリ 対応 未対応 過去の時点への表のフラッシュバック 対応 未対応 バックアップのリストアが不要の過去の時点へのデータベースのフラッシュバック 対応 未対応 システム・メンテナンスへの対応 ORACLE DB2 クラスタへのオンラインでのノード追加機能 対応 未対応 ディスクのオンライン追加と削除機能 対応 未対応 オンライン・パッチ 対応 未対応 フル・パッチセットとメジャー・リリースのローリング・データベース・アップグレード 対応 未対応 メモリをオンライン調整するための拡張サポート 対応 未対応 メモリ管理に関する有用なアドバイザリ 対応 未対応 大半の構成パラメータをオンラインで変更可能 対応 未対応 データ保守への対応 ORACLE DB2 パーティションのオンラインでの追加、交換、移動機能 対応 未対応 表をオンラインで再編成および再定義するための柔軟で包括的な機能 対応 未対応 個別の表パーティションのオンラインでの再編成機能 対応 未対応 デフォルト値を使用した、オンラインでの迅速な列追加機能 対応 未対応 列のオンラインでの名前変更とマージ機能 対応 未対応 非表示の索引 対応 未対応 排他ロック不要のオンラインでの制約の追加と変更、列の追加、索引の作成と再構築機能 対応 未対応 基礎リソースがビジーな場合のDDL操作待機機能（待機時間はユーザー指定） 対応 未対応

OracleとDB2の比較 - 計画外停止への対応

計画外停止への対応については、システム障害への対応およびデータ障害への対応の項で説明します。

システム障害への対応

システム障害は、ハードウェア障害、電源異常、オペレーティング・システムやサーバーのクラッ シュによって発生します。このような障害による中断の範囲は、影響を受けるユーザーの数とサー ビスが復旧するまでの時間によって異なります。システム障害における課題は、高速リカバリの実 現であり、より理想的に言えば、高度なフォルト・トレランスです。 次の表に示すように、システム障害への効果的な対応方法において、OracleにはDB2との明確な差別 化の要因となる一連の機能が用意されています。 表2：システム障害への対応 - OracleとDB2の比較 システム障害への対応 ORACLE DB2 予測可能なリカバリ時間 対応 未対応 リカバリ・アドバイザ 対応 未対応 ロールバック中のデータの可用性 対応 未対応 パーティション内のデータの偏りに影響されない問合せパフォーマンス 対応 未対応 すべての主要なOSおよびサーバー・プラットフォーム用の統合化クラスタリング・テクノロジー 対応 未対応 OLTPおよびデータウェアハウス・アプリケーション向けの統一化クラスタリング 対応 未対応 クラスタ内での高速統合化された中間層接続フェイルオーバー 対応 未対応 クラスタ全体の包括的なロードバランシング機能 対応 未対応 エンタープライズ・グリッドを実現する自動ワークロード管理 対応 未対応 次項では、これらの差別化要因について詳しく説明します。 ファストスタート障害リカバリ Oracleのファストスタート™ 障害リカバリ機能は、システム障害に関する停止時間を最小化するよう に設計されています。この機能は、ファストスタート・チェックポイントとファストスタート・ロー ルバックの2つのコンポーネントからなります。前者は、チェックポイント位置を継続的かつ増分的に 進めることによってロール・フォワード・リカバリを最適化します。後者は、リカバリのロールバッ ク・フェーズにおける遅延をなくします。

ファストスタート・チェックポイント - 平均リカバリ時間の予測 Oracleでは、システム障害からのリカバリ所要時間を管理するため、動的パラメータによって平均リ カバリ時間（MTTR）を直接指定できます。リカバリ時間を継続的に見積もり、目標リカバリ時間[5] に合わせてチェックポイント作成速度を自動的に調整します。DB2には、リカバリ所要時間を効果的 に予測または管理する方法は用意されていません。DB2では、静的パラメータSOFTMAXによって、 チェックポイント間に出力されるリカバリ・ログ・ファイルのパーセンテージを管理します[6]。DBA は、この値を基に、実際のリカバリ時間を推定する必要があります。 頻繁にチェックポイントを作成すると余分なオーバーヘッドが発生するため、Oracleでは、v$instance_ recovery動的ビューを介して、目標MTTRのコストに対してリアルタイムでフィードバックを反映 させます。また、Oracle Enterprise Managerを介してGUIベースの警告も発行します。DB2では、SOFTMAX パラメータを調整するためのランタイム・コストを確定するのは不可能です。 また、Oracleでは、さまざまなリカバリ・シナリオのコストをシミュレートするv$mttr_target_advice ビューを介して警告を発行します。このシミュレーションは、現在の本番環境ワークロードに基づ いてリアルタイムで実行されます。この警告の内容に基づいて、管理者は、リカバリ速度と余分なI/O オーバーヘッドの最適なバランスをとることができます。これにより、高速リカバリ構成を実現す るために、推測したり、リスクを冒したりせずに済みます。 ファストスタート・ロールバック - 最悪のケースにおけるリカバリ時間の短縮 Oracleでは、長いトランザクションが実行されていてもクラッシュ・リカバリ時間が長くなることは ありません。というのは、独自のオンデマンド・ロールバック・テクノロジーによって、ユーザー は、インスタンス・リカバリ・ロールバック操作が完了する前にデータベースにアクセスできるか らです。Oracleでは、ロールフォワード処理が完了すると、ユーザーがデータベースにアクセスでき るようになります。DB2と違って、すべてのトランザクションがロールバックされるまで待つことは せず、新規のユーザー・トランザクションがデータにアクセスしている間に、トランザクションの ロールバックをバックグラウンドで実行します。これらの新規のユーザー・トランザクションのい ずれかが停止トランザクションによってロックされたデータに遭遇すると、そのユーザー・トラン ザクションは、停止トランザクションによって実行されたデータの変更を即座にロールバックして、 処理を続行します。 一方、DB2では、クラッシュ・リカバリが長いトランザクションから大きく影響を受けます。DB2 では、すべてのアクティブなトランザクションがロールバックされるまでデータベースにアクセス できないため、クラッシュ・リカバリ時間が、実行中のもっとも長いトランザクションに左右され ます。また、DB2は未コミットのトランザクションを含むログに切り替えることができないため、長 いトランザクションがあると、その分だけさらにリカバリ時間が長くなります。 実環境のクラスタリングによるフォルト・トレランス システム障害からの保護を実現するOracleの高可用性ソリューションの基盤となるのは、Oracle Real Application Clustersです。Oracle RACは、共有キャッシュ・アーキテクチャを備えたクラスタ・デー タベースです。従来のシェアード・ナッシングおよび共有ディスク方式における限界を克服し、す べてのビジネス・アプリケーションに高いスケーラビリティと可用性を備えたデータベース・ソリュー ションを提供します。

Oracleの統一クラスタリング・ソリューションとは対照的に、DB2のクラスタリング・ソリューショ ンは、統一性に欠け、統合化されていない部分があります。DB2は、以下の2つの異なるクラスタリ ング・ソリューションを提供しています。 • データウェアハウス・アプリケーション向けのDB2データベース・パーティション化機能（DPF） • OLTPアプリケーション向けのDB2 pureScale（DB2バージョン9.8より使用可能） DB2データベース・パーティション化機能（DPF） DB2は、データベース・パーティション化機能を介して使用可能なシェアード・ナッシング・クラス タ化データベースを提供します[8]、[9]。このようなDB2クラスタの各ノードには、1つ以上のデータ ベース・パーティション（または、データベース・パーティション・グループ）が含まれます。

注：バージョン9.5より、DPFは、InfoSphere Warehouse Enterprise Editionを介してのみ使用 可能になりました。InfoSphere Warehouse Enterprise Editionは別の製品であり、システム要 件や価格も異なります[10]、[11]。

注：旧リリースのDB2（たとえばバージョン8.2）では、DPFは、DB2 Universal Database

Enterprise Server Editionの独立したオプションとして用意されていました。バージョン9よ

り、別製品であるIBM DB2 Warehouseを介してのみ利用可能になりました。2008年5月、DB2

Warehouseバージョン9.5は、Online Analytical Processing（OLAP）とデータ・マイニングに

重点が置かれるようになり、IBM InfoSphere Warehouse V9.5.1と改名されました。

予期せぬノード障害が発生した場合、Oracle RACとDB2 DPFのどちらも透過的にデータベースから リカバリできますが、リカバリ時間は、上記で述べた機能、および以下に挙げる理由により、Oracle RACの方が短くなります。 • DB2は、存続しているノード上のパーティションを再起動するのにデータベース・マネージャを 使用します。このため、DB2の各プロセスを起動し、共有メモリを初期化し、データベース・ファ イルを開く必要があります。 • 今日の大規模なシステムでは、バッファ・キャッシュのサイズがギガバイトまたは数十ギガバイ トになることも珍しくありません。このような大容量のバッファ・キャッシュをウォームアップ するには時間がかかります。Oracle Real Application Clustersでは、ウォーム・キャッシュを備えて いるインスタンスに対してフェイルオーバーが発生します。DB2 DPFでは、フェイルオーバーの 際、常に、コールド・キャッシュを使用して新規のインスタンスを最初から起動する必要があり ます。したがって、データベースのリカバリ後、アプリケーションの最初の応答時間は、DB2 DPF よりもOracle RACの方が短くなります。アプリケーションが必要とするデータとパッケージが、 存続しているノードにすでにキャッシングされているからです。 • DB2 DPFが持つこの欠点に対応するため、IBMでは、同社の高可用性障害時リカバリ（HADR）機 能（DB2 v8.2で最初に導入）を、フェイルオーバー操作（DB2の用語ではテイクオーバー）時に おいてスタンバイ・データベースの再起動を不要にする機能として位置付け、これによりスタン バイはフェイルオーバー実行中もホットの状態を維持していると主張しています。確かに、この ようなスタンバイ・データベースは、Oracle RACと違って、最近変更されたすべてのバッファを 保有していますが、最近の読取りバッファは保有していません。たとえば、索引ブランチとルー ト・ブロックはキャッシュ内には存在しません。この点に関して、次のような記載があります[13]。

フェイルオーバー直後のDB2機能のパフォーマンスは、フェイルオーバー直前のパフォーマン スとまったく同じにはなりません。フェイルオーバー直後のパフォーマンスは、必要なキャッ チアップ処理の量によって異なります。ランプアップ時間は、DB2データベースが最初に起動 されるときのアプリケーションの立ち上がり時間と同じになるはずです。

このような障害の対処方法に加えて、DPFはOLTPアプリケーション向けにパフォーマンスが最適化 されていません（DPFがInfoSphere Warehouse Enterprise Editionを介してのみ利用可能なのはこのため です）。その理由は、DB2が分散キー（旧リリースのパーティション・キー）を保持する方法にあり ます。分散キーは、特定のデータ行が格納されるデータベース・パーティションを決定するために 使用される列として保持されます。分散キーは、CREATE TABLE文を実行すると表に定義されます （デフォルトは、プライマリ・キーの最初の列、プライマリ・キーが存在しない場合は、その表に定 義されている最初の非ロング・フィールド列です）。分散キーが定義されると、そのキーを使用し て、表の各列の場所が次のようにして決まります。 • ハッシング・アルゴリズムが分散キーの値に適用され、0～4095の数値が生成されます。 • データベース・パーティション・グループが作成されると、分散マップが生成されます。各番号 が順番にラウンドロビン方式で繰り返され、分散マップが埋められます。 • 番号は、分散マップへの索引として使用されます。分散マップのその場所の番号が、その行が格 納されるデータベース・パーティションの番号になります。 この方法では、特にDB2 DPF環境にアクセスするOLTPアプリケーションの問合せ/更新パフォーマン ス（たとえば、データ・アクセスに複数のパーティションにまたがる結合操作が含まれる場合のパ フォーマンス）が明らかに低下します（DB2のドキュメントに、良い分散キーを選択することが重要 であると強調しているのはこのためです）。また、不適切なパーティション・キーを使用すると、 データの分散が不均等になり、アプリケーション・パフォーマンスも不均等になります。最後に、 すべての問合せ/更新を適用する際にパーティション化ハッシュ・アルゴリズムを実行する必要があ るため、問合せ/更新のコストが大きくなります。具体的には、パーティション・キーのサイズに比 例してコストも増大します。

これを軽減するため、IBMでは、DB2 Design Advisor [15]という別のツールを使用することを推奨し ています。このツールを使用すると、データベース・パーティションが存在するとき、DB2ワークロー ドのパフォーマンスを改善するために必要なオブジェクトを特定できます。ただし、このツール自 体の制限や制約もあるので注意が必要です。 DPFにはスケーラビリティに関する側面もあります。明白なことですが、高可用性構成では、ノード 数が増えるにしたがってパーティションの数が急激に増大します。これにより、次のような運用上 の問題が発生します。 • クラスタの管理に必要な作業量が増えます。各パーティションには、それぞれ固有の構成パラメー タ、データベース・ファイル、管理が必要なREDOログがあります。 • 各物理ノードのリソース使用率が低下する可能性があります。複数のパーティションが同じ物理 ノードによって所有されますが、そのパーティションは、バッファ・プール、パッケージ、キャッ シュなどに使用するメモリを共有できません。これは、メモリの使用率低下の原因になります。 というのは、複数のメモリ断片よりも1つのメモリ断片を最大限に活用する可能性があるからです。 • パーティション数の増加に伴い、データの負荷および（または）データの偏りが増大する可能性 があります。

データ・ボリュームと処理負荷を複数のパーティション間でリバランスさせて、データ分散の偏り を解消するため、DB2では、REDISTRIBUTE DATABASE PARTITION GROUPコマンドライン・ユー ティリティを用意しています。このユーティリティは、必要に応じて、手動で実行する必要があり ます[17]。これは、データベースのオフライン・バックアップ、内部的に生成されたソースおよびター ゲット分散マップの変更を必要とする複数の内部手順からなる厄介なユーティリティです。しかも、 このREDISTRIBUTEコマンドの実行中はデータベースに対する更新操作が禁止されます。 Oracle RACはスケーラビリティおよび高可用性を実現するのにパーティション化を必要としない共 有ディスク・サブシステムに基づいているため、Oracleには、上述のような設計およびパフォーマン ス上の欠陥は一切ありません。 DB2 pureScale 2009年の秋に、IBMは、DB2 9.8またはDB2 pureScaleと呼ばれるDB2 V9の新バージョンを発表しました。 これはIBMが初めてリリースした、Unixプラットフォーム向けの共有ディスク・ソリューションです。 ここ数年、IBMはDB2で巻き返しを図り、Oracleの後を追ってきましたが、このことは、Oracleが正 しい方向に向かっていることをIBMが認めているというもう1つの証拠です。 DB2 pureScaleは、非常に限られたハードウェア（IBM Power 6 P595またはP550）上の単一プラット フォーム用（AIX上のDB2）として発表され、インターコネクト・ネットワークにはInfiniBandが必 要です。他の業界標準のプラットフォームは、現在のところサポートされていません。DB2 pureScale は、OLTPアプリケーション専用に開発されたものです。 DB2 pureScaleは、DB2 HARD機能と統合されていません。インスタンス（DB2の用語ではメンバー） およびホスト障害に対する保護は提供できますが、データ破損、サイト障害、または地理的に広範 囲に影響を与える壊滅的な自然災害からの保護を実現することはできません。 DB2 pureScaleが提供する主要なテクノロジーは、一元化されたロック管理と、グループ・バッファ・ プールです。これらのコンポーネントは、専用のサーバーに常駐するか、または冗長性を維持する ため2台のサーバーに常駐します。このためシステムのオーバーヘッドが大きくなります。たとえば、 4ノードのクラスタの場合、pureScaleコンポーネントだけでハードウェア・コストが50%増大します。 グローバル・バッファ・プールのサイズは、単一のサーバーに搭載されているメモリの容量によっ て制限されます。

Oracle Real Application Clusters（Oracle RAC）

DB2の2つの完全に異なるクラスタリング・アーキテクチャとは対照的に、Oracleでは、Oracle Real Application Clustersを介して統一された共有ディスク・クラスタリング・ソリューションを提供して います。Oracle RACは、複数のアクティブ・サーバーのクラスタに1つのデータベースを透過的に配 置して、ハードウェア障害や計画停止時間に対するフォルト・トレランスを実現します。

Oracle RACは、Oracle E-Business Suite、PeopleSoft、Siebel、SAP、およびカスタム・アプリケーショ ンなどのパッケージ製品をはじめとした主流ビジネス・アプリケーションをすべてサポートしてい ます。また、シングル・サーバーによるシングル・ポイント障害を排除することにより、こうした アプリケーションで非常に高い可用性を実現します。Oracle RAC構成では、全ノードがアクティブ となって本番ワークロードを処理します。クラスタ内の1つのノードに障害が発生すると、残りの ノードでOracle Databaseが継続実行されます。そのため、アプリケーションを使用中のユーザーは作 業を継続しながら、一方では各ノードを停止してメンテナンスを実施できます。Oracle RACは、Oracle JDBC、Oracle Data Provider for .NET、Oracle Call Interfaceなどの中間層クライアントと統合され、個々 のノードの障害発生時に、自動で連携動作する接続プールと存続ノードへのアプリケーション・フェ イルオーバーを可能にします。 Oracle RAC構成は、標準の市販プロセッサ、ストレージ、およびネットワーク・コンポーネントを 使用して構築できます。また、シンプルな拡張モデルを使用して、アプリケーションを柔軟に拡張 できます。高度なロードバランシング・アルゴリズム（たとえば、実行時接続プールのロードバラ ンシングにサーバー側のロードバランシング・アドバイザリを統合したもの）を使用して、ユーザー・ セッションをクラスタ内でもっとも負荷の少ないノードに回すことができます。さらに、複合ワー クロード環境をサポートしているため、さまざまなオンライン・トランザクション処理（OLTP）ア プリケーションや意思決定支援システム（DSS）アプリケーションで1つのデータベースを共有でき ます。Oracle RACは、”サービス”という概念を使用して、同一データベース上で異なるアプリケー ション・ワークロードを管理するという難題に対してシンプルなソリューションを提供しています。 すなわち、DBAは、通常の運用時も障害に対処しているときも、どの処理リソースをどのサービス に割り当てるかを管理する権限を保有しています。サービスに対するリソースの割当てを簡単かつ 動的に行えるため、柔軟なエンタープライズ・グリッド環境を実現できます。

Oracle Automatic Storage ManagementとOracle ClusterwareはOracle RACを補完し、統合化されたストレー ジ管理とクラスタ・ソフトウェア・ソリューションによってエンタープライズ・グリッドを実現し ます。pureScaleと違って、Oracle RACには、OSやハードウェアの制約がないため、世界中の数万を 超える顧客サイトに配置されています。 IBMのクラスタリング・ソリューションと比較したときのOracle RACの技術的な利点について詳しく は、[19]を参照してください。

データ障害への対応

データ障害やメディア障害から保護し、リカバリするソリューションの設計は極めて重要です。シ ステム障害やネットワーク障害が発生すると、ユーザーがデータにアクセスできなくなるおそれが あり、適切なバックアップが作成されていない状態でメディア障害が発生すると、損失データをリ カバリできなくなるおそれがあります。 次の表に示すように、Oracleにはデータ障害に対応する幅広い機能が備わっており、これらがDB2と の差別化要因となっています。

表3：データ障害への対応 - OracleとDB2の比較 データ障害への対応 ORACLE DB2 組込みのデータベース障害検出、分析、および修復機能 対応 未対応 増分更新バックアップ計画 対応 未対応 全体バックアップ時の未使用ブロックの圧縮 対応 未対応 拡張されたバックアップ圧縮レベル 対応 未対応 リカバリ時の次のバックアップへの自動リストア・フェイルオーバー 対応 未対応 リストアのプレビュー 対応 未対応 試行リカバリ 対応 未対応 バックアップ作成時の暗号化 対応 未対応 中間ストレージ不要のネットワーク経由での直接的なデータベースのクローン作成 対応 未対応 ブロックレベル・メディア・リカバリ 対応 未対応 読取り専用表領域 対応 未対応 再開可能なバックアップ 対応 未対応 LOBの増分バックアップ 対応 未対応 統合ミラー化 対応 未対応

コマンドラインおよびOracle Enterprise ManagerベースのツールであるOracle Recovery Managerは、Oracle データベースのバックアップおよびリカバリを効率的に実行するために推奨されている方法です。 Oracle RMANにより、ファイル多重化や圧縮を用い、バックアップにおけるパフォーマンスおよびス ペース消費量の最適化を図ることができます。また、バックアップ処理時の本番データ・ブロック の整合性を検証し、さらにリストア時のバックアップの整合性を検証することにより、破損のない バックアップを作成します。Oracle RMANは、高速リカバリ領域を利用し、Oracle Secure Backup [20] とサード・パーティのテープ・バックアップ管理製品を統合して、一元管理されたD2D2T（Disk to Disk to Tape）のバックアップを実現します。

組込みのデータベース障害検出、分析、および修復機能

データ障害に直面すると、DBAはまず、問題の診断と適切なリカバリ計画の策定に時間を投入します。 障害の性質によっては、この調査と計画に費やす時間が総リカバリ時間の大部分を占めることもよ くあります。Data Recovery Advisor（DRA）は、障害（ブロック破損や消失ファイルなど）のリアル タイム自動検出や障害分析結果のレポートに加え、そのまま実行したり、カスタマイズして後で実 行したりすることができるリカバリ計画（RMANリカバリ・スクリプト）の作成により、この時間 を大幅に短縮します。さらに、データ整合性チェックにより、データベースの整合性を事前に監視 して、データの問題にユーザーが遭遇する前に把握して修復します。 DBAが数百単位のデータベースと数千単位のデータファイルを管理する大規模な環境では、DRAの 使用によりリカバリ診断および管理タスクを大幅に簡素化できます。また、DRAでOracleの障害を自 己診断することにより、ユーザーが重要な本番システムのリカバリに迫られて、不適切なリカバリ 計画の策定やミスをおかすリスクを軽減できます。

DB2は、Recovery Expert（別ライセンスのDB2 Toolkitの一部）によって、部分的にOracleと同等の機 能を提供しています。Recovery Expertは、個々のリカバリ・アクションについて最適な手順を提案し ますが、リアルタイムで障害を検出したり、障害診断を適切なリカバリ計画に結びつけたりするこ とはありません。 増分更新バックアップ計画 高速増分更新バックアップでは、増分バックアップを適用して、Oracle RMANによりイメージ・コピー がロールフォワードされます。イメージ・コピーは、最新の増分バックアップ取得時のSCNに基づ いて、ブロック変更時に更新されます。増分更新バックアップにより、データベースの全体バック アップを毎日作成する必要がなくなり、その分のオーバーヘッドを削減できます。DB2では、このよ うな機能は提供していません。 未使用ブロックの圧縮 Oracle RMANでは、全体バックアップ時にその時点で未使用のブロックを削除することにより、バッ クアップ・サイズを大幅に縮小できます。たとえば、1TBの表を削除および消去した場合、次の全体 バックアップではその1TB分のブロックはバックアップされません。DB2には、こうしたブロック排 除機能は備わっていません。 拡張されたバックアップ圧縮レベル

Oracle RMANは、Oracle Database 10gより、ネイティブのバックアップ圧縮機能を提供しています。 これにより、バックアップ・サイズの40%以上の削減を達成できます。Oracle Database 11g Release 2 より、Oracle RMANは、特定の環境の圧縮率とバックアップ・パフォーマンスに対する要求に柔軟に 適合するため、さまざまなバックアップ圧縮レベルを用意しています。ユーザーは、使用する圧縮 度に基づいて、HIGH、MEDIUM、LOWのいずれかのレベルを選択できます。DB2では、バックアッ プ圧縮設定（つまりライブラリ）をデフォルトで1つしか用意していません。追加の設定が必要な場 合、ユーザーは、サード・パーティ製の圧縮ライブラリを入手する必要があります。

リカバリ時の自動リストア・フェイルオーバー リストア時にバックアップの破損が検出された場合や、バックアップにアクセスできない場合、Oracle RMANはエラーを返す前に、確認済みのバックアップからのファイルのリストアを試行します。こ の機能は、RESTOREコマンドまたはRECOVERコマンドでファイルがリストアされるたびに自動的 に実行されるため、リストアが失敗した場合に有効なバックアップを検索したり、操作を再試行し たりする必要がありません。DB2には、このような機能は用意されていません。 リストアのプレビュー データベースのリストア処理を実行する前に、DBAは処理完了に必要なバックアップ・ファイルの 一覧を表示できます。Oracle RMANのリストアのプレビューでは、必要なバックアップがすべて入手 可能であるかどうかの確認や、特定のバックアップの使用または不使用を指示する条件の特定が可 能です。DB2では、このような機能は提供していません。 試行リカバリ テスト・リカバリは、最初に必要なアーカイブ・ログがすべて破損なく揃っていることを確認する 場合に非常に便利な機能であり、実際のメディア・リカバリを実行することなく、リストアされた データファイルに正常に適用できます。Oracleの試行リカバリはまさにこの機能を実行するもので、 リストアされたデータファイルが変更されることはありません。DB2では、このような機能は提供し ていません。 バックアップの暗号化 多くの企業にとって、機密性の高い極秘情報のバックアップを保護することは、安定性を確保する うえで極めて重要です。バックアップを開いて読み取ることができるのは、バックアップ作成者の みに限定する必要があります。Oracle RMANには、拡張暗号化規格（AES）の128ビット、256ビット、 および512ビット・バージョンを使用した、バックアップ作成時の暗号化機能が備わっています。DB2 は、ネイティブのバックアップ暗号化を提供していません。 ネットワーク経由のデータベース・クローニング DBAの一般的なタスクの1つに、テスト、品質保証、レポート、および障害時リカバリ用に本番デー タベースをクローニングするタスクがあります。リストアやクローン・データベースの作成にバック アップを使用することは可能ですが、その場合はバックアップのコピーや、クローン・サーバーへの アクセスの確立が必要です。Oracle Database 11gでは、Oracle RMANにより、オンラインの本番デー タベースのクローニングをネットワーク経由でクローン・サーバーに直接実行できるため、バック アップは不要です。DB2では、このようなクローニング機能は提供していません。

ブロック・メディア・リカバリ Oracleのブロックレベル・メディア・リカバリ機能を使用すると、1ブロックだけが破損した場合、 そのブロックだけがリカバリされます。ファイルの残りの部分、つまり当該ブロックを含む表はオ ンラインのまま維持され、アクセス可能なので、データの可用性が向上します。DB2では、単一ブロッ ク単位でのデータのリカバリはできないため、すべてのファイルをオフラインにして、リストアお よびリカバリする必要があります。

さらに、Oracle Database 11g Release 2では、Oracle Active Data Guardスタンバイ・データベースが構成 されている場合、プライマリ・データベースで発生した破損は自動的に検出され、スタンバイ・デー タベースの正常ブロックと一緒にインラインで透過的に修復されます。ユーザーまたはアプリケー ションから破損したブロックに問合せを発行した場合でも、ブロックが修復された後、問合せ結果 が返される間、短い一時停止が発生するだけです。DB2には、オンラインの自動ブロック修復機能は ありません。 再開可能なバックアップ OracleがOracle RMANを介して提供する別の時間節約機能として、再開可能なバックアップ操作があ ります。Oracleでは、バックアップ操作が失敗しても、障害発生時点から再開できます。DB2にはそ のような機能は用意されていないため、バックアップ中に問題が発生すると、すべての操作が最初 から再開することになり、時間が失われます。さらに問題を複雑にしているのが、DB2では、「バッ クアップ対象とリストア対象の表領域が異なる場合でも、表領域のバックアップ操作と表領域のリ ストア操作を同時に実行できない」点です[21]。 ラージ・オブジェクトの増分バックアップ ラージ・オブジェクト（LOB）には多くの場合、決して変更されないイメージや音声ファイルなど が格納されます。これらの増分バックアップは重要です。Oracleは、LOBの増分バックアップを実行 できますが、DB2では実行できません。したがって、 「表領域に、ロング・フィールド・データやラージ・オブジェクト・データが含まれている とき、増分バックアップを実行すると、当該表領域内に前回のバックアップ以降変更され たページが存在する場合は、すべてのロング・フィールド・データまたはラージ・オブジェ クト・データがバックアップ・イメージにコピーされます。」[22] Oracle ASMによる統合データのミラー化

Oracle Automatic Storage Managementは、Oracle Databaseに搭載されている統合ボリューム管理および

ファイル・システムであり、ディスク障害グループの概念に基づいたネイティブ・ミラー化メカニ ズムを提供します。このメカニズムを使用して、ストレージ障害からデータを保護できます。Oracle ASMの障害グループとは、障害を許容できる共有リソース（ディスク・コントローラまたはディス ク・アレイ全体）を持つ一連のディスクを指します。Oracle ASMのミラー化では、データベースの 範囲が割り当てられる際に、プライマリ・コピーとセカンダリ・コピーが作成され、セカンダリ・ コピーのディスクにはプライマリ・コピーとは異なる障害グループから選択されます。

この機能により、ストレージ・サブシステム内のコンポーネントの障害からデータを透過的に保護 して使用可能な状態を維持できます。Oracle ASMではこれだけではなく、破損ブロックの読取りに 伴う読取りエラーが発生した場合、正常なコピー範囲の読取りが透過的に行われ、読取りエラーが 発生したディスクにコピーされます。 DB2には、こうした統合ミラー化メカニズムによりデータ保護を強化する機能は備わっていません。

障害時リカバリへの対応

Oracle Data Guard

Oracle Data Guardは、障害、災害、エラー、データ破損からOracleデータを保護する1つ以上のスタン バイ・データベースを作成および維持するための、管理、監視、自動化ソフトウェア・インフラス トラクチャを提供します。本番サイトに計画停止や計画外停止が発生した場合、Oracle Data Guardを 使用すれば、データ損失ゼロでスタンバイ・データベースを本番データベース・ロールに簡単に切 り替え、クライアント接続を自動的にリダイレクトして、新しい本番データベースで企業のデータ・ ニーズへの対応を開始できます。Oracle Data Guardスタンバイ・データベースには2つのタイプがあ ります。フィジカル・スタンバイ・データベースはREDO Applyを使用し、プライマリ・データベー スの正確なレプリカをブロック単位で維持します。ロジカル・スタンバイ・データベースはSQL Apply を使用し、データの物理編成と物理構造は異なりますが、プライマリ・データベースと同じ論理情 報を保持します。Oracle Data Guard 11gの先進の機能（Oracle Active Data GuardとOracle Data Guard 11g Snapshot Standby）はどちらも、REDO Applyに基づいており、可用性、データ保護、操作透過性、お よびスタンバイ・ソフトウェア、サーバー、ストレージへの投資収益率を最高レベルで実現します。

IBM HADR

HADR（高可用性障害時リカバリ）はDB2 8.2で最初にリリースされ、IBMのInformix Dynamic Server acquisition [23]で提供されているHigh Availability Data Replication（略称HDR）と呼ばれる同様の機能 に基づいています。

DB2 HADRはソース・データベース（プライマリ）のデータ変更をターゲット・データベース（ス タンバイ）にレプリケーションします。サイトの一部または全部の障害が発生した場合、スタンバ イ・データベースがプライマリ・データベースを引き継ぎます。

Oracle Data Guardの相対的な長所

Oracle Data GuardとDB2 HADRの2つのテクノロジーを注意深く見てみると、前者が後者より優れて いる分野が多数存在することが分かります。エンタープライズ・データ保護と可用性の主要な要件 を確認して、詳細な比較を提供します。

データ保護とデータの高可用性 エンタープライズ・データ保護の最初の要件は、スタンバイ・データベースが、プライマリ・デー タベースの信頼できる完全なレプリカであると保証することです。つまり、プライマリ・データベー スとスタンバイ・データベースを同じ相対時点（たとえば、それぞれのデータベースに同じ挿入、 更新、削除、またはDDLトランザクションが適用された時点）で比較したとしたら、2つのデータベー スが互いに相手の完全なレプリカであることが確認されます。このレプリケーション・メカニズム のインフラストラクチャは、プライマリ・データベースとスタンバイ・データベース間で非一貫性 リスクが発生しないことを、比較を実行して検証する必要がない程度に保証する必要があります。 この特性によって、スタンバイ・データベースをあらゆる点でプライマリ・データベースの代理に する、つまり、どちらか一方のデータベースのバックアップを使用して他方のデータベースを元の 状態に戻すことができます。これにより、顧客は、データの相違が決して発生しないと保証するこ とで、あらゆる法規制やデータ保護のためのビジネス要件に対応できます。

この要件については、Oracle Data Guard REDO Apply（フィジカル・スタンバイ）とIBM HADRのど ちらも十分に満たしています。どちらもネイティブのデータベース・リカバリ・メカニズムを使用 して、プライマリ・データベースとスタンバイ・データベースが互いに相手の物理レプリカになる よう保証しています。同じ処理相対時点で2つのデータベース間にデータの相違が発生することはあ りません。プライマリ・データベースとスタンバイ・データベースを定期的に比較する必要はあり ません。これにより、本番データベースの論理レプリカを保持するSQLベースのレプリケーション・ テクノロジーよりも高いレベルのデータ保護を実現できます。

それでも、Oracle Data Guardのユーザーの方が、データ保護とデータ可用性という点で、IBM HADR に比べて高度な機能の恩恵を受けることができます。次の項で、これらの高度な機能について説明 します。 独立性 2番目の要件である独立性は、最初の要件があるために、実現がより難しくなっています。スタンバ イ・データベースはプライマリの完全なレプリカでなければなりませんが、同時に、プライマリ・ データベースに影響を与える可能性のある障害からスタンバイ・データベースを分離するために、2つ のデータベースは疎結合されていなければなりません。

この点に関しては、Oracle Data GuardとIBM HADRのどちらも高得点をつけることができます。どち らのソリューションもデータベース対応のプロセスを使用して、すべての変更データを別々に検証 してから、スタンバイ・データベースに適用します。スタンバイ側でも、スタンバイ・データベー スに変更内容を適用するとき、プライマリ側とは別のコード・パスを使用する必要があります。こ れにより、プライマリ・データベースの破損や障害に繋がるソフトウェアおよびハードウェア障害 によって、スタンバイ・データベースが影響を受けるのを防ぐことができます。このアプローチは、 物理ブロックのレプリケーションに限定されるストレージ・アレイのリモート・ミラー化よりもは るかに優れています。ストレージのミラー化では、複製するブロックがデータベース・レベルで検 証されることもなければ、トランザクション・セマンティクスについても感知しません。プライマ リ・データファイルに破損したブロックが適用されると、それがそのまま、リモート側のデータファ イルにもミラー化および適用されます。また、管理者がプライマリ・データベース側で重要なデー タやログ・ファイルを間違って削除するといった帯域外イベントも、リモート・ミラー化によって スタンバイ側に忠実に複製されてしまうため、両方のデータベースが使用不能になります。

データ保護の場合と同様に、Oracle Data Guardユーザーは、IBM HADRを使用した場合よりも、プラ イマリとスタンバイの間で優れた分離性を実現する高度な機能の恩恵を受けることができます。次 の項で、これらの高度な機能ついて説明します。 プライマリ・データベースに害を与えない データ保護ソリューションの3番目の要件は、「害を与えない」という医者がよく行う宣誓と同じです。 つまり、データ保護ソリューションが現実によくある次のような問題に遭遇したとき、プライマリ・ データベースのパフォーマンスと可用性が低下するようなことがあってはなりません。

• Wide Area Networkのサービス・レベルが予測不能である

• ワークロードが急増してピークに達し、ネットワークの容量を超える可能性がある

• スタンバイ・サーバー、ストレージ・サブシステム、およびネットワークで障害が発生した • 人的エラーによりサービスの中断やデータの破損が発生する可能性がある

Oracle Data Guardは、リモート・データ転送やスタンバイでの適用プロセスの進行に影響を与える可 能性のあるイベントからプライマリ・データベースを保護するという点で、IBM HADRよりもはる かに大きな利点をもたらします。また、Oracle HA機能との統合化により、IBM HADRでは不可能な、 人的エラーや論理的破損からの高速リカバリを可能にすることで、さらに高レベルのHA保護を実現 しています。これらの利点の多くは、Oracle Data Guard固有のアーキテクチャによってもたらされて います。詳細については、以下の各項で説明します。

投資収益率 - スタンバイ・ロール時のスタンバイ・サーバー、ストレージ、ソフトウェアの使用率

4番目の要件は、今日の経済環境の現実を反映したものです。停止時間に伴うコストが増大し続ける 中、包括的なデータ保護と高可用性を実現しながら、スタンバイ・サーバー、ストレージ、ソフト ウェアの投資収益率を最大化することが求められています。

Oracle Active Data Guardは、Oracle Database 11g Release 1で導入された機能です。この機能により、Oracle Data Guard構成で、1つ以上のフィジカル・スタンバイ・データベースを読取り専用でオープンした まま、プライマリ・データベースから受信した変更の適用を続行できます。Oracle Active Data Guard は、読取り専用でオープンされたOracleデータベースと同等の機能をすべて透過的に提供します。Oracle Active Data Guardスタンバイ・データベースに関して、特別な制限が課されたり、運用上の複雑さが 増大したりすることはありません。Oracle Active Data Guard 11g Release 2では、アクティブ・スタン バイ・データベースの価値をさらに高める高度なサービス品質機能が追加されました。

IBM HADRでは最近、DB2 9.7 Fix Pack 1で、アクティブ・スタンバイ・データベースが新しく導入さ れました。Oracle Active Data Guardと異なり、IBM HADR機能には、この分野では数多くの重大な制 限があります。これらの制限については、以下の項で説明します。