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

Transcription

1 2009 年 12 月 Oracle Database 11g Release 2 と IBM DB2 9.7 の技術比較 : 高可用性に重点を置いた比較

2 概要... 1 はじめに... 2 計画停止時間と計画外停止時間... 2 概要 : オラクルの高可用性ソリューション... 3 計画外停止時間の最小化... 3 計画停止時間の最小化... 5 OracleとDB2のHA 機能の比較... 5 OracleとDB2の比較 - 計画外停止への対応 システム障害への対応 データ障害への対応 障害時リカバリへの対応 人的エラーへの対応 OracleとDB2の比較 - 計画停止への対応 システム メンテナンスへの対応 データ メンテナンスへの対応 Oracleの高可用性ベスト プラクティス オラクルの高可用性機能を導入している顧客 結論 参照資料... 50

3 概要 今日のビジネスは データベースに大きく依存しています アプリケーションやデータが使用できなくなると ビジネス全体が停止し 収益や顧客を失い 不利益を被る場合があります また 悪評によって 顧客や株価に長期的な影響を及ぼすおそれがあります したがって 継続的なデータの可用性を確保することは今日のビジネスに不可欠と言えます 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

4 はじめに 企業データのデータベース ソリューションを検討中の組織は データベースの高可用性機能についても検討する必要があります データは組織のもっとも重要なビジネス資産の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

5 概要 : オラクルの高可用性ソリューション 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

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

7 計画停止時間の最小化計画停止時間には ルーチン処理 定期メンテナンス 新規導入などの作業が含まれますが とりわけ複数のタイムゾーンに属するユーザーをサポートするグローバル企業では 計画停止時間は単なる業務の中断に過ぎません 計画外停止時間の最小化と同様に 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

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

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

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

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

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

13 ファストスタート チェックポイント - 平均リカバリ時間の予測 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

14 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

15 フェイルオーバー直後の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

16 データ ボリュームと処理負荷を複数のパーティション間でリバランスさせて データ分散の偏りを解消するため 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

17 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

18 表 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

19 組込みのデータベース障害検出 分析 および修復機能データ障害に直面すると 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

20 リカバリ時の自動リストア フェイルオーバーリストア時にバックアップの破損が検出された場合や バックアップにアクセスできない場合 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

21 ブロック メディア リカバリ 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

22 この機能により ストレージ サブシステム内のコンポーネントの障害からデータを透過的に保護して使用可能な状態を維持できます 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

23 データ保護とデータの高可用性エンタープライズ データ保護の最初の要件は スタンバイ データベースが プライマリ データベースの信頼できる完全なレプリカであると保証することです つまり プライマリ データベースとスタンバイ データベースを同じ相対時点 ( たとえば それぞれのデータベースに同じ挿入 更新 削除 またはDDLトランザクションが適用された時点 ) で比較したとしたら 2つのデータベースが互いに相手の完全なレプリカであることが確認されます このレプリケーション メカニズムのインフラストラクチャは プライマリ データベースとスタンバイ データベース間で非一貫性リスクが発生しないことを 比較を実行して検証する必要がない程度に保証する必要があります この特性によって スタンバイ データベースをあらゆる点でプライマリ データベースの代理にする つまり どちらか一方のデータベースのバックアップを使用して他方のデータベースを元の状態に戻すことができます これにより 顧客は データの相違が決して発生しないと保証することで あらゆる法規制やデータ保護のためのビジネス要件に対応できます この要件については Oracle Data Guard REDO Apply( フィジカル スタンバイ ) とIBM HADRのどちらも十分に満たしています どちらもネイティブのデータベース リカバリ メカニズムを使用して プライマリ データベースとスタンバイ データベースが互いに相手の物理レプリカになるよう保証しています 同じ処理相対時点で2つのデータベース間にデータの相違が発生することはありません プライマリ データベースとスタンバイ データベースを定期的に比較する必要はありません これにより 本番データベースの論理レプリカを保持するSQLベースのレプリケーション テクノロジーよりも高いレベルのデータ保護を実現できます それでも Oracle Data Guardのユーザーの方が データ保護とデータ可用性という点で IBM HADR に比べて高度な機能の恩恵を受けることができます 次の項で これらの高度な機能について説明します 独立性 2 番目の要件である独立性は 最初の要件があるために 実現がより難しくなっています スタンバイ データベースはプライマリの完全なレプリカでなければなりませんが 同時に プライマリ データベースに影響を与える可能性のある障害からスタンバイ データベースを分離するために 2つのデータベースは疎結合されていなければなりません この点に関しては Oracle Data GuardとIBM HADRのどちらも高得点をつけることができます どちらのソリューションもデータベース対応のプロセスを使用して すべての変更データを別々に検証してから スタンバイ データベースに適用します スタンバイ側でも スタンバイ データベースに変更内容を適用するとき プライマリ側とは別のコード パスを使用する必要があります これにより プライマリ データベースの破損や障害に繋がるソフトウェアおよびハードウェア障害によって スタンバイ データベースが影響を受けるのを防ぐことができます このアプローチは 物理ブロックのレプリケーションに限定されるストレージ アレイのリモート ミラー化よりもはるかに優れています ストレージのミラー化では 複製するブロックがデータベース レベルで検証されることもなければ トランザクション セマンティクスについても感知しません プライマリ データファイルに破損したブロックが適用されると それがそのまま リモート側のデータファイルにもミラー化および適用されます また 管理者がプライマリ データベース側で重要なデータやログ ファイルを間違って削除するといった帯域外イベントも リモート ミラー化によってスタンバイ側に忠実に複製されてしまうため 両方のデータベースが使用不能になります 21

24 データ保護の場合と同様に 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

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

26 障害時リカバリ 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

27 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

28 プライマリ データベースとスタンバイ データベースのどちらかで 破損ブロックを自動修復 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

29 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

30 また 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

31 例があります 同社では シングルのOracle Active Data Guard 構成を使用して データの保護を実現したり 休暇シーズン中の需要がピークに達する時期に対応するために読取りパフォーマンスを簡単にスケールさせたりしています DB2 HADRでは プライマリごとに単一のスタンバイ データベースしか使用できないため 2 次的な障害によってデータの損失と可用性の低下が起こりやすくなります メジャー バージョンおよびサブバージョン間のデータベースのローリング アップグレード Oracle Data Guardは Oracle Database より ロジカル スタンバイ データベースについて Oracle 以降はフィジカル スタンバイ データベースについても メジャー バージョンおよびサブバージョン間のローリング アップグレードをサポートしています (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

32 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

33 対策 : この場合 スタンバイ側のログ レコードが一致しないか 失われたため プライマリ側と正常に再統合できないことが もっとも考えられる原因です これを確認するには 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

34 アクティブ データ ブロックは 本番アプリケーションを中断することなく プライマリ データベースの破壊されたブロックを透過的に修復するときに使用します 一方 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

35 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

36 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

37 スナップショット スタンバイでは 処理中にプライマリ データベースから送信されたREDOデータが取得され アーカイブされますが 適用は行われません フェイルオーバーが必要な場合やQA テストが完了すると スナップショット スタンバイは テスト中に実行されたすべてのローカルな変更を破棄する単一のコマンドによって スタンバイ データベースに戻されます スタンバイは 読取り / 書込みモードでオープンされていた間にローカルにアーカイブされたREDOデータを使用して 自動的にプライマリ データベースと再同期化されます このプロセスの繰返し回数に制限はありません スナップショット スタンバイは 保証されたリストア ポイントを使用して 必要に応じて何度でも リセット することで 同じデータベースに対して繰り返しテストを実行できます このため Oracle Real Application Testingの理想的な補完機能となっています DB2 HADRでは 透過的に なおかつ単一のコマンドを用いて二重の目的にスタンバイ データベースを使用することはできません 二重の目的とは 上述のとおり スタンバイ データベースをスタンバイ データベースに対する読取り / 書込みアクセスを必要とするテストやその他の用途に読取り / 書込み用にオープンし 同時にプライマリ データベースで実行中の現在のトランザクション用にデータ保護と障害時保護を実現することです また 障害時保護を維持しながら ユーザーの望む回数だけ何度でも読取り / 書込みデータベースとの間で移行を繰り返すこともできません 人的エラーへの対応データ障害とアプリケーション停止のおもな原因は ( 偶然または悪意の ) 人的エラーです データベースは数分で破損しますが これまで 元データのリカバリには数時間かかっていました さらに悪いことに 人的エラーは一般にデータベースで検出できません というのは 誤って行った変更も他の変更と同様に データベースがまだ稼働している間に処理されるためです 本当に難しいのは こうした人的エラーを特定し 最短ルートでリカバリを実行することです 次の表に示すように 人的エラーへの効果的な対応方法において OracleにはDB2と比較して明確な差別化要因となる機能が備わっています 従来のソリューションでは 多くのまたはすべてのデータベース状態を障害発生前の状態にリストアする必要があるため 数時間を要していましたが Oracle フラッシュバック テクノロジーは リカバリ時間を数時間から数分に短縮します フラッシュバック テクノロジーは革新的なリカバリ テクノロジーです なぜなら リカバリ時間がデータベース サイズに依存しないという設計原理に基づいて実装されているからです 35

38 表 5: 人的エラーへの対応 - Oracle と DB2 の比較 人的エラーへの対応 ORACLE DB2 SQL 問合せを使用して過去の時点のデータを取得対応未対応 ごみ箱のサポート対応未対応 トランザクション レベルでのデータベース変更の確認およびバックアウト対応未対応 行バージョンの変更の表示対応未対応 SQL インタフェースを使用したログのマイニングと変更の監査対応未対応 柔軟な表領域のポイント イン タイム リカバリ対応未対応 過去の時点への表のフラッシュバック対応未対応 バックアップのリストアが不要の過去の時点へのデータベースのフラッシュバック対応未対応 次項では 人的エラーへの対応における Oracle の差別化要因について詳しく説明します Oracleのフラッシュバック テクノロジー Oracleのフラッシュバック テクノロジーは ポイント イン タイム ビューや 行 トランザクション 表 およびデータベースの各レベルにおける高速リカバリを可能にします フラッシュバック機能を使用すれば 論理エラーを修復するための時間は そのエラーが発生するのに要した時間以上はかかりません しかも 非常に簡単に使用できます たとえば 複雑なメディア リカバリを行う代わりに 単一のSQLコマンドによってデータベースのリカバリを実行できます また 精密な分析を可能にし 顧客注文を誤って削除するなどのローカルなダメージを修復できます 1カ月分の顧客発注記録を削除してしまった場合などにも 広範なダメージを修正できるだけでなく 長期の停止時間を迅速に回避できます Oracleのフラッシュバック テクノロジーは 行レベル トランザクション レベル 表レベル およびデータベース全体など すべてのレベルでのリカバリをサポートします [29] DB2には そのような機能はありません 以下の各項で 詳しく説明します データ リカバリ Oracleのフラッシュバック問合せを使用すれば データベースの構造を変更することなく 管理者やユーザーが過去の所定の時点におけるデータの状態を表示できます この強力な機能を使用すれば 誤って削除または変更された可能性がある破損データを表示して再構築できます 開発者は この機能を使用して アプリケーションにセルフサービスのエラー修正機能を構築し エンドユーザーが遅延なくエラーの取消しや修正を行えるようにして 管理者がこの作業を実行する負担を取り除くことができます 36

39 フラッシュバック問合せでは 過去の設定可能な時点のデータを再構築するために必要な情報が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