2 Data Guardの概説

Data Guard構成には、1つのプライマリ・データベースと、それに関連付けられた最大30個のスタンバイ・データベースが含まれます。この章では、Data Guardの使用を開始するための次の考慮事項について説明します。

スタンバイ・データベースのタイプ
Data Guard構成の管理のためのユーザー・インタフェース
Data Guardの動作要件
スタンバイ・データベースのディレクトリ構造に関する考慮事項

2.1 スタンバイ・データベースのタイプ

スタンバイ・データベースは、Oracle本番データベースのトランザクション一貫性のあるコピーで、最初はプライマリ・データベースのバックアップ・コピーから作成されます。スタンバイ・データベースが作成および構成されると、Data Guardは、プライマリ・データベースのREDOデータをスタンバイ・システムに転送し、スタンバイ・データベースに適用することによって、スタンバイ・データベースを自動的にメンテナンスします。

スタンバイ・データベースのタイプには、フィジカル・スタンバイ・データベース、ロジカル・スタンバイ・データベース、スナップショット・スタンバイ・データベースがあります。フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースは、必要に応じてプライマリ・データベースのロールを担い、本番処理を引き継ぐことができます。Data Guard構成には、これらのタイプのスタンバイ・データベースを任意に組み合せて含めることができます。

2.1.1 フィジカル・スタンバイ・データベース

フィジカル・スタンバイ・データベースはプライマリ・データベースを正確に、ブロックごとにコピーしたものです。フィジカル・スタンバイはREDO Applyと呼ばれるプロセスによって正確なコピーとして維持されます。このプロセスではデータベース・リカバリ・メカニズムを使用して、プライマリ・データベースから受信したREDOデータを継続的にフィジカル・スタンバイ・データベースに適用します。

フィジカル・スタンバイ・データベースは、読取り専用アクセス用にオープンし、問合せをプライマリ・データベースからオフロードするために使用できます。 Oracle Active Data Guardオプションのライセンスを購入している場合は、フィジカル・スタンバイ・データベースを開いている間はRedo Applyをアクティブにすることができます。それにより、問合せによって、プライマリ・データベースからのものと同じ結果が得られます。この機能は、リアルタイム問合せ機能と呼ばれます。

2.1.2 ロジカル・スタンバイ・データベース

ロジカル・スタンバイ・データベースは、最初はプライマリ・データベースと同じ内容のコピーで作成されますが、後で異なる構造に変更できます。ロジカル・スタンバイ・データベースは、SQL文を実行して更新されます。これにより、ユーザーは問合せとレポート生成の目的で、スタンバイ・データベースにいつでもアクセスできます。このように、ロジカル・スタンバイ・データベースは、データ保護操作とレポート生成操作に同時に使用できます。

Data Guardは、ログ・ファイルのデータをSQL文に変換し、ロジカル・スタンバイ・データベースでそのSQL文を実行することによって、アーカイブREDOログ・ファイルまたはスタンバイREDOログ・ファイルの情報をロジカル・スタンバイ・データベースに自動的に適用します。ロジカル・スタンバイ・データベースはSQL文を使用して更新されるため、オープン状態のままであることが必要です。ロジカル・スタンバイ・データベースは読取り/書込みモードでオープンされますが、再生成されたSQLに対するターゲット表は、読取り専用操作用にのみ使用可能です。更新中、これらの表は、レポート生成、要約、問合せなどの他のタスクで同時に使用できます。さらに、これらのタスクは、メンテナンスされている表に追加の索引やマテリアライズド・ビューを作成することによって最適化できます。

ロジカル・スタンバイ・データベースには、データ型、表のタイプ、DDL操作およびDML操作のタイプに関していくつかの制限があります。ロジカル・スタンバイ・データベースのデータ型およびDDLのサポートの詳細は、付録Cを参照してください。

ロジカル・スタンバイ・データベースのメリット

ロジカル・スタンバイ・データベースは、データ・リカバリ(DR)のメリットとともに高可用性(HA)を提供するには理想的です。フィジカル・スタンバイ・データベースと比較して、ロジカル・スタンバイ・データベースは、さらに次の重要なHAのメリットを提供します。

別の種類の障害からの保護

ロジカル・スタンバイはREDOを分析してデータベースに対する論理的な変更を再構成するため、ブロック・レベルの変更を介してレプリケートされる可能性がある、プライマリでの特定の種類のハードウェア障害を検出し、それから保護することができます。Oracleでは、同じプライマリ・サーバーに対してフィジカル・スタンバイとロジカル・スタンバイの両方を保持できます。
リソースの効率的な使用

プライマリ上の変更をレプリケートしている間は、ロジカル・スタンバイ・データベースは読取り/書込み用にオープン状態になります。その結果、ロジカル・スタンバイ・データベースはその他のビジネス要件を満たすために、同時に使用することができます。たとえば、レポート・ワークロードを実行することができますが、プライマリのスループットが低下します。プライマリ・データの完全で正確なコピーに対して、新しいソフトウェア・リリースや特定の種類のアプリケーションをテストするために使用することができます。プライマリからレプリケートされたデータをローカルな変更から保護しながら、他のアプリケーションおよび追加のスキーマをホストすることができます。特定の物理的な再構築(たとえばパーティショニング・スキームの変更など)による影響の判定に使用することができます。ロジカル・スタンバイはユーザー・トランザクションを識別し、バックグラウンドでのシステム変更をフィルタ処理しながら該当する変更だけをレプリケートするので、対象となるトランザクションだけを効率よくレプリケートすることができます。
ワークロードの分散

ロジカル・スタンバイは、ワークロードの分散に使用可能な、最新で一貫性のあるプライマリ・データベースのレプリカを作成することができる、シンプルなターンキー・ソリューションを提供します。レポート・ワークロードの増加に伴い、透過的ロード分散によって、プライマリ・サーバーのトランザクション・スループットには影響を及ぼすことなく、追加のロジカル・スタンバイを作成できます。
レポート生成要件および意思決定支援要件のための最適化

ロジカル・スタンバイの主な利点は、レポート作成のワークロードを最適化する重要な補助構造(プライマリのトランザクション・レスポンス時間に対する抑制効果をもたらす構造)を作成できることです。ロジカル・スタンバイは、そのデータをパーティショニングの異なる各種ストレージに物理的に再構成し、多数の異なる索引を付けて、オンデマンド・リフレッシュ・マテリアライズド・ビューを作成および維持することができます。また、データ・キューブおよびその他のOLAPデータ・ビューの作成促進に使用することができます。
ソフトウェア・アップグレード時の停止時間の最短化

ロジカル・スタンバイを使用すると、パッチ・セットやソフトウェアの新しいリリースの適用に関連する停止時間を大幅に短縮できます。ロジカル・スタンバイは、新しいリリースへのアップブレード後に切り替えて、アクティブなプライマリにすることができます。これにより、古いプライマリをロジカル・スタンバイに変換してパッチ・セットを適用する間、完全な可用性を可能にします。

2.1.3 スナップショット・スタンバイ・データベース

スナップショット・スタンバイ・データベースは、プライマリ・データベースに完全なデータ保護を提供するタイプの更新可能なスタンバイ・データベースです。スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信およびアーカイブしますが、適用はしません。プライマリ・データベースから受信したREDOデータは、スナップショット・スタンバイ・データベースへのローカル更新がすべて破棄された後、スナップショット・スタンバイ・データベースが変換されてフィジカル・スタンバイ・データベースに戻ると適用されます。

プライマリ・データベースのREDOデータは受信と同時には適用されないので、スナップショット・スタンバイ・データベースは通常、時間の経過とともにプライマリ・データベースとの差異が生じます。スナップショット・スタンバイ・データベースのローカルな更新によって差異が増えます。ただし、スナップショット・スタンバイはいつでもフィジカル・スタンバイ・データベースに戻すことができ、その後プライマリから受信したREDOデータを適用できるので、プライマリ・データベース内のデータは完全に保護されています。

スナップショット・スタンバイ・データベースのメリット

スナップショット・スタンバイ・データベースは、全面的に更新可能なスタンバイ・データベースで、フィジカル・スタンバイ・データベースと同様の、障害時リカバリおよびデータ保護のメリットがあります。スナップショット・スタンバイ・データベースは、プライマリ・データベースの障害からリカバリする時間が増えても、プライマリ・データベースの一時的かつ更新可能なスナップショットを保持するメリットがある場合に最もよく使用されます。

スナップショット・スタンバイ・データベースの使用には、次のメリットがあります。

常にデータ保護を維持しながら、開発およびテスト用に本番データベースの正確なレプリカを提供します。
フィジカル・スタンバイに変換して再同期化することで、現行の本番データが格納されるように簡単にリフレッシュできます。

スナップショット・スタンバイの作成、テスト、本番環境との再同期化に続いて、再びスナップショット・スタンバイの作成およびテストを実行できることは、必要に応じて何度も繰り返すことができる1サイクルです。同じプロセスを使用して、データへの読取り/書込みアクセスが必要なレポート生成用にスナップショット・スタンバイを簡単に作成し、定期的に更新できます。

2.2 Data Guard構成の管理のためのユーザー・インタフェース

Data Guard構成の構成、実装および管理には、次のインタフェースを使用できます。

Oracle Enterprise Manager

Enterprise Managerでは、Data Guard環境の作成、構成および監視に関係するタスクの多くを自動化する、Data Guard BrokerのGUIインタフェースが用意されています。GUIとそのウィザードの詳細は、『Oracle Data Guard Broker』およびOracle Enterprise Managerのオンライン・ヘルプを参照してください。
SQL*Plusコマンドライン・インタフェース

いくつかのSQL*Plus文では、STANDBYキーワードを使用して、スタンバイ・データベースに対する操作を指定します。他のSQL文にはスタンバイ固有の構文はありませんが、スタンバイ・データベースで操作を実行するときに役立ちます。関連する文のリストは、第16章を参照してください。
初期化パラメータ

Data Guard環境の定義には、いくつかの初期化パラメータが使用されます。関連する初期化パラメータのリストは、第14章を参照してください。

Data Guard Brokerコマンドライン・インタフェース(DGMGRL)

DGMGRLコマンドライン・インタフェースは、Enterprise Managerの代替手段です。DGMGRLコマンドライン・インタフェースは、ブローカを使用してバッチ・プログラムまたはスクリプトからData Guard構成を管理する場合に役立ちます。完全な情報は、『Oracle Data Guard Broker』を参照してください。

2.3 Data Guardの動作要件

次の各項で、Data Guard使用時の動作要件を説明します。

ハードウェアおよびオペレーティング・システムの要件
Oracleソフトウェア要件

2.3.1 ハードウェアおよびオペレーティング・システムの要件

Oracle Database 11gから、Data GuardではData Guard構成の柔軟性が高まり、プライマリ・システムとスタンバイ・システムで、異なるCPUアーキテクチャ、オペレーティング・システム(たとえばWindowsとLinux)、オペレーティング・システムのバイナリ(32-bit/64-bit)、またはOracleデータベースのバイナリ(32-bit/64-bit)を使用できるようになりました。

プラットフォームの混在について向上した柔軟性は、http://support.oracle.comにあるMy Oracle SupportのNote 413484.1および1085687.1で記述されている現行の制限事項の対象となります。

Note 413484.1では、フィジカル・スタンバイに対するプラットフォーム混在のサポートおよび制限事項について説明しています。

Note 1085687.1では、ロジカル・スタンバイに対するプラットフォーム混在のサポートおよび制限事項について説明しています。

同じリリースのOracle Database Enterprise Editionをプライマリ・データベースおよびすべてのスタンバイ・データベースにインストールする必要があります。ただし、ロジカル・スタンバイ・データベースを使用したローリング・データベース・アップグレード時を除きます。

2.3.2 Oracleソフトウェア要件

次のリストに、Data Guard使用時の Oracleソフトウェア要件を示します。

Oracle Data Guardは、Oracle Database Enterprise Editionの専用機能として提供されています。Oracle Database Standard Editionには提供されていません。

注意:

Oracle Database Standard Editionを実行しているデータベースでは、スタンバイ・データベース環境を再現することが可能です。これを行うには、オペレーティング・システムのコピー・ユーティリティ、または定期的にアーカイブREDOログ・ファイルをデータベースからデータベースに送信するカスタム・スクリプトを使用して、手動でアーカイブREDOログ・ファイルを転送します。したがって、この構成では、Data Guardによって提供される利便性、管理性、パフォーマンスおよび障害時リカバリ機能を得られません。

Data Guard SQL Applyを使用して、Oracle Databaseソフトウェアをパッチ・セット・リリースn(10.1.0.3以上)から上位バージョンのパッチ・セットまたはメジャー・バージョン・リリースにローリング・アップグレードできます。ローリング・アップグレード時には、プライマリ・データベースおよびロジカル・スタンバイ・データベースを1つずつアップグレードする間、異なるリリースのOracle Databaseを実行できます。詳細は、第12章「SQL Applyを使用したOracle Databaseのアップグレード」および該当するOracle Database 10gパッチ・セット・リリースのREADMEファイルを参照してください。
Data Guard構成のすべてのデータベースで、COMPATIBLE初期化パラメータを同じ値に設定する必要があります。ただし、ロジカル・スタンバイ・データベースは例外で、プライマリ・データベースよりもCOMPATIBLEの設定値を大きくできます。
Oracle8iデータベース・ソフトウェア上でOracle Data Guardを実行している場合のOracle Data Guard 11gへのアップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

プライマリ・データベースは ARCHIVELOGモードで実行する必要があります。詳細は、『Oracle Database管理者ガイド』を参照してください。
プライマリ・データベースは、単一インスタンス・データベースまたはOracle Real Application Clusters(Oracle RAC)データベースのいずれかです。スタンバイ・データベースは、単一インスタンス・データベースまたはOracle RACデータベースで、フィジカル・タイプ、ロジカル・タイプおよびスナップショット・タイプを組み合せることができます。Oracle Data GuardをOracle RACとともに構成および使用する方法の詳細は、『Oracle Database高可用性概要』を参照してください。
プライマリ・データベースとスタンバイ・データベースには、それぞれ独自の制御ファイルが必要です。
スタンバイ・データベースがプライマリ・データベースと同じシステムにある場合、スタンバイ・データベースのアーカイブ・ディレクトリは、プライマリ・データベースとは異なるディレクトリ構造を使用する必要があります。同じ構造を使用すると、スタンバイ・データベースがプライマリ・データベース・ファイルを上書きする可能性があります。
プライマリ・データベースに対して、ログに記録されず、スタンバイ・データベースに伝播できないダイレクト書込みが行われるのを防ぐには、プライマリ・データベースでFORCE LOGGINGをオンにした後で、スタンバイ作成用にデータファイルのバックアップを実行します。スタンバイ・データベースが必要な間は、データベースをFORCE LOGGINGモードに保持してください。
プライマリ・データベースとスタンバイ・データベースのインスタンスの管理に使用するユーザー・アカウントには、SYSDBAシステム権限が必要です。

動作を簡略化するために、Oracle Automatic Storage Management(Oracle ASM)およびOracle Managed Files(OMF)をData Guard構成で設定する際は、プライマリおよびスタンバイ・データベースに対称的に設定することをお薦めします。つまり、移行やメンテナンス用に意図的に混合構成を実装する場合を除き、Data Guard構成のいずれかのデータベースでOracle ASM、OMF、またはその両方を使用する場合は、構成内のすべてのデータベースでもそれぞれOracle ASM、OMFまたはその両方を使用する必要があります。詳細は、13.5項の使用例を参照してください。

注意:

更新の際に時間ベースのデータが使用される一部のアプリケーションでは、複数のタイムゾーンで入力されたデータを処理できないため、ロールの推移後もレコードの時間的順序が維持されるよう、プライマリおよびリモート・スタンバイ・システムに同じタイムゾーンを設定することをお薦めします。

2.4 スタンバイ・データベースのディレクトリ構造に関する考慮事項

各種スタンバイ・データベースのディレクトリ構造によってスタンバイ・データファイル、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイルのパス名が決まるため、ディレクトリ構造は重要です。可能であれば、プライマリ・システムとスタンバイ・システムでデータファイル、ログ・ファイルおよび制御ファイルの名前およびパス名を同一にし、Optimal Flexible Architecture(OFA)のネーミング規則を使用する必要があります。スタンバイ・データベースのアーカイブ・ディレクトリも、サイズおよび構造を含めてサイト間で同一であることが必要です。この方法により、バックアップ、スイッチオーバーおよびフェイルオーバーなどの他の操作を同じ手順で実行できるようになり、メンテナンスの複雑さが軽減されます。

スタンバイ・システム	ディレクトリ構造	結果的な注意事項
プライマリ・システムと同じ	プライマリ・システムと異なる(必須)	ファイル名を手動で変更するか、スタンバイ・データベースで `DB_FILE_NAME_CONVERT`初期化パラメータおよび`LOG_FILE_NAME_CONVERT`初期化パラメータを設定すると、スタンバイ・データベース制御ファイル内のプライマリ・データベースのデータファイル、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイルのパス名を自動的に更新できます。(3.1.4項を参照)。スタンバイ・データベースは、プライマリ・データベースとスタンバイ・データベースが存在しているシステムを破壊するような障害に対する保護には役立ちませんが、計画的なメンテナンスに対するスイッチオーバー機能は提供します。
離れたシステム	プライマリ・システムと同じ	スタンバイ・データベース制御ファイル内のプライマリ・データベースのファイル名、アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイル名を変更する必要はありません。ただし、新しいネーミング計画が必要な場合(複数のディスクにファイルを分散する場合など)は、変更しても構いません。スタンバイ・データベースを別の物理メディアに置くことにより、プライマリ・システムを破壊するような障害からプライマリ・データベースのデータを保護できます。
離れたシステム	プライマリ・システムと異なる	ファイル名を手動で変更するか、またはスタンバイ・データベースで`DB_FILE_NAME_CONVERT`初期化パラメータおよび`LOG_FILE_NAME_CONVERT`初期化パラメータを設定すると、データファイル名を自動的に変更できます(3.1.4項を参照)。スタンバイ・データベースを別の物理メディアに置くことにより、プライマリ・システムを破壊するような障害からプライマリ・データベースのデータを保護できます。