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

(1)

Oracle Data Guard 11g

次世代のデータ保護と

可用性

Oracle テクニカル・ホワイト・ペーパー

2007 年 5 月

(2)

ご注意

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

(3)

Oracle Data Guard 11g

次世代のデータ保護と可用性

はじめに ... 4

Oracle Data Guard - 概要 ... 5

Oracle Data Guard 11g の新機能の概要... 7

Oracle Data Guard プロセス・アーキテクチャ... 10

主要テクノロジ・コンポーネント... 11

Oracle Data Guard 構成... 11

保護モード... 12

最大保護モード ... 12

最大可用性モード ... 13

最大パフォーマンス・モード ... 14

自動ギャップ解消 - 通信障害の対応... 14

適用サービス - REDO Apply と SQL Apply... 14

フィジカル・スタンバイ・データベース - REDO Apply ... 15

REDO をスタンバイ・データベースに適用する前の

データ検証 ... 15

REDO Apply とリアルタイム問合せ... 16

スナップショット・スタンバイ ... 17

ロジカル・スタンバイ・データベース - SQL Apply... 17

SQL Apply の動作 ... 18

REDO Apply または SQL Apply のいずれかを選択する方法... 19

Oracle Data Guard 構成の管理... 20

ロール管理サービス... 22

スイッチオーバー ... 22

フェイルオーバー ... 23

ファスト・スタート・フェイルオーバー ... 23

柔軟性に優れた構成オプション ... 24

新しいスタンバイ・データベースとしての旧プライマリ・

データベースのリストア ... 25

自動クライアント・フェイルオーバー... 26

サービスの再配置... 26

クライアント通知および再接続 ... 27

ロール移行イベント... 28

ローリング・データベース・アップグレード... 28

カスケードした宛先 ... 29

Oracle Data Guard および Oracle Real Application Clusters ... 29

Oracle Maximum Availability Architecture ... 29

Oracle Data Guard とリモート・ミラー化ソリューション... 30

Oracle Data Guard の顧客 ... 30

結論 ... 31

(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 は、充実した機能およ

び豊富な管理インタフェースを備えています。

• 最大の投資収益率 - スタンバイ・ロールで実行中にすべてのスタンバイ・データベースを本番目的で使用できます。複雑さまたはコストが増えることなく、アイドル・リソースが排除されます。

(5)

システムおよびインフラストラクチャに組み込まれた高可用性の度合いに関係なく、使用中の IT アーキテクチャに Oracle Data Guard を配置することで、データ保護と可用性が例外なく拡張されます。

このホワイト・ペーパーでは、Oracle Data Guard 11g について、アーキテクチャとテクノロジの面から概説します。詳細については、Oracle Data Guard ドキュメント [2]を参照してください。

Oracle Data Guard - 概要

Oracle Data Guard は、統合された Oracle Database High Availability（HA）ソリューション・セットの中心コンポーネントです。このコンポーネントを使用して業務に影響を及ぼす可能性のあるさまざまな計画停止時間と計画外停止時間を最小限に抑えることによって、組織はビジネスの継続性を確保できます。次の図は、Oracle Database 11g で使用できるさまざまな HA 機能を示しています。これらの各機能の詳細については、Oracle Technology Network の Oracle Database High Availability[3] を参照してください。

"Fidelity National Financial社は、Oracle RACおよびGridインフラストラクチャを実装しました。また、Oracle Recovery

Managerを配置してバックアップとリカ

バリ機能を実装し、Oracle Data Guard

を利用してWAN全体のリモート障害時リカバリと高可用性を実現しました。

Oracle High Availability機能の利用と

Oracle Maximum Availability Architecture

（MAA）ベスト・プラクティスの実装によって、Fidelity National Financial社は最小コストで品質保証契約を満たすことができました。"

- 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 転送サービス、適用サービス、

(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ロール管理サービス：計画停止または計画外停止によって本番

データベースが使用できなくなった場合、Oracle Data Guardロール管理サービス

は、選択されたスタンバイ・データベースを本番ロールに素早く切り替え、停止時間を最小限に抑えて、データ損失を防止します。Oracle Data Guardは、手動の制御、またはユーザー設定可能な一連のルールに準拠したオペレータが介入しない自動的な制御で、ロールを移行する柔軟性を提供します。Oracle Data Guardは、ミッション・クリティカルなアプリケーションに必要なレベルの高可用性を提供するためにクライアント・フェイルオーバーを自動化するインフラストラクチャを提供します。フェイルオーバーの後、障害が発生したプライマリは、新しいプライマリのスタンバイ・データベースとして迅速に回復して、構成を保護された状態に素早く戻すことができます。

"Oracle Data Guardファスト・スタート・フェイルオーバーは、緊急時でも 1 日24時間態勢で重要な顧客サービスを提供するためにPPLが依存する停止管理システムの人を介さない簡単で高速なフェイルオーバーを実現します。Oracle9iから障害時リカバリ（DR）にOracle Data Guardを使用していますが、ファスト・スタート・フェイルオーバーは高可用性とDRの境界をなくします。このため、単一のソリューションで両方の要件を満たすことができます。" - PPL Services Corp.、

Enterprise Technology Services、

ディレクタ、Chris Carter氏 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を適用して、スタンバイ・データベースへの最新の読取りアクセスを有効にします。

(7)

これによって、すべてのスタンバイ・データベースは、読取り専用の問合せとレポートをサポートするプライマリ・データベースのオーバーヘッドを軽減するための優れた選択肢となります。

すべての Oracle Data Guard スタンバイ・データベースは、RMAN[4]を使用したオンライン・バックアップをサポートします。フィジカル・スタンバイ・データベースはプライマリ・データベースの完全なレプリカなので、フィジカル・スタンバイ・データベースを使用して、プライマリ・データベースのバックアップのオーバーヘッドを軽減できます。フィジカル・スタンバイ・データベース（REDO Apply）をスナップショット・スタンバイに変換できます。これによって、本番データの読取り/書込み用のレプリカを使用したホット・パッチおよびその他のテストを実行できます。Oracle Data Guard は、スナップショット・スタンバイへの REDO データの送信を継続して、常にデータを保護します。スナップショット･スタンバイは、安全に保管するためにアーカイブされ、テストの終了後にスタンバイ・データベースに戻される際に素早く再同期するために使用できます。ロジカル・スタンバイ（SQL Apply）データベースでは、オープンな読取り/書込みの柔軟性が向上しています。SQL Apply によって保守されるデータを変更できない場合、ローカル表をデータベースに追加できます。また、ローカル索引構造を作成して、レポートを最適化したり、データ・ウェアハウスとしてスタンバイ・データベースを利用したり、データ・マートをロードするために使用される情報を処理したりできます。

"Oracle Data Guardローリング・アップグレードでは、データベース（Oracle Database 10.1.0.3から 10.1.0.4）、サーバー、ストレージの完全なアップグレードの実行中に停止時間が制限されます。読取りアクセス用の停止時間はなく、読取り/書込みトランザクションの停止時間は30分未満です。"

- Thomson Legal & Regulatory、データベース・アーキテクト、 Dan Dressel氏（Oracle OpenWorld 2006にて）ロジカル・スタンバイ・データベースを使用して、ローリング・データベース・アップグレードを実行できます。これによって、新しいデータベース・パッチセットまたは完全なデータベース・リリースにアップグレードする場合に停止時間を最小限に抑えられます。また、一時的にフィジカル・スタンバイを一時ロジカル・スタンバイに変換して、ローリング・データベース・アップグレードを実行した後にフィジカル・スタンバイの通常の運用状態に戻すことができます。

Oracle Data Guard 11g の新機能の概要

Oracle Data Guard 11g で利用できる新機能は、以下のとおりです。

リアルタイム問合せ：フィジカル・スタンバイ・データベースは、Applyがアクティブな場合に読取り専用でオープンできます。これによって、フィジカル・スタンバイ・データベースに接続しているユーザーは、プライマリ・データベースの最新のデータの問合せとレポートを行うことができます。スナップショット・スタンバイ：これは、フィジカル・スタンバイ・データベースから作成される新しいタイプのスタンバイ・データベースです。作成された後、スナップショット・スタンバイを読取り/書込みでオープンして、テストなどを実行するためにプライマリ・データベースから独立したトランザクションを処理できます。スナップショット・スタンバイ・データベースは、引き続きプライマリ・データベースから更新を受信およびアーカイブします。ただし、プライマリから受け取ったREDOデータは、スナップショット・スタンバイがフィジカル・スタンバイ・データベースに変換されてスナップショット・スタンバイのときに実行

(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が必要です。

(9)

追加のSQL Applyデータ型のサポート：SQL Applyは、以下の機能を含む追加の データ型、他のOracle機能、およびPL/SQLのサポートを引き続き拡張します。 "Oracle Data Guardロジカル・スタンバ

イは、処理能力とスケーラビリティを大幅に向上させる長期戦略のハードウェアとソフトウェア・プラットフォームの重要なコンポーネントです。この完全なソリューションを実装すると、ほとんどのバッチ処理操作で 50～95%パフォーマンスが向上しました。"

- e-Rewards Market Research、ビジネス・インテリジェンス・アーキテクト、 David Sink氏 • 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）

(10)

Oracle Data Guard プロセス・アーキテクチャ

図 2 に示すように、Oracle Data Guard では Oracle データベースの複数のプロセスを使用して、高可用性や障害時リカバリに必要な自動化を行います。

Oracle Data Guard は、プライマリ・データベースで、LogWriter Network Server（LNS）という特殊なバックグラウンド・プロセスを使用します。このプロセスは、ログ・ライターによって書き込まれる REDO データを取得し、同期または非同期で REDO データをスタンバイ・データベースに送信します。LNS プロセスは、転送のオーバーヘッドおよびネットワークの分断からログ・ライターを切り離します。同期 REDO 転送（SYNC）を使用する場合、プライマリ・データベースのログ・ライターは、クライアント・アプリケーションのコミットを確認する前に、スタンバイで REDO データを受け取ってデータがスタンバイ REDO ログに書き込まれたことを示す LNS からの確認応答を待つ必要があります。これによって、すべてのコミットされたトランザクションがディスク上に存在し、スタンバイ・ロケーションで保護されることが保証されます。非同期 REDO 転送（ASYNC）を使用する場合、プライマリのログ・ライターは、 REDO データがディスクに書き込まれたことを示すスタンバイ・データベースからの確認応答を待つ必要がありません。REDO 転送と非同期にクライアント・アプリケーションに対してコミットが確認されます。また、ASYNC は、スタンバイ・データベースに REDO を効率的にストリーミングでき、ネットワークのスループットを低下させる可能性のあるネットワークの確認応答によるオーバーヘッドを排除します。 NEW! - 非同期REDO転送パフォーマン スの強化機能は、ネットワーク利用とリカバリ・ポイント目標をさらに改善し ます。

図2：Oracle Data Guardプロセス・アーキテクチャ

プライマリ・データベースとスタンバイ・データベースの接続が（ネットワーク障害またはスタンバイ・サーバー障害により）切断される場合、選択された保護モード（保護モードはこのホワイト・ペーパーの後半で説明します）に応じて、

(11)

プライマリ・データベースは、引き続きトランザクションを処理し、新しいネットワーク接続が確立されるまで、スタンバイに送信できないREDOデータの未処理分を蓄積します（アーカイブ・ログ・ギャップと呼ばれます）。この場合、Oracle Data Guardは、スタンバイ・データベース・ステータスを継続的に監視し、接続を再確立する日時を検出して、構成をできるだけ素早く保護された状態に戻すためにスタンバイ・データベースとプライマリ・データベースを自動的に再同期しま す。アーカイバ（ARCn）プロセスは、ギャップの解消に必要なログ・ファイルを 送信するために常に利用されます。ギャップ解消を迅速化する複数のオプションを使用できます。

• Oracle Data Guard は、転送時間を短縮して使用できる帯域幅を最大限に活用するため、ギャップを解消するために転送されるアーカイブ・ログを圧縮できます。 NEW! - ギャップを解消してネットワー クまたはスタンバイ・サーバー障害の後にスタンバイ・データベースを再同期するために必要なログ・ファイルを送信する場合、アーカイブ・ログ圧縮が使用さ れます。 • 転送の必要な多くのアーカイブ・ログが存在する場合、最大 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 でプライマリ・データベースに接続します。データベース同士の通信が可能であれば、設置場所に関する制約はありません。ただし、障害時リカバリを考慮した場合、スタンバイ・データベースはプライマリ・データベースから地理的に離れた場所へ設置することを推奨します。

(12)

Oracle Data Guard 11gでは、Data Guard構成の柔軟性が向上しています。この構成では、MetaLink Note 413484.1に定義されている制約に準拠する、各種CPUアーキテクチャ、オペレーティング・システム（WindowsおよびLinuxなど）、オペレーティング・システム・バイナリ（32 ビット/64 ビット）、およびOracleデータベース・バイナリ（32 ビット/64 ビット）が、プライマリ・システムおよびスタンバイ・システムに含まれます。プライマリ・データベースとスタンバイ・データベースの 2 つの不変の要件は、endianフォーマットが同じこととOracleデータベースのリリースが同じことです。ただし、ロジカル・スタンバイ・データベースを使用したローリング・データベース・アップグレードの実行中を除きます。

NEW! Oracle Data Guard 11gには、プ ライマリ・システムおよびスタンバイ・ システムに異なるCPUアーキテクチャ、 OSバイナリ、およびOracleデータベー ス・バイナリを配置する複数のオプショ ンがあります。たとえば、Windowsのプ ライマリ・データベース、Linuxのスタン バイ・データベースがあります。 最新の機能と制約については、MetaLink Note 413484.1 を参照してください。

保護モード

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 が確認するまで、プライマリ・データベース上のログ・ライター・プロセスは、クライアント・アプリケーションへのコミットを許可しません。

(13)

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

(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 構成内のプライマリ・データベースとすべてのスタンバイ・データベースを自動的に同期します。

(15)

Oracle Data Guard には、この REDO データをスタンバイ・データベースに適用する 2 つの方法が用意されており、サポートする 2 種類のスタンバイ・データベースに対応しています。 • REDO Apply は、フィジカル・スタンバイ・データベースに使用されます。 • SQL Apply は、ロジカル・スタンバイ・データベースに使用されます。プライマリ・データベースからの REDO データ送信という点に関しては、この 2 種類のスタンバイ・データベースに違いはありません。REDO データがスタンバイ・サーバーに送信されると、スタンバイ・データベースに適用されるために使用される方法が異なります。

フィジカル・スタンバイ・データベース - REDO Apply

フィジカル・スタンバイ・データベースは、Oracle メディア・リカバリを使用して、プライマリ・データベースから受け取った REDO データを適用します。ブロック単位で見た場合、スタンバイ・データベースはプライマリ・データベースと同一であり、索引を含むデータベース・スキーマも同じになります。

NEW! REDO Applyパフォーマンスは、 Oracle Database 10gと比較してすべて のワークロード・プロファイル用に大幅 に拡張されました。

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 の破損から完全に切り離されます。また、スタンバイ・データベースで実行されるソフトウェア・コード・パスは、プライマリとは基本的に異なります。このため、プラ

(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-600 3020）が返されます。スタンバイ・データベースの書込み損失を修復するには、スタンバイ・データベースまたは影響するファイルを再作成する必要があります。両方の場合、スタンバイ・データベースは、アラート・ログとトレース・ファイルに障害の理由を書き込みます。全体として、プライマリ・データベースの破損はスタンバイ・データベースの整合性に影響しないという Oracle Data Guard の基本原則に基づいて、上記の機能が提供されます。 NEW! リアルタイム問合せでは、問合せ とレポートのために最新のフィジカル・スタンバイ・データベースへの読取り専 用アクセスを有効にします。 REDO Apply とリアルタイム問合せ プライマリ・データベースの最新のレプリカに対して問合せを実行できる REDO Apply がオン（リカバリがアクティブ）の場合、フィジカル・スタンバイ・データベースを読取り専用でオープンできます。以下の方法で実行できます。

(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 文に変換し、それをスタンバイ・データベースで実行することによって、ロジカル・スタンバイ・データベースとプライマリ・データベースとの同期を維持します。フィジカル・スタンバイと同様に、適用中でも問合せやレポートのためにロジカ

(18)

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

(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 は、より簡潔なソリューションを望むユーザー向けの簡単なプロセスです。

(20)

• フィジカル・スタンバイは、テストや開発などの目的でスナップショット・スタンバイにできます。 • プライマリ・データベースの完全なレプリカであるフィジカル・スタンバイを使用して、バックアップ実行時のプライマリ・ホストをオフロードできます。 • フィジカル・スタンバイには制限がありません。処理とパフォーマンスは、データ型とトランザクション・プロファイルに完全に透過的です。REDO は REDO です。 • 障害時リカバリ・シナリオでは、プライマリの正確で物理的なレプリカであるスタンバイ・データベースを好むユーザーもいます。 SQL Applyを利用する決定に影響する要素 • ロジカル・スタンバイ・データベースは、常に読取り/書込みでオープンするので大きな柔軟性があります。たとえば、データベースへの読取り/書込みアクセスが必要なレポート・アプリケーションがあります。フィジカル・スタンバイ・ユーザーは別のデータベースへのデータベース・リンクでこの制限に対処できますが、ロジカル・スタンバイは、追加の手順なしで読取り/書込みアクセスを有効にできます。Oracle Data Guard によって保護されているロジカル・スタンバイ表は、プライマリ・データベース以外の物理レイアウトに保存できるため、追加索引やマテリアライズド・ビューを作成して、問合せパフォーマンスを向上させ、具体的なビジネス要件に適合できます。 • ロジカル・スタンバイ・データベースは、データ・ウェアハウス・アプリケー

ション、意思決定支援、データ・マートの移入に使用されるデータのステージングと処理に使用できます。Oracle Data Guard 構成で保護されるデータベース・スキーマに加え、ロジカル・スタンバイはその他のデータベース・スキーマをホストでき、ユーザーはそうしたスキーマで、いつでも DDL オペレーションや DML オペレーションを実行できます。 • ロジカル・スタンバイで開始されるローリング・データベース・アップグレードは、アップグレードを実行するためにフィジカル・スタンバイを一時ロジカル・スタンバイに変換するローリング・アップグレードよりも少ない手順で済みます。

Oracle Data Guard 構成の管理

システム・ビュー。Oracle Data Guardは、さまざまなビューを提供し、Oracle Data Guard構成のランタイム・パフォーマンスを詳細に監視します。これらのビューには、SQL*Plus、Oracle Data Guard Broker、またはOracle Enterprise Manager Grid Controlからアクセスできます。 NEW! 本番環境のデータに基づいてNET_ TIMEOUTの最適な値をユーザーに提供す る応答時間のヒストグラム たとえば、V$REDO_DEST_RESP_HISTOGRAMは、SYNC REDO転送の宛先の応答時間のヒストグラムを含む固定ビューです。このビューのデータは、同期の宛先に使用されるネットワーク・タイムアウト属性の適切な値を決定する際に非常に役立ちます。最大可用性モードで使用されるLOG_ARCHIVE_DEST_n NET_TIMEOUT属性では、離れた宛先を放棄してログ・ライターを続行する前にLNSの確認応答をログ・ライターが待機する最長期間を指定します。非常に小さい値を設定すると、頻繁にタイムアウトが発生して、データ保護レベルが低下する可能性があります。

(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 構成にある各データベースのステータスが示されます。

(22)

• 発生したファスト・スタート・フェイルオーバー - ファスト・スタート・フェイルオーバーが有効に設定されていて、ファスト・スタート・フェイルオーバーが発生すると、このメトリックによって新しいプライマリ・データベース（旧スタンバイ・データベース）に重要なアラートが発信されます。 • ファスト・スタート・フェイルオーバー時間 - ファスト・スタート・フェイルオーバーが有効に設定されていて、ファスト・スタート・フェイルオーバーが発生すると、このメトリックによって新しいプライマリ・データベース（旧スタンバイ・データベース）に重要なアラートが発信され、発生のタイムスタンプが表示されます。

図4 - Oracle Enterprise ManagerのOracle Data Guardホームページ

ロール管理サービス

Oracle Data Guard ロール管理サービスは、本番サイトの計画停止（スイッチオーバー）と計画外停止（フェイルオーバー）のために指定されたスタンバイ・データベースを本番ロールに素早く移行します。また、ロール管理サービスによって、障害時リカバリ準備のテストが非常に簡単になります。 スイッチオーバー スイッチオーバーは、オペレーティング・システムやハードウェアのアップグレード、Oracle データベース・ソフトウェアおよびパッチセットのローリング・アップグレードなどの計画停止で、プライマリ・データベースの停止時間を短縮するために使用します。スイッチオーバーを実行するには、プライマリ・データベースからすべてのユーザー・セッションを切断する必要があります。その後、プライマリ・データベースはスタンバイ・ロールに移行し、スタンバイ・データベースがプライマリ・ロー