Oracle Database 11g Release 2とIBM DB2 9.7の技術比 …ƒ›ワイト・ペーパー - Oracle Database 11g Release 2とIBM DB2 9.7の技術比較：高可用性に重点を置いた比較

2009年12月

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

Oracleホワイト・ペーパー - Oracle Database 11g Release 2と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


はじめに

企業データのデータベース・ソリューションを検討中の組織は、データベースの高可用性機能につ

いても検討する必要があります。データは組織のもっとも重要なビジネス資産の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に基づいた分析を実施します。

2


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

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は、データベース・ファイルのネイティブ・ミラー化という保護機能を追加で提供します。人的エ

ラーから保護する機能としては、一連のフラッシュバック機能（フラッシュバック・データベース

やフラッシュバック表など）があります。この機能により、データベースを安全と分かっている時

点まで巻き戻して、長時間に及ぶ停止時間を発生させることなく人的エラーの影響を非常に簡単に

取り消すことができます。

3


さまざまなメディア障害からデータを保護するための機能としては、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データベー

ス同士でのみ使用できます。

4


計画停止時間の小化

計画停止時間には、ルーチン処理、定期メンテナンス、新規導入などの作業が含まれますが、とり

わけ複数のタイムゾーンに属するユーザーをサポートするグローバル企業では、計画停止時間は単

なる業務の中断に過ぎません。計画外停止時間の小化と同様に、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のおもな差別化要因を一

覧表示します。本書では、これらの差別化要因について詳しく説明していきます。

5


表1：おもな高可用性機能の差別化要因 - OracleとDB2

システム障害への対応 ORACLE DB2

予測可能なリカバリ時間対応未対応

リカバリ・アドバイザリ対応未対応

ロールバック中のデータの可用性対応未対応

パーティション内のデータの偏りに影響されない問合せパフォーマンス対応未対応

すべての主要なOSおよびサーバー・プラットフォーム用の統合化クラスタリング・テクノロジー対応未対応

OLTPおよびデータウェアハウス・アプリケーション向けの統一化クラスタリング対応未対応

クラスタ内での高速統合化された中間層接続フェイルオーバー対応未対応

クラスタ全体の包括的なロードバランシング機能対応未対応

エンタープライズ・グリッドを実現する自動ワークロード管理対応未対応

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

増分更新バックアップ計画対応未対応

全体バックアップ時の未使用ブロックの圧縮対応未対応

拡張されたバックアップ圧縮レベル対応未対応

リカバリ時の次のバックアップへの自動リストア・フェイルオーバー対応未対応

リストアのプレビュー対応未対応

試行リカバリ対応未対応

バックアップ作成時の暗号化対応未対応

中間ストレージ不要のネットワーク経由での直接的なデータベースのクローン作成対応未対応

ブロックレベル・メディア・リカバリ対応未対応

読取り専用表領域対応未対応

再開可能なバックアップ対応未対応

LOBの増分バックアップ対応未対応

統合ミラー化対応未対応

6


障害時リカバリへの対応 – データの保護と可用性 ORACLE DB2

スタンバイへの適用が進行してもプライマリのパフォーマンスやデータ保護に影響を与えない対応未対応

ネットワークの混雑が発生してもASYNC構成のプライマリ・データベースが決して停止しない対応未対応

プライマリ/スタンバイの初期化時、パラメータの変更時に可用性が影響を受けない対応未対応

ハードウェア/ソフトウェア障害によるサイレント破損がプライマリとスタンバイの両方で検出される対応未対応

破損ブロックが、ユーザーおよびアプリケーションに対して透過的に、オンラインで自動修復される対応未対応

人的エラーおよび論理的破損からの高速リカバリ対応未対応

データ損失とスプリット・ブレインなしの統合化自動データベース・フェイルオーバー対応未対応

ユーザーが構成可能なデータ損失SLAに準拠した、ASYNC用の管理された自動フェイルオーバー対応未対応

すべてのケースにおけるアプリケーションの接続時フェイルオーバー（データベース・ロールによる管理）対応未対応

フェイルオーバー後のプライマリの高速回復。元のプライマリが修復できる場合は、バックアップからリ

ストアせずに済む。これはフェイルオーバー時に、スタンバイがプライマリ・データベースと同期してい

たかどうかに関係なく当てはまる

対応未対応

複数スタンバイによるフェイルオーバー後のノンストップ保護対応未対応

メジャー・バージョンおよびサブバージョン間のデータベースのローリング・アップグレード対応未対応

スタンバイ・データベースをバックアップからリストア。バージョンのアップグレード後は不要。対応未対応

プライマリ/スタンバイの混合構成（例：32ビット/64ビット、Windows/Linuxなど）のサポートにより、テ

クノロジーの更新、保守、移行時の計画停止時間を短縮

対応未対応

効率的なネットワーク使用のための統合されたログ転送の圧縮対応未対応

ネットワークおよびスタンバイ・データベースの停止からの高速かつ中断のないリカバリ対応未対応

ストアド・プロシージャのスタンバイ・データベースへのレプリケーション対応未対応

データベース・パーティション化のサポート対応未対応

アクティブ-アクティブ・クラスタのサポート対応未対応

7


障害時リカバリのROI向上のための対応 – スタンバイ・データベースの使用率 ORACLE DB2

アクティブ・スタンバイ・データベースに対する読取り専用の問合せが、プライマリ・データベースに対

して実行された問合せと同じ完全な読取り一貫性を返す。問合せによる未コミットのデータへのアクセス、

非リピータブル・リードや仮読取りは不可能。

対応未対応

アクティブ・スタンバイ・データベースに対するデータ型制限がない（XML、LOB、LONG、ADTなど）対応未対応

ユーザーが、DDL再生中のアクティブ・スタンバイ・データベースに対する継続的な読取り専用アクセス

権を保有

対応未対応

ローカル・ログ・ファイルを使用して同期化されている中のアクティブ・スタンバイ・データベースに

ユーザー接続からアクセス可能

対応未対応

管理者はプライマリ・データベースとアクティブ・スタンバイ・データベースの大適用ラグ（0から’n’

秒）の目標値を設定できる。適用ラグはアクティブ・スタンバイ・データベースに対して実行中の読取り

専用問合せがビジネス要件を確実に達成できるように、自動的に監視される。手動による介入は不要

対応未対応

アクティブ・スタンバイ・データベースに対して自動メモリ管理機能がサポートされている。これにより

読取り専用のワークロード、およびフェイルオーバー発生後にスタンバイがプライマリに移行するときの

ワークロードのパフォーマンスが適化される。手動のチューニングは不要

対応未対応

スタンバイ・データベースに対するバックアップおよびアーカイブ操作がサポートされている対応未対応

バックアップとリストアがデータベース・ロールに対して透過的に実行される対応未対応

スタンバイ・データベースを二重目的に使用できる。すなわち、すべてのプライマリ・データベース・ト

ランザクションについて災害時保護を継続的に提供しながら、QAテストや他の読取り/書込みアクティビ

ティに使用できる

対応未対応

8


人的エラーへの対応 ORACLE DB2

SQL問合せを使用して過去の時点のデータを取得対応未対応

ごみ箱のサポート対応未対応

トランザクション・レベルでのデータベース変更の確認およびバックアウト対応未対応

行バージョンの変更の表示対応未対応

SQLインタフェースを使用したログのマイニングと変更の監査対応未対応

柔軟な表領域のポイント・イン・タイム・リカバリ対応未対応

過去の時点への表のフラッシュバック対応未対応

バックアップのリストアが不要の過去の時点へのデータベースのフラッシュバック対応未対応

システム・メンテナンスへの対応 ORACLE DB2

クラスタへのオンラインでのノード追加機能対応未対応

ディスクのオンライン追加と削除機能対応未対応

オンライン・パッチ対応未対応

フル・パッチセットとメジャー・リリースのローリング・データベース・アップグレード対応未対応

メモリをオンライン調整するための拡張サポート対応未対応

メモリ管理に関する有用なアドバイザリ対応未対応

大半の構成パラメータをオンラインで変更可能対応未対応

データ保守への対応 ORACLE DB2

パーティションのオンラインでの追加、交換、移動機能対応未対応

表をオンラインで再編成および再定義するための柔軟で包括的な機能対応未対応

個別の表パーティションのオンラインでの再編成機能対応未対応

デフォルト値を使用した、オンラインでの迅速な列追加機能対応未対応

列のオンラインでの名前変更とマージ機能対応未対応

非表示の索引対応未対応

排他ロック不要のオンラインでの制約の追加と変更、列の追加、索引の作成と再構築機能対応未対応

基礎リソースがビジーな場合のDDL操作待機機能（待機時間はユーザー指定）対応未対応

9


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

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

システム障害への対応

システム障害は、ハードウェア障害、電源異常、オペレーティング・システムやサーバーのクラッ

シュによって発生します。このような障害による中断の範囲は、影響を受けるユーザーの数とサー

ビスが復旧するまでの時間によって異なります。システム障害における課題は、高速リカバリの実

現であり、より理想的に言えば、高度なフォルト・トレランスです。

次の表に示すように、システム障害への効果的な対応方法において、OracleにはDB2との明確な差別

化の要因となる一連の機能が用意されています。

表2：システム障害への対応 - OracleとDB2の比較

システム障害への対応 ORACLE DB2

予測可能なリカバリ時間対応未対応

リカバリ・アドバイザ対応未対応

ロールバック中のデータの可用性対応未対応

パーティション内のデータの偏りに影響されない問合せパフォーマンス対応未対応

すべての主要なOSおよびサーバー・プラットフォーム用の統合化クラスタリング・テクノロジー対応未対応

OLTPおよびデータウェアハウス・アプリケーション向けの統一化クラスタリング対応未対応

クラスタ内での高速統合化された中間層接続フェイルオーバー対応未対応

クラスタ全体の包括的なロードバランシング機能対応未対応

エンタープライズ・グリッドを実現する自動ワークロード管理対応未対応

次項では、これらの差別化要因について詳しく説明します。

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

Oracleのファストスタート™ 障害リカバリ機能は、システム障害に関する停止時間を小化するよう

に設計されています。この機能は、ファストスタート・チェックポイントとファストスタート・ロー

ルバックの2つのコンポーネントからなります。前者は、チェックポイント位置を継続的かつ増分的に

進めることによってロール・フォワード・リカバリを適化します。後者は、リカバリのロールバッ

ク・フェーズにおける遅延をなくします。

10


ファストスタート・チェックポイント - 平均リカバリ時間の予測

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は、共有キャッシュ・アーキテクチャを備えたクラスタ・デー

タベースです。従来のシェアード・ナッシングおよび共有ディスク方式における限界を克服し、す

べてのビジネス・アプリケーションに高いスケーラビリティと可用性を備えたデータベース・ソリュー

ションを提供します。

11


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]。

12


フェイルオーバー直後の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つのメモリ断片を大限に活用する可能性があるからです。

• パーティション数の増加に伴い、データの負荷および（または）データの偏りが増大する可能性

があります。

13


データ・ボリュームと処理負荷を複数のパーティション間でリバランスさせて、データ分散の偏り

を解消するため、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つのデータベースを透過的に配

置して、ハードウェア障害や計画停止時間に対するフォルト・トレランスを実現します。

14


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との差別化要因となっています。

15


表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）のバックアップを実現します。

次項では、上記の表に示したOracleの差別化要因について詳しく説明します。

16


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

データ障害に直面すると、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つしか用意していません。追加の設定が必要な場

合、ユーザーは、サード・パーティ製の圧縮ライブラリを入手する必要があります。

17


リカバリ時の自動リストア・フェイルオーバー

リストア時にバックアップの破損が検出された場合や、バックアップにアクセスできない場合、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では、このようなクローニング機能は提供していません。

18


ブロック・メディア・リカバリ

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のミラー化では、データベースの

範囲が割り当てられる際に、プライマリ・コピーとセカンダリ・コピーが作成され、セカンダリ・

コピーのディスクにはプライマリ・コピーとは異なる障害グループから選択されます。

19


この機能により、ストレージ・サブシステム内のコンポーネントの障害からデータを透過的に保護

して使用可能な状態を維持できます。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つのテクノロジーを注意深く見てみると、前者が後者より優れて

いる分野が多数存在することが分かります。エンタープライズ・データ保護と可用性の主要な要件

を確認して、詳細な比較を提供します。

20


データ保護とデータの高可用性

エンタープライズ・データ保護の初の要件は、スタンバイ・データベースが、プライマリ・デー

タベースの信頼できる完全なレプリカであると保証することです。つまり、プライマリ・データベー

スとスタンバイ・データベースを同じ相対時点（たとえば、それぞれのデータベースに同じ挿入、

更新、削除、またはDDLトランザクションが適用された時点）で比較したとしたら、2つのデータベー

スが互いに相手の完全なレプリカであることが確認されます。このレプリケーション・メカニズム

のインフラストラクチャは、プライマリ・データベースとスタンバイ・データベース間で非一貫性

リスクが発生しないことを、比較を実行して検証する必要がない程度に保証する必要があります。

この特性によって、スタンバイ・データベースをあらゆる点でプライマリ・データベースの代理に

する、つまり、どちらか一方のデータベースのバックアップを使用して他方のデータベースを元の

状態に戻すことができます。これにより、顧客は、データの相違が決して発生しないと保証するこ

とで、あらゆる法規制やデータ保護のためのビジネス要件に対応できます。

この要件については、Oracle Data Guard REDO Apply（フィジカル・スタンバイ）とIBM HADRのど

ちらも十分に満たしています。どちらもネイティブのデータベース・リカバリ・メカニズムを使用

して、プライマリ・データベースとスタンバイ・データベースが互いに相手の物理レプリカになる

よう保証しています。同じ処理相対時点で2つのデータベース間にデータの相違が発生することはあ

りません。プライマリ・データベースとスタンバイ・データベースを定期的に比較する必要はあり

ません。これにより、本番データベースの論理レプリカを保持するSQLベースのレプリケーション・

テクノロジーよりも高いレベルのデータ保護を実現できます。

それでも、Oracle Data Guardのユーザーの方が、データ保護とデータ可用性という点で、IBM HADRに比べて高度な機能の恩恵を受けることができます。次の項で、これらの高度な機能について説明

します。

独立性

2番目の要件である独立性は、初の要件があるために、実現がより難しくなっています。スタンバ

イ・データベースはプライマリの完全なレプリカでなければなりませんが、同時に、プライマリ・

データベースに影響を与える可能性のある障害からスタンバイ・データベースを分離するために、2つのデータベースは疎結合されていなければなりません。

この点に関しては、Oracle Data GuardとIBM HADRのどちらも高得点をつけることができます。どち

らのソリューションもデータベース対応のプロセスを使用して、すべての変更データを別々に検証

してから、スタンバイ・データベースに適用します。スタンバイ側でも、スタンバイ・データベー

スに変更内容を適用するとき、プライマリ側とは別のコード・パスを使用する必要があります。こ

れにより、プライマリ・データベースの破損や障害に繋がるソフトウェアおよびハードウェア障害

によって、スタンバイ・データベースが影響を受けるのを防ぐことができます。このアプローチは、

物理ブロックのレプリケーションに限定されるストレージ・アレイのリモート・ミラー化よりもは

るかに優れています。ストレージのミラー化では、複製するブロックがデータベース・レベルで検

証されることもなければ、トランザクション・セマンティクスについても感知しません。プライマ

リ・データファイルに破損したブロックが適用されると、それがそのまま、リモート側のデータファ

イルにもミラー化および適用されます。また、管理者がプライマリ・データベース側で重要なデー

タやログ・ファイルを間違って削除するといった帯域外イベントも、リモート・ミラー化によって

スタンバイ側に忠実に複製されてしまうため、両方のデータベースが使用不能になります。

21


データ保護の場合と同様に、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機能には、この分野では数多くの重大な制

限があります。これらの制限については、以下の項で説明します。

22


比較のまとめ

次の表に、HADRに対するOracle Data Guardの長所をまとめます。

表4：障害時リカバリへの対応 - OracleとDB2の比較

障害時リカバリ – データの保護と可用性 ORACLE DB2

スタンバイへの適用の進行がプライマリのパフォーマンスやデータ保護に影響を与えない対応未対応

ネットワークの混雑が発生してもASYNC構成のプライマリ・データベースが決して停止しない対応未対応

プライマリ/スタンバイの初期化時、パラメータの変更時に可用性が影響を受けない対応未対応

ハードウェア/ソフトウェア障害によるサイレント破損がプライマリとスタンバイの両方で検出される対応未対応

破損ブロックが、ユーザーおよびアプリケーションに対して透過的に、オンラインで自動修復される対応未対応

人的エラーおよび論理的破損からの高速リカバリ対応未対応

データ損失とスプリット・ブレインなしの統合化された自動データベース・フェイルオーバー対応未対応

ユーザーが構成可能なデータ損失SLAに準拠した、ASYNC用の管理された自動フェイルオーバー対応未対応

すべてのケースにおけるアプリケーションの接続時フェイルオーバー（データベース・ロールによる管理）対応未対応

フェイルオーバー後のプライマリの高速回復。元のプライマリが修復できる場合は、バックアップからリ

ストアせずに済む。これはフェイルオーバー発生時に、スタンバイがプライマリ・データベースと同期し

ていたかどうかに関係なく当てはまる

対応未対応

複数スタンバイによるフェイルオーバー後のノンストップ保護対応未対応

メジャー・バージョンおよびサブバージョン間のデータベースのローリング・アップグレード対応未対応

スタンバイ・データベースをバックアップからリストア。バージョンのアップグレード後は不要対応未対応

プライマリ/スタンバイの混合構成（例：32ビット/64ビット、Windows/Linuxなど）のサポートにより、テ

クノロジーの更新、保守、移行時の計画停止時間を短縮

対応未対応

効率的なネットワーク使用のための統合されたログ転送の圧縮対応未対応

ネットワークおよびスタンバイ・データベースの停止からの高速かつ中断のないリカバリ対応未対応

ストアド・プロシージャのスタンバイ・データベースへのレプリケーション対応未対応

データベース・パーティション化のサポート対応未対応

アクティブ-アクティブ・クラスタのサポート対応未対応

23


障害時リカバリROI – スタンバイ・データベースの使用率 ORACLE DB2

アクティブ・スタンバイ・データベースに対する読取り専用の問合せが、プライマリ・データベースに対

して実行された問合せと同じ完全な読取り一貫性を返す。問合せによる未コミットのデータへのアクセス、

非リピータブル・リードや仮読取りは不可能

対応未対応

アクティブ・スタンバイ・データベースに対するデータ型制限がない（XML、LOB、LONG、ADTなど）対応未対応

ユーザーが、DDL再生中のアクティブ・スタンバイ・データベースに対する継続的な読取り専用アクセス

権を保有

対応未対応

ローカル・ログ・ファイルを使用して同期化されている中のアクティブ・スタンバイ・データベースに

ユーザー接続からアクセス可能

対応未対応

管理者は適用ラグ（0から’n’秒）を大化するサービス・レベルの目標を設定できる。適用ラグはアク

ティブ・スタンバイ・データベースに対して実行中の読取り専用問合せがビジネス要件を確実に達成でき

るように、自動的に監視される。手動による介入は不要

対応未対応

アクティブ・スタンバイ・データベースに対して自動メモリ管理機能がサポートされている。これにより

読取り専用のワークロード、およびスタンバイがフェイルオーバー発生後、プライマリに移行するときの

ワークロードのパフォーマンスが適化される。手動のチューニングは不要

対応未対応

スタンバイ・データベースに対するバックアップおよびアーカイブ操作がサポートされている対応未対応

バックアップとリストアがデータベース・ロールに対して透過的に実行される対応未対応

スタンバイ・データベースを二重目的に使用できる。すなわち、すべてのプライマリ・データベース・ト

ランザクションについて災害時保護を継続的に提供しながらQAテストと他の読取り/書込みアクティビ

ティに使用できる

対応未対応

以下の各項では、Oracle Data Guardの相対的な長所についてさらに詳しく説明します。

障害時リカバリ - データの保護と可用性

Oracle Data Guardのアーキテクチャと機能は、プライマリ・データベースのパフォーマンスを低下さ

せることなく、優れたデータ保護とデータ可用性を実現します。次にその例を挙げます。

スタンバイへの適用がプライマリのパフォーマンスやデータ保護に影響を与えない

障害の分離は、重要なOracle Data Guardの設計基準です。Oracle Data Guardのスタンバイ適用サービ

スは、すべての保護レベルおよび転送モード（SYNCとASYNC）で、プライマリ・データベースと

完全に非同期で動作します。状況によってスタンバイへの適用が遅れたり停止したりしても、プラ

イマリ・データベースのパフォーマンス、可用性、データ保護には一切影響ありません。Oracle Data Guardプライマリは、スタンバイへのデータ転送を継続します。スタンバイは、適用プロセスが追い

つくまで、または障害が修復されるまで、データをスタンバイ・データベースのローカルなログ・

ファイルにアーカイブすることによってトランザクションを継続的に保護します。

24


DB2 HADRは、このレベルの分離性または耐障害性を実装していません。スタンバイの適用が遅れ

ると、HADRスタンバイがプライマリのREDOデータの受信に使用しているバッファが一杯になります。

これにより、スタンバイはそれ以上のデータの受信をブロックし（データ損失のリスクが向上）、

HADRの同期モードまたは疑似同期モードにおける新規のプライマリ・トランザクションを即座にブ

ロックします。HADR非同期モードでは、これにより、次項で説明するとおり、ネットワークの混雑

が発生し、それがさらにプライマリ・データベースのトランザクションをブロックします。

プライマリを停止しない非同期ネットワーク転送

Oracle Data Guard ASYNCネットワーク転送は真に非同期で動作します。ネットワーク転送に影響を

与えるイベントが発生しても、プライマリ・データベースのパフォーマンスと可用性が影響を受け

ることはありません。

一方、DB2 HADR非同期構成でのプライマリ・データベース上のトランザクション処理は、ネット

ワークの混雑が発生するとブロックされる可能性があります。DB2 HADR Redbookには、次のように

記載されています。「ASYNCモードでは、ネットワークの混雑とスタンバイの受信バッファのあふ

れによって、プライマリのログ処理が停止します。このため、プライマリ上のトランザクションは、

混雑が解消されるまでブロックされます…」[24]

インスタンス化とパラメータを変更してもプライマリは影響を受けない

Oracle Data Guard構成は停止時間ゼロでインスタンス化されます。Oracle Data Guardパラメータは動

的で、プライマリ・データベースに一切影響を与えることなく変更できます。

DB2 HADR 構成パラメータは動的ではありません。たとえば、 HADR_TIMEOUT や

HADR_SYNCMODEなどのパラメータに対する変更は、データベースをシャットダウンおよび再起

動した後、初めて有効になります。このようなパラメータのプライマリ値とスタンバイ値は一致し

ていなければならないため、変更を有効にするには、プライマリとスタンバイの両方で停止時間が

必要になります。

書込み損失によって発生するサイレント破損の検出

Oracle Data Guardは、書込み損失に対して業界固有の保護機能を実現しています。I/Oサブシステムが

Oracleに対して書込み完了通知を返してきたものの、実際には、永続ストレージに対する書込みが行

われていない場合、書込み損失が発生します。このI/Oサブシステムは、後続ブロックの読取りで、

古いバージョンのデータ・ブロックを返します。このブロックが、データベースの他のブロックの

更新に使用されるため、データベースが破損します。Oracleでは、DB_LOST_WRITE_PROTECT初期

化パラメータが提供されています。このパラメータを設定すると、バッファ・キャッシュ・ブロッ

ク読取りがREDOログに記録され、この情報を使用して書込み損失が検出されます。Oracle Data Guardのスタンバイ・データベースでは、管理リカバリ時にこのREDOが適用され、対応するブロックが読

み取られてSCNとREDOログのSCNとの比較が行われ、書込み損失があるかどうか判断されます。プ

ライマリ・データベースの書込み損失を修復するための推奨手順は、フィジカル・スタンバイへの

フェイルオーバーとプライマリの再作成です。スタンバイで書込み損失が発生しても、スタンバイ・

データベースまたは影響を受けたファイルを再作成するだけで済みます。

DB2 HADRには、書込み損失を検出して、それによって発生するデータ損失や本番データベースの

停止時間を回避する機能は備わっていません。

25


プライマリ・データベースとスタンバイ・データベースのどちらかで、破損ブロックを自動修復

Oracle Active Data Guard 11g Release 2を使用すると、破損ブロックを自動修復できます。ブロックレ

ベルのデータ損失は、通常、断続的でランダムなI/Oエラー、および破損したメモリのディスクへの

書込みによって生じます。Oracleシステムで破損が検出されると、そのブロックにはメディア破損と

いうマークが付けられ、ディスクに書き込まれます。そして、通常はORA-1578エラーがアプリケー

ションに返されます。そのブロックに対する後続の読取りは、そのブロックを手動でリカバリする

まで成功しません。ただし、Oracle Active Data Guardのスタンバイ・データベースが稼働しているプ

ライマリ・データベースで破損が発生した場合は、スタンバイ・データベースのブロックの正常な

コピーを使用して、アプリケーションに対して透過的に、ブロック・メディア・リカバリが自動的

に実行されます。また、スタンバイ・データベースの不良ブロックは、プライマリ・データベース

の正常なバージョンのブロックを使用して自動的にリカバリされます。

人的エラー関連の破損を元に戻す組込みメカニズム

人的エラーは、停止時間のおもな原因の1つです。人的エラーは論理的な破損につながり、それが広

がって、ポイント・イン・タイム・リカバリ操作の必要が生じるため、かなり長い停止時間が発生

する可能性があります。Oracle Data Guardでは、適用遅延を使用してこうした破損から迅速にリカバ

リできます。適用遅延とは、一定の期間、スタンバイへのREDOの適用を遅延させる機能です（遅延

期間は設定可能です）。管理者はこの機能を使用して、スタンバイ・データベースにエラーが適用

される前にスタンバイへのフェイルオーバーを実行したり、有効なデータをスタンバイからエクス

ポートしてプライマリ・データベースの正確な修復に使用したりすることができます。こうしたエ

ラーの典型例は、プライマリ・データベースで実行される不正なバッチ・ジョブです。

遅延を使用する際に妥協しなければならないことがあります。それは、初にスタンバイ・データ

ベースにログ・データのバックログを適用しないと、プライマリ・データベースとして使用できな

いため、フェイルオーバーが必要な場合は、停止時間が長くなるという点です。Oracle Flashback Databaseは、Oracle Data Guardのユーザーに代わりの方法を提供します。すなわち、プライマリ・データベー

スとセカンダリ・データベースを直前の時点に迅速にリカバリできるようにすることで、これまで

と同レベルの保護を実現します。Oracle Flashback Databaseでは、スタンバイ・データベースが常に

新の状態に維持されるため、フェイルオーバー時に遅延が発生しません。Oracle Flashback Databaseは、

新の問合せとレポートにOracle Active Data Guardスタンバイを使用する場合にも推奨される方法です。

DB2 HADRには、上記のような機能は一切用意されていません。

データ損失なしの統合化された自動データベース・フェイルオーバー

Oracle Data Guardのファストスタート・フェイルオーバーは、プライマリ・データベースの停止を自

動的に検出して、事前に選択されて同期化されたスタンバイ・データベースに対してフェイルオー

バーを実行します。手作業による介入やクラスタウェアとの外部統合は必要ありません。元のプラ

イマリ・データベースが修復、マウントされ、新しいプライマリ・データベースとの接続を確立で

きる状態になると、Oracle Data Guardは自動的に、障害の発生したプライマリ・データベースをスタ

ンバイ・データベースに自動的に変換して、再同期化します。（SYNC構成とASYNC構成の両方と

も）時間のかかるバックアップからのリストアは必要ありません。ファストスタート・フェイルオー

バーを使用すると、自動フェイルオーバーによってスプリット・ブレイン（プライマリ/スタンバイ構

成の2つ以上のデータベースが同時にプライマリとして動作する状態）が発生することもなくなります。

26


DB2 HADRには、障害の発生したプライマリを自動的に検出して、引継ぎ操作を実行する機能は用

意されていません。このプロセスは手動になります。管理者は、プライマリ・データベースが使用

不可能になっているかどうかを確認してから、引継ぎコマンドを実行する必要があります。

IBMでは、HADR構成の自動フェイルオーバーの実装を回避する方法として、クラスタ・マネージャ

を使用することを推奨しています。それには統合とスクリプティングを個別に行う必要があり、WANの配置に長距離クラスタの実装が必要となる典型的な災害時リカバリでは、さらに複雑になります。

自動フェイルオーバーがHADRに備わっていないとなると、外部統合やスクリプティングによって、

考えられるすべての障害シナリオでスプリット・ブレインの発生を確実に防止するよう注意を払う

必要があります。

非同期構成用の統合化された自動フェイルオーバー

Oracle Data Guard 11gは、ファストスタート・フェイルオーバーを拡張することで、大パフォーマ

ンス・モード（ASYNC）もサポートしています。自動フェイルオーバーを保証するユーザー設定可

能なデータ損失しきい値の追加によって、任意のリカバリ・ポイント目標（RPO）を超えるデータ

損失は発生しません。SYNCの場合とまったく同様に、元のプライマリはスタンバイ・データベース

として自動的に復旧します。バックアップからのリストアは必要ありません。

ユーザーは、自動フェイルオーバーが、指定されたヘルス・チェック条件または特定のORA-nnnnnエラーに基づいて即座に実行されるように構成することもできます。

新しいDBMS_DG PL/SQLパッケージによって、アプリケーションは、自動フェイルオーバーを開始

するようOracle Data Guardに通知することもできます。

DB2 HADRには、このような機能はありません。

すべてのケースにおけるアプリケーションの接続時フェイルオーバー

Oracle Data GuardとOracleの透過的アプリケーション・フェイルオーバー（TAF）の組合せにより、

代替接続記述子を使用して、クライアント側の接続時フェイルオーバーを有効にすることができます。

Oracle Data Guard 11g Release 2は、ロール固有のデータベース・サービスを実装しています。これに

より、その時点のデータベースのロール（プライマリ、スタンバイ、スナップショット・スタンバ

イ）に合わせて各種サービスが自動的に開始されます。Oracle Data Guardの自動クライアント・フェ

イルオーバー構成では、フェイルオーバー先を確定するのにクライアントがプライマリ・データベー

スに接続されていなくてもかまいません。これは、プライマリ・データベース側で新規のクライアント

接続を受け入れられない場合、あるいは複数のスタンバイ・データベースを構成しており、フェイル

オーバー時にどのスタンバイもプライマリのロールを引き継ぐことができる場合に重要となります。

DB2 HADRの自動クライアント再ルーティング（ACR）は、接続時フェイルオーバーをサポートし

ていません。ACRは、“db2 update alternate server...”コマンドを使用して、スタンバイ・データベー

スをプライマリ・データベースに登録することによって機能します。このコマンドを発行した後、

クライアントは代替サーバー情報を取得するためプライマリ・データベースに正常に接続する必要

があります。そもそもプライマリ・データベースがダウンしているために、クライアントがプライ

マリ・データベースに接続できない場合、自動再ルーティングは実行されません。

27


また、ACRはデータベース・ロールという概念を実装していません。このため、アプリケーション

が間違ったデータベースに接続してしまう可能性があります。IBMのドキュメント[25]には次のよう

に記載されています。

「クライアント再ルーティングでは、書込み可能なデータベース（プライマリおよび標準データベー

ス）と読取り専用のデータベース（スタンバイ・データベース）を区別しません。プライマリ・デー

タベースと標準データベースの間でクライアントの再ルーティングを構成すると、アプリケーショ

ンが、接続先として意図しないデータベースにルーティングされる可能性があります。」

非同期構成におけるプライマリの簡単な復旧

Oracle Data Guardは、障害の発生したプライマリ・データベースを新しいスタンバイ・データベース

として高速に復旧させることができます。その際、データ損失ゼロのフェイルオーバー（SYNC）の

場合も、データ損失ありのフェイルオーバー（ASYNC）の場合も、バックアップからのフル・リス

トアは必要ありません。これにより、構成を保護された状態に迅速に戻すことができるので、DBAが行う作業は、事実上発生しません。

DB2 HADRでは、フェイルオーバー時にプライマリ・データベースとスタンバイ・データベースが

完全に同期していない場合はいつでも、バックアップからのフル・リストアが必要になります。数

テラバイトのデータベースとWANトポロジがごく一般的な構成であり、そうした構成では長い待機

時間や帯域幅の制限によって、リモートからのリストアにますます時間と費用がかかるため、バッ

クアップからのフル・リストアは気が遠くなる作業になる可能性があります。このような制約があ

るため、次のような望ましくない結果になります。

• 停止してかなりの時間が経過してから後の手段として、スタンバイ・データベースへのフェイ

ルオーバーが行われる傾向がある。

• 高いネットワーク・コストが発生する。このため、新規プライマリのバックアップを元のプライマリ・

サイトに転送している間、同じネットワーク帯域幅を共有する他のアプリケーションが中断される。

• リストア・プロセス中の人的エラーへの対応に伴う時間、労力、フラストレーション、その他の

潜在的な問題によって、DBAが、さらなる時間、労力を費やし、フラストレーションが溜まる結

果になることが多い。

• 新しいプライマリ・データベースが保護されていない状態になる期間が長くなるため、2次的な障

害が発生すると、データ損失と停止時間に対する保護から無防備となる。

複数のスタンバイ・データベースのサポート

Oracle Data Guardは、単一のOracle Data Guard構成内で非常に柔軟な構成オプションを指定することで、

複数のスタンバイ・データベースをサポートします。たとえば、プライマリ・データベースにロー

カルのSYNCスタンバイ・データベースを配置し、セカンダリ・データベースにリモートのASYNCスタンバイ・データベースを配置できます（大30のスタンバイ・データベースを直接接続できます）。

いずれか1つのスタンバイ・データベースにフェイルオーバーを実行すれば、残りのスタンバイ・デー

タベースにより新しいプライマリが自動認識されて、障害イベントの全期間にわたって継続的にデー

タ保護が実行されます。

この方法により、データ保護とデータ可用性が向上するだけでなく、他の目的（非定型問合せとレ

ポートのオフロード、読取りパフォーマンスのスケール、バックアップ、QAテストの実行、データ

ベースのローリング・アップグレードの実行、移行など）に使用するために複数のOracle Data Guardスタンバイ・データベースを簡単に配置できます。この機能の分かりやすい使用例として、Appleの

28


例があります。同社では、シングルのOracle Active Data Guard構成を使用して、データの保護を実現

したり、休暇シーズン中の需要がピークに達する時期に対応するために読取りパフォーマンスを簡

単にスケールさせたりしています。

DB2 HADRでは、プライマリごとに単一のスタンバイ・データベースしか使用できないため、2次的

な障害によってデータの損失と可用性の低下が起こりやすくなります。

メジャー・バージョンおよびサブバージョン間のデータベースのローリング・アップグレード

Oracle Data Guardは、Oracle Database 10.2.0.4より、ロジカル・スタンバイ・データベースについて、

Oracle 11.1.0.6以降はフィジカル・スタンバイ・データベースについても、メジャー・バージョンお

よびサブバージョン間のローリング・アップグレードをサポートしています（Oracle Data Guard 11gの一時ロジカル・スタンバイを使用）。アップグレードを実行するために、Oracle Data Guardスタン

バイ・データベースを再作成する必要はありません。

DB2 HADRは、DB2のバージョン間またはメジャー・サブバージョン間（たとえば、8.2から9.1、あ

るいは9.1から9.8など）でのローリング・アップグレードをサポートしていません（ローリング・アッ

プグレードはIBM Fix Pack間でのみサポートされています）。HADRプライマリ・データベースの更

新中はデータベースを停止する必要があります。

データベース・バージョンのアップグレード中にスタンバイ・データベースをリストアする必要はありません。

Oracle Data Guardでは、データベースの新バージョンにアップグレードした後、プライマリの新しい

バックアップからスタンバイ・データベースをリストアする必要はありません。

DB2 HADRでは、DB2の新バージョンまたはメジャー・サブバージョンに移行するとき、新バージョ

ンになってから作成したプライマリ・データベースの新しいバックアップからスタンバイ・データ

ベースをリストアする必要があります。この操作には、DBAの作業時間とネットワーク帯域幅が消

費されます。とりわけ、超大規模データベースまたはWANを使用している場合には、その消費量が

大きくなります。結果として、プライマリ・データベースが保護されない時間が長くなります。

プライマリ/スタンバイの混合構成による計画停止時間短縮のサポート

Oracle Data Guardは、多数の構成をサポートする柔軟性を備えています。たとえば、プライマリ・シ

ステムとスタンバイ・システムで、異なるCPUアーキテクチャ、異なるオペレーティング・システ

ム（例：WindowsとLinux）、異なるオペレーティング・システム・バイナリ（32ビット/64ビット）、

異なるOracleデータベース・バイナリ（32ビット/64ビット）を指定できます。これにより、特定の

プラットフォームの移行やテクノロジーの更新を実行するとき、計画済みの停止時間とリスクを軽

減できます。

Oracle Data Guardは、単一インスタンスのOracle DatabaseからOracle RACやOracle Exadataストレージ

などの自動ストレージ管理（ASM）に移行するときにも使用できます。

後に、Oracle Data Guardスタンバイ・データベースは、プライマリ・データベースよりも少ないリ

ソース（CPU、メモリ、I/Oなど）で構成できます。これにより、顧客に柔軟な配置オプションを提供で

きます。たとえば、単一サーバー上またはOracle RACクラスタ上に複数のスタンバイ・データベースのホ

スティングを統合する配置モデルがあるとします。このようなモデルがビジネスの目的に適合する場合

は、このようなモデルを採用することでスタンバイ・データベースに必要な投資を削減できます。

29


DB2 HADRにはそのような柔軟性はありません。プライマリ・システムとスタンバイ・システムに

おける相違は一切認められません。これは、多くの場合、アーキテクチャ上の理由によるものです

が、スタンバイ・データベースのリソースが不足していると、プライマリ・データベースのパフォー

マンスとデータ保護機能を低下させるのではとの懸念が原因になっている場合もあります。Oracle Data Guardには、このような制限はありません。

統合化されたネットワーク転送の圧縮

Oracle Data Guard 11g Release 2とOracle Advanced Compressionオプションの組合せにより、プライマ

リ・データベースとスタンバイ・データベース間のすべてのREDO送信を自動的に圧縮できます。転

送圧縮により、使用可能なネットワーク帯域幅を効率的に利用できます。これにより、顧客は、帯

域幅が制限され、REDOボリュームが使用可能な帯域幅を超えている場合でも、リカバリ・ポイント

の目標を達成できます。また、停止によってネットワーク転送が中断された後の、プライマリ・デー

タベースとスタンバイ・データベースの再同期化が高速化されます。

DB2 HADRはネットワーク圧縮の統合化機能を提供していません。

レプリケーションおよびスタンバイ・データベースの停止からの高速かつ中断のないリカバリ

Oracle Data Guardは、転送圧縮だけでなく、高速でログ・ギャップを解消するように設計されている

ため、レプリケーションに影響を与えるすべての停止（ネットワークやスタンバイ・データベース

の停止）から迅速にリカバリできます。複数のOracle Data Guardパラレル・バックグラウンド・プロ

セスは、長時間の停止の後、スタンバイ・データベースを再同期化するために必要な大容量のアー

カイブ・ログ・データを自動的に転送します。このプロセスがバックグラウンドで実行されている

間、Oracle Data Guardは、新のログ・ファイル・データも送信します。これにより、送信が現在以

上に遅れるのを防ぐことができます。高ボリュームのパラレル送信が可能なのは、Oracle Data Guard構成では、プライマリ・システムとスタンバイ・システム間で高度な分離が行われているからです。

送信する必要のある未処理のデータが大量に存在する場合、Oracle Data Guardスタンバイ・データ

ベースは処理可能な量よりも速くデータを受信できるので、ネットワーク転送およびプライマリ・

データベースのパフォーマンス、または可用性が低下することはありません。スタンバイのデータ

受信速度が高速であるほど、データ保護速度も高速になり、データベースは、より短い時間で保護

された状態に復帰します。

IBM HADRには、このような機能はありません。

Oracle Data Guardでは、プライマリ・データベースで計画外停止が発生したり、レプリケーションが

突然終了したりしても、Oracle Data Guardの構成を通常の動作状態に戻すためにスタンバイ・データ

ベースを再作成する必要はありません。

DB2 HADRではそうはいきません。DB2のドキュメント[27]に記載されている次のようなシナリオで

考えてみます。

「兆候：たとえば、オペレーティング・システムの修正が実行され、DB2に対する事前のメールによ

る警告なしにサーバーがリサイクルされたとします。結果として、HADRは切断され、再起動を試行

しても繰り返し失敗します。

30


対策：この場合、スタンバイ側のログ・レコードが一致しないか、失われたため、プライマリ側と

正常に再統合できないことが、もっとも考えられる原因です。これを確認するには、db2diag.logファ

イルの出力に、プライマリまたはスタンバイ上でHADRの起動を試みた時刻を確認します。このエ

ラー・メッセージの意味は明白です。エラー発生後の対応策も単純です。プライマリをバックアッ

プし、スタンバイに転送し、スタンバイ側でリストアすることによって、HADRを再構築するしかあ

りません。」

データベース・パーティション化とストアド・プロシージャのレプリケーションのサポート

Oracle Data Guard REDO Applyは、データベースのパーティション化を透過的にサポートしており、

すべてのストアド・プロシージャを複製します。

DB2 HADRは、DB2のパーティション化機能（データベース・パーティション化機能 - DPF）をサポー

トしていません。ストアド・プロシージャも複製しないため、HADRスタンバイ側において手動で再

作成する必要があります。

アクティブ-アクティブ・クラスタの完全なサポート

Oracle Data GuardはOracle RACと完全に統合化されています。どのプライマリ・データベースまたは

スタンバイ・データベースもOracle RACクラスタになることができます。すべてのOracle Data Guard保護モード、転送モード、および適用モードがサポートされています。REDOデータの自動転送とリ

カバリは、すべての構成で使用可能です。フィジカル・スタンバイ・データベース（Oracle RACまたはシングルノード）もアクティブ・スタンバイ・データベースになることができます。また、プ

ライマリ・データベースから受信したアップデートを適用する間は読取り専用問合せが可能です。

Oracle Data GuardとOracle RACは、Oracle Databaseによってサポートされているすべてのプラット

フォームに対応しています。

DB2 HADRは、DB2 pureScaleをサポートしていません。

障害時リカバリのROI - スタンバイ・データベースの利用

Oracle Data Guard REDO Apply（フィジカル・スタンバイ）には、スタンバイ・ロールでの実行中に、

スタンバイ・データベースのサーバー、ストレージ、ソフトウェアを本番目的に簡単に利用できる

高度な機能が用意されています。これにより、DR投資に対する高い収益率を実現できます。Oracle Data Guardスタンバイ・データベースを利用する高の機能の1つは、Oracle Database 11g Release 1から使用可能になったOracle Active Data Guardによって提供されます。Oracle Active Data Guardを使用

すると、Oracle Data Guardフィジカル・スタンバイ・データベースを、本番データベースの超高パ

フォーマンスのリアルタイム同期レプリケーションとして利用できます。このレプリケーションは、

本番データベースと同時に読取りアクセス可能です。これにより、読取り専用アプリケーション・

モジュール（レポート作成アプリケーションなど）の負荷をOracle Active Data Guardフィジカル・ス

タンバイにオフロードして、アプリケーション全体のスループットを高めることができます。高速

増分バックアップをフィジカル・スタンバイ・データベースにオフロードして、本番サーバーのパ

フォーマンスをさらに高めることもできます。また、前述のとおり、Oracle Active Data Guardは、ア

クティブ・データ・ブロックのリアルタイム・リポジトリとしても使用できます。

31


アクティブ・データ・ブロックは、本番アプリケーションを中断することなく、プライマリ・デー

タベースの破壊されたブロックを透過的に修復するときに使用します。

一方、DB2 HADRがHADRスタンバイの読取り機能の提供を始めたのは、2009年後半にリリースされ

たDB2 v9.7 Fix Pack 1からです。IBMはこの機能をHADRアクティブ・スタンバイ・データベースと

呼んでいますが、制約が多いため、使用できないか、レポート作成アプリケーションとして十分な

サービス品質を提供できません。IBM HADRアクティブ・スタンバイは、オンライン・バックアッ

プのサポートやオンラインの透過的なブロック破壊保護機能など、Oracle Active Data Guardの高度な

機能も提供していません。

Oracle Data Guardフィジカル・スタンバイ・データベースは、Oracle Active Data Guardの機能を提供

する他に、データ保護損失ゼロのスタンバイ・ロールで実行中に、読取り/書込み用テスト・システ

ムとして利用することもできます。DB2には、このような機能はありません。

次の各項では、スタンバイ・データベースの利用という観点から見て、Oracle Data GuardがDB2 HADRよりも優れている点を詳しく説明します。

アクティブ・スタンバイ・データベースで実行中の問合せの完全な読取り一貫性

Oracle Active Data Guardスタンバイ・データベースは、プライマリ・データベース・トランザクショ

ンから受信した変更内容を適用している間、読取り専用問合せとレポート用にアクセス可能です。

また、プライマリ・データベースによって使用されているのと同じ完全な読取り一貫性モデルを実

装しています。Oracle Active Data Guardスタンバイ・データベースは、プライマリ・データベースで

問合せを実行したときとまったく同じように、正確な新の結果を返すことができます。これによ

り、Oracle Active Data Guardスタンバイ・データベースは、プライマリ・データベースからワークロー

ドをオフロードする信頼性の高い方法として、プライマリ・データベースのパフォーマンスを大幅

に向上させ、スタンバイ・システムに対する投資の収益率を高めます。

IBM HADRは近、HADRスタンバイ・データベースに対する読取り専用アクセスを許可する新しい

機能を発表しましたが、この発表もやはり、多くの重大な制限が目立っていました。たとえば、HADRがサポートできるのはUncommitted Read（UR）分離レベルだけであり、HADRスタンバイ・データ

ベースを実行する問合せの読取り一貫性は提供していません。HADRアクティブ・スタンバイ・デー

タベースからの読取り一貫性を求めるすべてのアプリケーション、文、またはサブ文は、エラーに

なります。より制限されたUR分離レベルに準拠した問合せを実行すると、信頼できない結果になり

ます（このような問合せは未コミット・データにアクセスでき、非リピータブル・リードや仮読取

りが可能です）。

アクティブ・スタンバイ・データベースに対するデータ型制限なしの問合せ

Oracle Data Guardは、比類のない操作透過性を実現します。Oracle Data Guard REDO Apply（フィジカ

ル・スタンバイ）は、すべてのデータ型についてレプリケーションと読取り専用アクセスを完全に

サポートしています。データ型に関する制限は一切ありません。

32


IBM HADRでは、XMLおよびラージ・オブジェクト（LOB）データ型、ロング・フィールド（LF）、

これらのデータ型のいずれかに基づく別の型、構造型列を、アクティブ・スタンバイ・データベース

で問い合わせることはできません。これらのデータ型に対して問合せを実行するとエラーになります。

DDL再生中のアクティブ・スタンバイ・データベースに対する継続的な読取り専用アクセス

DDL操作は、Oracle Active Data Guardスタンバイ・データベースに透過的に複製されます。DDLログ・

レコードや保守操作が適用される間、アクティブ・スタンバイに問い合わせる可能性のあるアプリ

ケーションのパフォーマンスに影響を与えることは一切ありません。

一方、HADRアクティブ・スタンバイ・データベースは、DDLログ・レコードの再生中または保守操

作中は、すべての既存の接続を終了し、新規の接続をブロックします。HADRスタンバイに対する新

しい接続は、すべてのアクティブDDLが再生された後、または保守操作が完了した後に初めて許可

されます。

DDL同期中のアクティブ・スタンバイ・データベースに対する継続的な読取り専用アクセス

読取り専用ユーザーは、ログ・データのソースがスタンバイ・データベースに対してローカルであ

るかリモートであるかに関係なく、スタンバイからプライマリへのレプリケーションおよび同期の

全フェーズ期間中、Oracle Data Guardアクティブ・スタンバイ・データベースに対して継続的にアク

セス可能です。

HADRは、ローカルのログ・ファイル・パスに存在するログ・ファイルを適用することによってアクティ

ブ・スタンバイ・データベースが同期化されている間、アクティブ・スタンバイ・データベースに

対する接続を許可しません。この状態を、IBMではローカル・キャッチアップ状態と呼んでいます。

Oracle Active Data Guardには、このような制限はありません。

アクティブ・スタンバイ・データベースに対する問合せSLA（品質保証契約）の自動監視と自動実施

Oracle Database 11g Release 2より、Oracle Active Data Guardでは、構成可能な品質保証契約（SLA）が

有効になっています。SLAは、セッション・パラメータSTANDBY_MAX_DATA_DELAYを使用して

実装します。このパラメータの値で、プライマリ・データベースで変更がコミットされてから、ア

クティブ・スタンバイ・データベースでその変更内容が問合せ可能になるまでの許容される経過時

間の制限（秒単位）を指定します。この時間制限をオーバーした場合、アクティブ・スタンバイ・

データベースからエラー・コードORA-3172が返されます。アプリケーションは、切断の場合と同様

に、このエラーに対して応答し、問合せを別のアクティブ・スタンバイ・データベースまたはプラ

イマリ・データベースにリダイレクトすることで、必要なSLAを満たすことができます。これにより、

管理者は、スタンバイ適用の進行状況を監視したり、レポート要件を満たすカレント・データベー

スになるためのアクティブ・スタンバイ・データベースの能力に影響を与えるイベント（プライマ

リとスタンバイ・データベース間のネットワーク接続の中断など）に応答したりする作業から解放

されます。

DB2 HADRには、アクティブ・スタンバイ・データベースに関して、このような機能はありません。

自動メモリ管理

Oracle Data Guardスタンバイ・データベースは、自動メモリ管理をサポートしています。

33


IBMのセルフチューニング・メモリ・マネージャ（STMM）は、HADRスタンバイ上ではサポートさ

れていません。スタンバイ・データベースをチューニングすることで、読取り専用ワークロードの

実行に適合させたり、フェイルオーバー発生後もパフォーマンスを維持したりするには手作業が必

要になります。

スタンバイ・データベースをバックアップに使用する機能

Oracle Data Guardフィジカル・スタンバイ・データベースを使用して、プライマリ・データベースか

らのバックアップの負荷を容易に軽減できます。バックアップ操作（フル、高速増分、マージ）は

オンラインで実行され、データ保護機能や読取り専用トランザクションをサポートするスタンバイ・

データベースの可用性が低下することは一切ありません。スタンバイに格納されたバックアップは、

プライマリ・データベースまたはスタンバイ・データベースをリストアするときに使用できます。

HADRスタンバイ・データベースでは、バックアップ操作はサポートされていません。IBMは、回避

策をドキュメントに記載していますが、この回避策は追加の手順を必要とし、データ保護機能を損

ないます。IBMのStorage Copy機能を使用して、まず、スタンバイ・データベースのストレージ・イ

メージのスナップショットを取得する必要があります。それには、FlashCopy操作中の書込み操作を

すべて禁止するために、管理者が、スタンバイ・データベースの非アクティブ化、データベース・

インスタンスの停止、すべてのファイル・システムのアンマウント、およびボリューム・グループ

の非アクティブ化（Vary Off）を実行する必要があります。

データベース・ロールを意識しない包括的なバックアップとリストア

Oracle Data GuardのOracle Recovery Managerへの統合化により、プライマリまたはスタンバイ上で包

括的なバックアップ/リカバリ操作を実行できます。おもな機能は次のとおりです。

• Oracle RMANのDUPLICATE FROM ACTIVE DATABASEコマンドによって、リモートのスタンバ

イ・データベースをインスタンス化するとき、中間ストレージを使用する必要がなくなりました。

• バックアップとリストア操作は、プライマリおよびスタンバイのロール移行に対して透過的に実

行されるため、DB2リカバリ履歴ファイル（db2rhist.asc）に対して行うような、手動による同期

化は必要ありません。

• プライマリまたはスタンバイに対して表領域レベルのリストを実行できます。

DB2 HADRには、上記のような機能はありません。

スタンバイ・データベースをテスト・システムとしても利用する

Oracle Data Guard 11gフィジカル・スタンバイ・データベースは、単一のコマンドで、読取り/書込み

モードでオープンしているデータベースに変換できます。その際、プライマリのパフォーマンスや

データ保護機能が影響を受けることは一切ありません。この機能は、Oracle Data Guardスナップショッ

ト・スタンバイと呼ばれ、プライマリ・データベースの完全なポイント・イン・タイム・スナップ

ショットに対して直接の読取り/書込みアクセスを可能にします。Oracle Data Guardのスナップショッ

ト・スタンバイは、プライマリ・データベースのコピーに一時的に読取り/書込みアクセスが必要な

本番前テストなどのアクティビティに適なQAシステムです。

34


スナップショット・スタンバイでは、処理中にプライマリ・データベースから送信されたREDOデー

タが取得され、アーカイブされますが、適用は行われません。フェイルオーバーが必要な場合やQAテストが完了すると、スナップショット・スタンバイは、テスト中に実行されたすべてのローカル

な変更を破棄する単一のコマンドによって、スタンバイ・データベースに戻されます。スタンバイ

は、読取り/書込みモードでオープンされていた間にローカルにアーカイブされたREDOデータを使

用して、自動的にプライマリ・データベースと再同期化されます。このプロセスの繰返し回数に制

限はありません。

スナップショット・スタンバイは、保証されたリストア・ポイントを使用して、必要に応じて何度

でも「リセット」することで、同じデータベースに対して繰り返しテストを実行できます。このた

め、Oracle Real Application Testingの理想的な補完機能となっています。

DB2 HADRでは、透過的に、なおかつ単一のコマンドを用いて二重の目的にスタンバイ・データベー

スを使用することはできません。二重の目的とは、上述のとおり、スタンバイ・データベースをス

タンバイ・データベースに対する読取り/書込みアクセスを必要とするテストやその他の用途に読取

り/書込み用にオープンし、同時にプライマリ・データベースで実行中の現在のトランザクション用

にデータ保護と障害時保護を実現することです。また、障害時保護を維持しながら、ユーザーの望

む回数だけ何度でも読取り/書込みデータベースとの間で移行を繰り返すこともできません。

人的エラーへの対応

データ障害とアプリケーション停止のおもな原因は（偶然または悪意の）人的エラーです。データ

ベースは数分で破損しますが、これまで、元データのリカバリには数時間かかっていました。さら

に悪いことに、人的エラーは一般にデータベースで検出できません。というのは、誤って行った変

更も他の変更と同様に、データベースがまだ稼働している間に処理されるためです。本当に難しい

のは、こうした人的エラーを特定し、短ルートでリカバリを実行することです。

次の表に示すように、人的エラーへの効果的な対応方法において、OracleにはDB2と比較して明確な

差別化要因となる機能が備わっています。従来のソリューションでは、多くのまたはすべてのデータ

ベース状態を障害発生前の状態にリストアする必要があるため、数時間を要していましたが、Oracleフラッシュバック・テクノロジーは、リカバリ時間を数時間から数分に短縮します。フラッシュバッ

ク・テクノロジーは革新的なリカバリ・テクノロジーです。なぜなら、リカバリ時間がデータベー

ス・サイズに依存しないという設計原理に基づいて実装されているからです。

35


表5：人的エラーへの対応 - OracleとDB2の比較

人的エラーへの対応 ORACLE DB2

SQL問合せを使用して過去の時点のデータを取得対応未対応

ごみ箱のサポート対応未対応

トランザクション・レベルでのデータベース変更の確認およびバックアウト対応未対応

行バージョンの変更の表示対応未対応

SQLインタフェースを使用したログのマイニングと変更の監査対応未対応

柔軟な表領域のポイント・イン・タイム・リカバリ対応未対応

過去の時点への表のフラッシュバック対応未対応

バックアップのリストアが不要の過去の時点へのデータベースのフラッシュバック対応未対応

次項では、人的エラーへの対応におけるOracleの差別化要因について詳しく説明します。

Oracleのフラッシュバック・テクノロジー

Oracleのフラッシュバック・テクノロジーは、ポイント・イン・タイム・ビューや、行、トランザク

ション、表、およびデータベースの各レベルにおける高速リカバリを可能にします。フラッシュバッ

ク機能を使用すれば、論理エラーを修復するための時間は、そのエラーが発生するのに要した時間

以上はかかりません。しかも、非常に簡単に使用できます。たとえば、複雑なメディア・リカバリ

を行う代わりに、単一のSQLコマンドによってデータベースのリカバリを実行できます。また、精密

な分析を可能にし、顧客注文を誤って削除するなどのローカルなダメージを修復できます。1カ月分

の顧客発注記録を削除してしまった場合などにも、広範なダメージを修正できるだけでなく、長期

の停止時間を迅速に回避できます。

Oracleのフラッシュバック・テクノロジーは、行レベル、トランザクション・レベル、表レベル、お

よびデータベース全体など、すべてのレベルでのリカバリをサポートします［29］。DB2には、その

ような機能はありません。以下の各項で、詳しく説明します。

データ・リカバリ

Oracleのフラッシュバック問合せを使用すれば、データベースの構造を変更することなく、管理者やユー

ザーが過去の所定の時点におけるデータの状態を表示できます。この強力な機能を使用すれば、誤って

削除または変更された可能性がある破損データを表示して再構築できます。開発者は、この機能を使用

して、アプリケーションにセルフサービスのエラー修正機能を構築し、エンドユーザーが遅延なくエ

ラーの取消しや修正を行えるようにして、管理者がこの作業を実行する負担を取り除くことができます。

36


フラッシュバック問合せでは、過去の設定可能な時点のデータを再構築するために必要な情報がOracleサーバーによって自動的に管理されるため、管理は非常に簡単です。DB2にはこれに匹敵する機能は

用意されていませんが、もっとも近い機能としてQuery Monitor [30]があります。Query Monitor機能

を使用すると、問合せと結果を一定の時間保持できます。

誤って削除したオブジェクトをリカバリする機能として、Oracleにはフラッシュバック・ドロップと

いう機能が用意されています。この機能は、削除したオブジェクトと依存オブジェクトのすべてが

含まれる論理コンテナのごみ箱にアクセスします。ごみ箱は、各表領域の空き領域を利用しており、

空き領域が減少すると先入れ先出しベースでオブジェクトが消去されます。表を削除しても実際に

削除されるわけではなく、その表はごみ箱に移され、接頭辞BIN$$のついた名前に変更されるだけです。

関連する表属性の名前もすべて変更されます。削除したオブジェクトは新しい名前でアクセスでき、

各ユーザーの持つアクセス権と権限も以前と同様に維持されます。ごみ箱はデフォルトで常に使用

でき、追加設定は不要です。

DB2は、バージョニング・リポジトリをサポートしています。バージョニング・リポジトリを使用す

ると、すべてを手作業でリストアする代わりに、破棄されたオブジェクトをバックアップからリス

トアしてリカバリできます。バージョニング・リポジトリはOracleのごみ箱ほど簡単ではありません。

ごみ箱は、単に使用可能な空き領域を使用するだけです。フラッシュバック・ドロップは、ごみ箱

オブジェクトの名前を元に戻すだけで、バックアップからオブジェクトをリストアするという意味

ではありません。後に、バージョニング・リポジトリはDB2 9.7では使用できませんが、DB2 Toolkitの一部として別途ライセンスされています。このツールキットがないと、DB2は、破棄されたオブジェ

クトをリカバリするために、従来のデータベースと表領域をリストアおよびリカバリすることにな

ります[31]。

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

Oracleには、行の変更履歴を表示して、トランザクションや影響のある変更をすべて確認する簡単な

問合せが備わっています。フラッシュバック・バージョン問合せを使用すれば、管理者は、一定時

間内の行バージョンごとの全変更と関連メタデータ（トランザクションIDや操作タイプなど）の記

録を確認できます。また、フラッシュバック・トランザクション問合せでは、特定のトランザクショ

ンによって影響を受ける全操作（および対応するUNDO）の一覧を取り出すことができます。この2つの操作はいずれも、保存期間を簡単に設定できる既存のUNDOデータを利用したものです。DB2には、

これに匹敵する機能はありません。

Oracle LogMinerは、DBAが不要な変更を検索して修正できる、フラッシュバック・バージョン問合

せとの併用が可能な強力な監査ツールです。シンプルなSQLインタフェースを使用して、ユーザー、

表、時刻、更新型、更新値、およびこれらの組合せによる検索を実行できます。また、データベー

ス表にDDL関連の構造変更が行われている場合でもデータベース表を追跡できるマルチバージョン・

ディクショナリをサポートしています。Oracle LogMinerには、誤った操作を取り消すために必要な

SQL文が搭載されています。さらに、Oracle Enterprise Managerインタフェースで変更履歴をグラフ表

示できます。これはバックアップをリストアしてリカバリを実行するよりもはるかに簡単かつ迅速

です。DB2には、ログのマイニングやトランザクションの変更の取消しを行う統合機能は備わってい

ません。

問題のあるトランザクションによる変更は、PL/SQLパッケージやOracle Enterprise Manager経由でア

クセスできるフラッシュバック・トランザクションで簡単に取り消すことができます。

37


問題のあるトランザクションの従属トランザクション（初に問題のあるトランザクションによっ

て変更された表の行を後で変更したトランザクション）による変更も一緒に取り消されます。取消

しが完了すると、データを検証して、変更をコミットまたはロールバックできます。この処理は、

有効なREDOログを使用して実行されます。DB2には、誤ったトランザクションや悪意のあるトラン

ザクションの取消しを行う単一コマンドは用意されていません。

IBMは個別にライセンスされたDB2 Toolkitを提供しています。このツールキットには、表および表

領域に対する変更を時間の経過とともに報告するログ分析ツールが含まれています。Oracleでは、す

べてのフラッシュバック機能がデータベース自体に組み込まれており、個別にはライセンスされて

いません。

ポイント・イン・タイム・リカバリ

ポイント・イン・タイム・リカバリを実行している間、Oracleでは、リカバリを終了しなくてもデー

タベースに問合せを発行できます。これは、エラーによって重要なデータまたは重要でない構造体

（索引など）のどちらに影響があるのか判定するときに便利です。Oracleでは、リカバリを継続する

がエラーが発生したら取り消すことができる試行リカバリもサポートされています。試行リカバリ

は、ポイント・イン・タイム・リカバリがかなり長時間続いている場合に、リカバリを取り消すと

きにも使用できます。DB2には、このような機能は用意されていません。

Oracleでは、取消し可能な操作を制限することなく、表領域をポイント・イン・タイムで完全にリカ

バリできます。DB2は、小リカバリ時間が課されます[32]。これは、表領域に対してポイント・イ

ン・タイム・リカバリを実行できるもっとも早い時点を指します。DB2の表領域の小リカバリ時間

が更新されるDDLイベントは次のとおりです。

• 表領域内の表を変更した結果、システム・カタログが変更された。

• 当該表領域内の表に対する制約が解除された。

• 当該表領域内の表の列が追加/変更された。

• 当該表領域内の表/索引が追加/破棄された。

• バッファ・プールやプリフェッチ・サイズなどの表領域属性が変更された。

人的エラーから表レベルで迅速にリカバリする機能として、Oracleにはフラッシュバック表という機

能が備わっています。この機能を使用すれば、SQLコマンド（例：FLASHBACK TABLE orders,

order_items TIMESTAMP time）1つで表や表セットを所定の時点まで迅速にオンライン・リカ

バリできます。フラッシュバック問合せと同様に、フラッシュバック表もまたUNDOデータを使用し

て表をリカバリします。DB2には、このようなきめ細かいリカバリ機能は備わっていません。

データベース全体に論理的破損が発生した場合は、データを破損発生前の状態に戻すため、ポイント・

イン・タイムのリストアとリカバリが必要となる場合があります。Oracleでは、データベース全体を

所定の時点に巻き戻す、フラッシュバック・データベース機能を搭載することにより、時間のかかる

従来のリストアとリカバリの手順を回避しています。フラッシュバック・データベースでは、変更

ブロックのみが処理されるため、従来の手動でのリストアとリカバリは不要となり、数秒または数

分で処理が完了します。フラッシュバック・データベース・コマンドを発行すると、変更ブロック

の履歴が保存されているフラッシュバック・ログからブロックが取得され、アーカイブREDOログを

使用して所定の時点までリカバリされます。DB2には、このような組込みの継続的データ保護（CDP）機能はなく、スナップショットとCDPを実現するために、依然としてストレージ・レベルの機能に

依存しています。

38


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

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

ビジネス・ニーズの変化に伴い、システムの変更が必要になる場合があります。たとえば、ビジネス

が成長すれば、データの処理量も増加します。その結果、ディスク、メモリ、CPU、クラスタのノー

ド、またはシステム全体のハードウェアをアップグレードする処理能力の増強が必要となります。

Oracleには、次の表に示すように、システム・リソースを動的に変更する独自の機能が備わっています。

表6：システム保守への対応 - OracleとDB2の比較

システム保守への対応 ORACLE DB2

クラスタへのオンラインでのノード追加機能対応未対応

ディスクのオンライン追加と削除機能対応未対応

オンライン・パッチ対応未対応

フル・パッチセットとメジャー・リリースのローリング・データベース・アップグレード対応未対応

メモリをオンライン調整するための拡張サポート対応未対応

メモリ管理に関する有用なアドバイザリ対応未対応

大半の構成パラメータをオンラインで変更可能対応未対応

次項では、これらのOracleの機能について詳しく説明します。

クラスタ・ノードの追加

シェアード・ナッシング環境でのデータのパーティション化は、パーティション化されたデータを

新しいパーティション・マップに基づいて再分散する必要があるため、クラスタへのサーバーの追

加に時間とコストがかかります。パーティション化オプションを使用してDB2データベースにノード

を追加するために、DBAまたはシステム管理者が行う必要がある作業を以下に示します。

• ハードウェアの追加

• 新しいパーティションの設定（パーティション固有のパラメータの設定など）

• データベースの再起動（全ノードの停止と再起動）

• 多数のパーティション間でのデータの再分散

39


DB2でDPFを使用してデータを再分散させるには、DBAの作業とデータベースの停止時間が必要にな

ります。このデータを再分散させるには3つの方法がありますが、いずれもデータベースの動作を中

断させます。

• 既存のノードグループの再分散 - ノードグループ内のデータはコマンドが完了するまでアクセス

できません。コマンドが完了するまでに要する時間は、再分散されるデータの量が多いほど長く

なります。これはインプレース再分散なので、操作がログに出力され、ログ領域を使い切ってし

まう傾向があります。

• 新規ノードグループの作成 - 新しいノードグループ内に古い表のレプリカが作成されます。それ

には、古いノードグループに格納されていたデータを格納するための十分な領域が必要です。そ

れだけの領域があったとしても、古いノードグループのデータが新しいノードグループにコピー

されている間、古いノードグループのデータを変更することはできません。また、索引、トリガー、

制約、特権といったすべての依存データを再作成する必要があります。

• ピース単位の再分散 - これは初のオプションと同じですが、ハッシュ・バケット内のデータを

一度に1つずつ再分散できる点が異なります。これにより、ユーザーによって管理されるよりも長

い期間にわたって再分散が拡散するため、特定時点における非可用性ウィンドウが制限されます。

この管理負荷は非常に大きく、短くはない時間、データベースをオフラインにする必要があります。

一方、Oracle RACにノードを追加する場合は、次の管理タスクが必要です。

• ハードウェアの追加

• 新しいインスタンスの設定（インスタンス固有のパラメータの設定など）

ご覧のとおり、Oracle RACではシームレスにスケールアウトされるため、データの再パーティション

化や、オフラインでのメンテナンス、データベースの再起動は必要ありません。Oracle RACを使用

すれば、データベース・アクセスを中断せずにノードを追加できます。

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

Oracle ASMでは、Oracleデータベースの停止時間を発生させずに、アクティブに使用されているディ

スク・グループに対してディスクの追加や削除を実行できます。Oracle ASMでは、ディスクの追加

や削除が実行されるたびにディスク・グループがリバランスされ、データベース・ファイルがディ

スク・グループ内の全ディスクに均等に分散されます。そのため、管理者がディスク・グループの

ホット・スポットを探して手動でデータを移動し、I/Oの負荷を分散してリストアする必要がありま

せん。DB2には、このような統合化機能は用意されていません。

40


オンライン・パッチ

Oracle Database 11gでは、一部のプラットフォームに限り、個別パッチを完全オンラインでインストー

ルできるため、データベース・インスタンスを停止する必要はなく、さらにOracle RAC構成やOracle Data Guard構成も必要ありません。OPatchに組み込まれているオンライン・パッチ処理では、インス

タンスの各関連プロセスが、安全な実行ポイントでパッチ・コードを確認し、そのコードをプロセ

ス領域にコピーします。

DB2には同様の機能は備わっていません。DB2で実行可能なのは、Fix Packのローリング適用であり、

それにはHADR構成が必要です。

包括的なローリング・データベース・アップグレード

Oracleでは、Oracle Data Guardは、Oracle Database 10.1.0.3より、ロジカル・スタンバイ・データベー

スについて、Oracle 11.1.0.6以降はフィジカル・スタンバイ・データベースについても、メジャー・

バージョンおよびサブバージョン間のローリング・アップグレードをサポートしています（Oracle Data Guard 11gの一時ロジカル・スタンバイを使用）。

Oracle Data Guardを使用して、本番データベースを新規のシステム、ストレージ、またはアーキテク

チャに移行するときの停止時間を小化することもできます。そのような例として、オペレーティ

ング・システムの異なるバージョンのサポート、Linux/Windowsの混在環境のサポート、32ビット/64ビットの混在環境、その他選択されたプライマリ/スタンバイの組合せのサポートなどがあります。

DB2 HADRは、DB2のバージョン間またはメジャー・サブバージョン間（たとえば、8.2から9.1、あ

るいは9.1から9.7など）でのローリング・アップグレードをサポートしていません（ローリング・アッ

プグレードはIBM Fix Pack間でのみサポートされています）。HADRプライマリ・データベースの更

新中はデータベースを停止する必要があります。DB2 9.7にアップグレードするには、HADRを再初

期化し、HADRスタンバイ・データベースをプライマリ・データベースのバックアップからリストア

する必要があります。

オンラインでのメモリの構成

Oracleでは、データベースをシャットダウンおよび再起動することなく、すべてのメモリ構造体のサ

イズを動的に変更できます。一方、IBMでは、このような機能（たとえば、新規バッファ・プールの

追加、既存のバッファ・プールのサイズ変更、バッファ・プールの破棄などを、データベースを再

起動せずに実行する機能）に制限があります。

また、Oracleでは、管理者が、使用可能なメモリを確実に適利用できるようにします。具体的には、

管理者がデータベースのパフォーマンスを大化するために必要なメモリ容量を正確に判定するた

めのさまざまなアドバイザリがあります。そのために、特許出願中のシミュレーション・アルゴリ

ズムを使用して小限のオーバーヘッドですぐに使用可能な正確なアドバイザリ・データを生成し

ます。これらのアドバイザリのおかげで、Oracle DBAは、メモリの割当てを確定する試行錯誤の作

業に時間を費やす必要がなくなりました。また、過剰な割当てによってシステム・メモリを無駄に

することもなくなりました。DB2ではこうしたアドバイザリは提供していません。したがって、DB2の管理者は、実際の経験に基づいて、または経験的アプローチを用いてデータベース・パフォーマ

ンスをチューニングする必要があります。

41


オンラインでのパラメータの構成

HA環境では、データベースの構成パラメータを変更して、特定の操作およびシステム環境に合わせ

てデータベース操作をチューニングしなければならないことがあります。Oracleが提供している膨大

な数のパラメータはデータベースを再起動せずに動的に変更できるため、停止時間は発生しません。

DB2バージョン9.7には、オンラインで構成できないDatabase Manager ConfigurationパラメータとDatabase Configurationパラメータが多数存在するため[33]、新規のパラメータ値を有効にするにはデータベー

スを停止してから再起動する必要があります。このためアプリケーションの停止時間が発生し、HA環境に悪影響を及ぼす可能性があります。

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

ビジネス要件とプロセスが変更されると、基礎データをメンテナンスして、新たな環境に合わせて

変換する必要があります。しかもそれを、ビジネスをほぼ中断させることなく実行しなくてはなり

ません。ビジネスをサポートするデータのメンテナンス、再定義、および変換は、どのDBAにとっ

ても重要な作業です。この作業は、新たなビジネス条件により不意に必要になることもあり、また、

定期的な作業として発生することもあります。次の表に示すとおり、Oracleでは、DB2とは対照的に、

この点に関して一連の機能を用意しています。これらの機能は一般に、高可用性が維持されるよう

に本番データのオンライン保守をサポートするものです。

表7：データ保守への対応 - OracleとDB2の比較

データ保守への対応 ORACLE DB2

パーティションのオンライン追加、交換、移動機能対応未対応

表をオンラインで再編成および再定義するための柔軟で包括的な機能対応未対応

個別の表パーティションのオンライン再編成機能対応未対応

デフォルト値を使用した迅速なオンライン列追加機能対応未対応

列のオンライン名前変更とマージ機能対応未対応

非表示索引対応未対応

排他ロック不要のオンラインでの制約の追加と変更、列の追加、索引の作成と再構築機能対応未対応

基礎リソースがビジーな場合のDDL操作待機機能（待機時間はユーザー指定）対応未対応

Oracleには、ALTER INDEXコマンドやALTER TABLEコマンドから、オンライン再定義機能を使用し

たより複雑な再編成タスクまで、オンラインで索引や表を再編成するさまざまな機能が搭載されてい

ます。中でも、Oracle独自の機能であるオンライン再定義機能を使用すると、次のことが可能です。

42


• 表のストレージ・パラメータの変更

• 表の表領域間の移動

• 表での1つまたは複数の列の追加、変更、削除

• パーティション化のサポートの追加または削除

• パーティション構造の変更

• 1つの表パーティションでの物理プロパティの変更（同一スキーマ内の別の表領域への移動など）

• マテリアライズド・ビューのログやOracle Streams Advanced Queuingのキュー表での物理プロパティ

の変更

• パラレル問合せのサポートの追加

• 表の再作成による断片化の削減

• 通常表（ヒープ構成表）の編成の索引構成表への変更（またはその逆の操作）

• リレーショナル表のオブジェクト列のある表への変換（またはその逆の操作）

• オンライン表再定義時のデータ変換（LONG型からLOB型への変換など）、元の表に基づいた再

定義表の新しい列でのデフォルト値の計算

DB2 9.7で、ADMIN_MOVE_TABLEを介して表をオンラインで移動および再定義する機能が導入さ

れましたが、この機能はOracleデータベースの機能と比較すると欠陥と制約が多数存在します。次に

例を示します[34]。

• 表を移動することで、外部キー制約を持つ表を再定義できません。外部キーを持つ表を移動する

には、db2lookコマンドで外部キーを取得してから、その外部キーを破棄し、移動操作を実行し、

キーのリサイクルを行います。オンラインの再定義では、参照制約を持つ表がフルにサポートさ

れています。

• 表を移動することで、表の単一パーティションを再定義できません。Oracle Database 10g Release 2より、オンライン再定義でこの機能を提供しています。

• ソース表にLOB、XML、LONG列が含まれている場合は、一意索引が必要です。 Oracleのオンラ

イン再定義では、ソース表に一意索引は必要ありません。

• DB2では、ステージング表と'insert from select'を使用して初にソース表をターゲット表にコピー

する設計を採用しているため、潜在的なパフォーマンスの問題を多数抱えています。一方、オン

ライン再定義では、マテリアライズド・ビューのログを使用して、ターゲット表に適用する必要

のあるソース表に対する更新を管理しています。また、高速マテリアライズド・ビューのログを

リフレッシュして更新を適用します。

• ソース表で長時間のトランザクションが存在するため、COPYフェーズ中にロック・タイムアウ

トが発生する可能性があります。オンライン再定義では、設計上、ソース表から仮表への初期コ

ピー中にロック・タイムアウトが発生することはあり得ません。

43


非一意索引を持ち、多数の更新プロセスが実行されるソース表ではデッドロックが発生する可能

性があります。オンライン再定義では、設計上、ソース表でデッドロックが発生することはあり

得ません。

また、DB2には、オンラインで表に制約を追加する機能は用意されていません。制約を追加するには

表をロックする必要があります。Oracleのマルチバージョン・テクノロジーでは、表をロックせずに

制約を追加できます。また、DB2では、非パーティション表をパーティション表に変換したり、表構

造体をオンラインで変更したりできません。

DB2 9.7 Fix Pack 1には、ADMIN_MOVE_TABLEに対する2つの改良点が含まれている点を指摘して

おきます。これらの改良点とOracleのオンライン再定義を比較してみます。

• NO_TARGET_LOCKSIZE_TABLEオプションを使用すると、COPYおよびSWAPフェーズ中

にターゲット表にアクセスできます。ユーザーまたはアプリケーションが、表の移動中に

ターゲット表にアクセスする必要がある理由についてはよく分かりません。ソース表に対

する進行中のDML操作はターゲット表で単純に再生されるからです。実際、ターゲット表

のデータを表移動のコンテキスト外で直接変更すると、コピーされたデータと矛盾が生じ、

アプリケーション非一貫性データになる可能性があります。オンライン再定義では、上記

の理由により、ユーザーが仮表を参照または更新することは推奨されません。

• CLUSTERオプションでは、ソース表にクラスタ索引が作成されている場合、またはコピー

索引が指定されている場合に、ソース表からORDER BY句でデータを読み取ります。

NON_CLUSTERオプションでは、データ移動のパフォーマンスを向上させるため、（クラ

スタ索引やコピー索引が指定されているかどうかに関係なく）ORDER BY句を使用せずに

ソース表からデータを読み取ります。オンライン再定義では、設計上、ソース表のデータ

を常に順不同で読み取ります。

ご存じのとおり、DB2は、堅牢な真のオンライン・データ再定義/変換機能をいまだに提供していま

せん。

エディションを使用したオンライン・アプリケーション・アップグレード

Oracle Databaseは、Oracle Database 11g Release 2で導入されたエディションベースの再定義機能によっ

て、可用性を損なわないアプリケーションのオンライン・アップグレードをサポートしています。

アップグレードのインストールが完了した後は、アップグレード前のアプリケーションとアップグ

レード後のアプリケーションを同時に使用できます。このため、ユーザーが終了を決定するまで、

既存のセッションでアップグレード前のアプリケーションを継続して使用できます。また、すべての

新しいセッションで、アップグレード後のアプリケーションを使用できます。アップグレード前の

アプリケーションのセッションがなくなり次第、アップグレード前のアプリケーションを廃止でき

ます。アプリケーション全体でアップグレード前のバージョンからアップグレード後のバージョンへ

のホット・ロールオーバーを実施できます。エディションベースの再定義は次のように動作します。

• コード変更が新エディションで内部的にインストールされます。

• 古いエディションで表示されない新しい列または表にのみ記述して、安全にデータ変更を行います。

エディショニング・ビューは、各エディションに異なる表を公開して、それぞれに固有の列だけ

を表示できます。

• クロスエディション・トリガーは、古いエディションから新しいエディション（ホット・ロール

オーバーの場合はその逆）への列のデータ変更を伝播します。

44


IBMのDB2には、アプリケーションのオンライン・アップデートに関して、同等のサポートは用意さ

れていません。

迅速なオンライン列追加機能

Oracleでは、DEFAULT値とNOT NULL制約を使用して列を追加する場合、既存レコードすべてにデ

フォルト値を保存する必要はありません。代わりに、列のデフォルト値をデータ・ディクショナリ

に保存するだけです。そのため、スキーマの変更が1秒未満で完了し、既存のデータ量に左右される

ことなく、領域の使用もほぼゼロで済みます。DB2には、この種の高速な列追加機能は用意されてい

ません。

オンラインでのロックを使用しない制約の追加/変更、列の追加、索引の作成/再構築

Oracleのオンライン索引作成と再構築操作では、操作時のどの時点でも排他ロックは使用されません。

つまり、表での継続的なDML（更新、挿入、削除）操作が透過的に実行され、索引操作の完了が待

機されないため、ロック時と待機時のシステム使用率の上昇や低下を小限に抑えることができます。

DB2では、あらゆる表変更や索引作成操作の際に、超排他‘Z’ロックを取得します。このロックは、

更新だけでなく表の読取りも禁止します[35]。

このロックは特定の条件下で（たとえば、表が変更または削除されたとき、表の索引が作

成または削除されたとき、または何らかの表再構成が行われたとき）表に対して取得され

ます。同時に実行されている他のアプリケーションは、表に対する読取りまたは更新を実

行できません。

非表示索引

Oracleの非表示索引は、索引を使用不可にしたり、削除したりする方法に代わる機能です。非表示索

引はあらゆるDML操作で維持されますが、索引がヒントで明示的に指定されていない限り、オプティ

マイザでは使用されません。

非表示索引は、アプリケーションの開発時とテスト時に威力を発揮します。その際、アプリケーショ

ンを頻繁に変更する必要がありますが、アプリケーションを完全にオフラインにすることはできま

せん。非表示索引を使用すれば、アプリケーション全体に影響を与えることなく、アプリケーショ

ンの一部の操作やモジュールに一時索引構造を利用できます。さらに、非表示索引を使用して、索

引を実際に削除せずに索引の削除機能をテストできるため、本番環境でのテストに猶予期間を設け

ることができます。DB2には、これと同等の索引機能は備わっていません。

DDLの待機

OracleのDDL（データ定義言語）操作はデータベース・オブジェクトの論理構造に影響を与えるため、

基本オブジェクト（列の削除や表の削除など）でロックが必要になることがあります。Oracleを使用

すれば、DDL操作完了までの待機時間をユーザーが指定できるため、必要なロックが取得できない

場合にすぐに操作を失敗させずに済みます。WAITオプションを使用すれば、DDL操作が成功するま

での猶予期間を開発者が定義できるため、エラーがすぐに発生することによる、エラー処理のため

にアプリケーション・ロジックを追加する必要はありません。DB2には、こうしたデータベース構造

変更操作の猶予期間は備わっていません。DB2には、データベース、表、行、パーティションの各レ

ベルで、同時実行アプリケーションの汎用ロック待機設定が用意されていますが、データベース構

造変更操作固有の猶予期間は用意されていません。

45


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

十分に統合されたテクノロジーは、今日の複雑な業務における厳しい高可用性ニーズを満たすうえ

で不可欠です。加えて、そうしたテクノロジーをもっとも効率的な方法で実装するためのベスト・

プラクティス・ガイドラインも重要です。

Oracle Maximum Availability Architecture（Oracle MAA）[36]は、そうした目標を達成するため、高可

用性に重点を置いたOracleのベスト・プラクティスのブループリントです。Oracle MAAには、次のよ

うな利点があります。

• Oracle MAAは、詳細な構成ガイドラインを提供して、Oracleの高可用性システムの実装コストを

削減します。選択した高可用性アーキテクチャがビジネス・ニーズに応じて継続的に機能し、拡

張可能であることを確実にするため、さまざまな構成がパフォーマンスにもたらす影響の調査結

果に焦点を当てています。

• Oracle MAAは、人的エラー、システム障害、クラッシュ、メンテナンス、データ障害、破損、災

害などによる計画停止時間と計画外停止時間をゼロまたは小限にするためのベスト・プラクティ

スとリカバリ手順を提供します。

• Oracle MAAを使用すれば、障害発生時に、停止からの復旧時間の長さとデータ損失の許容範囲値

を管理できるため、独自のビジネス要件に合わせて平均リカバリ時間（MTTR）をカスタマイズ

できます。

Oracle MAAは、オラクルの高可用性システム・エンジニアリング・グループにより、設計、構築、

および検証されています。このグループは、高可用性のベスト・プラクティスの設計と実装に加え、

OracleおよびOracle関連の多様なシステム・テクノロジーに関して高度な専門知識を持つスタッフか

ら構成されています。

46


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

Oracleの高可用性機能は、多くの顧客に導入されており、今日のビジネスに求められる24時間365日の稼働要件に対応できるデータベース・テクノロジーを選択する際に重要な差別化要因となってい

ます。Oracle Databaseの可用性、パフォーマンス、信頼性、管理性、およびセキュリティ機能のメリッ

トを享受している全業界におよぶ長い顧客リストは、[37]にてご覧いただけます。Oracleの各種高可

用性ソリューションに的を絞った実装顧客リストと実装事例の詳細は、[38]にてご覧いただけ、さら

にクイック・リファレンスとして以下にも記載します。

表8：Oracleの高可用性機能を導入している顧客一覧

OracleのHA顧客 OracleのHA導入事例

3n（National Notification Network） Oracle Streamsを使用したシステムの信頼性とHAの実現

Allstate Oracle MAAと、Oracle RAC、Oracle ASM、Oracle Data Guard、Oracle RMAN、Oracle Flashbackの導入

Amadeus 計画停止時間の小化：Oracle Data Guardとトランスポータブル表領域

Amazon.com Oracle Active Data Guard 11gとファストスタート・フェイルオーバーを使用した自動フェイルオーバー

Apple Inc. Oracle Active Data Guard 11gによるデータ保護と読取りパフォーマンスのスケールアウト

Banknorth Group, Inc. フラッシュバック・テクノロジーのスナップショット機能の使用

BarnesandNoble.com 電子商取引のHA/DR（Oracle RAC、Oracle Data Guard）

Bharti Airtel Oracle E-Business SuiteとOracle Discovererを使用したOracle Streams

Bonnier Oracle Streamsを使用したサイトの移行

Brivo Oracle Data Guardを使用したオフサイトの障害時リカバリ

British Telecom Oracle Data Guardスタンバイ・データベースのOracle RMANバックアップ

Burlington Coat Factory コスト削減とHA/DRの向上（Oracle RAC、Oracle Data Guard、Oracle Flashback Database、Oracle RMAN）

CERN 小限の停止時間でのテクノロジーの更新とデータベースの移行

CGI 北米大手石油およびガス企業。Oracle RMANを使用して50万ドルのコストを削減。

ChevronTexaco Oracle RMANのDUPLICATEコマンドを使用したDBAの作業時間の節約

Commonwealth Bank of Australia Oracle RAC、Oracle Data Guard、Oracle ASM、Oracle RMAN、Oracle Grid Controlを使用したOracle MAA

47


CSX Oracle RMANのオンライン・バックアップによる16TBのデータ保護とエンタープライズ・バック

アップ・アーキテクチャにおけるOracle Secure Backup

Dell Oracle RAC、Oracle Data Guard、Oracle RMAN、Oracle Grid Control上にSAPアプリケーション

を実装

Elster Group 自動メータリング・ソリューションにおける組込みのOracle Database 11g - Oracle RAC、Oracle

Data Guard、Oracle RMAN、Oracle Flashback Database、Oracle Grid Control

e-Rewards データウェアハウスのHAと同期化、およびOracle MAAを使用したOLTPデータベース

Fannie Mae SYNC/ASYNCのREDO転送を使用した高パフォーマンスの実現

Fidelity National Financial 12TBデータベースのOracle MAAと750マイル離れたデータセンター

Imprivata Oracle Streamsによるグローバル認証とアクセス管理

Intermap Technologies Oracle Active Data Guard 11gスタンバイを使用した24時間安全なインターネット・アクセス

Kemira GrowHow Ltd アウトソーシングのDRサービスからの切替え

MorphoTrak Oracle Active Data Guard 11gとファストスタート・フェイルオーバー

Myriad Genetics ラボラトリ・システムとOracle Streamsとのほぼリアルタイムの統合

Department of the Interior Oracle RMANを使用したバックアップとリカバリの効率化

NeuStar 300マイル離れたデータベース間でのデータ損失ゼロ（SYNC）の実現

Nokia NokiaのOracle Database 11g MAAアーキテクチャ内のOracle RMAN

Novartis Oracle RMANを使用したバックアップとリカバリ事例

PG&E Oracle RMANを使用したバックアップとリカバリ事例

PPL ミッション・クリティカルな停止管理システムの自動フェイルオーバー（Oracle Data Guard、

Oracle RMAN、Oracle Flashback、Oracle Enterprise Manager）

Public Trust SMBの低コストのグリッド・コンピューティング（Oracle Data Guard、Oracle RAC、Oracle

RMAN、Oracle ASM、Oracle Application Server、Oracle Enterprise Manager）

Purdue Pharma L.P. Oracle RMANを使用したメディア障害からの回復

ReserveAmerica Oracle 10gのフラッシュバック・テクノロジーの活用

Real Networks マテリアライズド・ビューの代わりにOracle Active Data Guard 11gを使用したレポート・インス

タンスの同期化

Shire Pharmaceuticals Oracle RAC、Oracle ASM、Oracle Data Guard（英国から米国への大陸間配置）、Oracle Recovery

Manager、Oracle Enterprise Manager

48


Starbucks エンタープライズ・データウェアハウス（EDW）のVLDBバックアップおよびリカバリ・アーキテ

クチャ

Starwood Hotels Oracle RMANベスト・プラクティスによる利益の大化

Swarovski and Company SAP R/3のDR保護

The Hartford マルチテラバイトのデータベースの移行：クロス・プラットフォームTTSとOracle RMANの

CONVERTコマンド

Thomson Legal & Regulatory Oracle Data Guard SQL Applyを使用した計画停止時間の小化

Titan Technology Partners クライアントへのOracle Secure Backupの導入

Trilegiant Oracle RMANのオンライン・バックアップを使用した8TBのデータの保護

Turkcell Oracle Database 11gのバックアップおよびリカバリ計画

ValueCentric Oracle Data Guardを使用したMySQLのOracleへの変換によるHA/DRの実現

Volkswagen AG 大陸間のハブ・アンド・スポーク・アーキテクチャによる継続運用

結論

Oracleは、あらゆる企業が直面している高可用性問題を認識することにより、システム障害、データ

破損、災害、および人的エラーなどのあらゆる形の計画外停止時間から企業を保護し、簡単に使用

できる包括的で強力な独自の機能を提供します。また、こうした目標を達成しつつ、同じ環境で計

画メンテナンス時の停止時間の小化をも実現します。

Oracleには、Oracle RAC、Oracle Data Guard、Oracle GoldenGate、Oracle RMAN、Oracle Flashbackなど

のコンポーネントから構成される、十分に統合された高可用性ソリューション・スタックが備わっ

ています。そのため、今日の経済環境の極めて重要な要素である顧客の時間を節約し、コスト、シ

ステム・リソース、および人的リソースを削減できます。Oracleは、Oracle Maximum Availability Architectureフレームワークを通じて高可用性ソリューションを構成するベスト・プラクティス・ガ

イドラインを公開し、顧客に提供することで、さらに一歩前進を遂げました。Oracleの高可用性ソ

リューションを導入した顧客リストは、この領域におけるOracleの技術面での比類なきリーダーシッ

プとビジョンを実証するものです。

Oracleとは異なり、DB2に備わっているのは基本的な高可用性機能であり、現在大部分の企業で必要

とされる、すべてを網羅する高度な高可用性機能が不足しています。この点で、DB2はOracleよりも

数リリース後れを取っており、今日のビジネス・アプリケーションが要求する高水準の稼働時間を

実現するうえでは適切な選択肢とは言えません。

49


参照資料

1. 『Oracle Database High Availability Overview 11g Release 2 (11.2)』 http://download.oracle.com/docs/cd/E11882_01/server.112/e17157/toc.htm 『Oracle Database高可用性概要 11gリリース2（11.2）』 http://download.oracle.com/docs/cd/E16338_01/server.112/b56308/toc.htm

2. 『Overview:Oracle Database High Availability』 http://www.oracle.com/technetwork/database/features/availability/index.html

3. 『Oracle Database 11g Release 2 Documentation Library』 http://www.oracle.com/pls/db112/portal.all_books 『Oracle Database 11g Release 2 Documentation Library (日本語)』

http://download.oracle.com/docs/cd/E16338_01/nav/portal_3.htm

4. 『IBM DB2 Database for Linux, UNIX, and Windowsインフォメーション・センター』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp

5. 『Oracle Database Performance Tuning Guide 11g Release 2 (11.2) - Tuning Instance Recovery Performance: Fast-Start Fault Recovery』 http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF13009 『Oracle Databaseパフォーマンス・チューニング・ガイド 11gリリース2（11.2） - インスタンス・

リカバリのパフォーマンスのチューニング: ファスト・スタート・リカバリ』 http://download.oracle.com/docs/cd/E16338_01/server.112/b56312/instance_tune.htm#i1009414

6. DB2のドキュメント - データベースの基本：『softmax - リカバリー範囲およびソフト・チェッ

クポイント・インターバル構成パラメータ』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.config.doc/doc/r0000242.html

7. IBM Redbooks：『High Availability and Disaster Recovery Options for DB2 on Linux, UNIX, and Windows』 - 2009年2月、304ページ http://www.redbooks.ibm.com/redbooks/pdfs/sg247363.pdf

8. IBM Developerworksの記事：『DB2 partitioning features』 http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0608mcinerney/index.html

9. DB2のドキュメント：『データベース・パーティション・グループ』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.partition.doc/doc/c0004888.html

10. IBM Developerworksの記事:『Compare the distributed DB2 9.7 database servers』" http://www.ibm.com/developerworks/data/library/techarticle/dm-0909db2compare/

11. IBM Developerworksの記事：『Which distributed edition of DB2 9.7 is right for you?』 http://www.ibm.com/developerworks/data/library/techarticle/dm-0909db2whichedition/

50

http://download.oracle.com/docs/cd/E11882_01/server.112/e17157/toc.htm

http://download.oracle.com/docs/cd/E16338_01/server.112/b56308/toc.htm

http://www.oracle.com/technetwork/database/features/availability/index.html

http://www.oracle.com/pls/db112/portal.all_books

http://download.oracle.com/docs/cd/E16338_01/nav/portal_3.htm

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp

http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF13009

http://download.oracle.com/docs/cd/E16338_01/server.112/b56312/instance_tune.htm%23i1009414

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.config.doc/doc/r0000242.html


http://www.redbooks.ibm.com/redbooks/pdfs/sg247363.pdf

http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0608mcinerney/index.html

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.partition.doc/doc/c0004888.html


http://www.ibm.com/developerworks/data/library/techarticle/dm-0909db2compare/

http://www.ibm.com/developerworks/data/library/techarticle/dm-0909db2whichedition/


12. 米国IBMのソフトウェア発表 208-113、2008年5月6日『Renaming IBM DB2 Warehouse and extending warehouse analytics with IBM InfoSphere Warehouse V9.5.1』 http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS208-113

13. DB2のドキュメント：Tivoli Provisioning Manager、Version 5.1.0.1 - 『HADR considerations』 http://publib.boulder.ibm.com/infocenter/tivihelp/v16r1/topic/com.ibm.tivoli.tpm.clu.doc/cluster/rclu_hadrconsider.html

14. DB2のドキュメント：『分散キー』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.partition.doc/doc/c0004906.html

15. DB2のドキュメント：『設計アドバイザー』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.perf.doc/doc/c0005144.html

16. DB2のドキュメント- データベースの基本：『設計アドバイザーの制限と制約事項』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.perf.doc/doc/c0011428.html

17. DB2のドキュメント- データベースの基本：『データベース・パーティション間でのデータの再

配分』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.partition.doc/doc/c0053335.html

18. DB2のドキュメント- データベース管理：『REDISTRIBUTE DATABASE PARTITION GROUPコマンド（ADMIN_CMDプロシージャーを使用）』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.sql.rtn.doc/doc/r0023581.html

19. Oracleホワイト・ペーパー - 『Oracle Real Application Clusters 11gとIBM DB2 v9（Linux、Unix、Windows向け）の技術比較』 http://www.oracle.com/technology/global/jp/products/database/clustering/pdf/wp-oracleibm-2009.pdf

20. 『Oracle Secure Backup』 http://www.oracle.com/technetwork/jp/database/secure-backup/overview/index.html

21. DB2のドキュメント- データベース管理：『バックアップの使用』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha.doc/doc/t0006192.html

22. DB2のドキュメント- データベース管理：『増分バックアップおよびリカバリ』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha.doc/doc/c0006069.html

23. IBM Developerworksの記事:『A look at the new functions in DB2 Universal Database V8.2』 http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0404zikopoulos/index.html

24. IBM Redbooks：『High Availability and Disaster Recovery Options for DB2 on Linux, UNIX, and Windows』2009年2月、150ページ http://www.redbooks.ibm.com/redbooks/pdfs/sg247363.pdf

51

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS208-113

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS208-113

http://publib.boulder.ibm.com/infocenter/tivihelp/v16r1/topic/com.ibm.tivoli.tpm.clu.doc/cluster/rclu_hadrconsider.html

http://publib.boulder.ibm.com/infocenter/tivihelp/v16r1/topic/com.ibm.tivoli.tpm.clu.doc/cluster/rclu_hadrconsider.html



http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.perf.doc/doc/c0005144.html




http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.sql.rtn.doc/doc/r0023581.html

http://www.oracle.com/technology/global/jp/products/database/clustering/pdf/wp-oracleibm-2009.pdf

http://www.oracle.com/technetwork/jp/database/secure-backup/overview/index.html

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha.doc/doc/t0006192.html

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha.doc/doc/c0006069.html

http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0404zikopoulos/index.html



52

25. DB2のドキュメント- データベース管理：『スタンバイ・データベースの読み取りの使用可能化』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha.doc/doc/t0054260.html

26. Apple Inc.、Oracle 11g Active Data Guard：『High Scalability, High Availability, Real-Time Data Changes, and Reader Farm』 http://www.oracle.com/technetwork/database/features/availability/311400-134359.pdf

27. IBM Redbooks：『High Availability and Disaster Recovery Options for DB2 on Linux, UNIX, and Windows』2009年2月、90ページ http://www.redbooks.ibm.com/redbooks/pdfs/sg247363.pdf

28. DB2のドキュメント - 新機能の概要：『DB2 Version 9.7 for Linux, UNIX, and Windows fix pack summary』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha.doc/doc/c0054258.html

29. 『Oracle Database Flashback Technologies』 http://www.oracle.com/technology/global/jp/deploy/availability/htdocs/Flashback_Overview.html

30. DB2のドキュメント - 『DB2 Query Monitor』 http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2tools.cqm.doc.ug/cqmhome.htm

31. DB2のドキュメント - データベース管理：『ドロップされた表のリカバリ』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha.doc/doc/t0006318.html

32. DB2のドキュメント - データベース管理：『表スペースにおける変更のロールフォワード』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha.doc/doc/c0006312.html

33. DB2 のドキュメント - データベースの基本：『構成パラメータのサマリー』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.config.doc/doc/r0005181.html

34. DB2のドキュメント：『ADMIN_MOVE_TABLEプロシージャーによるオンラインでの表の移動』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.dm.doc/doc/t0054864.html

35. DB2のドキュメント - データベースの基本：『ロック属性』 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.perf.doc/doc/c0005270.html

36. 『Overview: Oracle Maximum Availability Architecture - MAA』 http://www.oracle.com/technetwork/database/features/availability/maa-090890.html

37. 『Oracle Customer Successes』 http://www.oracle.com/us/corporate/customers/index.html

38. 『Oracle High Availability Case Studies』 http://www.oracle.com/technetwork/database/features/ha-casestudies-098033.html


http://www.oracle.com/technetwork/database/features/availability/311400-134359.pdf



http://www.oracle.com/technology/global/jp/deploy/availability/htdocs/Flashback_Overview.html

http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db2tools.cqm.doc.ug/cqmhome.htm





http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.dm.doc/doc/t0054864.html


http://www.oracle.com/technetwork/database/features/availability/maa-090890.html

http://www.oracle.com/technetwork/database/features/ha-casestudies-098033.html

Oracle Database 11g Release 2と IBM DB2 9.7の技術比較：高可用性

に重点を置いた比較

Copyright © 2009, Oracle and/or its affiliates. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は一

切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商

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

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

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

手段によっても再作成または送信することはできません。

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

0109

2009年12月著者：Oracle HA Product Management

Oracle Corporation World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065 U.S.A.

海外からのお問い合わせ窓口：電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

www.oracle.comm

Documents

Oracle Database 11g Release 2とIBM DB2 9.7の技術比 …ƒ›ワイト・ペーパー - Oracle Database 11g Release 2とIBM DB2 9.7の技術比較：高可用性に重点を置いた比較