Oracle Database 10g の Oracle Data Guard
企業のための障害時リカバリ
オラクル・ホワイト・ペーパー
企業のための Oracle Data Guard 障害時リカバリ
概要 ... 3
障害の影響 ... 3
高可用性の課題... 3
Oracle Data Guard ... 4
Oracle Data Guard の概要 ... 4
Oracle Data Guard とは ... 4
Oracle Data Guard の機能... 5
Oracle Data Guard の効果... 6
Oracle Data Guard プロセス・アーキテクチャ ... 7
主要なテクノロジ・コンポーネント... 8
Data Guard の構成 ... 8
REDO Apply と SQL Apply... 8
フィジカル・スタンバイ・データベース
− REDO Apply... 9
ロジカル・スタンバイ・データベース
− SQL Apply... 11
Real Time Apply ... 13
データ保護モード... 14
最大保護 ... 14
最大可用性 ... 14
最大パフォーマンス ... 15
フェイルオーバーとスイッチオーバー... 15
自動再同期化... 17
人的エラーからの保護... 17
ローリング・アップグレード... 18
REDO ログ宛先のカスケード ... 18
Enterprise Manager と Data Guard Broker... 18
構成オプション ... 19
Oracle Data Guard および RAC ... 20
最大可用性アーキテクチャ ... 20
Data Guard とリモート・ミラー化ソリューション ... 21
結論 ... 23
企業のための Oracle Data Guard 障害時リカバリ
概要
多くのグローバル企業の経営陣にとって、最優先課題は事業継続性と障害時リカ バリです。グローバル企業は、経済的変動、市場動向の急速な変化、競争圧力に 365 日 24 時間の体制が必要です。また、不測の事業中断にも効率的な対処が必要 となります。Oracle Data Guard は、企業のコア資産であるデータの保護に、今日入手可能で最 も効率的なソリューションです。障害や事故に直面した場合でも、365 日 24 時間 体制でデータを利用できます。このホワイト・ペーパーは、Oracle Database 10g の Oracle Data Guard のテクノロジについて説明し、それが企業の事業継続維持の ためのインフラストラクチャにおいて最も重要な要素の 1 つであることを示しま す。
障害の影響
E-Business の急成長により、今日の企業は、非常に複雑で高度にネットワーク化 された世界経済の中で活動しており、以前と比べて中断の影響を格段に受けやす くなっています。業界によって異なりますが、そのような中断および停止時間の コストは、1 時間で数百万ドルに達することもあります。この数値は驚異的です が、その理由は明白です。インターネットは、数百万の顧客を直接電子店舗で扱 います。顧客関係、競争上の優位性、業界の評判、法的義務、株主の信任などの 重要で相互依存性の高い事業課題は、業務の中断と停止時間に対する脆弱性が増 加している現在、ますます重要度を高めています。高可用性の課題
事業に影響する停止時間には、計画外停止と計画停止があります。計画外停止は、 ハードウェアやシステムの故障、データ/ストレージの障害、人的エラー、コンピ ュータ・ウィルス、ソフトウェアの欠陥、自然障害、犯罪などが原因です。事業 は、システム・アップグレードのようにスケジュールされたメンテナンスの計画 的停止にも対応が必要です。 事業継続性戦略を意図する企業は、このような課題に効率的に対処できる事業継 続性計画（BCP: Business Continuity Plan）の作成が必要です。そのような BCP の 重要要件の 1 つに、企業データの保護があります。給与/従業員情報、顧客レコー ド、価値の高い研究、財務レコード、履歴情報などのデータは、最も重要な企業 資産の 1 つであるためです。企業がデータを失い、簡単に置き換えができない場Oracle Data Guard
Oracle Data Guard は、企業におけるきわめて重要な事業継続性のニーズに対処す る設計がされています。Oracle Data Guard は、データ保護機能と障害時リカバリ （DR: Disaster Recovery）機能の広範なセットを提供し、Oracle データベースに悪 影響のある障害、人的エラー、破損などから企業が生き残れるように支援します。 このホワイト・ペーパーでは、Oracle Database 10g の Oracle Data Guard の構造およ びテクノロジの概要を説明します。Data Guard の詳細は、Oracle Data Guard ドキュ メントを参照してください（参照[1]）。
Oracle Data Guard の概要
Oracle Data Guard とは
Oracle Data Guard は、管理、監視、自動化のソフトウェア・インフラストラクチ ャで、故障、障害、エラー、破損などから企業データを保護するため、1 つ以上 のスタンバイ・データベースを作成し、保守および監視します。 Data Guard では、これらのスタンバイ・データベースは、本番データベースのト ランザクション一貫性コピーとして保守されます。これらのスタンバイ・データ ベースは、本番データ・センターから数千マイルも離れた障害時リカバリ・サイ ト、または同じ都市、キャンパスまたはビルに配置できます。計画停止または計 画外停止が原因で本番データベースが使用できない場合、Data Guard により、ス タンバイ・データベースを本番ロールに切り替え、その停止に起因する停止時間 を最小限に抑えてデータ消失を防止できます。
Oracle Database 10gEnterprise Edition の機能として Data Guard は、Real Application Clusters（RAC）や Recovery Manager（RMAN）など、他の Oracle High Availability （HA）ソリューションと組合せることにより、これまでにないハイレベルなデー
タ保護とデータ可用性を提供します。
次の図に、Oracle Data Guard の概要を示します。
Oracle Data Guard の機能
Oracle Data Guard は、本番データベース（プライマリ・データベースとも呼ばれ ます）とプライマリ・データベースのトランザクション一貫性コピーである 1 つ 以上のスタンバイ・データベースで構成されます。Data Guard は、REDO ログを 使用してこのトランザクション一貫性を保守します。トランザクションがプライ マリ・データベースで発生すると REDO データが生成され、ローカル REDO ログ・ ファイルに書き込まれます。Data Guard は、この REDO データもスタンバイ・サ イトに送信し、スタンバイ・データベースに適用してプライマリ・データベース と常に同期させます。Data Guard により管理者は、この REDO データをスタンバ イ・サイトに同期式か、または非同期式で送信するかを選択できます。
スタンバイ・データベースの基盤となるテクノロジは、Data Guard REDO Apply（フ ィジカル・スタンバイ・データベースおよび Data Guard SQL Apply（ロジカル・
スタンバイ・データベース）です。フィジカル・スタンバイ・データベースは、 ブロック単位でプライマリ・データベースと同一なオンディスク・データベース 構造で、Oracle メディア・リカバリで更新されます。ロジカル・スタンバイ・デ ータベースは、プライマリ・データベースと同じデータを持つ独立したデータベ ースです。これは SQL 文により更新されるため、リカバリだけでなく、レポート 作成、問合せなど他のタスクのためにも同時に使用できる相対的な利点がありま す。 Data Guard により、プライマリ・データベースとスタンバイ・データベースの簡 単なスイッチオーバーとフェイルオーバーができるようになり、計画停止および 計画外停止時の全体的停止時間を最小限に抑えることができます。 プライマリ・データベースおよびスタンバイ・データベース、また各種の相互作 用を、SQL*Plus で管理できます。管理性を容易にするため、Data Guard には Data Guard Broker と呼ばれる分散管理フレームワークが実装されています。この Data Guard Broker は、Data Guard 構成の作成、メンテナンス、監視を自動化および一元 化します。管理者は、Oracle Enterprise Manager か Broker の独自の特殊なコマンド ライン・インタフェース（DGMGRL）のいずれかを使用して、Broker の管理機能 を活用できます。
次の図に、Oracle Data Guard のコンポーネントを示します。
図 2: Oracle Data Guard のアーキテクチャ・コンポーネント
Oracle Data Guard の効果
Oracle Data Guard には、次の効果があります。
• 障害時リカバリと高可用性 − Data Guardは、効率的で包括的な障害時リカバ リおよび高可用性ソリューションを提供します。管理しやすいスイッチオー バー機能とフェイルオーバー機能により、プライマリ・データベースとスタ ンバイ・データベースのロールを反転し、計画停止および計画外停止時のプ ライマリ・データベースの停止時間を最小限にします。 • 完全なデータ保護 − スタンバイ・データベースにより、Data Guardは、不測 の障害に直面した場合でもデータ消失が発生しないことを保証します。スタ ンバイ・データベースは、データ破損やユーザー・エラーに対する防衛手段 を提供します。プライマリ・データベースでのストレージ・レベルの物理的 破損は、スタンバイ・データベースに伝播されません。同様に、プライマリ・ データベースに恒久的損害を与える論理的破損やユーザー・エラーを解決で きます。また、REDOデータは、スタンバイ・データベースに適用される時点 で妥当性チェックが行われます。 • システム・リソースの効率的利用 − プライマリ・データベースから受信した REDOデータにより更新されるスタンバイ・データベース表を、バックアップ 操作、レポート作成、要約、問合せなど、他のタスクに使用できるため、こ のようなタスクにかかわるプライマリ・データベースの負荷を軽減し、貴重 なCPUサイクルやI/Oサイクルを節約できます。ロジカル・スタンバイ・デー タベースの使用により、ユーザーは、プライマリ・データベースから更新さ れないスキーマで、表に対するデータ操作ができます。ロジカル・スタンバ イ・データベースは、表がプライマリ・データベースから更新される間、オ ープンしたままで保持し、同時にその表を読取り専用アクセスに使用できま す。また、問合せパフォーマンスの向上と特定な事業要件のために、補助索 引やマテリアライズド・ビューを保守されている表で作成もできます。
• 可用性要件とパフォーマンス要件とのバランスを取れる柔軟性の高いデータ 保護 − Oracle Data Guardは、最大保護モード、最大可用性モードおよび最大 パフォーマンス・モードを提供し、システム・パフォーマンス要件にバラン スの取れたデータ保護が実現できるよう企業を支援します。 • 自動ギャップ検出および解決 − プライマリ・データベースと1つ以上のスタ ンバイ・データベース間の接続が切れた場合（ネットワーク問題などのため に）、プライマリ・データベースで生成中のREDOデータをスタンバイ・デー タベースに送信できません。接続が再確立されると、消失したアーカイブ・ ログ・シーケンス（すなわちギャップ）がData Guardにより自動的に検出され、 必要なアーカイブ・ログが自動的にスタンバイ・データベースに送信されま す。スタンバイ・データベースは、管理者による手動操作を必要とせずに、 プライマリ・データベースと再同期されます。
• 一元化されたシンプルな管理 − Data Guard Brokerは、Data Guard構成にある複 数のデータベースの管理と操作タスクを自動化します。Brokerは、単一のData Guard構成内のすべてのシステムも監視します。管理者は、Oracle Enterprise ManagerかBrokerの独自の特殊なコマンドライン・インタフェース
（DGMGRL）のいずれかを使用して、この統合化された管理フレームワーク を活用できます。
• Oracleデータベースとの統合 − Oracle Data Guardは、追加コストなしでOracle データベース（Enterprise Edition）の完全に統合された機能として使用できま す。
Oracle Data Guard プロセス・アーキテクチャ
次の図に示すとおり、Oracle Data Guard は、いくつかの Oracle データベース・イ ンスタンスのプロセスを使用して、障害時リカバリおよび高可用性に必要な自動 化を行います。
プライマリ・データベースでは、Oracle Data Guard は、ログ・ライター・プロセ ス（LGWR）またはアーカイバ・プロセス（ARCH）により、トランザクション REDO データを収集し、このデータをスタンバイに送ります。また、フェッチ・ アーカイブ・ログ・プロセス（FAL）により、プライマリとスタンバイ間の通信 ロスに基づいてスタンバイにアーカイブされたログを送信するクライアントサー バー・メカニズムを提供してギャップ解消と再同期化を自動化します。
スタンバイ・データベースでは、Oracle Data Guard は、リモート・ファイル・サ ーバー（RFS）プロセスでプライマリ・データベースから REDO レコードを受け
取り、管理リカバリ・プロセス（MRP）で REDO 情報をフィジカル・スタンバイ・ データベースに適用します。また、論理スタンバイ・プロセス（LSP）で SQL 変
換された REDO 情報をロジカル・スタンバイ・データベースに適用します。 Data Guard Broker が有効化されると、Oracle Data Guard でも Data Guard Broker
Monitor（DMON）プロセスによって、一元化された構成としてプライマリ・デー タベースとスタンバイ・データベースの管理、監視が行われます。
主要なテクノロジ・コンポーネント
Data Guard の構成
Data Guard は、1 つのプライマリ・データベースと最大 9 つまでのスタンバイ・デ ータベースで構成されます。プライマリ・データベースおよびスタンバイ・デー タベースは、Real Application Clusters（RAC）環境の単一ノードで稼働します。ス タンバイ・データベースは、Oracle Net Services により、標準 TCP/IP ベースのネ ットワーク（Local Area Network（LAN）、Metropolitan Area Network（MAN）お よび Wide Area Networks（WAN））を介してプライマリ・データベースに接続さ れています。各データベースが互いに通信できる環境では、データベースを置く 場所の制限はありません。ただし、障害時リカバリのために、スタンバイ・デー タベースは、プライマリ・サイトとは地理的に離れたサイトに置くことをお薦め します。 Data Guard では、プライマリ・データベースとスタンバイ・データベースに同じ オペレーティング・システム・アーキテクチャの使用を要求されます。このため、 プライマリ・データベースに、Intel のアーキテクチャで Linux のオペレーティン グ・システムを使用している場合、このプライマリ・データベースのすべてのス タンバイ・データベースにも Intel で Linux が必要です。たとえば、Windows シス テムでは使用できません。さらに、Data Guard 構成内のプライマリ・データベー スとすべてのスタンバイ・データベースには、Oracle Database Enterprise Edition の 同じリリースをインストールする必要があります。REDO Apply と SQL Apply
スタンバイ・データベースは、最初はプライマリ・データベースのバックアップ・ コピーから作成されます。一度作成されると、Data Guard は、プライマリ・デー タベース REDO データをスタンバイ・システムに送信し、REDO データをスタン バイ・データベースに適用することにより、スタンバイ・データベースをプライ マリ・データベースのトランザクション一貫性コピーとして自動的に保守します。
Data Guard には、この REDO データをスタンバイ・データベースに適用し、プラ イマリ・データベースとのトランザクション一貫性を維持する方法が 2 種類用意 されています。これらは、Data Guard によりサポートされる 2 タイプのスタンバ イ・データベースに対応しています。 • REDO Apply: フィジカル・スタンバイ・データベースに対して使用 • SQL Apply: ロジカル・スタンバイ・データベースに対して使用 図 2 は、プライマリからの REDO データ送信については、2 種類のスタンバイ・ データベースに違いがないことを示しています。一度この REDO データがスタン バイ・サーバーに送信された後は、この 2 種類のスタンバイ・データベースには、 REDO データのスタンバイ・データベースへの適用方法に違いがあります。
フィジカル・スタンバイ・データベース
− REDO Apply
フィジカル・スタンバイ・データベースとプライマリ・データベースとの同期は、 Oracle メディア・リカバリでプライマリから受信した REDO ログ・データの適用 により維持されます。スタンバイ・データベースは、ブロック単位でプライマリ・ データベースと物理的に同一です。このため、索引を含むデータベース・スキー マは同じです。 REDO Apply の動作 プライマリ・データベースのログ・スイッチにより、スタンバイ・データベース のログ・スイッチが入ります。スイッチが入ると、スタンバイ・データベースの アーカイバ・プロセスが現在のスタンバイ REDO ログ・ファイルをスタンバイ・ データベースのアーカイブ・ログにアーカイブします。このとき、Data Guard REDO Apply は、管理リカバリ処理（MRP）という特殊なプロセスを使用して、アーカ イブ・ログから REDO データを読み込んでフィジカル・スタンバイ・データベー スに適用します。Oracle Database 10g の Oracle Data Guard の新機能 Real Time Apply が有効化されて、現在のスタンバイ REDO ログ・ファイルが RFS プロセスで一杯 の状態になると、MRP は、REDO データを直接現在のスタンバイ REDO ログ・フ ァイルから読み込まれます。MRP（および REDO のアプリケーション）は、データベースを実装し次のコマン ドにより、フィジカル・スタンバイ・データベース上で開始できます。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
メディア・リカバリ処理はパラレルで稼働可能なため、Data Guard REDO Apply の最大パフォーマンスを達成できます。このような稼働には、Oracle Database 10g より前のリリースでは、前述の RECOVER MANAGED STANDBY DATABASE コマン ドに PARALLEL 句が必要でした。Oracle Database 10g では、MRP は、開始される と最適数のパラレル・リカバリ処理を自動的に（PARALLEL 句を要求せずに）判 断します。この数は、スタンバイ・サーバー上で使用できる CPU の数に基づいて 判断されます。
フィジカル・スタンバイ・データベースは読取り専用でオープンできるため、オ ープン時に、フィジカル・スタンバイ・データベースに問合せできます。フィジ カル・スタンバイ・データベースは、読取り専用でオープンと同時にリカバリで きません。読取り専用でオープンした状態でスタンバイに送信される REDO デー タは、スタンバイ・サイトに蓄積されて、適用されません。ただし、リカバリ操 作はいつでもフィジカル・スタンバイで再開できるため、蓄積された REDO デー タは自動的に適用されます。これで、フィジカル・スタンバイ・データベースを 順番に稼働できます。これには短時間のリカバリでの稼働を含めることもできま す。その後フィジカル・スタンバイ・データベースは、レポートの実行に読取り 専用で開かれ、未処理の REDO データを適用するためにリカバリの実行に戻りま す。 フィジカル・スタンバイ読取り専用のオープンに、リカバリは、次のコマンドに より、スタンバイ上でリカバリの取り消しが必要です。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
これで、データベースは、読取り専用でオープンできます。 ALTER DATABASE OPEN;
フィジカル・スタンバイの利点 フィジカル・スタンバイ・データベースには、次のメリットがあります。 • 障害時リカバリと高可用性 − フィジカル・スタンバイ・データベースは、堅 牢で効率的な障害時リカバリおよび高可用性ソリューションを実現します。 管理しやすいスイッチオーバー機能とフェイルオーバー機能により、プライ マリ・データベースとフィジカル・スタンバイ・データベースのロールを簡 単に反転できるため、計画停止および計画外停止時のプライマリ・データベ ースの停止時間を最小限にします。 • データ保護 − フィジカル・スタンバイ・データベースを使用した、Data Guard は、不測の障害に直面した場合でもデータの消失が起こらないよう保証でき ます。フィジカル・スタンバイ・データベースでは、プライマリがサポート できるすべてのデータ型、およびDDL操作とDML操作がサポートされます。 また、データ破損やユーザー・エラーに対する防衛機能も提供されます。 プライマリ・データベースでのストレージ・レベルの物理的破損は、スタン バイ・データベースに伝播されません。同様に、プライマリ・データベース に恒久的損害を与える論理的破損やユーザー・エラーを解決できます。また、 REDOデータは、スタンバイ・データベースに適用される時点で妥当性チェッ クが行われます。
• プライマリ・データベース処理負荷の軽減 − フィジカル・スタンバイ・デー タベースは、レポート作成や問合せに読取り専用でもオープンできます。ま た、Oracle Recovery Manager（RMAN）により、フィジカル・スタンバイ・デ ータベースを本番データベース用のバックアップに作成するのに使用できま す。このため、本番システムからの貴重なCPUサイクルとI/Oサイクルを節約 できます。Recovery Managerは、フィジカル・スタンバイ・データベースが読 取り専用のオープンと同時にリカバリを実行している間にこのバックアップ ができます。 • パフォーマンス − フィジカル・スタンバイ・データベースにより使用される REDO Applyテクノロジでは、低レベルのリカバリ・メカニズムを使用して変 更を適用します。これは、SQLレベル・コード層をすべてバイパスするため、 変更の適用に最も効率的なメカニズムです。その結果、REDO Applyテクノロ ジは、データベース間で変更を伝播する非常に効率的なメカニズムになって います。
ロジカル・スタンバイ・データベース
− SQL Apply
ロジカル・スタンバイ・データベースには、プライマリ・データベースと同じ論 理情報が含まれますが、構造はデータの物理的編成と異なる場合があります。SQL Apply テクノロジでは、プライマリ・データベースから受信した REDO データを SQL 文に変換し、その SQL 文をスタンバイ・データベースで実行することにより、 ロジカル・スタンバイ・データベースとプライマリ・データベースとの同期を維 持します。そのため、ロジカル・スタンバイ・データベースには、SQL の適用中 でも、問合せやレポート作成には同時にアクセスできます。 ロジカル・スタンバイ・データベースは SQL 文により更新されるため、読取り/ 書込みモードでオープンのままになります。またプライマリ・データベースから 更新中の表は、同時にその他のタスク（レポート、要約、問合せなど）にも使用 できます。これらのタスクは、追加索引とマテリアライズド・ビューを、維持さ れている表に作成して最適化もできます。ロジカル・スタンバイ・データベース は、複数のデータベース・スキーマをホスティングでき、ユーザーは、プライマ リ・データベースから更新されないスキーマで、表に対する通常のデータ操作が できます。 ロジカル・スタンバイ・データベースには、データ型、表型、DDL 型および DML 操作型にいくつかの制限があります。サポートされていないデータ型およびスト レージ属性のリストは、[1]を参照してください。 SQL Apply の動作 SQL Apply では、プライマリ・データベースからロジカル・スタンバイ・データ ベースへの変更を適用するタスクのパラレル実行サーバーとバックグラウンド・ プロセスのコレクションが使用されます。次の図に、情報の流れと各プロセスの ロールを示します。図 4: Data Guard SQL Apply プロセス・アーキテクチャ
これらの様々な SQL Apply プロセスは、ロジカル・スタンバイ・データベースに 次の簡単なコマンドの入力だけで開始できます。
ALTER DATABASE START LOGICAL STANDBY APPLY;
各 SQL Apply プロセスを考慮して、Reader プロセスでは、アーカイブ・ログ（ま たは、Real Time Apply が有効化されている場合はスタンバイ REDO ログ）から REDO レコードを読み出します。プリペアラ・プロセスでは、ブロック変更の表 変更つまり論理変更レコード（LCR）に変換します。この時点では、LCR は、特 定のトランザクションを表現しません。ビルダー・プロセスでは、個々の LCR か ら完全なトランザクションをアセンブルします。アナライザ・プロセスでは、完 全なトランザクションを調べて、様々なトランザクション間の依存性を識別しま す。コーディネータ・プロセス（論理スタンバイ・プロセスまたは LSP として知 られる）では、トランザクションを適用プロセスに割り当て、トランザクション 間の依存性を監視し、ロジカル・スタンバイ・データベースへの変更のコミット を許可します。アプライヤ・プロセスは、割り当てられたトランザクションの LCR をデータベースに適用して、コーディネータによりコミットする指示のトランザ クションをコミットします。 Data Guard は、各プロセスの状態を検査する有用なビューを提供します。 論理スタンバイの利点 ロジカル・スタンバイ・データベースでは、フィジカル・スタンバイ・データベ ースと同様の障害時リカバリ、高可用性、データ保護のメリットを活用できます。 このデータベースには、次に示す効果もあります。 • スタンバイ・ハードウェア・リソースの効率的使用 − ロジカル・スタンバイ・ データベースは、障害時リカバリ用だけでなく、他の事業目的にも使用でき ます。Data Guard構成で保護されているデータベース・スキーマ以外のスキー マも入れることができるため、ユーザーはそのようなスキーマでいつでも DDL操作やDML操作を実行できます。Data Guardにより保護されている論理
スタンバイ表は、プライマリ・データベースと異なる物理レイアウトで格納 できるため、補助索引やマテリアライズド・ビューを作成して、問合せパフ ォーマンスの改善および特定な事業要件に合せることができます。 • プライマリ・データベース負荷の軽減 − ロジカル・スタンバイ・データベー スは、プライマリ・データベースから表の更新中もオープンしたまま保持で きるため、読取りアクセスのために同時に表を使用できます。したがって、 ロジカル・スタンバイ・データベースは、同時にデータ保護およびレポート 作成にも使用できるため、レポート作成や問合せタスクによるプライマリ・ データベースの負荷を軽減し、貴重なCPUサイクルとI/Oサイクルを節約でき ます。
Real Time Apply
Oracle Database 10g の Data Guard の新機能である Real Time Apply は、REDO デー タがスタンバイ REDO ログ（SRL）に書き込まれると、すぐにスタンバイ・デー タベース（REDO Apply または SQL Apply）に適用できます。以前の Data Guard リリースでは、リリースが適用するために、この REDO データをアーカイブ・ロ グのフォームでスタンバイ・データベースにアーカイブする必要がありました。 フィジカル・スタンバイ・データベースに対する Real Time Apply の有効化には、 次のコマンドを使用してフィジカル・スタンバイ・データベース上でリカバリの 開始が必要です。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
ロジカル・スタンバイ・データベースに対する Real Time Apply の有効化には、次 のコマンドを使用してロジカル・スタンバイ・データベースで適用プロセスの開 始が必要です。
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Real Time Apply 機能により、スタンバイ・データベースはプライマリ・データベ ースと密接に同期化されるため、最新のリアルタイムなレポート作成が可能にな ります（特に Data Guard SQL Apply の場合）。また、スイッチオーバーやフェイ ルオーバーの所要時間も短縮されるため、事業の計画停止や計画外停止の時間を 削減できます。
障害の影響は、多くの場合、リカバリ・ポイント目標（RPO、すなわち障害発生 時に事業がどの程度のデータ消失に耐えられるか）やリカバリ時間目標（RTO、 すなわち障害発生時に事業がどの程度の停止時間に耐えられるか）で測定されま す。Oracle Data Guard で最大保護とリアルタイム適用との組合せの場合、事業は 障害発生時にデータ消失ゼロと最小限の停止時間という両方のメリットを受ける ことができます。すなわち、Oracle Data Guard は、事業に対する最良の RPO と RTO を持つ今日入手可能な唯一のソリューションとなっています。
データ保護モード
コスト、可用性、パフォーマンス、トランザクション保護のバランスを取るため、 Oracle Data Guard には 3 つのハイレベル・モードが用意されています。これらの モードは、使用可能な管理インタフェースにより設定が簡単です。次の例は、そ の目的で使用できる、プライマリ・データベース上で可能な簡単な SQL 文です。 ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE}; 適切なデータ保護モードの決定に、企業は、システム応答時間に対するユーザー 要求を考慮して、データ保護に対する事業要件を慎重に検討する必要があります。 次の表に、データ消失リスクの観点からみた各モードの適合性を示します。 保護モード 障害発生時のデータ消失リスク REDO トランスポート・ メカニズム 最大保護 データ消失ゼロ、二重の障害保護 LGWR SYNC 最大可用性 データ消失ゼロ、単一の障害保護 LGWR SYNC 最大パフォーマンス 最小限のデータ消失 − 通常は 0 秒∼数秒 LGWR ASYNC または ARCH 次の項では、各モードについてさらに詳しく説明します。
最大保護
最大保護モードは、プライマリ・データベースに対する最高レベルのデータ保護 を提供し、データ消失ゼロの包括的な障害時リカバリ・ソリューションを保証し ます。最大保護モードで動作している場合、REDO レコードは、ログ・ライター・ プロセスによってプライマリ・データベースからスタンバイ・データベースに同 期的に転送されます。そして、トランザクション・データが 1 つ以上のスタンバ イ・サーバーのディスクで使用可能なことが確認されるまで、プライマリ・デー タベース上のトランザクションはコミットされません。このモードは通常 2 つ以 上のスタンバイ・データベースの構成なため、二重の障害保護が提供されます。 関係している最後のスタンバイ・データベースが使用不可になると、プライマリ・ データベース上の処理は停止します。これにより、プライマリ・データベースが すべてのスタンバイ・データベースとの連絡を失った場合でも、トランザクショ ンが失われないことが保証されます。 REDO 送信が同期する性質上、この最大保護モードは、プライマリ・データベー ス応答時間に影響を与える可能性があります。応答時間への影響は、ピーク時の トランザクション負荷を処理する十分な帯域幅を持ち、低い待機時間におけるネ ットワークの構成により、最小限に抑えることができます。最大保護モードを必 要とする事業の例としては、株取引、為替、金融機関などがあります。最大可用性
最大可用性モードは、プライマリ・データベースに対して 2 番目に高いレベルの データ可用性を提供し、データ消失ゼロと単一コンポーネント障害に対する保護 を保証します。最大保護モードの場合、REDO データは、ログ・ライター・プロセスによってプライマリ・データベースからスタンバイ・データベースに同期的 に転送されます。そして、トランザクション・データがスタンバイ・データベー スのディスク上で使用可能としての確認まで、プライマリ・データベース上のト ランザクションは完了されません。ただし、このモードでは、最大保護モードと は異なり、関係している最後のスタンバイ・データベースがネットワーク接続問 題などに使用不可の場合、プライマリ・データベース上の処理は続行されます。 スタンバイ・データベースは、一時的にプライマリ・データベースから取り残さ れますが、再度使用できるようになると、データ消失がないように自動的に同期 化されます。 この保護モードは、REDO 送信が同期するため、応答時間およびスループットに 影響を与える可能性があります。応答時間への影響は、ピーク時のトランザクシ ョン負荷の処理に十分な帯域幅を持ち、待機時間を短縮するネットワークの構成 により、最小限に抑えることができます。 最大可用性モードは、本番サイトでの重大事故発生時に（他の障害がなかった場 合）データ消失を完全に排除し、ネットワーク/スタンバイ・サーバーの障害によ る本番データベースへの影響を回避することを望む企業に適しています。
最大パフォーマンス
最大パフォーマンス・モードはデフォルトの保護モードです。プライマリ・デー タベース・データ保護の度合いは最大可用性モードより多少低くなりますが、パ フォーマンスは高くなります。このモードでは、プライマリ・データベースがト ランザクションを処理すると、REDO データは、ログ・ライター・プロセスによ り非同期的にスタンバイ・データベースに送信されます。プライマリ・データベ ースのアーカイバ・プロセスの設定により、このモードで REDO データの送信も できます。どちらの場合も、プライマリ・データベースのコミット操作は、スタ ンバイからの受信確認応答を待たずに、プライマリでの書込みを完了します。い ずれかのスタンバイ宛先が使用できない場合でも、プライマリ・データベースで の処理は続行され、パフォーマンスにはほとんど影響しません。ただし、このよ うな場合は、エラー・メッセージがデータベース・アラート・ログに記録され、 それに応じてアラートが Enterprise Manager を介して設定できます。 プライマリで障害が発生した場合、プライマリ側ではコミットされたにもかかわ らず、スタンバイへの送信が完了しなかったトランザクションの発生があります。 ネットワークのスループットが REDO トラフィックのピーク時に十分に対処でき れば、失われるトランザクションを少数または皆無にできます。 最大パフォーマンス・モードは、プライマリ・データベースの可用性とパフォー マンスが、わずかのデータ消失リスクよりも重要な場合に使用します。このモー ドは、ネットワークの固有の待機時間によって同期 REDO 送信の適合性が制限さ れることがある WAN に、Data Guard を配置する場合にも適しています。フェイルオーバーとスイッチオーバー
Oracle Data Guard では、本番サイトの計画停止と計画外停止の処理に、使いやす い 2 通りの方法を用意しています。その方法とは、スイッチオーバーとフェイル
Enterprise Manager GUI インタフェースを使用した管理者による開始も、直接 SQL による開始も、どちらの方法でも簡単です。 フェイルオーバーは、プライマリ・データベースに計画外の壊滅的障害が発生し、 プライマリ・データベースを迅速にリカバリできない場合、新しいプライマリ・ データベースとしてスタンバイ・データベースの 1 つを稼働する操作です。 フェイルオーバー操作は、プライマリ・ロールに変更するスタンバイ・データベ ース上で起動します。Oracle Database 10g のフラッシュバック・データベース機能 がフェイルオーバーの最初のプライマリ・データベースで使用可能な場合、この 機能は、最初のプライマリを新規スタンバイ・データベースとして戻す Data Guard が構成されていれば、フェイルオーバー後に使用できます。フラッシュバック・ データベースがフェイルオーバー前に使用可能ではなく、最初のプライマリ・デ ータベースをフェイルオーバー後にスタンバイとして戻す必要がある場合は、フ ラッシュバック・データベースを新規プライマリ・データベースのバックアップ・ コピーから作成し直す必要があります。 次の図に、サンフランシスコのプライマリ・データベースからボストンのフィジ カル・スタンバイ・データベースにフェイルオーバーの結果を示します。 図 5: スタンバイ・データベースへのフェイルオーバー 一方、スイッチオーバー・オプションは、プライマリ・データベースの計画的保 守に、プライマリ・データベースとスタンバイ・データベースのロールを計画的 に反転させます。スイッチオーバー操作とフェイルオーバー操作の主な違いは、 スイッチオーバーはプライマリ・データベースがまだ使用可能であるときに実行 され、フラッシュバックまたは最初のプライマリ・データベースの再インスタン ス化を必要としません。そのため、最初のプライマリ・データベースをほとんど 瞬時にスタンバイ・データベースのロールに移行できます。したがって、計画的 保守をこれまで以上に容易かつ頻繁にできます。たとえば、プライマリ・サイト
でハードウェアをアップグレードする際、スイッチオーバーですべてのデータベ ース・クライアントをスタンバイ・サイトに切り替えることにより、プライマリ・ サイトでアップグレードができます。 スイッチバックという用語が、Data Guard ロール管理に使用されることもありま す。スイッチバック操作とは、単に、ロールを最初の状態に戻すスイッチオーバ ーだけの操作です。 スイッチオーバー操作は、推移中にデータが消失しないことを保証します。フェ イルオーバー時に Data Guard が最大保護モードまたは最大可用性モードで稼働し ている場合、どちらの操作でもデータ消失ゼロが保証されます。 一時システムまたはネットワークに障害が発生した際、フェイルオーバーとスイ ッチオーバーの不適切な実行を回避できる Data Guard スイッチオーバーおよびフ ェイルオーバー操作は自動化されていませんが、管理者により明示的な起動が必 要です。これらの操作を起動すると、Data Guard により関連のプロセスが自動化 されます。 複数のスタンバイ・データベースが構成に含まれている場合、フェイルオーバー 操作とスイッチオーバー操作はシームレスに動作します。たとえば、複数のスタ ンバイ・データベースが構成されているときにプライマリ・データベースがダウ ンした場合、管理者は使用可能なスタンバイの 1 つをプライマリとして柔軟に選 択できます。Data Guard は、新しいプライマリの使用に、欠落した REDO データ や不完全な REDO データの送信など、他のスタンバイ・データベースへの転送プ ロセスを完全に自動化します。
自動再同期化
Oracle Data Guard により、スタンバイ（フィジカルまたは論理）データベースが プライマリ・データベースから一時的に切断するネットワーク接続問題を円滑に 処理できます。 スタンバイ・データベース（ただし、そのスタンバイ・データベースが、最大保 護モードに設定された最後のスタンバイの場合は、プライマリ・データベースは シャットダウンされる）が使用できないと、トランザクションは、プライマリ・ データベースでローカルに取得されます。スタンバイに対する接続が再確立され ると、スタンバイがプライマリと再同期まで、蓄積されたアーカイブ・ログがス タンバイに自動的に送信され適用されます。このプロセスには、管理操作は一切 必要ありません。プライマリ・サイトの近辺でネットワーク停止が日常的に発生 する場合、このような再同期化を処理できる十分なネットワーク容量を確保して おくことをお薦めします。
人的エラーからの保護
プライマリ・データベースがオープン中でアクティブであり、トランザクション が進行中の場合、REDO データが生成され、スタンバイ・サイトに送信されます。 人的エラーがシステム停止時間の主要原因であることを考えると、この REDO デ ータには重要な表の削除のような重大に論理的ユーザー・エラーが含まれる可能Data Guard には、そのようなユーザー・エラーを回避する使いやすい手段がいく つか用意されています。たとえば、管理者はプライマリ・データベースとスタン バイ・データベースの両方で Oracle Database 10g のフラッシュバック・データベ ース機能を使用することにより、そのユーザー・エラーを取り消してデータベー スを迅速に過去のある時点に戻すことができます。また、管理者がスタンバイ・ データベースにフェイルオーバーすることを決定していて、ユーザー・エラーが スタンバイ・データベースにすでに適用済の場合（たとえば Real Time Apply が有 効な場合）、管理者は過去の安全な時点までスタンバイ・データベースをフラッ シュバックできます（スタンバイ・データベースでフラッシュバック機能がすで に有効な場合）。その他、1 つまたは複数のスタンバイ・データベースには Real Time Apply 機能を使用せず、REDO データの適用を設定/変更した時間のみ遅らせる（そ の間に、このようなユーザー・エラーや破損に対する保護が提供される）という オプションも管理者に与えられます。 選択したオプションにかかわらず、スタンバイ・データベースでの適用プロセス では、スタンバイ・データベースに破損した物理 REDO データが適用されないよ う常にログ・レコードの妥当性チェックが行われます。
ローリング・アップグレード
Oracle Database 10g では、Data Guard SQL Apply を使用してデータベース停止時間 をほとんど排除する、ローリング方式でのデータベース・ソフトウェア・アップ グレード（Oracle Database 10g 以上）をサポートします。その手順は、ロジカル・ スタンバイ・データベースを次のリリースにアップグレードし、このアップグレ ードのテストと妥当性チェックのため混合モードで実行し、アップグレードした データベースのスイッチオーバーによりロールを反転し、最後に古いプライマ リ・データベースをアップグレードするものです。テストのために混合モードで 実行している間は、アップグレードを中止して、データの消失なくソフトウェア をダウングレードできます。この手順の間のデータ保護を強化するため、第 2 の スタンバイ・データベースを使用できます。 Data Guard は、停止時間を最小限にするローリング・アップグレードをサポート して、多くの管理タスクで一般的な大きなメンテナンス時間枠を削減し、事業の 24 時間稼働を実現します。
REDO ログ宛先のカスケード
この場合、スタンバイ・データベースは、オリジナルのプライマリ・データベー スからではなく、他のスタンバイ・データベースから REDO データを受信します。 プライマリ・データベースは、そのサブセットのみに REDO データを送信するた め、この機能では、プライマリ・システムの負荷やネットワーク・トラフィック が軽減され、プライマリ・サイト周辺の貴重なネットワーク・リソースの使用量 が減少します。Enterprise Manager と Data Guard Broker
Oracle Data Guard Broker は、Data Guard 構成の作成、保守、監視を自動化および 一元化する分散管理フレームワークです。すべての管理操作は、Broker を使用す る Oracle Enterprise Manager または Broker の特別なコマンドライン・インタフェー
ス（DGMGRL）を通じて、リモートからも実行できます。次のスクリーンショッ トは、Enterprise Manager からの Data Guard ホームページです。
図 6: Oracle Enterprise Manager による Oracle Data Guard の構成
次のリストに、Broker により自動化および簡素化される操作の一部を示します。 • プライマリ・データベースと9個までのスタンバイ（フィジカルおよび論理） データベースを含むData Guard構成を作成して有効化します。これらのデータ ベースをすべて使用して、または混合してRACクラスタにできます。 • 構成の任意のサイトからData Guard構成全体を管理します。 • 構成内の全システムにわたる複雑なロール変更を必要とするスイッチオーバ ー操作またはフェイルオーバー操作を実行します。 • 一元化された監視ツール、テスト・ツールおよびイベント通知ツールにより、 ログ適用速度を監視し、診断情報を収集し、問題を迅速に検出します。 Broker の使いやすいインタフェースおよび Data Guard 構成の一元化された管理と 監視により、Data Guard は企業に対して優れた高可用性とデータ保護を提供する ソリューションとなります。
構成オプション
スタンバイ・データベースは、リモート（WAN または MAN を介した接続）また はローカル（LAN での接続）にできます。Data Guard 構成には、ローカルとリモ ートの両方のスタンバイ・データベースを含むことができるため、両方のアプロ ーチのメリットを活用する構成ができます。
リモート・スタンバイ・データベースは、障害時リカバリに最適なソリューショ ンです。それは、プライマリ・データベースが使用できない障害の発生でも、ス
ローカル・スタンバイ・データベースは、データ・センター内の人的エラーやデ ータ破損に関係する停止の解決に適しています。LAN は、費用がかからず、待機 時間の短い信頼性の高いネットワークを提供できるため、スタンバイを使用する 専用の LAN セグメントがあれば、最大保護モードの理想的な環境になります。 Data Guard ネットワーク構成に推奨されるベスト・プラクティスは、[5]を参照し てください。
Oracle Data Guard および RAC
Oracle Data Guard と Oracle Real Application Clusters（RAC）は、相互の補完関係に あります。RAC はシステム障害またはインスタンス障害に対処します。RAC は、 ノード障害やインスタンスのクラッシュなど、データに影響しない障害からの迅 速で自動的なリカバリを提供します。また、アプリケーションのスケーラビリテ ィを強化します。一方 Data Guard は、トランザクション一貫性のあるプライマリ・ データベースとスタンバイ・データベースによりデータ保護を提供します。これ らのデータベースはディスクを共有し、ロック手順を実行することはありません。 したがって、サイトの障害やデータ破損からのリカバリが可能になります。 Data Guard は、RAC とネイティブに統合されています。すなわち、プライマリ・ データベースもスタンバイ・データベース（フィジカルまたは論理）も RAC デー タベースとすることができます。また、RAC データベースを Enterprise Manager または Broker のコマンドライン・インタフェース、または直接 SQL を使用して管 理できます。データ・レベル保護とシステム・レベル保護の両方からメリットを 得るには、Oracle Data Guard と Real Application Clusters との組合せが必要です。
最大可用性アーキテクチャ
より多くのシステム機能が提供されると、IT 管理者、設計者、管理者などは適切 な機能のセットを統合して、事業要件のすべてに適合する統一された高可用性 （HA）を持つソリューションの構築が難しく感じます。Oracle Maximum Availability
Architecture（MAA）は、実証済 Oracle 高可用性テクノロジと推奨事項に基づく Oracle のベスト・プラクティスの青写真で、その目標は、最適な高可用性アーキ テクチャの設計に複雑性を排除し、システムの可用性を最大限に活用することで す。 MAA には、次のような利点があります。 • MAAは、詳細な構成ガイドラインの提供により、Oracleシステムの可用性を 高める実装コストを削減します。異なる構成でのパフォーマンスへの影響の 調査から、選択の可用性の高いアーキテクチャでは、企業のニーズに合せて 継続し、スケールの調整を保証することが明らかになっています。 • MAAは、人的エラー、システム故障、クラッシュ、保守、データ障害、破損、 障害などによる計画停止および計画外停止から発生する停止時間を、ゼロま たは最小限にするベスト・プラクティスとリカバリ手順を提供します。
• MAAでは、障害発生時の停止や受容可能な量のデータ消失からリカバリまで の時間の長さを制御できるため、事業要件に合せた平均リカバリ時間 （MTTR）を調整できます。
Data Guard は、MAA の重要なコンポーネントです。MAA のガイドラインには、 様々な Data Guard 構成に関するベスト・プラクティスの推奨事項（[3]∼[6]参照） が記載され、RAC および Data Guard、REDO データ移行メカニズム、スイッチオ ーバーおよびフェイルオーバー、メディア・リカバリ、SQL Apply 構成、ネット ワーク構成などが説明されています。Data Guard 実装に興味を待たれる場合、こ れらの MAA ベスト・プラクティス・ガイドラインの参照を強くお薦めします。 また、Oracle Database 10g に興味を待たれる場合、MAA のホワイト・ペーパーの 他に、高可用性ベスト・プラクティスに関する標準 Oracle マニュアル（参照[2]） を参照してください。
Data Guard とリモート・ミラー化ソリューション
リモート・ミラー化ソリューションは、概念的に、シンプルで完全なデータ保護 の提供に見えます。ただし、リモート・ミラー化ソリューションと比較すると、 Oracle Data Guard の方が本質的に効率が高く、費用もかからず、データ保護に最 適なソリューションと言えます。Oracle Data Guard があれば、リモート・ミラー 化ソリューションを購入し、統合は必要ありません。次に、リモート・ミラー化 ソリューションと比較した Oracle Data Guard のメリットを示します。
• 優れたネットワーク効率
Oracle Data Guard では、リモート・サイトに送信が必要なのは REDO データ のみです。一方、データ保護のためにリモート・ミラー化ソリューションを 使用する場合、データベース・ファイル、オンライン・ログ、アーカイブ・ ログおよび制御ファイルのミラー化が必要です。すなわち、リモート・ミラ ー化では、各変更を少なくともリモート・サイトに 3 回の送信になります。 さらに、各ログの書込みには通常多数の変更が含まれているため（グループ・ コミットと呼ばれる）、データベースへの書込みはログへの書込みよりはる かに頻繁になります。すなわち、データベース REDO 送信ベースのソリュー ションで必要とされるネットワークの帯域幅の方が、リモート・ミラー化ソ リューションの帯域幅より小さいことを意味します。さらに重要なのは、こ れがネットワーク・ラウンドトリップも大幅に少ないことです。 リモート・ミラー化は、データベース以外のファイルには非常に便利ですが、 データベース・データについては、より優れた保護をより少ないコストで提 供する Data Guard が有利です。オラクル社の社内電子メール・システムの内 部分析では、次のグラフに示すとおり、リモート・ミラー化ソリューション の場合、Data Guard を使用した場合と比較して、7 倍のデータがネットワーク を介して送信され、27 倍の I/O 操作が明らかになりました。
図 7: ネットワーク・パフォーマンス: Data Guard とリモート・ミラー化 • WANに対するより優れた適合 ストレージ・システム・ベースのリモート・ミラー化ソリューションでは、 ストレージ・システムでの基礎的通信テクノロジ（ファイバ、ESCON）のた め距離に制限が課せられます。サード・パーティ・ベンダー製の特殊なデバ イスの使用により、この距離を延ばすことができます。このデバイスは、 ESCON/ファイバを、適切な IP、ATM または SONET ネットワークに変換し ます。問題は、そのような各デバイスでは、システムで待機時間が発生し、 本番データベースのパフォーマンスに影響を与えるため、その構成はデータ 消失ゼロ機能に不可欠な同期転送には不適切である点です。通信パスに中間 ストレージ・ボックスを導入することによりこの問題は軽減の可能性があり ますが、全体的なコストは上昇します。もう 1 つのソリューションは、同期 転送のバリエーションを使用することです。ただし、リモート・ミラー化ソ リューションに依存する場合、データの同期転送以外の方法で、データベー スが置かれているミラー化されたすべてのボリュームに渡って書込み順序を 維持できません。すなわち、そのような構成では、データの一貫性を常時保 証できないため、OLTP データのためのデータ保護/障害時リカバリ・ソリュ ーションとして不適切です。
Data Guard は、標準 IP ネットワークを使用して、REDO データのみをスタン バイ・サイトに送信するため、すべての保護モード（すなわち、転送を同期 モード、または非同期モードで行うかに関係なく）でトランザクション一貫 性が維持されます。また、高価な中間ストレージ・ボックスも不要であり、 WAN のための障害リカバリおよびデータ保護としてはるかに優れています。 • 優れたリジリエンスとデータ保護の改善
Oracle Data Guard プロセスは、プライマリ・データベースからの情報の読取り および書込みの際、データ書式を認識します。さらに、Oracle Data Guard はフ
ラッシュバック・データベース機能との統合により、変更の適用を遅らせる
こともできます。この機能により、多くの人的エラーとデータ破損の伝播や スタンバイ・データベースへの影響、またはその両方を防止できます。リモ ート・ミラー化には、このようなメリットはありません。重要な表を不注意
で削除すると、すぐにデータベース・ファイルのリモート・コピーに伝播さ れ悪影響があります。
• 高いROI（投資収益率）
Oracle Data Guard を使用している場合、変更が伝播されている間でも、スタン バイ・データベースをレポート作成に読取り専用でオープンできます。リモ ート・ミラー化ソリューションでは、これが常に可能とはかぎりません。そ のうえ、Oracle Data Guard は、Oracle データベースのコア機能であり、すぐに 使用できます。余分なコストや統合の必要がありません。一方、リモート・ ミラー化ソリューションでは、余分な購入コストがかかるうえ、データベー スとの複雑な統合が必要です。最後に、そのようなリモート・ミラー化ソリ ューションの大部分は独自仕様であるため、リモート・ミラー化ソリューシ ョンと同じベンダー・ストレージ・システム（プライマリ・サイトおよびセ カンダリ・サイトの両方）でしか使用できません。一方、Data Guard は、プ ライマリ・サイトとスタンバイ・サイトの両方の特定なストレージ・ソリュ ーションによって、ロックインの強制実行はありません。
結論
Oracle Data Guard は、企業にデータ保護、障害時リカバリおよび高可用性を提供 する包括的ソリューションで、計画停止および計画外停止の両方に対処する、柔 軟で管理しやすいフレームワークを提供します。フィジカル・スタンバイ・デー タベースとロジカル・スタンバイ・データベースは互いに補完関係にあり、同時 に保守できるため、効果的なデータ保護を提供しながらプライマリ・データベー スからオーバーヘッドの負荷を軽減します。また、各種のデータ保護モードによ り、保護、パフォーマンスおよびインフラストラクチャに対する様々な要件に適 合できる柔軟性を実現しています。Data Guard Broker を Oracle Enterprise Manager と組合せて、構成および管理に使いやすいフレームワークを提供します。 今日のグローバル企業は、このホワイト・ペーパーで説明したようなテクノロジ なしに顧客や様々な株主にミッション・クリティカルなレベルのサービスを提供 できません。そのようなテクノロジは、完全で、統合され、操作性に優れ、複数 の使用目的を持ち、すべての企業データを保護するものである必要があります。 同時に、このようなデータ保護および障害時リカバリ・テクノロジは費用がかか らず、企業がその DR 投資から価値を得る必要性もあります。Oracle Data Guard は、そのようなニーズをすべて満たすことができる、市場で唯一のソリューショ ンです。
参照
1. 『Oracle Data Guard 概要および管理』
2. 『Oracle 高可用性アーキテクチャおよびベスト・プラクティス』
3. MAA Detailed White Paper,
4. Oracle9i Media Recovery Best Practices,
http://otn.oracle.com/deploy/availability/htdocs/maa.htm
5. Oracle9i Data Guard: Primary Site and Network Configuration Best Practices, http://otn.oracle.com/deploy/availability/htdocs/maa.htm
6. Oracle9i Data Guard: SQL Apply Best Practices, http://otn.oracle.com/deploy/availability/htdocs/maa.htm
Oracle Database 10g の Oracle Data Guard 企業のための障害時リカバリ 2004 年 著書: Ashish Ray Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com オラクル社は、インターネット上での活動を強化するソフトウェアを提供します。 Oracle はオラクル社の登録商標です。 このガイドで使用されているさまざまな製品名およびサービス名には、オラクル社の商標が含まれています。 その他のすべての製品名およびサービス名は、各社の商標です。 この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。 万一、誤植などにお気づきの場合は、オラクル社までお知らせください。 オラクル社は本書の内容に関していかなる保証もしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。
