日立と
Oracle が実現する
BCM プラットフォームソリューション
＆
Oracle Active Data Guard 検証報告
Date: 2008 年 3 月
Version: 1.0
- 2 -
Copyright © 2008 Hitachi, Ltd. All Rights Reserved.
１ はじめに
2007 年 10 月、Oracle Database の最新メジャーバージョン Oracle Database 11g Release 1 がリリースされました。今回のバージョンアップでは、万一の本番システム災害時にも企業の重 要なデータを保護し、遠隔の待機システムにフェイルオーバーすることで業務の継続を実現する Oracle Data Guard において、いくつかの革新的な新機能が実装されています。
今回、日本オラクル株式会社と株式会社日立製作所はOracle GRID Center にて、日立の高信 頼ブレードサーバBladeSymphony と Oracle Database 11g Release 1 の組み合わせにおける実 システムを想定した大規模トランザクション環境を構築し、Oracle Data Guard の検証を実施し ました。
本ホワイトペーパでは、日立ハードウェアとOracle Database 11g Release 1 の組み合わせが 実現するBCM(Business Continuity Management)プラットフォームソリューションと、Oracle Database 11g Release 1 の新オプション Oracle Active Data Guard が提供する機能の有効性 の検証結果についてご紹介いたします。
謝辞
2006 年 11 月、日本オラクル株式会社は株式会社日立製作所やグリッド戦略パートナー各社と 協業体制を確立し、企業のシステム基盤の最適化を実現する次世代のビジネス・ソリューション を構築するため、先鋭の技術を集結した「Oracle GRID Center(オラクル・グリッド・センター)」 (http://www.oracle.co.jp/solutions/grid_center/index.html) を 開 設 し ま し た 。 本 稿 は 、 Oracle GRID Center の趣旨にご賛同頂いたインテル株式会社、シスコシステムズ合同会社のハードウェ ア・ソフトウェアのご提供および技術者によるご支援などの多大なるご協力を得て作成しており ます。ここに協賛企業各社およびご協力頂いた技術者に感謝の意を表します。 ※本ドキュメントの無断転載を禁じます 免責事項 このドキュメントは単に情報として提供され、内容は予告なしに変更される場合があります。 このドキュメントに誤りが無いことの保証や、商品性又は特定目的への適合性の黙示的な保証や 条件を含め明示的又は黙示的な保証や条件は一切無いものとします。日本オラクル株式会社およ び株式会社日立製作所は、このドキュメントについていかなる責任も負いません。また、このド キュメントによって直接又は間接にいかなる契約上の義務も負うものではありません。このドキ ュメントを形式、手段(電子的又は機械的)、目的に関係なく、日本オラクル株式会社および株式 会社日立製作所の書面による事前の承諾なく、複製又は転載することはできません。 商標類 BladeSymphony は、国内および海外における日立製作所の登録商標です。 Oracle は，米国 Oracle Corporation 及びその子会社，関連会社の登録商標です。
Intel，Itanium および Intel Xeon は，アメリカ合衆国およびその他の国におけるインテルコーポ レーションまたはその子会社の商標または登録商標です。
Red Hat は，米国およびその他の国で Red Hat, Inc. の登録商標若しくは商標です。 Linux は、Linus Torvalds の米国およびその他の国における登録商標あるいは商標です。 Cisco は，米国 Cisco Systems, Inc. の米国および他の国々における登録商標です。 その他の名称は、各社の商標または登録商標です。
２ 目次
１ はじめに... 2
２ 目次... 4
３ Business Continuity Management(BCM)の重要性... 6
４ Oracle Data Guard... 7
５ 日立とOracleが実現するBCMプラットフォームソリューション例 ... 10
６ Oracle Active Data Guard検証 ... 12
６-１ 検証目的と検証内容 ... 12 ６-２ 検証環境 ... 13 ６-２-１ システム構成... 13 ６-２-２ 使用ハードウェア ... 13 ６-２-３ 使用ソフトウェア ... 14 ６-２-４ 負荷について... 14 ７ 検証結果... 15 ７-１ ネットワーク経由の複製機能によるスタンバイ・データベース作成 ... 15
７-２ Oracle Active Data Guardによるスタンバイサイト有効活用とスタンバイサイト有効活 用時のシステムダウンタイム短縮効果... 19 ７-３ スタンバイ・データベースにおけるREDO適用性能の測定... 23 ７-４ ファスト・スタート・フェイルオーバー... 27 ７-５ 高負荷トランザクション状況下でのフェイルオーバー... 29 ８ まとめ ... 32 - 4 -
図目次
図 ４-1 Oracle Data Guard概要図 ... 7
図 ４-2 Oracle Active Data Guardによるスタンバイ・データベースの有効活用 ... 8
図 ４-3 スナップショット・スタンバイによるスタンバイ・データベースの有効活用 ... 8
図 ４-4 ファスト・スタート・フェイルオーバーの動作 ... 9
図 ５-1 日立のハードウェアとOracle Data Guardによるオンラインシステムメンテナンス ... 10 図 ５-2 スタンバイコストを抑えたデータ保護と迅速なサーバリソース追加の実現... 11 図 ６-1 検証システム構成 ... 13 図 ７-1 従来のスタンバイ・データベース作成方法... 16 図 ７-2 ネットワーク経由の複製機能によるスタンバイ・データベース作成... 16 図 ７-3 従来の課題 スタンバイサイト活用時間とシステムダウンタイムの関係 ... 20
図 ７-4 Oracle Active Data Guardによるスタンバイサイト有効活用 ... 21
図 ７-5 今回検証した想定業務シナリオ... 22 図 ７-6 フィジカル・スタンバイへのフェイルオーバーの流れ ... 23 図 ７-7 REDO適用性能が低い場合... 24 図 ７-8 十分なREDO適用性能を確保できている場合... 24 図 ７-9 ファスト・スタート・フェイルオーバーの動作 ... 27 図 ７-10 高負荷トランザクション状況下でのフェイルオーバー検証 ... 29 表目次 表 ７-1 適用性能比較パターン ... 25 表 ７-2 検証構成パターン ... 29 表 ７-3 検証した障害パターン ... 30 表 ７-4 検証した障害パターンと検証結果 ... 30 グラフ目次 グラフ ６-1 負荷生成時のプライマリ・データベースサーバのCPU使用率... 15 グラフ ７-1 スタンバイ・データベース作成時間の比較(従来方法とネットワーク経由の複製 機能によるスタンバイ・データベース作成) ... 17 グラフ ７-2 従来方法によるスタンバイ・データベース作成時のCPU利用率とネットワーク 転送量(上：プライマリ・データベースサーバ、下：スタンバイ・データベースサーバ) ... 17 グラフ ７-3 ネットワーク経由の複製機能によるスタンバイ・データベース作成時のCPU利 用率とネットワーク転送量(上：プライマリ・データベースサーバ、下：スタンバイ・デ ータベースサーバ) ... 18 グラフ ７-4 ネットワーク経由の複製機能によるスタンバイ・データベース作成時の業務ト ランザクションスループットとプライマリ・データベースサーバのCPU使用率とネット ワーク転送量... 19
グラフ ７-5 Oracle Active Data GuardによるスタンバイサイトCPUリソースの有効活用効 果... 21
グラフ ７-6 Oracle Active Data Guardによるフィジカル・スタンバイ有効活用時のシステ ムダウンタイム短縮効果... 22
グラフ ７-7 REDO生成量とREDO適用性能の比較 ... 25
グラフ ７-8 適用性能比 ... 26
グラフ ７-9 プライマリ・データベースの全インスタンス障害時のトランザクションと各デ ータベースサーバのCPU使用率の挙動... 31
３
Business Continuity Management(BCM)の重要性
昨今の企業におけるIT システムの重要性はますます高くなっています。たとえ万一の地震など の天災によるサイト障害やハードウェアに起因するようなシステム障害が発生してしまったとし ても、企業は顧客情報などのビジネス上重要なデータを保護することと、迅速なシステム復旧に よる継続したサービスを提供することを求められています。まとめると、以下のような要件が挙 げられます。 ビジネスの継続性 重要なサービスが使用もしくは提供できなくなった場合、ビジネス全体に多大な影響 を与えます。収益が失われるのはもとより、顧客や取引企業からの信頼を失うこともあ ります。 データの保護 企業にとってデータは最も重要な財産のひとつです。給与や従業員情報、顧客レコー ド、貴重な研究結果、財務レコード、履歴情報などのデータを企業が失った場合、その データの再構築や再生成が不可能でないとしても、非常に多くのコストを必要とし会社 が事業を継続できるかどうかの重大な影響を与えることになります。 変化に柔軟に対応するシステム 障害などの計画外停止におけるビジネス継続性だけでなく、ソフトウェアのアップグ レードやハードウェアメンテナンスなどの計画停止においてもシステムの停止時間を 最小限に抑え、ビジネスへの影響を最小限に抑える必要があります。オープンシステム においては、ソフトウェアの進化が早く、システムを常に最新の堅牢な状態に保つため に、短いサイクルでアップグレードやパッチの適用を実施していくことが重要になりま す。ハードウェアに関しても、CPU のマルチコア化などの進化が早く、最新のハード ウェアに入れ替えるだけで、性能向上やTCO 削減が実現可能なケースもあります。こ のような変化に柔軟に対応するシステムが求められているのです。 費用対効果 - スタンバイサイトの有効活用 - 災害時のために待機しているスタンバイサイトのサーバリソースを有効活用するこ とは、費用対効果を考えた場合、非常に重要です。万一のための災害対策としても、通 常運用時のリソース効率が低ければ、システム予算確保などにおいて、大きなハードル となります。日立のハードウェアである BladeSymphony や Hitachi Storage と、ORACLE が提供する Oracle Real Application Clusters (Oracle RAC)および Oracle Data Guard を組み合わせること により、このような課題を解決するソリューションを提供することができます。
- 6 -
４
Oracle Data Guard
Oracle Data Guard は、本番データベース（プライマリ・データベースと呼びます）のコピ ーとしてスタンバイ・データベースを作成し、そのメンテナンス、管理および監視など、一連 の包括的なサービスを提供する機能です。スタンバイ・データベースはプライマリ・データベ ースとトランザクション一貫性のあるコピーとして作成され、作成後はプライマリ・データベ ースから送信される REDO を適用することによって、プライマリ・データベースの変更に追 従します。プライマリ・データベースが計画的または計画外の停止によって使用不可能になっ た場合は、スタンバイ・データベースをプライマリ・データベースに切り替えることで、停止 時間を最小限にできます。Oracle Data Guard は Oracle Database Enterprise Edition が提 供する機能です。
コピー
障害時
本番データベース スタンバイ・ データベース 本番データベース スタンバイ・ データベース 通常時は本番データベースに接続 障害発生時には スタンバイ・データベースに接続通常時
図 ４-1 Oracle Data Guard 概要図
スタンバイ・データベースには2 つの構成があります。1 つはプライマリ・データベースに 対して物理ブロックレベルで同じであるフィジカル・スタンバイ・データベースであり、もう 1 つは論理的に行データレベルで同じであるロジカル・スタンバイ・データベースです。
Oracle Database 11g Release 1 では、Oracle Data Guard に対して様々な機能拡張がさ れました。本検証で注目した新機能について紹介します。
Oracle Active Data Guard
従来のリリースでは、フィジカル・スタンバイ・データベースのデータを参照するに は、REDO 適用を停止する必要がありました。Oracle Database 11g Release 1 では、 新たに提供されたOracle Active Data Guard オプションによって REDO 適用を継続し たままフィジカル・スタンバイ・データベースのデータを参照できるようになりました。 この機能をリアルタイム・クエリーと呼びます。この機能拡張により、フィジカル・ス タンバイ・データベースをレポーティング業務等で常用する運用が現実的なものとなり ます。
フィジカル・スタンバイ プライマリ・データベース 通常業務 バッチ処理 レポーティング バックアップ 取得 レポーティング処理、バックアップ取得を スタンバイ・データベースにオフロード
Oracle Data Guard
図 ４-2 Oracle Active Data Guard によるスタンバイ・データベースの有効活用 Oracle Active Data Guard ではスタンバイ・データベースからバックアップを取得 する際にチェンジ・トラッキング・ファイルを使用した高速増分バックアップも利用で きるため、高可用性と、本番サイトにおける計画または計画外停止に対する災害保護の 利便性が提供されます。 スナップショット・スタンバイ スナップショット・スタンバイは、簡単な操作でフィジカル・スタンバイ・データベ ースを一時的に読み書き可能なテスト用データベースとして使用することを可能にし ます。テスト用データベースとして使用している間もプライマリ・データベースの REDO は受信されるため、データ保護の仕組みは継続します。また、スナップショット・ スタンバイからフィジカル・スタンバイ・データベースに戻す作業も簡単な操作で可能 です。 スナップショット・スタンバイ プライマリ・データベース 通常業務
Oracle Data Guard
テスト用 クライアント オープン中も REDO転送は継続 一時的に更新可能 なテスト環境として オープン 図 ４-3 スナップショット・スタンバイによるスタンバイ・データベースの有効活用 - 8 -
ネットワーク経由の複製機能によるスタンバイ・データベース作成
従来のリリースでは、スタンバイ・データベースを作成するにはプライマリサイトで のプライマリ・データベースのフルバックアップ取得、スタンバイサイトへのバックア ップの転送およびリストアが必要でした。Oracle Database 11g Release 1 では、デー タベースの複製を行う際に使用するRecovery Manager (RMAN)の duplicate コマンド が機能拡張し、ネットワーク経由のデータベース複製が可能になりました。この機能を 使用することで、稼働中のプライマリ・データベースのデータベース・ファイルを直接 スタンバイサイトにコピーしてスタンバイ・データベースを作成することが可能になり、 ストレージ容量の節約とスタンバイ・データベース作成時間の短縮が実現します。 ファスト・スタート・フェイルオーバー ファスト・スタート・フェイルオーバーは、プライマリ・データベースの障害検知と 検知後のフェイルオーバーを自動的に行う仕組みを提供します。障害検知とフェイルオ ーバーの開始は、プライマリ・データベース、スタンバイ・データベースとは別に配置 されたオブザーバが行います。オブザーバはData Guard Broker に含まれるコンポー ネントです。ファスト・スタート・フェイルオーバーによって、プライマリ・データベ ースの障害発生時に管理者の介入なしにフェイルオーバーをさせることが可能になり ます。 自動フェイルオーバー REDO転送 スタンバイ・データベース プライマリ・データベース 監視 オブザーバ 監視 図 ４-4 ファスト・スタート・フェイルオーバーの動作 従来のリリースでは、ファスト・スタート・フェイルオーバーは REDO 同期転送が 必須となる最大可用性モード設定時のみ使用可能でしたが、Oracle Database 11g Release 1 では、非同期での REDO 転送設定が可能な最大パフォーマンスモードにも対 応し、より多くの環境での導入が可能になりました。また、障害検知時にフェイルオー バーを開始するかどうかの設定をより柔軟に行えるようになり、様々なフェイルオーバ ー要件に対応できるようになりました。
- 10 -
Copyright © 2008 Hitachi, Ltd. All Rights Reserved.
５ 日立と
Oracleが実現するBCMプラットフォームソリューション
例
日立のハードウェアとOracle Database 11g Release 1 の組み合わせが実現する BCM ソリュ ーションについて、幾つかの例をご紹介いたします。
システムのオンラインメンテナンスの実現
図 ５-1は本番業務環境とテスト環境からなるData Guardシステム構成例です。テスト 環境はOracle Active Data Guardを利用したレポーティング業務として、あるいはスナ ップショット・スタンバイ機能を利用した開発環境として使用します。このような構成 では、Oracle Data Guardのローリングアップグレード機能によるOracleソフトウェア のパッチセット適用やバージョンアップが可能なだけでなく、Oracle Data Guardスイ ッチオーバー機能と組み合わせたBladeSymphonyサーバブレードの交換や追加、 Hitachi Storageの仮想化技術を利用した本番環境へのシームレスなオンラインディス クの追加などが可能です。このように、日立のハードウェアとOracle Database 11g Release 1 を組み合わせることにより、ソフトウェアとハードウェアの両面から、本番 業務への影響を最小限に抑えたシステムのオンラインメンテナンスを実現することが 可能になります。 本番環境 テスト環境
Oracle Data Guaｒd
構成 ①テスト環境へ スイッチオーバー ②新ブレード サーバ交換 Oracle ローリング アップグレード ストレージプールへの オンラインハードディスク追加 オンライン ブレードサーバ交換 LVM/ASM/その他OS設定の必要なし ディスク認識のためのリブート必要なし スイッチオーバーにより本番環境を切り 替えることで業務への影響を最小化
図 ５-1 日立のハードウェアと Oracle Data Guard によるオンラインシステムメンテ ナンス
スタンバイコストを抑えたデータ保護と迅速なサーバリソース追加の実現
図 ５-2は、スタンバイ・データベースのサーバリソースの割り当てを最小にした構成 例です。スタンバイ・データベースへの投資を可能な限り抑えつつ、Oracle Data Guard によるデータ保護を実現しています。万が一の震災などにより、プライマリ・データベ ースが機能しなくなってしまった場合、スタンバイ・データベースにフェイルオーバー
することで業務を継続することが可能ですが、本来のサービスレベルまでに復旧するに は、プライマリ・データベースと同等の処理能力を確保するなど、サーバへの追加リソ ース割り当てを行う必要があります。このような作業は非常に手間と時間がかかります が、BladeSymphonyのプロビジョニング機能とOracle Real Application Clustersのプ ロビジョニングをあわせて利用すれば、サーバリソース追加作業のコストを大幅に削減 し、迅速な対応が可能になります。 プライマリ・データベース Data Guaｒd 構成 通常運用時 4ノードRAC 1ノードRAC Data Guaｒd 構成 プライマリ・ データベース 障害時 4ノードRAC 1ノードRAC 災害でプライマリ・データベースに障害発生・・・ スタンバイ・データベースでは必 要最低限のサーバーリソースを 割り当てることで、投資コストを 抑えたデータ保護を実現 スタンバイ・データベースで業務を継続する 場合は、サーバリソースの追加が必要。 BladeSymphonyのプロビジョニング機能と Oracleのプロビジョニング機能を利用すること で追加作業の大幅簡略化と迅速な対応を実 現
+ 3ノード
プロビジョニング スタンバイ・データベース プライマリ・データベース スタンバイ・データベース 図 ５-2 スタンバイコストを抑えたデータ保護と迅速なサーバリソース追加の実現- 12 -
Copyright © 2008 Hitachi, Ltd. All Rights Reserved.
６
Oracle Active Data Guard検証
６-１ 検証目的と検証内容
今回GRID Center にて検証を実施した目的は大きくは以下の３つです。 Oracle Data Guard新機能の有効性の確認
Oracle Data Guard 新機能の効果や有用性、使用にあたっての考慮事項などを確認す ること。主に以下の機能に着目し検証を実施しました。
ネットワーク経由の複製機能によるスタンバイ・データベース作成
オンラインデータベースからの直接コピーによるスタンバイ・データベース作 成よる効果
Oracle Active Data Guard
Oracle Active Data Guard のリアルタイム・クエリー機能によるスタンバイ・ データベース有効活用とスタンバイ・データベース有効活用時のシステムダウン タイム短縮効果 スナップショット・スタンバイ ファスト・スタート・フェイルオーバー 大規模かつ高トランザクション状況下での性能とフェイルオーバー プライマリ・データベースへの業務負荷が高く、CPU やネットワークリソースをフ ルに使用している状況において障害が発生したとしても、スタンバイ・データベースへ 正常かつ迅速にフェイルオーバーすることを確認すること、および大規模かつ高トラン ザクション状況下で考慮すべき点について把握すること。
Oracle Data Guard 導入の主目的は、プライマリサイト障害時のスタンバイサイトへ の切り替えなのでこれらの点は非常に重要です。
ベストプラクティス運用の確立
スタンバイ・データベースの作成、Oracle Data Guard 環境の運用などの手順を確立 すること。
※本検証にて実績のある手順については、別途「Oracle Data Guard 11g フィジカル・ スタンバイ設定ガイド」にまとめていますので、そちらをご参考ください。
６-２ 検証環境
６-２-１ システム構成
図 ６-1が今回の検証システム構成です。クライアントマシンからデータベースサーバへの接続 と、プライマリサイト - スタンバイサイト間のREDO転送は同一のパブリックネットワークを使 用して行われます。ネットワーク帯域は 1Gbps です。 プライマリサイト クライアントマシン スタンバイサイト データベースサーバー ： 日立BladeSymphony BS320 プライマリサイト 2ノードRAC スタンバイサイト 2ノードRAC ストレージ ：Hitachi Adaptable Modular Storage Cisco Catalyst 6504 Cisco Catalyst 3750 図 ６-1 検証システム構成
６
-２-２ 使用ハードウェア
データベースサーバ 機種 日立BladeSymphony BS320 × 計 4 ブレード CPU デュアルコア インテル(R)Xeon(R)プロセッサー 3GHz 2 ソケット/ブレード メモリ 8GB クライアントマシン 機種 インテルホワイトボックス 計4 台 CPU クアッドコア インテル(R)Xeon(R)プロセッサー 2.66GHz 1 ソケット/サーバ メモリ 4GB ストレージ機種 Hitachi Adaptable Modular Storage (AMS) ハードディスク 144GB × 28HDD (+ 2HDD スペア) RAID グループ構成 2D+1P × 8 (Oracle データベース用)
６
-２-３ 使用ソフトウェア
データベースサーバOS Red Hat Enterprise Linux 4.5
Oracle Oracle Database 11g Release 1 (11.1.0.6) Enterprise Edition
Oracle Real Application Clusters Oracle Active Data Guard Oracle Partitioning クライアントマシン
OS Red Hat Enterprise Linux 4 Update 3 Oracle Oracle Client 10g Release 2 (10.2)
６-２-４ 負荷について
本検証では、Web ショッピング・サイトを想定したオンライン・トランザクション処理システ ム(OLTP)を負荷モデルとして使用しました。具体的には、オープンソースの J2EE フレームワー クである Spring Framework (http:// www.springframework.org)のサンプル・アプリケーショ ンとして提供されている JPetStore が生成する SQL 文を負荷生成用のカスタム・アプリケーシ ョンより多重実行しました。処理の流れは以下の通りです。
①ユーザー・サインオン
任意のユーザーID をランダムに選択し、ユーザー情報を検索。 select … from account, profile, signon
where account.userid=? and signon.password = ? and …; ②商品検索
ランダムに商品検索用のキーワードを生成し、商品を検索。検索結果が平均で100 件になるよ うに調整。
select … from category where catid = ?;
select … from product where（lower（name）like ?）; ③商品選択
検索してヒットした商品の中から一つのアイテムを選択。 select … from item, product
where i.itemid = ? and … ④在庫数チェック
選択したアイテムの在庫数をチェック。 select … from inventory where itemid = ? ⑤注文
指定した商品の注文データを発行。 insert into orders …;
insert into orderstatus …; insert into lineitem …;
注文した商品アイテムを在庫管理表から注文数の在庫数を減らす。 Update inventory set qty=qty-1 where itemid = ?;
- 14 -
⑥注文確定 commit 以上の処理をクライアントマシンより多重実行しており、負荷生成時にはグラフ ６-1が示すよ うにプライマリ・データベースサーバに対して高い負荷が掛かっています。 プライマリ・データベース・サーバー1のCPU使用率 0 20 40 60 80 100 0 120 240 360 480 600 720 840 960 1080 1200 時間(秒) C P U使用率( % )
user system iowait
プライマリ・データベース・サーバー2のCPU使用率 0 20 40 60 80 100 0 120 240 360 480 600 720 840 960 1080 1200 時間(秒) C P U 使 用 率 （%）
user system iowait
グラフ ６-1 負荷生成時のプライマリ・データベースサーバの CPU 使用率
７ 検証結果
７-１ ネットワーク経由の複製機能によるスタンバイ・データベース
作成
スタンバイ・データベース作成の際には、プライマリ・データベースのデータベース・ファイ ルをスタンバイサイトへコピーする必要があります。Oracle Database 10g までは、プライマリ・ データベースのバックアップを取得し、そのバックアップファイルをftp や scp などを使用しネ ットワーク経由でスタンバイサイトに転送する、あるいはバックアップファイルをテープへ出力 しスタンバイサイトに搬送する、などの方法が一般的でした。Oracle Database 11g Release 1 では、RMAN の duplicate コマンドの機能拡張により、プラ イマリ・データベースのデータベース・ファイルをオンラインで直接スタンバイサイトへコピー することが可能になりました。これにより、プライマリサイトでバックアップ取得作業、スタン バイサイトでのバックアップからの複製作業を省略することができます。また、プライマリサイ ト/スタンバイサイト両方にて必要であったバックアップファイル確保のためのディスクスペー スを用意する必要もなくなります。 従来方法とネットワーク経由の複製機能によるスタンバイ・データベース作成の比較検 証 以下の、従来方法とネットワーク経由の複製機能によるスタンバイ・データベース作 成で、スタンバイ・データベース作成にかかる時間とそのときのCPU 使用率を測定・ 比較し、その効果を検証しました。本検証における、プライマリ・データベースの総容 量は約170GB です。 ■従来方法（図 ７-1） ①RMAN を使用したオンラインバックアップによるバックアップファイルの作成 ②scp を使用しネットワーク経由で、プライマリサイトからスタンバイサイトへのバッ クアップファイルの転送 ③RMAN によるバックアップファイルからデータベースリストア
■ネットワーク経由の複製機能によるスタンバイ・データベース作成（図 ７-2） ①オンラインのプライマリ・データベース・ファイルをスタンバイ・データベー スへ直接コピー プライマリデー タベース スタンバ イデータベース バ ックアップ ファ イル ①バックアップファイ ルの作成(RMANに よるオンラインバッ クアップ) バ ックアップ ファ イル ③RMANによるバック アップファイルから のデータベースリス トア ②scpによるバックアップ ファイルの転送 プライマリサイト スタンバイサイト 従来のスタンバイデータベース構築方法 図 ７-1 従来のスタンバイ・データベース作成方法 プライマリデータベース スタンバイデータベース プライマリサイト スタンバイサイト ネットワーク経由の複製機能による スタンバイ・データベース作成 ①オンラインデータベースファイルの 直接コピー 図 ７-2 ネットワーク経由の複製機能によるスタンバイ・データベース作成 従来方法による作成とネットワーク経由の複製機能によるスタンバイ・データベース 作成、それぞれでスタンバイ・データベース作成にかかった時間を比較した結果がグラ フ ７-1です。 ネットワーク経由の複製機能によるスタンバイ・データベース作成、プ ライマリサイトにおけるバックアップの作成とスタンバイサイトにおけるリストア作 業がない分、従来方法に比べおよそ1/3 の時間でスタンバイ・データベースの作成が完 了しています。 - 16 -
0 3000 6000 9000 12000 時間(秒) 従来方法 ネットワーク経由の複製機能による スタンバイ・データベース作成 グラフ ７-1 スタンバイ・データベース作成時間の比較(従来方法とネットワーク経由の 複製機能によるスタンバイ・データベース作成) 従来方法によるスタンバイ・データベース作成時の、プライマリ・データベースサー バとスタンバイ・データベースサーバのCPU使用率とネットワーク転送量を示したのも のがグラフ ７-2です。プライマリサイトでのバックアップファイル作成とスタンバイサ イトでのデータベースリストアにおいて約 30%程度のCPUリソースを使用しているこ とが分かります。 ネットワーク経由の複製機能によるスタンバイ・データベース作成時の、プライマ リ・データベースサーバとスタンバイ・データベースサーバのCPU使用率とネットワー ク転送量を示したのものがグラフ ７-3です。従来方法と比べるとCPU使用率が低く、 効率よくオンラインデータファイルのネットワーク転送コピーが行われていることが わかります。CPU使用率だけでなく、単位時間当たりのネットワーク通信量についても、 scpコピーと比較して高速であることが分かります。 スタンバイ・データベースサーバのCPU利用率 0 10 20 30 40 50 60 70 80 90 100 0 1200 2400 3600 4800 6000 7200 8400 9600 時間(秒) CP U 使 用 率 (% )
user system iowait プライマリ・データベースサーバのCPU利用率 0 10 20 30 40 50 60 70 80 90 100 0 1200 2400 3600 4800 6000 7200 8400 9600 時間(秒) C P U 使 用率( % )
user system iowait
スタンバイ・データベースサーバのネットワーク転送量 0 10000 20000 30000 40000 50000 60000 70000 80000 90000 0 1200 2400 3600 4800 6000 7200 8400 9600 10800 時間(秒) ネット ワー ク 転 送 量 (K by te/s ) プライマリ・データベースサーバのネットワーク転送量 0 10000 20000 30000 40000 50000 60000 70000 80000 90000 0 1200 2400 3600 4800 6000 7200 8400 9600 10800 時間(秒) ネット ワー ク 転 送 量 (K by te/s ) 受信量KB/s 送信量KB/s RMANによる オンラインバック アップ scpによるバッ クアップファイ ル転送 RMANによる データベース リストア scpによるバッ クアップファイ ル転送 scpによるバッ クアップファイ ル受信 受信量KB/s 送信量KB/s グラフ ７-2 従来方法によるスタンバイ・データベース作成時の CPU 利用率とネット ワーク転送量(上：プライマリ・データベースサーバ、下：スタンバイ・データベース
サーバ) プライマリ・データベースサーバのCPU利用率 0 20 40 60 80 100 0 600 1200 1800 2400 3000 時間(秒) C P U 使用率( % )
user system iowait
スタンバイ・データベースサーバのCPU利用率 0 20 40 60 80 100 0 600 1200 1800 2400 3000 時間(秒) CP U 使 用 率 (% )
user system iowait
プライマリ・データベースサーバのネットワーク転送量 0 10000 20000 30000 40000 50000 60000 70000 80000 90000 0 600 1200 1800 2400 3000 時間(秒) ネット ワー ク 転 送 量 (K by te/s ) rxKB/s txKB/s スタンバイ・データベースサーバのネットワーク転送量 0 10000 20000 30000 40000 50000 60000 70000 80000 90000 0 600 1200 1800 2400 3000 時間(秒) ネッ ト ワ ー ク 転 送 量 (K by te/s ) et h0 rxKB/s txKB/s オンラインデータベース・ファイルの直接コピー 受信量KB/s 送信量KB/s 受信量KB/s 送信量KB/s グラフ ７-3 ネットワーク経由の複製機能によるスタンバイ・データベース作成時の CPU 利用率とネットワーク転送量(上：プライマリ・データベースサーバ、下：スタン バイ・データベースサーバ) ネットワーク経由の複製機能によるスタンバイ・データベース作成時の業務トランザク ションへの影響 本番業務処理中にスタンバイ・データベースを作成した場合の業務への影響を確認す るため、プライマリ・データベースに対し業務トランザクション負荷を与えた状態で、 ネットワーク経由の複製機能によるスタンバイ・データベース作成を実施し、挙動を確 認しました。その際の、業務トランザクションスループットとプライマリ・データベー スサーバにおけるCPU使用率とネットワーク転送量を測定した結果がグラフ ７-4です。 今回のケースでは、業務トランザクション処理とデータベース・ファイル転送処理の競 合により、業務トランザクションスループットが2 割前後の割合で減少していることが わかります。データベース・ファイル転送時は80MB/s近くの転送量を記録しましたが、 通常業務時は業務トランザクションが約20MB/s使用していることから、スタンバイサ イトへのデータベース・ファイル転送量が約60MB/sであることが確認できます。負荷 のない場合と比較すると転送量が減少するため、その分作成完了までの時間も長くなっ ています。 業務トランザクションの性能への影響は、そのトランザクションの処理特性によって も異なることが予想されるため、実際には、本番業務の負荷が低い時間帯を選んでスタ ンバイ・データベース作成を実施することで業務への影響を最小限にする方法や、 REDO 転送用のネットワークを別途用意する方法等も合わせて検討することが推奨さ れます。 また、WAN などの転送遅延が起こりうるネットワーク環境では、ネットワーク I/O バッファサイズの設定によってネットワーク経由の複製機能における転送効率が向上 する場合があります。設定に関する詳細はマニュアル「Net Services 管理者ガイド 11g リリース1(11.1)」の「14 パフォーマンスの最適化」内にある「I/O バッファスペース の構成」を参照ください。 - 18 -
プライマリ・データベース・サーバーのネットワーク転送量 0 20000 40000 60000 80000 100000 120000 0 360 720 1080 1440 1800 2160 2520 2880 3240 3600 3960 4320 4680 時間(秒) ネ ッ ト ワ ー ク 転送量 （K by te/s ） et h0 rxKB/s txKB/s プライマリ・データベース・サーバーのCPU使用率 0 20 40 60 80 100 0 360 720 1080 1440 1800 2160 2520 2880 3240 3600 3960 4320 4680 時間(秒) C P U 使用率（ % ）
user system iowait
トランザクションスループット 0 360 720 1080 1440 1800 2160 2520 2880 3240 3600 3960 4320 4680 時間（秒） トラ ン ザ ク シ ョ ン ス ル ー プ ット ネットワーク経由の複製機能によるスタンバイ・デー タベース作成時のトランザクションスループットへの 影響は、今回のケースでは2割前後 総転送量が約80MB/sあり、業務トランザクションが使 用している約20MB/sを除くとデータベース・ファイル 転送量が約60MB/sであることがわかる スタンバイ・データベース作成中 グラフ ７-4 ネットワーク経由の複製機能によるスタンバイ・データベース作成時の業 務トランザクションスループットとプライマリ・データベースサーバのCPU 使用率と ネットワーク転送量
７
-２ Oracle Active Data Guardによるスタンバイサイト有効活用
とスタンバイサイト有効活用時のシステムダウンタイム短縮
効果
Oracle Database 10g までの Oracle Data Guard では、スタンバイサイト有効活用における課 題として以下のようなものがありました。 フィジカル・スタンバイ機能において、スタンバイサイトをREAD-ONLY で活用する 際は、REDO の適用を停止する必要がある プライマリサイト障害時のダウンタイムを一定時間に抑えるには、定期的なデータ同期 処理が必要、そのためにスタンバイサイトを定期的に管理リカバリモードにする必要が あるなど、運用が複雑 ロジカル・スタンバイ機能においては、スタンバイサイトを活用できるが、データ型の 制限などで適用が限定される これらの制限により、従来のスタンバイサイトの活用においては複雑な運用を適用する必要が 有り、かつスタンバイサイトを有効活用する時間が長くなるほど、万一の障害時の復旧に時間が かかり、可用性を犠牲にすることになっていました(図 ７-3)。
スタンバイサイト活用時間 (ログデータ適用停止時間) プライマリサイト障害時に 適用が必要なログデータ量 障害時の システムダウンタイム に比例 図 ７-3 従来の課題 スタンバイサイト活用時間とシステムダウンタイムの関係
Oracle Database 11g Release 1 で新たに提供された Oracle Active Data Guard のリアルタイ ム・クエリー機能によってこれらの課題は解決し、システムの可用性を担保しながらスタンバイ サイトの有効活用が実現可能になります。今回は、この点について、実際に以下の2 点を検証す ることで、Oracle Active Data Guard の有効性を確認致しました。
①Oracle Active Data Guard によるスタンバイサイト有効活用
フィジカル・スタンバイ機能において、REDO の適用を行いながら、常時スタンバイサ イトをREAD-ONLY で活用できることを確認
②フィジカル・スタンバイサイト有効活用時のシステムダウンタイム短縮効果
①により、定期的な同期処理も不要であり、なおかつ、プライマリサイト障害時のダウ ンタイムを一定時間に抑えることが可能であることを確認
Oracle Active Data Guardによるスタンバイサイト有効活用
図 ７-4のような状況を想定し、プライマリサイトではオンラインショッピング業務と してオンライン・トランザクション負荷を掛けている状態で、スタンバイサイトに追加 業務として日時処理やレポートバッチのようなクエリーによる負荷を追加した際の挙 動を確認しました。Oracle Active Data Guardのリアルタイム・クエリー機能により、 スタンバイサイトで追加業務を行っている際もREDOの転送と適用は行われています。
- 20 -
プライマリデータベース スタンバイデータベース オンラインショッピング 業務 日時処理/レポートバッチ OLTPトランザクション SELECT/クエリー負荷 リアルタイムクエリー 追加業務 REDOの転送と適用
図 ７-4 Oracle Active Data Guard によるスタンバイサイト有効活用
グラフ ７-5はリアルタイム・クエリーによるスタンバイサイトへのSELECT負荷があ る場合と無い場合でのスタンバイ・データベースサーバのCPU利用率を比較したもので す。リアルタイム・クエリーによるSELECT負荷を掛けていない場合、スタンバイ・デ ータベースサーバではREDOの適用処理のみを行っており、CPU使用率はほんの十数% 程度です。リアルタイム・クエリーによる追加負荷を掛けた場合はCPUリソースを 90% 以上利用しており、従来は使用できなかったCPUリソースを実際に最大限に活用できる ことを確認できます。 スタンバイ・データベースサーバのCPU利用率 0 20 40 60 80 100 0 60 120 180 240 300 360 420 480 540 600 時間(秒) CPU 使 用 率 (% ) SELECT負荷あり SELECT負荷なし REDOログの適用処理のみなので CPU使用率は低い REDOログデータ適用中にお いてもSELECT負荷を処理し リソースを有効活用している
グラフ ７-5 Oracle Active Data Guard によるスタンバイサイト CPU リソースの有効 活用効果
フィジカル・スタンバイ有効活用時のシステムダウンタイム短縮効果
図 ７-5のような、プライマリサイトでは 24 時間オンラインショッピング業務を実行 しており、スタンバイサイトでは、夜間から日中にかけてレポートバッチおよび日時処 理業務をREAD-ONLYモードで活用しているような運用を想定します。
6:00 オンラインショッピングサービス オンラインショッピングサービス 12:00 18:00 24:00 プライマリサ イト スタンバイ サイト レポートバッチ レポートバッチ 日次処理 日次処理 オンラインショッピングサービス オンラインショッピングサービス フェールオーバー スタンバイサイト活用中にプラ イマリサイトに障害発生 オンラインショッピング サービスダウンタイム 図 ７-5 今回検証した想定業務シナリオ フィジカル・スタンバイを有効活用している際にプライマリサイトに障害が発生した 場合、オンラインショッピング業務をスタンバイサイトにフェイルオーバーします。そ の際にはプライマリ・データベースから転送されてきたREDOの適用をすべて完了しな ければなりません。従来方法ではフィジカル・スタンバイ有効活用中はREDOを適用で きないため、フェイルオーバー時に大量の未適用REDOを適用しなければならない可能 性があります。一方、Oracle Active Data Guardのリアルタイム・クエリー機能を使用 している場合はスタンバイサイトを有効活用中も転送されてきたREDOを随時適用す るため、フェイルオーバー時間が短縮されます。このような想定で実際に検証した結果 がグラフ ７-6です。グラフ上では障害発生を確認後、スタンバイ・データベースをプラ イマリ・データベースに切り替えてサービス再開し、新しいプライマリ・データベース に対して負荷を再生成するまでの間トランザクションスループットは０になります。こ の時間をフェイルオーバー時間と定義し、従来のケースとOracle Active Data Guardの ケースを比較しました。従来のケースと比較し、Oracle Active Data Guardではフェイ ルオーバー時間が大幅に短縮しています。従来のケースにおける、フェイルオーバー時 の未適用REDO量は約 20GBでしたが、未適用のREDO量が多い場合は、フェイルオー バー時間もその分さらに長くなります。 0 12 0 24 0 36 0 48 0 60 0 72 0 84 0 96 0 108 0 120 0 132 0 144 0 156 0 168 0 180 0 192 0 204 0 216 0 228 0 オン ラ イ ンシ ョッ ピン グ トラ ン ザ ク シ ョ ン ス ル ー プ ッ ト 0 12 0 24 0 36 0 48 0 60 0 72 0 84 0 96 0 108 0 120 0 132 0 144 0 156 0 168 0 180 0 192 0 204 0 216 0 228 0 オ ン ラ イ ンシ ョ ッ ピン グ トラ ン ザ クシ ョ ン ス ル ー プ ッ ト オンラインショッピング長 時間のサービスダウンタ イムが発生 フィジカルスタンバイ活用中も ログデータ適用されるため フェールオーバー時間が短縮 従来方法による スタンバイ活用の場合
Oracle Active Data Guard
によるスタンバイ活用の場合
時間 時間
グラフ ７-6 Oracle Active Data Guard によるフィジカル・スタンバイ有効活用時のシ ステムダウンタイム短縮効果
- 22 -
７-３ スタンバイ・データベースにおけるREDO適用性能の測定
一般的にシステムの可用性について考える場合には、リカバリ・ポイント目標（Recovery Point Objective : RPO）とリカバリ時間目標（Recovery Time Objective : RTO）の 2 つ指標を考慮す る必要があります。Oracle Data Guardの仕組みにおいては、RPO には プライマリ・データベ ースからスタンバイ・データベースへのREDO転送の設定や転送性能が関連します。これは、フ ェイルオーバー時に、スタンバイ・データベースに未転送だったREDOがシステムの紛失データ となるためです。一方、RTOに関しては、スタンバイ・データベースでのREDO適用性能（以降、 REDO適用性能）が影響します。これは、Oracle Data Guardではフェイルオーバー時間には未 適用のREDO適用時間が含まれるためです（※）。フィジカル・スタンバイへのフェイルオーバー は、大まかに以下の図 ７-6のような流れになります。 障害検知 障害検知 までの時間 までの時間 インスタンス インスタンス をオープン をオープン 未適用の 未適用の REDO REDOを適用を適用 ロールの ロールの 変更 変更 障害発生 フェイルオーバー 操作開始 フェイルオーバー操作完了 アプリケーションから見た停止時間
Oracle Data Guard の フェイルオーバー操作
図 ７-6 フィジカル・スタンバイへのフェイルオーバーの流れ
（※） Oracle Data Guard では、障害発生後に REDO を適用せず、即時にサービスを再開す ることも可能ですが、データ保護の観点から適用可能なREDO を全て適用した上でサービスを再 開することが推奨されています。 REDO 適用性能が適正かどうかを判断する方法としては、プライマリ・データベースの REDO 生成量に対するスタンバイ・データベースでのREDO 適用性能の比較する方法が考えられます。 REDO 適用性能が REDO 生成量を下回る場合は、運用時にはプライマリ・データベースとスタ ンバイ・データベースの最新データの差が開き、未適用のREDO が増加するため、障害発生時の フェイルオーバーにもその分時間がかかることが予想できます。
プライマリ・データベース スタンバイ・データベース REDO転送 プライマリ・データベース スタンバイ・データベース REDO転送 N時間後 転送/受信済みREDO 適用済みREDO 適用性能が低いと 受信済みREDOと 適用済みREDOの 差が開いていく 図 ７-7 REDO 適用性能が低い場合
一方、REDO 生成量を上回る REDO 適用性能があれば、未適用の REDO を極小化でき、結果 的にフェイルオーバー時間も極小化されます。 プライマリ・データベース スタンバイ・データベース REDO転送 プライマリ・データベース スタンバイ・データベース REDO転送 N時間後 十分な適用性能が 出ていれば、差は 開かない 転送/受信済みREDO 適用済みREDO 図 ７-8 十分な REDO 適用性能を確保できている場合 - 24 -
ここでは、プライマリ・データベースにおいて高負荷なトランザクションが実行されていると きのREDO 生成量とスタンバイ・データベースの REDO 適用性能を比較し、適正な REDO 適用 性能が出ているかを確認しました。
プライマリ・データベースのへ負荷生成の前後にOracle の統計情報を取得し、その差分から 1 秒間のREDO 生成量を計算しました。また、REDO 適用性能は、合計サイズが約 3GB のアーカ イブREDO ログ・ファイル群の適用によって性能を測定しました。測定開始前にはスタンバイの Oracle インスタンス再起動し、適用性能は V$RECOVERY_PROGRESS ビューより秒間の REDO 適用サイズを確認しました。また、測定は Oracle Active Data Guard の使用を想定する ため、スタンバイ・データベースのOracle インスタンスは読み取り専用オープンの状態で行いま した。 REDO生成量とREDO適用性能を比較した結果がグラフ ７-7です。 0 2 4 6 8 10 生成量/適用性能比 REDO生成量 REDO適用性能 グラフ ７-7 REDO 生成量と REDO 適用性能の比較 プライマリ・データベース各インスタンスのREDO 生成量の合計を大きく上回る REDO 適用 性能を記録したことがわかります。Oracle Database 11g Release 1 では Oracle RAC 構成のス タンバイ・データベースのREDO 適用は 1 インスタンスで行います。REDO 適用性能はオンラ インREDO ログ・ファイルおよびアーカイブ REDO ログ・ファイルを配置するディスク構成な どに影響を受けますが、この結果より今回の検証では複数ノードが生成するREDO を遅延なく適 用できるだけの性能がでていることが分かります。
次に、フィジカル・スタンバイ・データベースが読み取り専用オープンである場合とマウント 状態である場合のREDO 適用性能を比較します。これによって、Oracle Active Data Guard 導 入による REDO 適用性能への影響の有無を確認します。測定方法は、先程と同様で、以下の 3 つのパターンでの測定方法を比較しました。 パターン番号 スタンバイ・インスタンス 1 スタンバイ・インスタンス 2 1 マウント マウント 2 読み取り専用オープン マウント 3 読み取り専用オープン 読み取り専用オープン 表 ７-1 適用性能比較パターン
適用性能を比較した結果がグラフ ７-8です(パターン 1 の適用性能を 1 とした場合)。 0 0.2 0.4 0.6 0.8 1 1.2 1 2 3 パターン番号 適用 性能 比 適用性能比 グラフ ７-8 適用性能比 フィジカル・スタンバイ・データベースのインスタンスがマウント状態か読み取り専用オープ ン状態かに関わらず、適用性能は同等でした。これにより、Oracle Active Data Guard 導入によ るREDO 適用性能への影響はないことが分かります。
- 26 -
７-４ ファスト・スタート・フェイルオーバー
ファスト・スタート・フェイルオーバーは、プライマリ・データベースの障害検知と検知後の フェイルオーバーを自動的に行う機能です。Oracle Database 10g Release 2 では、ファスト・ス タート・フェイルオーバーの機能を使用するには、保護モードを最大可用性モードに設定するた め、同期REDO 転送を設定する必要がありました。同期 REDO 転送では、プライマリ・データ ベースへの更新データの保護がコミットレベルで保証されますが、高い応答性能が要求される業 務においては、ネットワーク性能に起因するプライマリ・データベースの応答時間劣化等、パフ ォーマンスへの影響を考慮する必要がありました。Oracle Database 11g Release 1 では、非同 期REDO 転送の設定が可能な保護モードである最大パフォーマンスモードでもファスト・スター ト・フェイルオーバーが設定可能になり、より多くの要件に対応可能になっています。
非同期REDO転送を設定した場合、プライマリ・データベースとスタンバイ・データベースの 最新データにタイムラグが発生する可能性があります。このタイムラグは、フェイルオーバーし た場合に消失するデータを意味します。Oracle Database 11g Release 1 のファスト・スタート・ フェイルオーバーでは、障害発生時に許容できるタイムラグをあらかじめ指定し、障害発生時に はそのタイムラグ値にしたがってフェイルオーバーを開始するかどうかを判断します。ここでは、 タイムラグ値を60 秒に設定した上でプライマリ・データベースの全インスタンスを abort オプ ションで停止し、ファスト・スタート・フェイルオーバーの動作を確認しました。障害発生後の 挙動は図 ７-9のようになりました。 スタンバイ・データベース プライマリ・データベース
②
オブザーバ①
図 ７-9 ファスト・スタート・フェイルオーバーの動作 ① オブザーバはプライマリ・データベースとの接続不能な時間が一定時間続くと障害と判 断します。障害と判断するまでの時間は任意に指定可能です。 ② オブザーバはプライマリ・データベースとスタンバイ・データベースの最新更新情報の タイムラグを確認します。タイムラグ値が事前指定した値より小さければフェイルオー バーを開始します。タイムラグ値は、スタンバイ・データベースの v$dataguard_stats ビューより確認できます。今回のケースでは、タイムラグが以下のように 0 秒だったた め、フェイルオーバーが実行されました。- 28 -
SQL> select name,value from v$dataguard_stats where name='transport lag'; NAME VALUE --- --- transport lag +00 00:00:00 一方、タイムラグ値が事前指定の閾値を超えていた場合は、フェイルオーバーは行われません。 これは、タイムラグ値が閾値を超えていることが、許容されないデータ消失量であることを意味 するためです。このような場合、スタンバイ・データベースの v$database ビューで確認可能な ファスト・スタート・フェイルオーバーのステータスは” TARGET OVER LAG LIMIT” と表示 されます。
SQL> select fs_failover_status from v$database; FS_FAILOVER_STATUS
--- TARGET OVER LAG LIMIT
以上のように、Oracle Database 11g Release 1 のファスト・スタート・フェイルオーバーで は、最大パフォーマンスモードによる非同期REDO 転送設定時にも、システムごとのデータ保護 の要件に合わせた自動フェイルオーバーが実現できることが確認できました。
Oracle Database 11g Release 1 では、タイムラグ値以外にも、様々な条件を設定することが でき、それによって自動フェイルオーバーの動作を細かく制御できるようになっています。これ らの機能拡張を有効に活用することで、フェイルオーバーに伴う管理作業が軽減されることが期 待されます。
７-５ 高負荷トランザクション状況下でのフェイルオーバー
Oracle RACが、プライマリ・データベースでの片ノード障害などのサイト内で局所的な障害に 対する業務継続性を提供するのに対し、Oracle Data Guardはプライマリ・データベースの全ノ ード障害などのサイト障害に対する業務継続性を提供します。今回、プライマリ・データベース に高負荷なトランザクションを掛けている状態で、いくつかの発生しうる障害を発生させ、必要 である場合はスタンバイ・データベースへのフェイルオーバーを実施し、トランザクションが継 続処理可能であることを検証し確認しました。今回検証した障害ケースを図 ７-10示します。３ つのOracle Data Guard構成A,B,C(表 ７-2)において、それぞれ障害 1～5(表 ７-3)を発生させま した。 プライマリ・データベース スタンバイ・データベース プライマリサイト スタンバイサイト 障害検証パターン ①プライマリ・データ ベース全インスタ ンス障害 ②プライマリ・データ ベース全サーバ 障害 ④スタンバイ・デー タベース全イン スタンス障害 ⑤スタンバイ・デー タベースのリスナー 障害 ③プライマリースタ ンバイ間のネット ワーク通信障害 図 ７-10 高負荷トランザクション状況下でのフェイルオーバー検証
構成 Oracle Data Guard の保護モード スタンバイサイトの状態 A 最大パフォーマンスモード Oracle Active Data Guard B 最大可用性モード Oracle Active Data Guard C 最大パフォーマンスモード スナップショット・スタンバイ 表 ７-2 検証構成パターン # 発生させた障害 障害発生の方法 1 プライマリ・データベースの全 Oracle インスタンス障害 プ ラ イ マ リ ノ ー ド 1 に て 、 srvctl stop database –o abort コマンドを実行
2 プライマリ・データベースの全 サーバ障害 プライマリノード 1 およびノード 2 におい て、同時にhalt –n -f コマンドを実行 3 プライマリ－スタンバイ間のネ ットワーク通信障害 ネットワークケーブルを抜く
4 スタンバイ・データベースの全 Oracle インスタンス障害
ス タ ン バ イ ノ ー ド 1 に て 、 srvctl stop database –o abort コマンドを実行
5 スタンバイ・データベースのリ スナー障害 スタンバイノード 1 およびノード 2 におい て、同時にリスナープロセスをkill 表 ７-3 検証した障害パターン 検証の手順は以下の通りです。 ① プライマリ・データベースへの負荷生成開始 ② プライマリ・データベース障害を擬似発生 ③ 負荷生成を停止 ④ スタンバイ・データベースへのフェイルオーバー実施 ⑤ 負荷生成再開 検証結果としては、すべての構成において、期待した挙動を示しました(表 ７-4)。プライマリ・ データベースにおける全Oracleインスタンス障害および全サーバ障害のケースにおいては、スタ ンバイ・データベースにフェイルオーバーすることで、トランザクション処理を継続することが 可能であることを確認しました。 # 発生させた障害 障害発生後の挙動結果 1 プライマリ・データベースの全 Oracle インスタンス障害 各構成ともスタンバイ・データベースへフェ イルオーバー実施後に、継続してトランザク ションを処理できることを確認。 2 プライマリ・データベースの全 サーバ障害 各構成ともスタンバイ・データベースへフェ イルオーバー実施後に、継続してトランザク ションを処理できることを確認。 3 プライマリ－スタンバイ間のネ ットワーク通信障害 各構成ともプライマリ・データベースにて継 続してトランザクション処理可能。 構成B では、NET_TIMEOUT 属性で設定さ れた秒数（本検証では 30 秒に設定）だけト ランザクション処理は停止し、その後は継続 して処理可能。 4 スタンバイ・データベースの全 Oracle インスタンス障害 各構成ともプライマリ・データベースにて継 続してトランザクション処理可能。 構成B においても継続してトランザクション を処理できることを確認。 5 スタンバイ・データベースのリ スナー障害 各構成ともプライマリ・データベースにて継 続してトランザクション処理可能。 表 ７-4 検証した障害パターンと検証結果 高負荷トランザクション時のフェイルオーバーで特徴的な挙動をひとつ紹介します。 グラフ ７-9は、構成Aでのプライマリ・データベースにおける全インスタンス障害時のトランザ クションスループットとプライマリ、スタンバイ各サーバのCPU使用率の挙動を示したグラフで - 30 -
す。①で障害発生後、②でフェイルオーバーが完了しトランザクションが再開しています。③ま での間にトランザクションスループットの落ち込みが見られます。これはフェイルオーバー後の データベースサーバにおいて行われるスタンバイREDOログ・ファイルのクリア処理によるディ スクI/Oと、再開したトランザクションによって発生するオンラインREDOログ・ファイルへのデ ィスクI/Oが競合することによって起こる挙動です。スタンバイREDOログ・ファイルのクリアに かかる時間は、ファイルサイズの合計とディスクI/O性能に依存します。この挙動を回避する方法 としては、スタンバイREDOログ・ファイルのクリアと通常のワークロードをカバーできるだけ のディスクI/O帯域を確保する方法や、オンラインREDOログ・ファイルとスタンバイREDOロ グ・ファイルを別のディスクに配置し、ディスクI/Oの競合を避ける方法が挙げられます。 0 20 40 60 80 100 0 20 40 60 80 100 0 20 40 60 80 100 0 20 40 60 80 100 0 12 0 24 0 36 0 48 0 60 0 72 0 84 0 96 0 10 80 12 00 13 20 14 40 15 60 16 80 18 00 19 20 20 40 21 60 22 80 トラン ザ ク シ ョ ン スルー プ ッ ト プライマリ・インスタンス1 のCPU使用率 プライマリ・インスタンス2 のCPU使用率 スタンバイ・インスタンス1 のCPU使用率 スタンバイ・インスタンス2 のCPU使用率 トランザクション スループット ① ② ③ ① プライマリデータベース全 インスタンス障害発生 ①～② スタンバイへフェールオーバー ②～③ REDOクリア処理 グラフ ７-9 プライマリ・データベースの全インスタンス障害時のトランザクションと 各データベースサーバのCPU 使用率の挙動
- 32 -
Copyright © 2008 Hitachi, Ltd. All Rights Reserved.
８ まとめ
今回のGRID Center における検証で、日立プラットフォーム上における Oracle Database 11g Release 1 の Oracle Data Guard について、その有効性を十分に実証することができました。特 にOracle Database 11g Release 1 で新たに提供された Oracle Active Data Guard が、スタンバ イサイトのリソースの有効活用と有効活用時における障害時フェイルオーバー時間短縮の両立を 実現可能であることを実証できたと考えています。Oracle Database 11g Release 1 新機能によ って、ディザスタリカバリシステムの費用対効果を従来よりも大きく向上させることができると 考えています。
また、大規模なトランザクション負荷環境での障害時の挙動を検証し、トランザクション業務 の継続性を確認することができました。日立のハードウェアとOracle Database 11g Release 1 Oracle Data Guard によるディザスタリカバリソリューションにより、企業インフラの BCM を 支える基盤を提供することができると考えています。
本ドキュメントご利用にあたっての注意事項
本ホワイトペーパに記載されている内容は、Oracle GRID Center にて実施された検証結果にも とづくものあり、すべての環境において同様の結果が得られるとは限りません。効果はお客様の 環境およびその他の要因によって異なる可能性があります。
