Oracle Data Guard 11g 次世代のデータ保護と可用性

Transcription

1 Oracle Data Guard 11g 次世代のデータ保護と可用性 Oracle テクニカル ホワイト ペーパー 2007 年 5 月

2 ご注意 本書は オラクルの一般的な製品の方向性を示すことが目的です また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 下記の事項は マテリアルやコード 機能の提供を確約するものではなく また 購買を決定する際の判断材料とはなりえません オラクルの製品に関して記載されている機能の開発 リリース および時期については 弊社の裁量により決定いたします Oracle Data Guard 11g 次世代のデータ保護と可用性 2

3 Oracle Data Guard 11g 次世代のデータ保護と可用性 はじめに... 4 Oracle Data Guard - 概要... 5 Oracle Data Guard 11g の新機能の概要... 7 Oracle Data Guard プロセス アーキテクチャ 主要テクノロジ コンポーネント Oracle Data Guard 構成 保護モード 最大保護モード 最大可用性モード 最大パフォーマンス モード 自動ギャップ解消 - 通信障害の対応 適用サービス - REDO Apply と SQL Apply フィジカル スタンバイ データベース - REDO Apply REDO をスタンバイ データベースに適用する前のデータ検証 REDO Apply とリアルタイム問合せ スナップショット スタンバイ ロジカル スタンバイ データベース - SQL Apply SQL Apply の動作 REDO Apply または SQL Apply のいずれかを選択する方法 Oracle Data Guard 構成の管理 ロール管理サービス スイッチオーバー フェイルオーバー ファスト スタート フェイルオーバー 柔軟性に優れた構成オプション 新しいスタンバイ データベースとしての旧プライマリ データベースのリストア 自動クライアント フェイルオーバー サービスの再配置 クライアント通知および再接続 ロール移行イベント ローリング データベース アップグレード カスケードした宛先 Oracle Data Guard および Oracle Real Application Clusters Oracle Maximum Availability Architecture Oracle Data Guard とリモート ミラー化ソリューション Oracle Data Guard の顧客 結論 参考資料 Oracle Data Guard 11g 次世代のデータ保護と可用性 3

4 Oracle Data Guard 11g 次世代のデータ保護と可用性 はじめに Oracle Data Guard 11g のハイライト プライマリから受け取った更新を適用する場合のフィジカル スタンバイ データベースへの読取りアクセス 損失ゼロのデータ保護を実現するテストなどの目的で読取り / 書込みでオープンされるフィジカル スタンバイ データベース 同期転送または非同期転送を使用した自動フェイルオーバー 高速な REDO ギャップ解消のアーカイブ ログの圧縮 プライマリ / スタンバイ構成の向上した柔軟性 (Windows プライマリや Linux スタンバイなど ) SQL Apply の XML データ型 (CLOB) サポート パフォーマンス 管理性 セキュリティの多くの強化機能 効率的な業務 高品質の顧客サービス 政府の規制への適合性 および企業情報資産の保護は すべて最高水準のデータ保護と可用性の実現によって決まります このため あらゆる規模および業界の企業におけるビジネス継続性構想の最優先事項としてデータ保護と可用性が示されても不思議ではありません 表面上 このような要件を満たす製品とサービスは 成熟していて魅力のないものに見えます テープ ストレージ ベースのリモート ミラー化 データベース ログ送信を使用したバックアップおよびリカバリは データ保護と障害時リカバリ (DR) 要件の従来からのソリューションです 従来のソリューションには 以前からの欠点も付随します たとえば リカバリ ポイント ( データ保護 ) とリカバリ時間 ( 高可用性 ) の両方の積極的な目標を確実に提供できない あるいは十分に活用されていない資産 高い取得コストおよびサポート コスト 複雑さの拡大を回避して最大の投資収益率を実現する方法で提供できない点です 一方 Oracle Data Guard 11g[1] は 障害時リカバリ ソリューションからユーザーが期待する内容を再定義します 高可用性と障害時リカバリの要件の両方に対応でき Oracle Real Application Clusters(Oracle RAC) を理想的に補完します Oracle Data Guard には プライマリ データベースから伝播する破損からスタンバイ データベースを確実に保護する Oracle データベースの必須機能があり 実装および管理が容易です また スタンバイ ロールで実行中にフィジカルとロジカル両方のスタンバイ データベースを本番目的で使用できます Oracle Data Guard には 以下の機能があります 信頼性 - 最適なデータ保護と可用性 スタンバイ データベースの状態を常に把握し 素早く ( 秒単位で ) プライマリ ロールを適用できます 低いコストと複雑さ - Oracle Database Enterprise Edition は 充実した機能および豊富な管理インタフェースを備えています 最大の投資収益率 - スタンバイ ロールで実行中にすべてのスタンバイ データベースを本番目的で使用できます 複雑さまたはコストが増えることなく アイドル リソースが排除されます Oracle Data Guard 11g 次世代のデータ保護と可用性 4

5 システムおよびインフラストラクチャに組み込まれた高可用性の度合いに関係なく 使用中の IT アーキテクチャに Oracle Data Guard を配置することで データ保護と可用性が例外なく拡張されます このホワイト ペーパーでは Oracle Data Guard 11g について アーキテクチャとテクノロジの面から概説します 詳細については Oracle Data Guard ドキュメント [2] を参照してください Oracle Data Guard - 概要 "Fidelity National Financial 社は Oracle RACおよびGridインフラストラクチャを実装しました また Oracle Recovery Managerを配置してバックアップとリカバリ機能を実装し Oracle Data Guard を利用してWAN 全体のリモート障害時リカバリと高可用性を実現しました Oracle High Availability 機能の利用と Oracle Maximum Availability Architecture (MAA) ベスト プラクティスの実装によって Fidelity National Financial 社は最小コストで品質保証契約を満たすことができました " Oracle Data Guard は 統合された Oracle Database High Availability(HA) ソリューション セットの中心コンポーネントです このコンポーネントを使用して業務に影響を及ぼす可能性のあるさまざまな計画停止時間と計画外停止時間を最小限に抑えることによって 組織はビジネスの継続性を確保できます 次の図は Oracle Database 11g で使用できるさまざまな HA 機能を示しています これらの各機能の詳細については Oracle Technology Network の Oracle Database High Availability[3] を参照してください - Fidelity Information Services Chief Oracle Database Engineering Counsel Charles Kim 氏 図 1 - Oracle Database 11g の統合された高可用性機能 Oracle Data Guard は 管理 監視 自動化のためのソフトウェア インフラストラクチャで 企業のデータを故障 障害 エラー 破損から保護するために 1 つまたは複数のスタンバイ データベースを作成し 保守し 監視します ユーザーの要求がある場合 Oracle Data Guard は ミッション クリティカルなアプリケーションに必要な高可用性を維持するために プライマリ システムで障害が発生した場合 本番システムをスタンバイ システムに自動的にフェイルオーバーします HA や DR の提供以外に Oracle Data Guard スタンバイ データベースは スタンバイ ロールで実行中にレポート 問合せ バックアップ およびテストに使用される本番機能もサポートします Oracle Data Guard の内部アーキテクチャは 3 つの異なる領域の実績あるサービス (REDO 転送サービス 適用サービス ロール管理サービス ) で構成されます Oracle Data Guard 11g 次世代のデータ保護と可用性 5

6 Oracle Data Guard REDO 転送サービス :Oracle Data Guard 構成には プライマリ データベースとも呼ばれる本番データベースと最大 9 個のスタンバイ データベースが含まれます Oracle Data Guard は REDO データを使用して プライマリ データベースとスタンバイ データベースの同期を維持します プライマリ データベースでトランザクションが発生すると REDO データ ( トランザクションのリカバリに必要な情報 ) が生成され ローカル REDO ログ ファイルに書き込まれます Oracle Data Guard REDO 転送サービスを使用して この REDO データをスタンバイ サイトに同期または非同期で転送します この柔軟性によって スタンバイ データベースを本番データ センターから数千マイル離れた障害時リカバリ サイトに配置することも 本番データ センターと同じ都市 同じ構内 同じ建物 あるいは同じコンピュータ ルームに設置することもできます Oracle Data Guard 適用サービス :REDO データをスタンバイ サイトに転送した後 Oracle Data Guard 適用サービスは データをスタンバイ データベースに適用する 2 つの異なる方法を提供します 2 つの方法とは Oracle Data Guard REDO Apply( フィジカル スタンバイ ) と Oracle Data Guard SQL Apply( ロジカル スタンバイ ) です フィジカル スタンバイ データベースは ブロック単位でプライマリ データベースとまったく同一のオンディスク データベース構造になっており Oracle メディア リカバリを使用して更新します ロジカル スタンバイ データベースは プライマリ データベースと同じデータを持つ独立したデータベースで SQL 文を使用して更新します それぞれの方法に利点があり 要件に最適な方法を選択する柔軟性を顧客に提供します これらの違いは このホワイト ペーパーの後半で詳しく説明します "Oracle Data Guard ファスト スタート フェイルオーバーは 緊急時でも 1 日 24 時間態勢で重要な顧客サービスを提供するために PPL が依存する停止管理システムの人を介さない簡単で高速なフェイルオーバーを実現します Oracle9i から障害時リカバリ (DR) に Oracle Data Guard を使用していますが ファスト スタート フェイルオーバーは高可用性と DR の境界をなくします このため 単一のソリューションで両方の要件を満たすことができます " - PPL Services Corp. Enterprise Technology Services ディレクタ Chris Carter 氏 Oracle Data Guard ロール管理サービス : 計画停止または計画外停止によって本番データベースが使用できなくなった場合 Oracle Data Guard ロール管理サービスは 選択されたスタンバイ データベースを本番ロールに素早く切り替え 停止時間を最小限に抑えて データ損失を防止します Oracle Data Guard は 手動の制御 またはユーザー設定可能な一連のルールに準拠したオペレータが介入しない自動的な制御で ロールを移行する柔軟性を提供します Oracle Data Guard は ミッション クリティカルなアプリケーションに必要なレベルの高可用性を提供するためにクライアント フェイルオーバーを自動化するインフラストラクチャを提供します フェイルオーバーの後 障害が発生したプライマリは 新しいプライマリのスタンバイ データベースとして迅速に回復して 構成を保護された状態に素早く戻すことができます Oracle Data Guard 構成の作成および管理 : プライマリ データベースとスタンバイ データベース およびその間のさまざまな通信は SQL*Plus を使用して管理できます また Oracle Data Guard Broker と呼ばれる Oracle Data Guard 構成の作成 メンテナンス 監視を自動化して一元化するための 分散型管理フレームワークも実装されています 管理者は Oracle Enterprise Manager Grid Control あるいは Oracle Data Guard Broker のコマンドライン インタフェース (DGMGRL) によって Oracle Data Guard Broker を操作できます スタンバイ リソースの利用 : すべての Oracle Data Guard スタンバイ データベースは プライマリ データベースから受け取った REDO を適用して スタンバイ データベースへの最新の読取りアクセスを有効にします Oracle Data Guard 11g 次世代のデータ保護と可用性 6

7 これによって すべてのスタンバイ データベースは 読取り専用の問合せとレポートをサポートするプライマリ データベースのオーバーヘッドを軽減するための優れた選択肢となります すべての Oracle Data Guard スタンバイ データベースは RMAN[4] を使用したオンライン バックアップをサポートします フィジカル スタンバイ データベースはプライマリ データベースの完全なレプリカなので フィジカル スタンバイ データベースを使用して プライマリ データベースのバックアップのオーバーヘッドを軽減できます フィジカル スタンバイ データベース (REDO Apply) をスナップショット スタンバイに変換できます これによって 本番データの読取り / 書込み用のレプリカを使用したホット パッチおよびその他のテストを実行できます Oracle Data Guard は スナップショット スタンバイへの REDO データの送信を継続して 常にデータを保護します スナップショット スタンバイは 安全に保管するためにアーカイブされ テストの終了後にスタンバイ データベースに戻される際に素早く再同期するために使用できます "Oracle Data Guardローリング アップグレードでは データベース (Oracle Database から ) サーバー ストレージの完全なアップグレードの実行中に停止時間が制限されます 読取りアクセス用の停止時間はなく 読取り / 書込みトランザクションの停止時間は 30 分未満です " - Thomson Legal & Regulatory データベース アーキテクト Dan Dressel 氏 (Oracle OpenWorld 2006 にて ) ロジカル スタンバイ (SQL Apply) データベースでは オープンな読取り / 書込みの柔軟性が向上しています SQL Apply によって保守されるデータを変更できない場合 ローカル表をデータベースに追加できます また ローカル索引構造を作成して レポートを最適化したり データ ウェアハウスとしてスタンバイ データベースを利用したり データ マートをロードするために使用される情報を処理したりできます ロジカル スタンバイ データベースを使用して ローリング データベース アップグレードを実行できます これによって 新しいデータベース パッチセットまたは完全なデータベース リリースにアップグレードする場合に停止時間を最小限に抑えられます また 一時的にフィジカル スタンバイを一時ロジカル スタンバイに変換して ローリング データベース アップグレードを実行した後にフィジカル スタンバイの通常の運用状態に戻すことができます Oracle Data Guard 11g の新機能の概要 Oracle Data Guard 11g で利用できる新機能は 以下のとおりです リアルタイム問合せ : フィジカル スタンバイ データベースは Apply がアクティブな場合に読取り専用でオープンできます これによって フィジカル スタンバイ データベースに接続しているユーザーは プライマリ データベースの最新のデータの問合せとレポートを行うことができます スナップショット スタンバイ : これは フィジカル スタンバイ データベースから作成される新しいタイプのスタンバイ データベースです 作成された後 スナップショット スタンバイを読取り / 書込みでオープンして テストなどを実行するためにプライマリ データベースから独立したトランザクションを処理できます スナップショット スタンバイ データベースは 引き続きプライマリ データベースから更新を受信およびアーカイブします ただし プライマリから受け取った REDO データは スナップショット スタンバイがフィジカル スタンバイ データベースに変換されてスナップショット スタンバイのときに実行されたすべての更新が破棄されるまで 適用されません このため 本番データを常に保護できます SYNC および ASYNC の REDO 転送の自動フェイルオーバー :Oracle Data Guard 10g Release 2 では 最大可用性の保護モード (SYNC) における新機能のファスト Oracle Data Guard 11g 次世代のデータ保護と可用性 7

8 スタート ファイルオーバーを使用した自動フェイルオーバーを導入しました Oracle Data Guard 11g は ファスト スタート フェイルオーバーを拡張して 最大パフォーマンス モード (ASYNC) もサポートしています 自動フェイルオーバーを保証するユーザー設定可能なデータ損失しきい値の追加によって 任意のリカバリ ポイント目標 (RPO) を超えるデータ損失は発生しません ユーザーは 指定された状態チェック条件または任意の ORA-nnnnn エラーに基づくファスト スタート フェイルオーバーのしきい値の期限まで待つことなく すぐに自動フェイルオーバーを実行できるように構成できます パッケージ化された新しい DBMS_DG PL/SQL によって アプリケーションは 自動フェイルオーバーの開始をファスト スタート フェイルオーバーのオブザーバ プロセスに通知できます "Oracle Data Guard は Oracle データの適切な障害時リカバリ ソリューションです 私たちは 非常に高いパフォーマンスのアプリケーションを利用できます データ損失ゼロ構成では Oracle Data Guard が実現するスループットに匹敵するサード パーティ製品はありません " - Fannie Mae マネージャおよびインフラストラクチャ アーキテクト Manohar Malayanur 氏 パフォーマンスの強化機能 : 多くのパフォーマンス強化機能には 以下が含まれます パラレル メディア リカバリ ( フィジカル スタンバイ ) によって すべてのワークロード プロファイルのフィジカル スタンバイ適用パフォーマンスが大幅に向上します SQL Apply の強化機能 ( ロジカル スタンバイ ) によって LOB LONG または XML 型の列を含まずパーティション化されていない表への挿入および更新の適用パフォーマンスが向上します また SQL Apply は 以前のリリースのようなシリアル処理ではなく パラレル処理でパラレル DDL を適用できるようになりました ASYNC REDO 転送の強化機能によって ネットワーク スループットが向上します ギャップ解消用に送信されるアーカイブ ログを圧縮して ネットワークまたはスタンバイ データベースの停止後に行われるスタンバイ データベースの再同期がさらに高速になります ファスト スタート フェイルオーバー使用中のフェイルオーバー時間をさらに短縮します フィジカル スタンバイ データベースで RMAN ブロック変更追跡をサポートするスタンバイ データベースの増分バックアップがさらに高速になります 一時ロジカル スタンバイ : ユーザーは フィジカル スタンバイを一時ロジカル スタンバイに変換し ローリング データベース アップグレードを実行し アップグレードの終了後にフィジカル スタンバイに戻します (KEEP IDENTITY 句の使用 ) このため ローリング データベース アップグレードを実行するフィジカル スタンバイ ユーザーは 冗長ストレージに投資する必要がありません その他の場合 ロジカル スタンバイ データベースを作成する必要があります データ保護の拡張 : フィジカル スタンバイは ストレージ ハードウェアおよびファームウェアの故障によるデータ破損によって引き起こされるデータファイルの書込み損失を検出できます Oracle Data Guard は スタンバイのブロックのバージョンと受信する REDO ストリームのバージョンを比較します バージョンが異なる場合 書込み損失が発生したことを示します ユーザーは スタンバイ データベースにフェイルオーバーしてデータの整合性を回復できます セキュリティの強化 : パスワード ファイルの代わりに SSL 認証を使用して REDO 転送を認証できます 注 :SSL 認証には PKI 証明書 ASO および OID が必要です Oracle Data Guard 11g 次世代のデータ保護と可用性 8

9 "Oracle Data Guard ロジカル スタンバイは 処理能力とスケーラビリティを大幅に向上させる長期戦略のハードウェアとソフトウェア プラットフォームの重要なコンポーネントです この完全なソリューションを実装すると ほとんどのバッチ処理操作で 50~95% パフォーマンスが向上しました " - e-rewards Market Research ビジネス インテリジェンス アーキテクト David Sink 氏 追加の SQL Apply データ型のサポート :SQL Apply は 以下の機能を含む追加のデータ型 他の Oracle 機能 および PL/SQL のサポートを引き続き拡張します XMLType データ型 (CLOB として保存される場合 ) ロジカル スタンバイ データベースで並行して DDL を実行する機能 透過的データ暗号化 (TDE) DBMS_FGA( ファイングレイン監査 ) DBMS_RLS( 仮想プライベート データベース ) SQL Apply 管理性の強化機能 :DBMS_SCHEDULER パッケージを使用して スタンバイ データベースでスケジューラ ジョブを作成できます また 必要に応じて ( データベースがプライマリ スタンバイ または両方の場合など ) 実行できるように適切なデータベース ロールにスケジューラ ジョブを関連付けることができます Oracle RAC データベースの SQL Apply を使用したスイッチオーバーでは 各 Oracle RAC クラスタの最初のインスタンスを除くすべてのインスタンスを事前に停止する必要がなくなりました また SQL Apply を再起動することなく Oracle Data Guard SQL Apply パラメータを動的に設定できます DBMS_LOGSTDBY.APPLY_SET パッケージを使用して 初期化パラメータを動的に設定できます これによって ロジカル スタンバイ構成の管理性 アップタイム および自動化が改善されます Oracle Data Guard Broker の強化機能 : 以下の強化機能によって Oracle Data Guard Broker を使用すると管理がさらに簡素化されます 管理者による REDO 転送サービスの接続説明の指定が可能な REDO 転送オプションの改善されたサポート 保護モードの最大可用性モードと最大パフォーマンス モードを切り替える際のデータベース停止時間の排除 コールド ファイルオーバー クラスタとして Oracle Clusterware を使用した HA 用に構成された単一インスタンス データベースのサポート Oracle Enterprise Manager Grid Control 11g の強化機能 :Oracle Enterprise Manager は 以下の管理をさらに簡素化します 既存の RMAN バックアップからのスタンバイ データベースの作成 Oracle RAC プライマリからの Oracle RAC スタンバイ データベースの作成 レポート 開発 およびテスト用の自動化されたスタンバイ クローン スイッチオーバーまたはフェイルオーバーでの新しいプライマリ データベースへの Oracle Enterprise Manager のジョブとメトリックのしきい値の自動伝播 ファスト スタート フェイルオーバーのフォルト トレラントなオブザーバ Oracle Enterprise Manager Data Recovery Advisor は Intelligent Data Repair(IDR) への推奨を行う際に使用できるスタンバイ データベースを利用します Oracle Data Guard 11g 次世代のデータ保護と可用性 9

10 Oracle Data Guard プロセス アーキテクチャ 図 2 に示すように Oracle Data Guard では Oracle データベースの複数のプロセスを使用して 高可用性や障害時リカバリに必要な自動化を行います Oracle Data Guard は プライマリ データベースで LogWriter Network Server(LNS) という特殊なバックグラウンド プロセスを使用します このプロセスは ログ ライターによって書き込まれる REDO データを取得し 同期または非同期で REDO データをスタンバイ データベースに送信します LNS プロセスは 転送のオーバーヘッドおよびネットワークの分断からログ ライターを切り離します 同期 REDO 転送 (SYNC) を使用する場合 プライマリ データベースのログ ライターは クライアント アプリケーションのコミットを確認する前に スタンバイで REDO データを受け取ってデータがスタンバイ REDO ログに書き込まれたことを示す LNS からの確認応答を待つ必要があります これによって すべてのコミットされたトランザクションがディスク上に存在し スタンバイ ロケーションで保護されることが保証されます NEW! - 非同期 REDO 転送パフォーマンスの強化機能は ネットワーク利用とリカバリ ポイント目標をさらに改善します 非同期 REDO 転送 (ASYNC) を使用する場合 プライマリのログ ライターは REDO データがディスクに書き込まれたことを示すスタンバイ データベースからの確認応答を待つ必要がありません REDO 転送と非同期にクライアント アプリケーションに対してコミットが確認されます また ASYNC は スタンバイ データベースに REDO を効率的にストリーミングでき ネットワークのスループットを低下させる可能性のあるネットワークの確認応答によるオーバーヘッドを排除します 図 2:Oracle Data Guard プロセス アーキテクチャ プライマリ データベースとスタンバイ データベースの接続が ( ネットワーク障害またはスタンバイ サーバー障害により ) 切断される場合 選択された保護モード ( 保護モードはこのホワイト ペーパーの後半で説明します ) に応じて Oracle Data Guard 11g 次世代のデータ保護と可用性 10

11 プライマリ データベースは 引き続きトランザクションを処理し 新しいネットワーク接続が確立されるまで スタンバイに送信できない REDO データの未処理分を蓄積します ( アーカイブ ログ ギャップと呼ばれます ) この場合 Oracle Data Guard は スタンバイ データベース ステータスを継続的に監視し 接続を再確立する日時を検出して 構成をできるだけ素早く保護された状態に戻すためにスタンバイ データベースとプライマリ データベースを自動的に再同期します アーカイバ (ARCn) プロセスは ギャップの解消に必要なログ ファイルを送信するために常に利用されます ギャップ解消を迅速化する複数のオプションを使用できます NEW! - ギャップを解消してネットワークまたはスタンバイ サーバー障害の後にスタンバイ データベースを再同期するために必要なログ ファイルを送信する場合 アーカイブ ログ圧縮が使用されます Oracle Data Guard は 転送時間を短縮して使用できる帯域幅を最大限に活用するため ギャップを解消するために転送されるアーカイブ ログを圧縮できます 転送の必要な多くのアーカイブ ログが存在する場合 最大 30 個の ARCn プロセスを使用できます これらの 29 個の ARCn プロセスを離れた場所に送信できます 1 つの ARCn プロセスは 常時ローカル アーカイブ専用です アーカイブ ログの未処理分がわずかに存在し ログ サイズが非常に大きい場合 最大 5 個の ARCn プロセスを構成して 1 つのログ ファイルの内容を並行して送信できます Oracle Data Guard スタンバイ データベースは スタンバイ適用プロセスが消失したログ ファイルあるいは受信したアーカイブ ログの欠陥または破損を検出すると アーカイブ ログの新しいコピーを事前にリクエストします ARCn プロセスを使用して このようなリクエストを満たします Oracle Data Guard REDO 転送サービスの受信側で Oracle Data Guard は スタンバイ データベースの 1 つ以上のリモート ファイル サーバー (RFS) プロセスを使用して REDO データを受信し スタンバイ REDO ログ (SRL) というファイルに受信したデータを書き込みます 管理リカバリ プロセス (MRP) を使用して フィジカル スタンバイ データベースの REDO データの適用を調整します また ロジカル スタンバイ プロセス (LSP) を使用して ロジカル スタンバイ データベースへの SQL 変換された REDO データの適用を調整します Oracle Data Guard Broker が有効化されると Oracle Data Guard も Oracle Data Guard Broker モニター (DMON) と他のプロセスを使用して プライマリ データベースとスタンバイ データベースを統合された 1 つの構成として管理し監視します 主要テクノロジ コンポーネント Oracle Data Guard 構成 Oracle Data Guard のプライマリ データベースおよびスタンバイ データベースの構成は 単一ノードまたは Oracle RAC 環境で実行できます スタンバイ データベースは Oracle Net Services を使用して TCP/IP でプライマリ データベースに接続します データベース同士の通信が可能であれば 設置場所に関する制約はありません ただし 障害時リカバリを考慮した場合 スタンバイ データベースはプライマリ データベースから地理的に離れた場所へ設置することを推奨します Oracle Data Guard 11g 次世代のデータ保護と可用性 11

12 NEW! Oracle Data Guard 11g には プライマリ システムおよびスタンバイ システムに異なる CPU アーキテクチャ OS バイナリ および Oracle データベース バイナリを配置する複数のオプションがあります たとえば Windows のプライマリ データベース Linux のスタンバイ データベースがあります 最新の機能と制約については MetaLink Note を参照してください Oracle Data Guard 11g では Data Guard 構成の柔軟性が向上しています この構成では MetaLink Note に定義されている制約に準拠する 各種 CPU アーキテクチャ オペレーティング システム (Windows および Linux など ) オペレーティング システム バイナリ (32 ビット /64 ビット ) および Oracle データベース バイナリ (32 ビット /64 ビット ) が プライマリ システムおよびスタンバイ システムに含まれます プライマリ データベースとスタンバイ データベースの 2 つの不変の要件は endian フォーマットが同じことと Oracle データベースのリリースが同じことです ただし ロジカル スタンバイ データベースを使用したローリング データベース アップグレードの実行中を除きます 保護モード Oracle Data Guard には コスト 可用性 パフォーマンス およびデータ保護のバランスを取る データ保護モードが 3 種類用意されています これらのモードは Oracle Data Guard 構成の動作を管理するルールを定義し 使用可能な管理インタフェースによって簡単に設定できます たとえば プライマリ データベース上で次のような単純な SQL 文を実行します SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION AVAILABILITY PERFORMANCE}; 適切なデータ保護モードを決定するには 企業はデータ保護に関する自社のビジネス要件と システム応答時間に対するユーザー ニーズとを十分に検討する必要があります 次の表は データ消失リスクの観点から見た各モードの適合性をまとめたものです 保護モード最大保護モード最大可用性モード最大パフォーマンス モード プライマリ データベース障害発生時のデータ消失リスクデータ損失ゼロデータ損失ゼロ - 障害の前にプライマリ データベースでトランザクションをコミット中に同期通信で中断が発生しなかった場合を仮定します最小のデータ損失 - ネットワーク帯域幅によって数秒程度 REDO 転送 SYNC SYNC ASYNC 以下のセクションでは これら 3 種類の保護モードについて詳しく説明します 最大保護モード 最大保護モードは 最高レベルのデータ保護を提供します 最大保護モードは SYNC REDO 転送を使用して REDO レコードをスタンバイ データベースに同期的に転送します 少なくとも 1 つのスタンバイ サーバーのディスクにトランザクション データが安全に保存されることを Oracle Data Guard が確認するまで プライマリ データベース上のログ ライター プロセスは クライアント アプリケーションへのコミットを許可しません Oracle Data Guard 11g 次世代のデータ保護と可用性 12

13 REDO 送信が同期的に実行されることから 最大保護モードはプライマリ データベースの応答時間に影響を及ぼす可能性があります こうした影響は トランザクションのピーク負荷に対して十分な帯域幅を備えた 待機時間の短いネットワークを構成することで最小限に抑えることができます 最高レベルのデータ保護の配置例としては 金融機関 宝くじシステムなどがあります 最大保護モードは少なくとも 2 つのスタンバイ データベースの構成にすることを強く推奨します 1 つのスタンバイ宛先で障害が発生した場合 残りの宛先でプライマリを確認できるので 中断なく稼働を続行できます この保護モードを検討しているユーザーは 少なくとも 1 つのスタンバイ データベースで REDO データを受け取ってそのデータがディスクに書き込まれたことを示す確認応答が返らなかった場合に プライマリ データベースの停止 ( 後でクラッシュする ) を許可する必要があります この動作は 複数の障害が発生した場合 ( たとえば プライマリとスタンバイ間のネットワークで障害が発生し 2 つ目のイベントによってプライマリ サイトに障害が発生する場合 ) にデータ損失ゼロを実現する最大保護モードのルールで必要です このモードが使用不可でもデータ損失ゼロの保護を実現し スタンバイでデータ保護を保証できない環境でもプライマリを使用する必要がある場合は 次の最大可用性の保護モードを使用してください 最大可用性モード 最大可用性モードは プライマリ データベースの可用性を損なうことなく 2 番目に高いレベルのデータ保護を提供します 最大保護モードと同様に SYNC REDO 転送サービスを使用して REDO データを同期的にスタンバイ データベースに転送します 少なくとも 1 つのスタンバイ サーバーのディスクでトランザクション データが使用できることを Oracle Data Guard が確認するまで ログ ライターは プライマリ データベースによるトランザクションのコミットを許可しません ただし 最大保護モードと異なり 最後に参加したスタンバイ データベースがネットワーク接続の問題やスタンバイ障害などで使用不能となった場合 プライマリ データベース処理は続行されます スタンバイ データベースは 接続が切断された状態のときに一時的にプライマリ データベースよりも遅れます 接続が再確立されると Oracle Data Guard は スタンバイ データベースとプライマリ データベースを自動的に再同期します REDO が同期転送されるため この保護モードは応答時間とスループットに影響する可能性があります こうした影響は トランザクションのピーク負荷に対して十分な帯域幅を備えた 待機時間の短いネットワークを構成することで最小限に抑えることができます 最大可用性モードは データ損失ゼロを確実にする保護を必要とするものの 本番データベースがネットワークやスタンバイ サーバーの障害によって影響を受けることを望まないビジネスに適しています 最初のネットワークまたはスタンバイ サーバーの障害が解決して構成が再同期される前に 別の障害によって本番データベースが大きな影響を受ける場合は データ損失が発生する可能性があります Oracle Data Guard 11g 次世代のデータ保護と可用性 13

14 最大パフォーマンス モード 最大パフォーマンス モードはデフォルトの保護モードです 最大可用性モードに比べ データ保護レベルは若干低くなりますが プライマリ データベースのパフォーマンスが高くなる可能性があります このモードでは トランザクションはプライマリ データベースで処理され REDO データは ASYNC REDO 転送によって非同期的にスタンバイ データベースに送られます プライマリ データベースのログ ライターは クライアント アプリケーションへのコミットを確認する前にスタンバイからの確認応答を待ちません これによって プライマリ データベース応答時間のネットワークのラウンドトリップとスタンバイ ディスク I/O の潜在的なオーバーヘッドが排除されます いずれかのスタンバイ宛先が使用不能になった場合も 処理はプライマリ データベースで続行されるので パフォーマンスへの影響はほとんどあるいはまったくありません 通常処理中のデータ損失の危険性は プライマリとスタンバイ間で使用中のデータ ( プライマリ データベースによって生成される REDO データを処理するネットワークの処理能力の範囲 ) に制限されます 適切な帯域幅が提供される場合 全体のデータ損失の危険性はごくわずかかゼロになります 最大パフォーマンス モードは プライマリ データベースの可用性やパフォーマンスが 多少のデータを失うリスクよりも重要な場合に使用します 顧客のネットワーク固有の待機時間が 同期 REDO 転送の適合性を制限するような場合の Oracle Data Guard の配置にも適しています 自動ギャップ解消 - 通信障害の対応 Oracle Data Guard では プライマリ データベースからスタンバイ データベースへの接続が一時的に切断されるといったネットワーク接続問題にスムーズに対処できます 動作は 選択された Oracle Data Guard の保護モードのルールで決定されます 最後のスタンバイ データベースが使用できなくなる場合 最大可用性モードと最大パフォーマンス モードの両方でプライマリ データベースのトランザクション処理を続行できます スタンバイ データベースへの接続が回復すると 蓄積されたアーカイブ ログが自動的にスタンバイ データベースに送信および適用され プライマリ データベースとの再同期が素早く実行されます プライマリ データベースは ギャップ解消時にスタンバイ データベースのプライマリ データベースとの遅れを防止するため 再同期プロセスと並行して現在の REDO ストリームも送信します 再同期プロセスは スタンバイ データベースを再同期するために必要なアーカイブ ログがプライマリ データベースのディスクで使用できる限り 管理者の介入が必要ありません 適用サービス - REDO Apply と SQL Apply スタンバイ データベースは プライマリ データベースのバックアップ コピーから作成されます 作成されると Oracle Data Guard は プライマリ データベースの REDO データをスタンバイ システムに送信し スタンバイ データベースに適用することで Data Guard 構成内のプライマリ データベースとすべてのスタンバイ データベースを自動的に同期します Oracle Data Guard 11g 次世代のデータ保護と可用性 14

15 Oracle Data Guard には この REDO データをスタンバイ データベースに適用する 2 つの方法が用意されており サポートする 2 種類のスタンバイ データベースに対応しています REDO Apply は フィジカル スタンバイ データベースに使用されます SQL Apply は ロジカル スタンバイ データベースに使用されます プライマリ データベースからの REDO データ送信という点に関しては この 2 種類のスタンバイ データベースに違いはありません REDO データがスタンバイ サーバーに送信されると スタンバイ データベースに適用されるために使用される方法が異なります フィジカル スタンバイ データベース - REDO Apply NEW! REDO Apply パフォーマンスは Oracle Database 10g と比較してすべてのワークロード プロファイル用に大幅に拡張されました フィジカル スタンバイ データベースは Oracle メディア リカバリを使用して プライマリ データベースから受け取った REDO データを適用します ブロック単位で見た場合 スタンバイ データベースはプライマリ データベースと同一であり 索引を含むデータベース スキーマも同じになります REDO Apply の動作 Oracle Data Guard の REDO Apply では 管理リカバリ プロセス (MRP) と呼ばれる特殊なプロセスが使用されます リモート ファイル サーバー (RFS) プロセスが REDO データをスタンバイ REDO ログ (SRL) に書き込むので MRP は その REDO データを読み取ってフィジカル スタンバイ データベースに適用します MRP は データベースをマウントして 以下のコマンドを実行することで フィジカル スタンバイ データベース上で起動されます SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; また MRP が SRL の読取りを完了する前に SRL がアーカイブされた場合 MRP はアーカイブ済みのスタンバイ ログの読取りに透過的に切り替わります ( この状況は プライマリ データベースの REDO 生成率がきわめて高い場合に生じます ) MRP はパラレルで実行され Oracle Data Guard REDO Apply のベスト パフォーマンスを達成できます MRP は 起動時に最適な数のパラレル リカバリ プロセスを自動的に決定します REDO をスタンバイ データベースに適用する前のデータ検証 Oracle Data Guard の主な利点として スタンバイ データベースに適用する前に Oracle プロセスで REDO データを検証する機能があります Oracle Data Guard は REDO ブロックを適用してスタンバイ データベースが同期される疎結合アーキテクチャです このため プライマリ データベースで発生する可能性のあるデータファイルの破損から完全に切り離されます SYNC REDO 転送の場合 REDO はプライマリ SGA から送信されます このため プライマリの物理 I/O の破損から完全に切り離されます また スタンバイ データベースで実行されるソフトウェア コード パスは プライマリとは基本的に異なります このため プライマリ データベースに影響する可能性があるソフトウェア エラーからスタンバイ データベースが効率的に切り離されます Oracle Data Guard 11g 次世代のデータ保護と可用性 15

16 破損の検出チェックは 次の主要インタフェースで発生します REDO 転送中のプライマリ データベース :LGWR LNS ARCH REDO Apply 実行中のスタンバイ データベース :RFS ARCH MRP DBWR スタンバイ データベースで REDO Apply によって REDO の破損が検出されると Oracle Data Guard は 元のアーカイブ ログと破損を切り離すためにアーカイブ ログ ギャップ処理の一部として有効なログを再取得します NEW! Oracle Data Guard の REDO Apply は ストレージ ハードウェアとファームウェアの故障によって発生する書込みの損失も検出します スタンバイ データベースに影響を与えることなく 別のソースのデータ破損を防止します フィジカル スタンバイは 以下の新しいパラメータも利用します DB_LOST_WRITE_PROTECT. 永続ストレージで書込みが実際に発生しなかった場合でも I/O サブシステムで書込み終了を確認する際に書込み損失が発生します この I/O サブシステムは 続くブロックの読取りで 古いバージョンのデータ ブロックを返します このブロックは 他のブロックを更新し データベースを破損します DB_LOST_WRITE_ PROTECT 初期化パラメータが設定されると データベースはバッファ キャッシュ ブロック読取りを REDO ログに記録します この情報を使用して 書込み損失を検出できます Oracle Data Guard とともに使用すると 書込み損失の検出は最も効果的です この場合 プライマリ データベースとスタンバイ データベースに DB_LOST_WRITE_ PROTECT を設定します 管理リカバリ中にスタンバイ データベースで REDO を適用する場合 対応するブロックが読み取られ SCN と REDO ログの SCN が比較されます プライマリ データベースのブロック SCN がスタンバイ データベースのブロック SCN より小さい場合 プライマリ データベースの書込み損失が検出され 外部エラー (ORA-752) が返されます プライマリ データベースの書込み損失を修復する推奨手順は フィジカル スタンバイへのフェイルオーバーとプライマリの再作成です SCN が大きい場合 スタンバイ データベースの書込み損失が検出され 内部エラー (ORA ) が返されます スタンバイ データベースの書込み損失を修復するには スタンバイ データベースまたは影響するファイルを再作成する必要があります 両方の場合 スタンバイ データベースは アラート ログとトレース ファイルに障害の理由を書き込みます 全体として プライマリ データベースの破損はスタンバイ データベースの整合性に影響しないという Oracle Data Guard の基本原則に基づいて 上記の機能が提供されます NEW! リアルタイム問合せでは 問合せとレポートのために最新のフィジカル スタンバイ データベースへの読取り専用アクセスを有効にします REDO Apply とリアルタイム問合せ プライマリ データベースの最新のレプリカに対して問合せを実行できる REDO Apply がオン ( リカバリがアクティブ ) の場合 フィジカル スタンバイ データベースを読取り専用でオープンできます 以下の方法で実行できます Oracle Data Guard 11g 次世代のデータ保護と可用性 16

17 REDO Apply がアクティブの場合に読取り専用アクセスのスタンバイ データベースをオープンするには 以下の文を使用して 最初に REDO Apply をキャンセルします SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 次に 以下の文を使用して 読取り専用アクセスのデータベースをオープンします SQL> ALTER DATABASE OPEN; スタンバイ データベースをオープンした後 以下のコマンドを使用して REDO Apply を再起動します SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NEW! スナップショット スタンバイ データベースは 読取り / 書込みでオープンしてテストなどの目的で使用できます プライマリ データベースは REDO データをスナップショット スタンバイに常に送信し 離れた場所でデータを確実に保護します スナップショット スタンバイは 保管用にこの REDO をアーカイブします テスト アクティビティが終了した後 スナップショット スタンバイをスタンバイ データベースに変換し スナップショット スタンバイとして運用していたときにプライマリから受け取ったログ ファイルを適用して スナップショット スタンバイとプライマリを再同期します スナップショット スタンバイ スナップショット スタンバイ データベースは フィジカル スタンバイ データベースをスナップショット スタンバイ データベースに変換して作成される更新可能なスタンバイ データベースです スナップショット スタンバイ データベースは プライマリ データベースから REDO データを受信およびアーカイブしますが適用はしません プライマリ データベースから受け取った REDO データは スナップショット スタンバイ データベースへのすべてのローカル更新が破棄された後のスナップショット スタンバイ データベースからフィジカル スタンバイ データベースへの変換の際に適用されます Oracle Enterprise Manager Oracle Data Guard Broker コマンドライン インタフェース (DGMGRL) または SQL*Plus からスナップショット スタンバイを作成できます SQL*Plus からスナップショット スタンバイを作成するには フィジカル スタンバイ データベースの以下のコマンドを発行します SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY; スタンバイ データベースがスナップショット スタンバイに変換されると 暗黙的に保証付きリストア ポイントが作成され フラッシュバック データベースが有効になります スナップショット スタンバイを使用して実行を完了した後 以下のコマンドを発行して フィジカル スタンバイ データベースに変換してプライマリと再同期できます SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY DATABASE; Oracle Data Guard は 保証付きリストア ポイントにデータベースを暗黙的にフラッシュバックして スナップショットが作成されてからスタンバイによってアーカイブされたプライマリ データベースの REDO を自動的に適用します 保証されたリストア ポイントは このプロセスが終了すると削除されます ロジカル スタンバイ データベース - SQL Apply ロジカル スタンバイ データベースは プライマリ データベースとデータの物理編成と物理構造は異なりますが 同じ論理情報を持っています SQL Apply テクノロジは プライマリ データベースから受け取った REDO データを SQL 文に変換し それをスタンバイ データベースで実行することによって ロジカル スタンバイ データベースとプライマリ データベースとの同期を維持します フィジカル スタンバイと同様に 適用中でも問合せやレポートのためにロジカル スタンバイ データベースにアクセスできます Oracle Data Guard 11g 次世代のデータ保護と可用性 17

18 NEW! 追加された SQL Apply サポート : - XMLType データ型 (CLOB) - DDL のパラレル実行 - 透過的データ暗号化 (TDE) - DBMS_FGA( ファイングレイン監査 ) - DBMS_RLS( 仮想プライベート データベース ) - DBMS_SCHEDULER( スケジューラ ) ロジカル スタンバイ データベースは SQL 文で更新されるのでフィジカル スタンバイよりも柔軟性があります このため ロジカル スタンバイ データベースを読取り / 書込みモードでオープンにできます また スタンバイ データベースにのみ存在するローカル表の追加や読取り / 書込みアクセスの必要なレポートまたは総和の実行など データベースへの読取り / 書込みアクセスを必要とする他のタスクを実行できます これらのタスクは SQL Apply によって保守されている表に追加索引およびマテリアライズド ビューを作成することで最適化できます データベースが読取り / 書込みでオープンされますが SQL Apply はプライマリ データベースと同期するデータへの変更を許可しません ロジカル スタンバイ データベースは 複数のデータベース スキーマをホストでき ユーザーは プライマリ データベースから更新されていないスキーマで 表に通常のデータ操作を実行できます ロジカル スタンバイ データベースの場合 データ型 表のタイプ DDL オペレーションと DML オペレーションのタイプに制約があります サポートされていないデータ型やストレージ属性については ドキュメント [2] を参照してください SQL Apply の動作 NEW! LOB LONG または XML 型の列を含まずパーティション化されていない表への挿入および更新のワークロードに対する SQL Apply のパフォーマンスが向上しました パラレル DDL も並行して SQL Apply によって適用されます このため 適用パフォーマンスがさらに向上します SQL Apply では プライマリ データベースからロジカル スタンバイ データベースに変更を適用したタスクを実行するバックグラウンド プロセスのコレクションが使用されます 図 3 に 情報の流れと各プロセスが実行するロールを示します 図 3 - SQL Apply プロセス 以下に各プロセスの機能を説明します Reader プロセスでは スタンバイ REDO ログから送られてくる REDO レコードを読み取ります Oracle Data Guard 11g 次世代のデータ保護と可用性 18

19 Preparer プロセスでは ブロック変更を表変更つまり論理変更レコード (LCR) に変換します Builder プロセスでは 個々の LCR から完了したトランザクションをまとめます Analyzer プロセスでは 完了したトランザクションを検査し 異なるトランザクション間の依存関係を識別します Coordinator プロセス ( ロジカル スタンバイ プロセスまたは LSP とも呼ばれます ) では トランザクションを適用プロセスに割り当て トランザクション間の依存関係を監視し ロジカル スタンバイ データベースへの変更のコミットを許可します Applier プロセスでは 割り当てられたトランザクションの LCR をデータベースに適用し Coordinator からの指示でトランザクションをコミットします この SQL コマンドを入力すると これらの SQL Apply プロセスが開始されます SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; REDO Apply と同様に 破損の検出チェックは次の主要なインタフェースで発生します REDO 転送中のプライマリ データベース :LGWR LNS ARCH SQL Apply 実行中のスタンバイ データベース :RFS ARCH SQL LSP DBWR REDO Apply または SQL Apply のいずれかを選択する方法 2 つのアプローチには共通点が多くあります フィジカル スタンバイ データベースとロジカル スタンバイ データベースは 同じ REDO 転送とロール管理サービスを利用します 適用プロセスだけが異なります いずれかを使用して プライマリ データベースの問合せとレポートをオフロードできます いずれかを使用して ローリング データベース アップグレードを実行できます フィジカル スタンバイ ユーザーは 上記の一時ロジカル スタンバイを利用します スタンバイ データベースのインスタンス化プロセスの実行中に すべてのスタンバイ データベースがフィジカル スタンバイ データベースとして最初に作成されます フィジカル スタンバイ データベースをロジカル スタンバイ データベースに変換するには 追加の手順が必要です ユーザーは 以下の理由に基づいて フィジカル スタンバイおよびロジカル スタンバイのいずれかを選択します REDO Apply を利用する決定に影響する要素 非常に高いパフォーマンス要件 - フィジカル スタンバイで使用される REDO Apply プロセスは非常に効率的なので SQL Apply と比べて I/O と CPU の使用量が少なくなります REDO Apply プロセスの効率性は 同じサーバーに複数の本番データベースおよびスタンバイ データベースをホストする場合 (SQL Apply 使用時のリソースの消費が実用的ではない場合 ) に役立ちます 複数のスタンバイ データベースをホストするために共有リソースを配置してコストを削減したい企業にとって これは重要です 相対的な簡潔さ REDO Apply は より簡潔なソリューションを望むユーザー向けの簡単なプロセスです Oracle Data Guard 11g 次世代のデータ保護と可用性 19

20 フィジカル スタンバイは テストや開発などの目的でスナップショット スタンバイにできます プライマリ データベースの完全なレプリカであるフィジカル スタンバイを使用して バックアップ実行時のプライマリ ホストをオフロードできます フィジカル スタンバイには制限がありません 処理とパフォーマンスは データ型とトランザクション プロファイルに完全に透過的です REDO は REDO です 障害時リカバリ シナリオでは プライマリの正確で物理的なレプリカであるスタンバイ データベースを好むユーザーもいます SQL Apply を利用する決定に影響する要素 ロジカル スタンバイ データベースは 常に読取り / 書込みでオープンするので大きな柔軟性があります たとえば データベースへの読取り / 書込みアクセスが必要なレポート アプリケーションがあります フィジカル スタンバイ ユーザーは別のデータベースへのデータベース リンクでこの制限に対処できますが ロジカル スタンバイは 追加の手順なしで読取り / 書込みアクセスを有効にできます Oracle Data Guard によって保護されているロジカル スタンバイ表は プライマリ データベース以外の物理レイアウトに保存できるため 追加索引やマテリアライズド ビューを作成して 問合せパフォーマンスを向上させ 具体的なビジネス要件に適合できます ロジカル スタンバイ データベースは データ ウェアハウス アプリケーション 意思決定支援 データ マートの移入に使用されるデータのステージングと処理に使用できます Oracle Data Guard 構成で保護されるデータベース スキーマに加え ロジカル スタンバイはその他のデータベース スキーマをホストでき ユーザーはそうしたスキーマで いつでも DDL オペレーションや DML オペレーションを実行できます ロジカル スタンバイで開始されるローリング データベース アップグレードは アップグレードを実行するためにフィジカル スタンバイを一時ロジカル スタンバイに変換するローリング アップグレードよりも少ない手順で済みます Oracle Data Guard 構成の管理 NEW! 本番環境のデータに基づいて NET_ TIMEOUT の最適な値をユーザーに提供する応答時間のヒストグラム システム ビュー Oracle Data Guard は さまざまなビューを提供し Oracle Data Guard 構成のランタイム パフォーマンスを詳細に監視します これらのビューには SQL*Plus Oracle Data Guard Broker または Oracle Enterprise Manager Grid Control からアクセスできます たとえば V$REDO_DEST_RESP_HISTOGRAM は SYNC REDO 転送の宛先の応答時間のヒストグラムを含む固定ビューです このビューのデータは 同期の宛先に使用されるネットワーク タイムアウト属性の適切な値を決定する際に非常に役立ちます 最大可用性モードで使用される LOG_ARCHIVE_DEST_n NET_TIMEOUT 属性では 離れた宛先を放棄してログ ライターを続行する前に LNS の確認応答をログ ライターが待機する最長期間を指定します 非常に小さい値を設定すると 頻繁にタイムアウトが発生して データ保護レベルが低下する可能性があります Oracle Data Guard 11g 次世代のデータ保護と可用性 20

21 非常に大きい値を設定すると 離れた宛先を放棄する際にデータベースを停止することで プライマリ データベースのスループットに悪影響を与える場合があります このヒストグラムのデータによって HA とデータ保護の目標のトレードオフを最適化するために必要な情報が管理者に提供されます Oracle Data Guard Broker は Data Guard 構成の作成 メンテナンス 監視を自動化し一元化する 分散型管理フレームワークです すべての管理操作は Oracle Data Guard Broker を使用する Oracle Enterprise Manager Grid Control か Oracle Data Guard Broker の特殊コマンドライン インタフェース (DGMGRL) を介して実行できます 次のリストに Oracle Data Guard Broker によって自動化され簡略化される操作の例を示します Oracle Data Guard 構成を作成し有効化します Oracle Data Guard 構成にある任意のサイトからの Data Guard 構成全体を管理します Oracle Data Guard 構成の全システムで 複雑なロール変更を含むスイッチオーバーまたはフェイルオーバー ( ファスト スタート フェイルオーバーを含む ) を呼び出します 一元的監視およびイベント通知によって 適用率を監視し 診断情報を取得し 問題を迅速に検出します Oracle Enterprise Manager Data Guard の管理ページとウィザードによって Oracle Data Guard 構成の作成および管理がさらに簡素化されます Oracle Enterprise Manager は 監視する Oracle Data Guard メトリックに関する傾向分析の履歴 ( たとえば 過去 24 時間あるいは過去 5 日間のメトリック パフォーマンスの推移など ) を取得できます また Oracle Enterprise Manager を介して通知アラームの設定もできるため メトリックが設定されたしきい値に達した場合 管理者は通知を受けられます 図 4 のスクリーンショットは Oracle Enterprise Manager の Oracle Data Guard ホームページを示します Oracle Enterprise Manager の監視対象となる Oracle Data Guard のメトリックの例は以下のとおりです 推定フェイルオーバー時間 - このスタンバイ データベースへフェイルオーバーするために必要なおおよその秒数 適用ラグ - スタンバイ データベースがプライマリ データベースからどれくらい遅れているかが示されます REDO 適用率 - スタンバイで REDO が適用される率 REDO 生成率 - プライマリで REDO が生成される率 転送ラグ - このスタンバイ データベースでまだ使用できない REDO のおおよその秒数 これは REDO がまだ送信されていないか ギャップがあるためです Oracle Data Guard ステータス - Oracle Data Guard 構成にある各データベースのステータスが示されます Oracle Data Guard 11g 次世代のデータ保護と可用性 21

22 発生したファスト スタート フェイルオーバー - ファスト スタート フェイルオーバーが有効に設定されていて ファスト スタート フェイルオーバーが発生すると このメトリックによって新しいプライマリ データベース ( 旧スタンバイ データベース ) に重要なアラートが発信されます ファスト スタート フェイルオーバー時間 - ファスト スタート フェイルオーバーが有効に設定されていて ファスト スタート フェイルオーバーが発生すると このメトリックによって新しいプライマリ データベース ( 旧スタンバイ データベース ) に重要なアラートが発信され 発生のタイムスタンプが表示されます 図 4 - Oracle Enterprise Manager の Oracle Data Guard ホームページ ロール管理サービス Oracle Data Guard ロール管理サービスは 本番サイトの計画停止 ( スイッチオーバー ) と計画外停止 ( フェイルオーバー ) のために指定されたスタンバイ データベースを本番ロールに素早く移行します また ロール管理サービスによって 障害時リカバリ準備のテストが非常に簡単になります スイッチオーバー スイッチオーバーは オペレーティング システムやハードウェアのアップグレード Oracle データベース ソフトウェアおよびパッチセットのローリング アップグレードなどの計画停止で プライマリ データベースの停止時間を短縮するために使用します スイッチオーバーを実行するには プライマリ データベースからすべてのユーザー セッションを切断する必要があります その後 プライマリ データベースはスタンバイ ロールに移行し スタンバイ データベースがプライマリ ロールに移行します Oracle Data Guard 11g 次世代のデータ保護と可用性 22

23 スイッチオーバーは Oracle Enterprise Manager GUI インタフェースあるいは Oracle Data Guard Broker のコマンドライン インタフェースを使用するか SQL を直接介して 管理者が開始します たとえば 下記の Oracle Data Guard Broker CLI(DGMGRL) コマンドによって スタンバイ データベース "Chicago" へのスイッチオーバーを開始し 完了します DGMGRL> SWITCHOVER TO Chicago; スイッチオーバーが開始されると 実際のロール移行プロセスは自動的に実行されます プロセスの間にデータが失われることはありません フェイルオーバー フェイルオーバーは プライマリ データベースに計画外の障害が発生する場合 新しいプライマリ データベースとしてスタンバイ データベースの 1 つを稼働する操作です この機能では プライマリに影響するイベントが診断され解決される場合に停止時間を発生させないでスタンバイ データベースをプライマリ ロールに素早く切り替えて リカバリ時間目標を達成できます フェイルオーバー操作には スタンバイ データベースの再起動は必要ありません また 元のプライマリ データベースのデータベース ファイルが影響を受けない限り データベースを再起動できます また フラッシュバック データベースを使用して 新しいプライマリのスタンバイ データベースとして元のプライマリを回復および再同期できます バックアップからリストアする必要はありません 手動フェイルオーバーは プライマリ ロールのスタンバイ データベース上で Oracle Enterprise Manager GUI インタフェースあるいは Oracle Data Guard Broker のコマンドライン インタフェースを使用するか SQL*Plus を直接介して 管理者が開始します たとえば 下記の Oracle Data Guard Broker CLI(DGMGRL) コマンドによって スタンバイ データベース "Chicago" へのフェイルオーバーを開始し 完了できます DGMGRL> FAILOVER TO Chicago; Oracle Data Guard が最大保護モードまたは最大可用性モードで動作していて フェイルオーバーの時点でターゲット スタンバイ データベースが同期化されている場合 手動フェイルオーバーによって データ損失ゼロが保証されます 最大パフォーマンス モードでは フェイルオーバーの時点で まだスタンバイに送られず プライマリ データベースに残っている REDO データがあった場合 そのデータは消失する場合があります 手動フェイルオーバー以外に 顧客は 非常に管理された方法で自動フェイルオーバーを実行する Oracle Data Guard 構成オプションを使用できます 詳細は 以下のセクションで説明しています ファスト スタート フェイルオーバー NEW! ファスト スタート フェイルオーバー ( 自動フェイルオーバー ) は ユーザー設定可能なデータ損失しきい値を使用して 最大パフォーマンス モード ( ASYNC REDO 転送 ) の Oracle Data Guard 構成もサポートします ファスト スタート フェイルオーバーによって Oracle Data Guard は フェイルオーバーを呼び出す手動の手順を実行することなく あらかじめ選択したスタンバイ データベースに自動的にフェイルオーバーできます プライマリ データベースが障害から回復した場合 新しいプライマリ データベースのスタンバイとして自動的に構成に復帰します ファスト スタート フェイルオーバーは Oracle Data Guard Broker 構成でのみ使用でき DGMGRL または Oracle Enterprise Manager からのみ構成できます Oracle Data Guard 11g 次世代のデータ保護と可用性 23

24 ファスト スタート フェイルオーバー構成は 別のオブザーバ プロセスによって監視されます このオブザーバ プロセスは DGMGRL クライアント側コンポーネントに統合された軽量プロセスです ファスト スタート フェイルオーバー環境を継続的に監視し プライマリ データベースが使用可能であることを確認します オブザーバおよびスタンバイ データベースの両方がプライマリ データベースとの接続を失うと オブザーバはファスト スタート フェイルオーバーを開始する前に 設定可能な時間の範囲でプライマリ データベースとの再接続を試みます ファスト スタート フェイルオーバーは プライマリ データベース スタンバイ データベース オブザーバという 3 つの構成メンバー中少なくとも 2 つが主要な状態移行に同意する場合に実行されるよう設計されており 異なる 2 つのプライマリ データベースが本番ワークロードを処理するスプリット ブレイン シナリオのような状況を回避します シンプルで洗練されたアーキテクチャによって ファスト スタート フェイルオーバーは データ保護が重要な意味を持つ 高可用性状況で使用される有力な候補となります Oracle Enterprise Manager を使用する利点は Oracle Data Guard ファスト スタート フェイルオーバー構成のオブザーバの高可用性も実現できることです Oracle Enterprise Manager を使用して オブザーバのステータスの監視 オブザーバ障害の検出 および元のホストでのオブザーバの再起動を行うことができます 失敗した場合 事前に指定した 2 番目のホストのオブザーバが再起動されます オブザーバの高可用性を保証する Oracle Enterprise Manager の機能は Oracle Data Guard ファスト スタート フェイルオーバーを使用する HA 戦略の重要な要素です 柔軟性に優れた構成オプション 管理者は 最大可用性モードによってデータ損失がない場合または最大パフォーマンス モードによってデータ損失量が事前に構成したしきい値を超えない場合に自動フェイルオーバーを制限できます ファスト スタート フェイルオーバーの動作を制御するプロパティは 以下のとおりです FastStartFailoverThreshold - フェイルオーバーの開始前にオブザーバとターゲット スタンバイ データベースが待機する秒数 ( プライマリ データベースが使用できなくなったことが確認された後 ) を指定します FastStartFailoverLagLimit - 自動フェイルオーバーで許可されるデータ損失量に対する時間ベースの制限を指定するプロパティです スタンバイ データベースで適用された REDO ポイントがプライマリの REDO 生成ポイントのこの値の範囲内の場合 ファスト スタート フェイルオーバーは許可されます 適用されたポイントがこの制限よりも遅い場合 ファスト スタート フェイルオーバーは許可されません このプロパティは 最大パフォーマンス モードにのみ適用可能です 最大可用性モードの構成でファスト スタート フェイルオーバーが有効な場合には使用されません FastStartFailoverAutoReinstate - 古いプライマリの診断および修復を行う場合 このプロパティを FALSE に設定して フェイルオーバー発生後の障害が発生したプライマリの自動回復を防止できます Oracle Data Guard 11g 次世代のデータ保護と可用性 24

25 また Oracle Enterprise ManagerまたはDGMGRL ENABLE FAST_START FAILOVER NEW! ファスト スタート フェイルオー CONDITIONコマンドを使用して フェイルオーバーしきい値の期限まで待たずにバーは オブザーバで検出されるとファスト スタート フェイルオーバーのしファスト スタート フェイルオーバーを発生させる条件を指定できます これきい値の期限まで待たずにフェイルオーには 次の機能が含まれます バーを発生させるユーザー設定可能なイベントを提供します "Datafile Offline" 書込みエラーによるデータファイル オフライン "Corrupted Controlfile" 破損した制御ファイル "Corrupted Dictionary" 重要なデータベース オブジェクトのディクショナリの破損 "Inaccessible Logfile" I/O エラーが原因でログ ライターによるログ グループのメンバーへの書込みができない "Stuck Archiver" デバイスがいっぱいである または使用できないため アーカイバによる REDO ログのアーカイブができない DBMS_DG PL/SQL パッケージを使用して 特定の条件が発生する場合にアプリケーションでファスト スタート フェイルオーバーをリクエストできます アプリケーションに一意な条件が検出される場合 DBMS_DG.INITIATE_FS_FAILOVER プロシージャを呼び出して ファスト スタート フェイルオーバーの即時発生の要求をプライマリ データベースに通知できます プライマリ データベースはオブザーバにこの要求を通知します オブザーバはファスト スタート フェイルオーバーをすぐに開始します スタンバイがフェイルオーバーを許可する有効なファスト スタート フェイルオーバー状態 ( 確認されており 同期または遅延範囲内の状態 ) であることが前提です 新しいスタンバイ データベースとしての旧プライマリ データベースのリストア フェイルオーバーの後 古いプライマリ データベースを新しいスタンバイ データベースとして回復し 構成のデータ保護機能を再開することが必要です 古いプライマリを再起動してデータベースをデータファイルにマウントできる場合 フラッシュバック データベースを使用して 新しいプライマリのバックアップから再作成しないで 新しいプライマリのスタンバイ データベースとして古いプライマリを回復できます ( フラッシュバック データベースは 障害イベントが発生する前に有効にする必要があります ) 前述したように ファスト スタート フェイルオーバーを使用する場合 この回復は自動で行われます 手動フェイルオーバーの場合 実際の操作は 古いプライマリ データベースを (V$DATABASE ビューの STANDBY_BECAME_PRIMARY_SCN 列に記録された ) フェイルオーバーが実行された時点までフラッシュバックし スタンバイ データベースとして起動し さらに Oracle Data Guard によって この新しいスタンバイ データベースを新しいプライマリ データベースと同期させます DGMGRL を使用してこの処理を簡単に実行するには 古いプライマリ データベースを再起動して 以下のコマンドを発行してください DGMGRL> REINSTATE DATABASE 'database'; Oracle Data Guard 11g 次世代のデータ保護と可用性 25

26 自動クライアント フェイルオーバー フェイルオーバーは 以下のカテゴリに分類できます サイト全体のフェイルオーバーは Oracle Data Guard スタンバイ データベースと中間層アプリケーション サーバーの完全な冗長セットを受け入れるセカンダリ サイトを利用します セカンダリ サイトにフェイルオーバーする際 中間層のサーバーが起動し ネットワークのロード バランサが新しいプライマリ サイトにリダイレクトされます Oracle Data Guard フェイルオーバーは セカンダリのスタンバイ データベースをプライマリ ロールに移行します Oracle MAA ペーパー Oracle 高可用性アーキテクチャおよびベスト プラクティス [5] は サイト全体のフェイルオーバーを実装するガイダンスを提供します Oracle RAC 内のノードで障害が発生した場合 障害が発生したノードに接続しているクライアントは 障害が発生した通知を素早く受け取り クラスタの残りのノードに再接続して処理を続行する必要があります テクニカル ホワイト ペーパー Oracle Real Application Clusters によるワークロード管理 [6] は Oracle RAC 内のノード障害に対処するためのガイダンスを提供します 部分的なサイトのフェイルオーバーは プライマリ サイトには影響しませんが プライマリ データベースが使用できなくなると発生します 影響を受けるクライアントは Oracle Data Guard フェイルオーバーの後にセカンダリの新しいプライマリ データベースにリダイレクトする必要があります 部分的なサイトの障害に対してクライアント フェイルオーバーを実装する概要は 以下に記載されています 詳細については 高可用性 Oracle Database でのクライアント フェイルオーバーのベスト プラクティス [7] を参照してください Oracle Data Guard 構成のクライアント フェイルオーバーの自動化には 高い水準で Oracle Data Guard フェイルオーバーの一部としての新しいプライマリ データベースへのデータベース サービスの再配置 TCP タイムアウトから切り離される障害発生のクライアントへの通知 新しいプライマリ データベースへのクライアントのリダイレクトが含まれます サービスの再配置 Oracle Database 10g では Oracle RAC データベースとデータベース サービス [8] と呼ばれる単一インスタンス (RAC ではない ) データベースの自動ワークロード管理機能が導入されました この機能によって データベース ワークロードをグループ化し そのワークロードにサービスを提供するコンピューティング リソースを簡単に指定できます 以下の例で使用される "sales" など 特定の事例のデータベース サービスを定義できます また サービスを提供するプライマリ データベースで障害が発生すると Oracle Data Guard フェイルオーバーの一部として新しいプライマリ データベースにサービスを自動的に再配置できます Oracle RAC クラスタ内で ユーザーは サービスを提供するインスタンスとは無関係に サービスにアクセスできます 接続リクエストを受信した際に クラスタ内のすべてのリスナーはリスナー登録を使用し どのインスタンスが現在データベース サービスを提供しているのかを認識するためです サービスを提供するインスタンスで障害が発生すると Oracle RAC は クラスタ内の残りのインスタンスにサービスを素早く再配置します サービスの再配置の概念は Oracle Data Guard 構成に適用されます この発生手順を示すには 単一ノードのプライマリ データベースとスタンバイ データベース およびすべての適切な高可用性設定で作成され構成された "sales" というデータベース サービスの簡単な Oracle Data Guard 構成を前提とします [7] クラ Oracle Data Guard 11g 次世代のデータ保護と可用性 26

27 イアント アプリケーションは 構成内の全ホスト ( プライマリおよびスタンバイ ) を含む Oracle Net の別名を使用してサービス "sales" に接続します その Oracle Net の別名で使用されるサービス名がプライマリ データベースのインスタンス上でのみ実行されるので スタンバイ データベースへの不必要な接続試行が防止されます 新しいプライマリへのサービスの再配置は Oracle Data Guard のロール変更でスタンバイ データベースをプライマリ ロールに移行する際のトリガーの使用によって自動化されます これによって 新しいプライマリ データベースのサービスが開始されます 例 : CREATE OR REPLACE TRIGGER manage_service AFTER STARTUP ON database DECLARE role VARCHAR(30); BEGIN SELECT DATABASE_ROLE INTO role FROM V$DATABASE; IF role = 'PRIMARY' THEN DBMS_SERVICE.START_SERVICE('sales'); ELSE DBMS_SERVICE.STOP_SERVICE('sales'); END IF; END; クライアント通知および再接続 上記の例に続くクライアント通知および再接続は 障害発生時に元のプライマリに接続しているクライアントが長い TCP タイムアウトの期限までハング状態で待機することを防止します Oracle は TCP タイムアウトから切り離される障害発生をこれらのクライアントに通知し 残りの RAC ノード ( または Oracle Data Guard フェイルオーバー後の新しいプライマリ データベース ) への新規接続および既存接続を実行します OCI クライアントで実現するには 高速アプリケーション通知機能 (FAN) を使用します 新しいプライマリは 障害が発生したインスタンスに接続しているクライアントを把握します フェイルオーバー プロセスの一部として 上記の例で使用されるサービス "sales" への再接続が通知されます 高速接続フェイルオーバーと スタンバイ データベースがプライマリ ロールに移行する際の DB_ROLE_CHANGE システム イベント [7] で起動したスタンバイ データベースで作成されたトリガーによって Oracle Data Guard 構成の JDBC クライアントに通知されます このトリガーは Oracle が提供するパブリッシャ プログラム [7] を呼び出します このプログラムは データベース サービスが新しいプライマリで使用できることを JDBC クライアントに通知し TCP タイムアウトから停止したクライアントを切り離します 最終的なタスクは 障害がクライアントに通知された後に障害が発生したホストに再接続する場合に TCP タイムアウトの影響を受けないという保証です これを実現するには 1 番目のホストが使用できなかった場合にアドレス リストの次のホストにクライアントが素早く接続するために SQLNET 接続タイムアウトを使用します [7] データベース サービスの再配置と JDBC クライアントの HA イベントの公開に使用されるトリガーの例を含む OCI OLE DB JDBC クライアントの構成の詳細 Oracle Data Guard 11g 次世代のデータ保護と可用性 27

28 は MAA ペーパー 高可用性 Oracle Database でのクライアント フェイルオーバーのベスト プラクティス に記載されています [7] ロール移行イベント 1 つのロールから別のロールへデータベースが移行するたびに Oracle Data Guard DB_ROLE_CHANGE システム イベントが起動します これは ロールの変更後に起動する点を除けば ON STARTUP システム イベントに酷似しています ロール変更後のタスクを管理する方法として 管理者はこのイベントが発生した場合に実行されるトリガーを作成できます このイベントは 新しいロールとは無関係に ロールの移行後初めてデータベースがオープンになったときに起動します DB_ROLE_CHANGE システム イベントをロール変更後のタスクの管理と自動化に使用できます このシステム イベントは 自動クライアント フェイルオーバーを簡素化するための 1 つの手段です 一般的なタスクには 新しい本番データベースでのサービス開始 名前解決サービスの変更 または接続記述子の変更が含まれるため クライアントは新しい本番データベースに再接続し サード パーティのアプリケーションの起動や一時表領域の追加などを行います DB_ROLE_CHANGE は 柔軟なメカニズムであるため 管理者はデータベース トリガーを使用して 実行できる任意のアクションを自動化できます ローリング データベース アップグレード NEW! フィジカル スタンバイ ユーザーは ロジカル スタンバイ データベースの追加ディスクを必要とすることなく SQL Apply ローリング アップグレードを実行できます フィジカルをロジカルに変換して ローリング アップグレードを実行します 次に KEEP IDENTITY 句を使用して フィジカル スタンバイ データベースにロジカルを戻します 主要リリースやパッチセット アップグレード ( 以降 ) の Oracle Database ソフトウェア アップグレードは Oracle Data Guard SQL Apply を使用した データベース停止時間のほとんどないローリング方式で実行できます ( 図 5 参照 ) 図 5 -SQL Apply によるローリング データベース アップグレード Oracle Data Guard 11g 次世代のデータ保護と可用性 28

29 ローリング アップグレード プロセスには ロジカル スタンバイ データベースの新リリースへのアップグレード 混合モードでのアップグレードのテストと検証 アップグレード済みデータベースへのスイッチオーバーによるロール切替え 旧プライマリ データベースのアップグレードという手順が含まれます テストのために混合モードで作動している間 データを消失することなくアップグレードを中止し ソフトウェアをダウングレードできます 上記の手順中 さらにデータ保護を強化するには 第 2 のスタンバイ データベースを使用する方法があります Oracle Database 11g から フィジカル スタンバイ データベースは ロジカル スタンバイによって提供されるローリング アップグレード機能も使用できます SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY 文の新しい KEEP IDENTITY 句オプションを使用して フィジカル スタンバイ データベースをローリング アップグレード用に一時的にロジカル スタンバイ データベースに変換できます アップグレードの終了後に元の構成 ( プライマリ データベースとフィジカル スタンバイ データベース ) に戻すことができます カスケードした宛先 Oracle Data Guard には柔軟性に優れた多くの構成オプションが用意されています カスケードした宛先を使用して フィジカル スタンバイ データベースは 受け取る REDO をプライマリ データベースから別のスタンバイ データベースに転送できます プライマリ データベースは 最初のスタンバイ データベースに REDO データを送るため この機能はプライマリ システムの負荷を軽減し 複数のスタンバイ データベースが必要な場合にプライマリ サイトでの貴重なネットワーク リソースの使用やネットワーク トラフィックを少なくします Oracle RAC と Oracle Data Guard Broker は カスケードした宛先を含む Data Guard 構成でサポートされていません Oracle Data Guard および Oracle Real Application Clusters "Oracle に精通しているので Oracle Data Guard を選択しました 私たちには Oracle の専門知識があります 私たちは 既存のストレージ システムに新しいグレードのストレージまたは新規コンポーネントを購入する必要がありませんでした また サード パーティのレプリケーション ソリューションでトレーニングする必要もありませんでした Oracle Data Guard を使用して 高水準のデータ保護と可用性を実現しています " - Burlington Coat Factory Senior Database Administrator Mike Balint 氏 Oracle Data Guard と Oracle RAC は 最高水準のスケーラビリティ 可用性 およびデータ保護を提供する補完するテクノロジです 上記のカスケードした宛先の使用に適用される制限を除いて Oracle RAC と Oracle Data Guard 間の統合はシームレスです Oracle RAC と単一ノード データベースの組み合わせによって Oracle Data Guard 構成のロールに参加できます Oracle RAC は 業界で一意なワークロード管理とスケーラビリティの機能を提供するとともにサーバー障害から保護する理想的な HA ソリューションです Oracle Data Guard は ストレージ アレイ障害 オペレータ エラー ローリング方式で実行できない Oracle RAC ノード全体の特定の計画メンテナンス またはサイト障害を引き起こす可能性のある複数の相関障害による停止時間を最小限に抑える完全な冗長性とともに追加レベルのデータの可用性と保護を提供します Oracle Maximum Availability Architecture Oracle Maximum Availability Architecture(MAA) [9] は オラクルの高可用性テクノロジを配置するテスト済みおよび顧客検証済みのベスト プラクティスの青写真です MAA の目標は 最適な高可用性アーキテクチャの設計から複雑さを排除することです Oracle Data Guard 11g 次世代のデータ保護と可用性 29

30 Oracle Data Guard は MAA の重要コンポーネントであり MAA ベスト プラクティスには Oracle RAC と Oracle Data Guard の両方を含む構成や REDO 転送メカニズム スイッチオーバーとフェイルオーバー メディア リカバリ SQL Apply 構成 ネットワーク構成などのさまざまな Oracle Data Guard 構成に関する推奨事項が含まれます Oracle Data Guard の実装に関しては この MAA ベスト プラクティス ガイドラインの参照を強く推奨します Oracle Data Guard とリモート ミラー化ソリューション " 私たちは EMC Symmetrix を利用して 帯域幅を取得しています このため SRDF などのソリューションを使用できますが この重要なデータベース システムでは Oracle Data Guard を使用しています 使用の主な理由は データの一貫性と整合性です " - BarnesandNoble.com Chief Technology Officer David Willen 氏 リモート ミラー化ソリューションは 一般的にシンプルで完全なデータ保護を実現する手段として認識されています リモート ミラー化ソリューションには (a) ホスト ベース レプリケーションと (b) ストレージ アレイ ベースのミラー化の 2 種類があります ホスト ベース レプリケーションのソリューションでは プライマリ サーバーの特殊ファイル システム ドライバやボリューム マネージャ コンポーネントが ローカルの書込みを阻止し 論理メッセージにパッケージ化し IP を通じてリモート ( セカンダリ ) ホストへ同期または非同期で送信します このようなソリューションでは 書込み順序を追跡するための特殊なログを保守する必要があります セカンダリ サーバーのデータ ボリュームは レプリケーションの実行中では 読取り専用アクセスであっても使用できません ストレージ アレイ ベースのミラー化ソリューションでは プライマリ サイトのストレージ アレイ コントローラが 変更されたディスク I/O ブロックを セカンダリ サイトの類似のストレージ アレイにミラー化します こうした変更は ESCON FICON Fibre Channel などのプロトコルを使用して送信されます 最近のバージョンでは iscsi や IP ベース送信もサポートされています 適切な通信リンクによるミラー化は 適切なファームウェアがロードされている特殊なリンク アダプタによって管理されています I/O がプライマリ サーバーで発生すると データはソース アレイのキャッシュに書き込まれ キューに配置されます リンク アダプタがキューの最初のエントリを受け取り リンクを介してミラー化されたアレイにそのエントリを移動させます Oracle Data Guard の方がリモート ミラー化ソリューションよりも本質的に効率がよく 費用もそれほどかからないので Oracle データベースの保護に適しています Oracle データベースを保護するために リモート ミラー化ソリューションを購入したり Oracle Data Guard と統合したりする必要はありません Oracle Data Guard の追加された重要な利点として スタンバイ ロールで実行中にスタンバイ データベースを本番目的で利用できる機能があります さらに詳細な分析については [10] を参照してください Oracle Data Guard の顧客 Oracle Data Guard の機能は Oracle Database Version 7 で始めて利用可能になり 引き続き新機能が追加されています 後続の Oracle リリースでさらに充実したテクノロジとなっています また 世界中の顧客のミッション クリティカルなアプリケーションに使用されています 多くの詳細な実装の事例は OTN で入手できます [11] Oracle Data Guard 11g 次世代のデータ保護と可用性 30

31 結論 "3,000 マイルに及ぶ Oracle Data Guard の大西洋を横断した配置によって 複数の大陸の 27 カ国で活動する専門製薬および生物製剤企業として 管轄されている多くの規制機関から要求されるレベルの信頼性とデータ保護が提供されます " - Global R&D Business Systems, Support and Delivery Associate Director Kevin Bradley 氏 Oracle Data Guard 11g は 他に例のないデータ保護とともに統合された HA/DR ソリューションを提供して 従来の障害時リカバリ パラダイムを根本的に変更します スタンバイ システムは スタンバイ ロールで実行中に本番機能を同時にサポートします Oracle Data Guard は 企業にデータ保護 障害時リカバリ および高可用性を提供する包括的ソリューションです 計画停止と計画外停止の両方に対処する 柔軟性に優れた管理しやすいフレームワークを提供します フィジカル スタンバイ データベースとロジカル スタンバイ データベースは プライマリ データベースのオーバーヘッドを軽減する一方で 価値の高いデータ保護機能を提供します 各種データ保護モードによって 保護 パフォーマンス インフラストラクチャに関するさまざまな要件に適合した柔軟性を備えています Oracle Data Guard Broker と Oracle Enterprise Manager を組み合わせることで 構成と管理のための使いやすいフレームワークが提供されます クラスタ ディスク ミラー化 さまざまなバックアップとリカバリ戦略を使用して IT インフラストラクチャに以前に組み込まれた高可用性の度合いに関係なく 使用中の IT アーキテクチャに Oracle Data Guard を追加することでデータ保護 可用性 および IT 投資収益率が強化されます Oracle Data Guard 11g 次世代のデータ保護と可用性 31

32 参考資料 1. Oracle Data Guard ( 英語 ) 2. Oracle Data Guard 概要および管理 m 3. Overview:Oracle Database High Availability( 英語 ) 4. Oracle Database 10g における Oracle Data Guard での Recovery Manager の使用 5. Oracle 高可用性ベスト プラクティス m 6. Oracle Real Application Clusters によるワークロード管理 ( サービス FAN 高速接続フェイルオーバーの実装の詳細な説明を提供します )( 英語 ) 7. 高可用性 Oracle Database でのクライアント フェイルオーバーのベスト プラクティス :Oracle Database 10g Release 2 BestPractices.pdf 8. Database サービス Oracle Maximum Availability Architecture 障害時リカバリの正しい選択 :Oracle Data Guard ストレッチ クラスタ またはリモート ミラー化 Oracle High Availability Case Studies( 英語 ) Oracle Data Guard 11g 次世代のデータ保護と可用性 32

33 Oracle Data Guard 11g 次世代のデータ保護と可用性 2007 年 5 月著者 : Ashish Ray Larry Carpenter Joseph Meeks テクニカル レビュー : Serge De La Sablonniere Mike Dietrich Holger Kalinowski Michael Rhys Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. 海外からのお問合せ窓口 : 電話 : ファクシミリ : Copyright 2007, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は一切間違いがないことを保証するものではなく さらに 口述による明示または法律による黙示を問わず 特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み いかなる他の保証や条件も提供するものではありません オラクル社は本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle JD Edwards PeopleSoft および Siebel は 米国 Oracle Corporation およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です