E カスケードされた宛先

プライマリ・システムの負荷を軽減するため、あるいはWide Area Network（WAN）を介してスタンバイ・データベースとプライマリ・データベースが分散している場合の帯域幅の要件を緩和するために、カスケードされた宛先を実装できます。これにより、スタンバイ・データベースは、REDOデータをプライマリ・データベースから直接受信するのではなく、別のスタンバイ・データベースから受信します。

カスケードされた宛先を使用するData Guard構成では、フィジカル・スタンバイ・データベースはプライマリ・データベースから受信したREDOデータを別のスタンバイ・データベースに転送できます。REDOデータを別のスタンバイ・データベースに転送するように構成できるのは、フィジカル・スタンバイ・データベースのみです。ロジカル・スタンバイ・データベースは、REDOを別のスタンバイ・データベースに転送できません。

注意
プライマリ・データベースがOracle Real Application Clusters（RAC）環境またはData Guard Broker環境の一部である場合は、REDOを転送するようにフィジカル・スタンバイを設定できません。

カスケードされた宛先を使用する次のData Guard構成がサポートされます。

プライマリ・データベース→カスケードされた宛先が定義されているフィジカル・スタンバイ・データベース→フィジカル・スタンバイ・データベース
プライマリ・データベース→カスケードされた宛先が定義されているフィジカル・スタンバイ・データベース→ロジカル・スタンバイ・データベース

フィジカル・スタンバイ・データベースでは、最大9個のリモート宛先をサポートできます。フィジカル・スタンバイ・データベースでカスケードされた宛先を定義すると、フィジカル・スタンバイは、スタンバイREDOログがいっぱいになってアーカイブされた後に、プライマリから受信したREDOを2つ目のスタンバイ・データベースに転送します。そのため、カスケードされた宛先の結果として転送されたREDOを受信する2つ目のスタンバイ・データベースは、必然的にプライマリ・データベースから遅れます。カスケードされた宛先は、プライマリ・システムからまったく遅れていないデータにアクセスする必要がないオフロードのレポート生成やアプリケーションにのみ使用することをお薦めします。これは、カスケードされた宛先の性質そのものが、エンド・ポイントであるスタンバイ・データベースがプライマリ・データベースから遅れている1つ以上のログ・ファイルであるということを意味するためです。また、プライマリ・ロールがロールの推移の対象となるスタンバイ・データベースは、REDOデータをプライマリ・データベースから直接受信することをお薦めします。

この付録では、次の情報を示します。

E.1 カスケードされた宛先の構成

フィジカル・スタンバイ・データベースを有効にして着信REDOデータをカスケードされた宛先に転送するには、次の手順を実行します。

フィジカル・スタンバイ・データベースでスタンバイREDOログ・ファイルを作成します（未作成の場合）。
スタンバイREDOログ・ファイルが未定義の場合は、スタンバイ・データベースで動的に定義できます。スタンバイ・データベースは、プライマリ・データベースで次回ログ・スイッチが発生した後に、スタンバイREDOログ・ファイルの使用を開始します。
プライマリ・データベースでLOG_ARCHIVE_DEST_n初期化パラメータを定義して、REDOをカスケードされた宛先に転送するフィジカル・スタンバイ・データベースを設定します。次の属性を使用する宛先を定義します。
- ASYNCまたはSYNC
- 必要に応じて、元のプライマリ・データベースとREDOを転送する中間スタンバイ・データベース間でロールの推移が発生した後でもREDO転送が有効であるように、VALID_FOR属性を設定します。この設定は、データベースがWide Area Network上に分散している場合に意味があります。
カスケードされた宛先が定義されているフィジカル・スタンバイ・データベース（REDOを転送するスタンバイ・データベース）でアーカイブが有効であることを確認します。
カスケードされた宛先ごとに（REDOデータを転送するフィジカル・スタンバイで）LOG_ARCHIVE_DEST_nパラメータを構成します。

例E-1に、Bostonというプライマリ・データベースの初期化パラメータを示します。BostonデータベースはChicagoというフィジカル・スタンバイ・データベースにREDOを送信し、ChicagoデータベースはDenverというカスケードされたスタンバイ・データベースに受信したREDOを転送します。この例では、Denverデータベースはロジカル・スタンバイ・データベースですが、フィジカル・スタンバイ・データベースは、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースのいずれにもREDOを転送できることに注意してください。

注意
カスケードされた宛先がロジカル・スタンバイ・データベースである場合、ロジカル・スタンバイがプライマリ・データベースに直接接続されるかのように作成することに注意してください。詳細は、第4章「ロジカル・スタンバイ・データベースの作成」を参照してください。

例E-1 カスケードされた宛先での初期化パラメータの使用例

Bostonデータベース（プライマリ・ロール）

DB_UNIQUE_NAME=boston
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
 
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston,denver)'
 
LOG_ARCHIVE_DEST_1='LOCATION=/arch1/boston/ VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE) 

DB_UNIQUE_NAME=boston'
 
LOG_ARCHIVE_DEST_2= 'SERVICE=denver  VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)  

DB_UNIQUE_NAME=denver'
 
LOG_ARCHIVE_DEST_3=  'SERVICE=chicago  VALID_FOR=  (ONLINE_LOGFILES,PRIMARY_ROLE)  

DB_UNIQUE_NAME=chicago'

Chicagoデータベース（スタンバイ・ロール）

DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(chicago,boston,denver)'
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
 
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/chicago/  VALID_FOR=(ALL_LOGFILES,ALL_ROLES)   
DB_UNIQUE_NAME=chicago'
 
LOG_ARCHIVE_DEST_2= 'SERVICE=denver  VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)  

DB_UNIQUE_NAME=denver'
 
LOG_ARCHIVE_DEST_3=  'SERVICE=boston  VALID_FOR=  (ONLINE_LOGFILES,PRIMARY_ROLE)  

DB_UNIQUE_NAME=boston'

Denverデータベース（スタンバイ・ロール）

DB_UNIQUE_NAME=denver
LOG_ARCHIVE_CONFIG= 'DG_CONFIG=(chicago,boston,denver)'
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
 
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/denver/  VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)   
DB_UNIQUE_NAME=denver'
 
LOG_ARCHIVE_DEST_2= 'LOCATION=/arch2/denver/  VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)  
DB_UNIQUE_NAME=denver'

Bostonプライマリ・データベースおよびChicagoフィジカル・スタンバイ・データベースでは、LOG_ARCHIVE_DEST_2初期化パラメータをSERVICE=denver VALID_FOR=(STANDBY_LOGFILES, STANDBY_ROLE)として定義しています。そのため、BostonデータベースとChicagoデータベースでロールが切り替えられても、REDOデータはDenverデータベースに引き続き転送されます。フィジカル・スタンバイ・データベースの元の設定の一部として、フィジカル・スタンバイ・データベースがプライマリ・ロールに推移した際にローカル・アーカイブに使用する、ローカルの宛先VALID_FOR=(ALL_LOGFILES, PRIMARY_ROLE)を定義する必要があることに注意してください。

E.2 カスケードされた宛先を使用したロールの推移

障害時リカバリを主目的とするスタンバイ・データベースでは、REDOデータをプライマリ・データベースから直接受信することをお薦めします。これは、最高レベルのデータ保護となります。カスケードされた宛先は、第2防御ラインとして利用できますが、本質的にREDOをプライマリから直接受信するスタンバイ・データベースより常に大幅に遅れます。

E.3 カスケードされた宛先の使用例

この項では、次の使用例について説明します。各使用例では、カスケードされた宛先の構成オプションとその使用方法を示します。

E.3.1 フィジカル・スタンバイによるリモート・フィジカル・スタンバイへのREDOの転送

会社のオフィスにプライマリ・データベースがあり、首都圏内の別の施設にスタンバイ・データベースを作成して、プライマリ・サイトで障害が発生した場合にデータ消失がないように保護するとします。ローカル・スタンバイに加えて、地理的に2000マイル離れた障害リカバリ・サイトにリモート・スタンバイ・データベースを保持するとします。リモート・スタンバイへのフェイルオーバーが必要な場合、少量のデータ消失は許容できます（大規模な地理的領域に影響を与える可能性があり、プライマリ・サイトとローカル・スタンバイ・データベースの両方に障害が発生する原因となるイベントに対する特別な保護と引き換えに許容できる交換条件です）。また、リモート・スタンバイ・データベースは、ローカル・スタンバイ・データベースへのフェイルオーバー後も引き続きデータ保護を提供し、バックアップを離れた場所に作成して格納できるようにしてオフサイトにテープを発送する必要をなくし、セキュリティを向上させます。

プライマリ・データベースは、REDOを両方のスタンバイ・データベースに直接送信するように構成できますが、WANを介してREDOを2つ目のスタンバイ・データベースに送信するプライマリ・データベースの潜在的なオーバーヘッドをなくす必要があります。この問題は、1つ目のフィジカル・スタンバイを首都圏内のローカル施設に作成し、SYNCネットワーク・トランスポートを使用してデータ消失がないように保護することで解決します。カスケードされた宛先は、ASYNCネットワーク転送を使用して、プライマリから受信したREDOをリモート・スタンバイ・データベースに転送するローカル・フィジカル・スタンバイ・データベースで定義します。これは、ローカル・スタンバイでカスケードされた宛先によるリモート・スタンバイとの通信をすべて管理するためで、プライマリ・データベースには、2つ目のスタンバイの保持による影響はまったくありません。

E.3.2 フィジカル・スタンバイによるローカル・スタンバイへのREDOの転送

この使用例では、米国の都市にプライマリ・データベースがあり、ヨーロッパの3つの異なる工業プラントに、エンドユーザーの問合せやレポート生成に使用するために、このデータベースの3つの完全なレプリカをデプロイするとします。目的は、ヨーロッパのユーザーおよびアプリケーションが米国にあるデータにアクセスする必要をなくし、ネットワークの分断によってデータがローカル・アクセスできなくなるを防ぐことです。プライマリで行われる更新の時期とその更新を3つのヨーロッパ・サイト全部にレプリケートする時期の間に多少の待機時間があることは許容できますが、データはできるだけ最新の状態にして問合せやレポート生成の実行に使用できるようにする必要があります。アプリケーションには完全に透過的で、必要に応じてヨーロッパのサイトにレプリカを追加デプロイできる解決策が必要です。最後の要件は、米国とヨーロッパの施設間で、帯域幅が制限され、ネットワーク待機時間が非常に長いネットワーク接続を使用して、この作業を実行する必要があるということです。

これらの要件に対処するため、まず、米国にあるプライマリ・データベース用のフィジカル・スタンバイ・データベースをヨーロッパに作成します。次に、各ヨーロッパ・プラントに1つずつ、計3つのロジカル・スタンバイ・データベースを作成し、各ロジカル・スタンバイをカスケードされた宛先としてフィジカル・スタンバイ・データベースに定義します。REDOのコピーの1つが、大西洋を隔てたリンクを介して米国からヨーロッパのフィジカル・スタンバイに送信されます。ヨーロッパのフィジカル・スタンバイは、ヨーロッパの工業プラントにある3つのロジカル・スタンバイ・データベースにREDOを転送し、エンドユーザーの問合せやレポート生成のために企業データにローカル・アクセスできるようにします。今後の成長のための余地は組み込まれています。追加のスタンバイ・データベースは、アプリケーションの変更、プライマリ・システムでの追加オーバーヘッド、大西洋を隔てた帯域幅の追加消費を必要とせずにヨーロッパにデプロイできます。

フィジカル・スタンバイ・データベースは、前述の例のように、各工業サイトにあるロジカル・スタンバイ・データベースにREDOデータを転送するように構成します。例E-1のパラメータとの唯一の相違点は、2つのLOG_ARCHIVE_DEST_nパラメータをフィジカル・スタンバイに追加定義して、REDOが3つのロジカル・スタンバイ・データベースすべてに転送されるようにしていることです。