1. No category

Oracleホワイト・ペーパー
2014年3月
Oracle Data Guard Broker
Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を構成するための
ベスト・プラクティス
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
はじめに ......................................................................................................................................................1
ブローカREDO転送構成プロパティ........................................................................................................3
REDO転送の変更の計画 ............................................................................................................................4
例1： プライマリ・データベースとスタンバイ・データベース .....................................................5
例2： 基本的なActive Data Guard Far Sync構成 ................................................................................6
例3： より高度なFar Sync構成 ..............................................................................................................8
例4： 基本的なカスケード接続されたフィジカル・スタンバイ構成 .............................................9
例5： より高度なカスケード接続された構成 .................................................................................. 11
結論............................................................................................................................................................ 12
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
はじめに
Oracle Database 12cのOracle Data Guard Brokerでは、高度な高可用性およびディザスタ・リカバリ
環境の管理と構成を自動化するいくつかの新機能が導入されています。
•
カスケード接続されたREDO転送（Active Data Guardリアルタイム・カスケードを含む）は、
ブローカで管理されたフィジカル・スタンバイ構成でサポートされます。
•
Active Data Guard Far Syncを使用すると、REDO転送の処理をプライマリ・データベースか
らオフロードできるだけでなく、標準的なSYNC転送の距離をはるかに超えた場所に配置さ
れたリモート・スタンバイ・データベースへのデータ損失ゼロのフェイルオーバーが可能に
なります。
•
高度な環境のREDO転送構成を容易にする新しいData Guard Brokerプロパティ、RedoRoutes
が提供されます。
このホワイト・ペーパーでは、Data Guard BrokerのDGMGRLコマンドを示す例と、これらの新機能
を使用するさまざまなActive Data Guard構成を管理および構成するために使用するベスト・プラク
ティスについて説明します。
初めて作成されたData Guard Broker構成は、最大パフォーマンスのデータ保護モードにデフォルト
設定されており、プライマリ・データベースはASYNC転送を使用して各構成メンバーにREDOを送信
します。以下の例は、この初期のデフォルト構成で始まり、データ損失ゼロの最大可用性データ保
護モードに変換するために必要なDGMGRLコマンドを示しています。例のいくつかには、Active Data
Guard Far SyncまたはActive Data Guardリアルタイム・カスケードが組み込まれています（リアルタ
イム・カスケードでは、スタンバイ・データベースがREDOを受信したらすぐに、非同期REDO転送
を使用してそのREDOを他のスタンバイ・データベースに直接転送できます）。すべての例において、
Data Guard Brokerのプロパティは、Data Guardのロール移行の後、どのデータベースがプライマリ・
ロールで動作しているか（スイッチオーバーまたはフェイルオーバー）には関係なく、望ましいREDO
転送方法が確実に利用されるように構成されています。ブローカがロール移行の後に、指定された
プロパティ値をどのように使用してREDO転送を自動的に再構成するかを理解してもらうために、1
つまたは複数のスイッチオーバーの後の構成を示した例も含まれています。
1
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
関連する背景情報または技術情報を提供するために、このホワイト・ペーパーの一部にはOracle Data
Guard 12cのドキュメントの内容が含まれています。Oracle Data Guard Broker構成を構成および管理
する方法や、スタンバイ・データベースとFar Syncインスタンスを初めて
作成および構成する方法について詳しくは、Oracle Technology Networkから入手できるOracle Data
Guard 12cのドキュメントを参照してください。 1
本番デプロイメントには追加の構成手順が必要になる可能性があることに注意してください。Oracle
Data Guardのドキュメントに加えて、Oracle Maximum Availability Architecture（Oracle MAA）は、
Oracleデータベースの高可用性およびディザスタ・リカバリ環境をデプロイおよび保守するための追
加のベスト・プラクティスを提供します。 2
注： Active Data Guard Far Syncまたはリアルタイム・カスケードを使用するには、Active Data Guard
でプライマリ・データベースとスタンバイ・データベースが使用できる必要があります。
-------------------------------------------------1
Data Guardのドキュメント：
2
Oracle MAAのベスト・プラクティス：
http://www.oracle.com/technetwork/database/features/availability/data-guard-documentation-152848.html
http://www.oracle.com/technetwork/jp/database/features/availability/maa-094615-ja.html
2
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
ブローカREDO転送構成プロパティ
REDO転送サービスは、1つ以上のData Guard Broker構成プロパティに適切な値を設定することに
よって管理されます。これらのうち、もっとも一般的に使用されるプロパティは次のとおりです。
•
DGConnectIdentifier
•
LogXptMode
•
NetTimeout
•
RedoCompression
•
RedoRoutes（Oracle Database 12cの新機能）
•
ReopenSecs
実際のREDO転送構成は、LOG_ARCHIVE_DEST_n初期化パラメータに適切な値を設定し、他の構成
メンバーにREDOを送信する各構成メンバー上のブローカによって実行されます。ブローカREDO転
送プロパティの変更において、LOG_ARCHIVE_DEST_n初期化パラメータ属性を変更する必要がある
場合は、ブローカは、その新しい設定がただちに適用されるように各プライマリ・データベース・
スレッド上のログ・スイッチを強制します。将来のロール移行を容易にするために、RedoRoutes
プロパティをData Guard Broker構成のすべてのメンバーに対して事前に構成してください。
非常に単純な構成の場合、これらのプロパティのデフォルト値は適切です。このホワイト・ペーパー
の例は、さまざまな標準的な構成について、RedoRoutesプロパティに適切な値を割り当てる方法を
示しています。その他のブローカREDO転送プロパティに値を割り当てる方法については、Data
Guard Brokerのドキュメントを参照してください。
Oracle Database 11gのData Guard Brokerでは、REDO転送モード（SYNCまたはASYNC）は、REDOの
受信者（スタンバイ・データベース）でLogXptModeプロパティを設定することによって指定され
ます。ブローカは次に、この情報を使用して、REDOソース（プライマリ・データベース）で、指定
されたREDO転送モードを含むLOG_ARCHIVE_DEST_n初期化パラメータを構成します。
Oracle Database Release 12cのOracle Data Guard Brokerでは、すでにサポートされているSYNCと
ASYNCのREDO転送モードにFASTSYNCが追加され、複雑な構成でのREDO転送構成を容易にするた
めにRedoRoutesプロパティ値でこれらのモードを指定できるようになりました。RedoRoutesプ
ロパティは、他の構成メンバーにREDOを送信するロールで動作する可能性のあるいずれかの構成メ
ンバー（プライマリ・データベース、カスケード・フィジカル・スタンバイ、またはFar Syncインス
タンス）で設定されます。ブローカはこのRedoRoutesプロパティ値を使用して、これらの各構成
メンバーで、指定された宛先のREDO転送モードを含むLOG_ARCHIVE_DEST_n初期化パラメータを
構成します。LogXptModeとRedoRoutesの両方の値を設定することは可能ですが、目的のログ転
送モードが確実に実装されるようにするために、いずれか特定の構成内ではこれらの2つのプロパ
ティのうちの1つだけを使用することを推奨します。RedoRoutesプロパティでは、現在どのデータ
ベースがプライマリ・ロールにあるかに基づいてREDO転送モードを変更でき、REDO転送の構成方
法をよりきめ細かく制御できることから、Data Guard Broker 12cでのREDO転送構成に適した方法で
す。RedoRoutesプロパティで指定されたREDO転送モードが、LogXptModeプロパティに指定され
ている値より優先されることに注意してください。
3
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
RedoRoutesの有効な値は、(redo_source_1 : redo_destination_1) [, (redo_source_n :
redo_destination_n)]の形式をした、各ルールが1組の丸括弧で囲まれた1つ以上のREDOルー
ティング・ルールで構成される文字列です。REDOルーティング・ルールのREDOソース・フィール
ドには、キーワードLOCAL（ローカル・データベース名の別名）、またはDB_UNIQUE_NAME値のカ
ンマ区切りのリストが含まれている必要があります。LOCALキーワードをFar Syncインスタンスで使
用することはできません。また1つのデータベースを、明示的にも、またはLOCALキーワードを使用
して暗黙的にも、特定のデータベースで定義された複数のREDOルーティング・ルール内のREDOソー
スとして指定することはできません。REDO宛先フィールドには、キーワードALL（構成内の可能性
のあるすべての宛先の別名）またはDB_UNIQUE_NAME値のカンマ区切りのリストが含まれている必
要があります。この各値の後に、オプションのREDO転送モード属性（ASYNC、SYNC、またはFASTSYNC）
を指定できます。オプションのREDO転送属性が指定されていない場合、使用されるREDO転送モー
ドは、宛先のLogXptModeプロパティで指定されているモードになります（デフォルトはASYNC）。
次のその他の使用方法が適用されます。
•
RedoRoutesプロパティには、(LOCAL : ALL ASYNC)として処理されるNULLのデフォルト値が
あります。これは、プライマリ・データベースの場合は、構成のすべてのメンバーにREDOデータ
を送信することを意味します。
•
REDOルーティング・ルールは、そのREDOソース・フィールドに現在のプライマリ・データベー
スが含まれている場合にアクティブになります。ルールがアクティブである場合、プライマリ・
データベースのREDOは、アクティブなルールのREDO宛先フィールドで指定されている各宛先に
対してそのルールが定義されているデータベースによって送信されます。
•
ロール移行の後、各構成メンバーがアクティブなREDOルーティング・ルールに従うように、ブロー
カはLOG_ARCHIVE_DEST_n初期化パラメータを自動的に再構成します。
•
カスケード接続された宛先へのリアルタイム・カスケードを有効にするには、その宛先に対して
ASYNCのREDO転送属性を明示的に指定する必要があります。
•
ロジカル・スタンバイ・データベース（SQL Apply）またはスナップショット・スタンバイ・デー
タベースではRedoRoutesプロパティを設定できません。
•
一時ロジカル・スタンバイを使用してデータベース・ローリング・アップグレードを実行してい
る場合は、このプロセス中にブローカが一時的に無効になるため、データベース・ログ・アーカ
イブ宛先パラメータへの必要なすべての更新を手動で実行する必要があります。
注： 各例では、必要に応じてLOCALキーワードやALLキーワードを使用しています。これらのキー
ワードの代わりに特定のデータベースのDB_UNIQUE_NAME値を使用するなど、同じREDO転送構成
を実現するための代わりの方法が存在する可能性があります。
REDO転送の変更の計画
Data Guard BrokerのREDO転送に関連したさまざまな構成プロパティの値の変更によって、プライマ
リ・データベースから他の構成メンバーへのREDOのフローが一時的に中断される場合があります。
また、ロール移行を実行した直後にも同じことが言えます。これらのケースでは、古いREDO転送が
破棄され、新しいREDO転送が完全にアクティブになる途中に、構成の表示に一時的な警告やエ
ラー・メッセージが表示される可能性があります。
4
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
たとえば、以下の例では、ブローカのRedoRoutesプロパティに新しい値を設定した直後、またはス
イッチオーバーを実行した直後に、ブローカの構成ステータスに一時的に次のメッセージが1つまた
は複数含まれる場合があります。
ORA-16629：データベースは異なる保護モードにより異なる保護レベルをレポートします。
ORA-16687：このデータベースは、複数のソースからREDOデータを受信します。
ORA-16778：1つ以上のデータベースでREDO転送エラーが発生しました。
ORA-16857：スタンバイがREDOソースから切断されている時間が指定されたしきい値を超えています。
ORA-16858：REDOソースとの最後の通信時間を判別できませんでした。
これらのメッセージのいずれかが引き続き表示される場合は、REDO転送が正しく構成されているか
どうか確認してください。また、プライマリ・データベースからのREDOをできるだけリアルタイム
に近い速度ですべてのスタンバイ・データベースに送信して適用できるように、すべての構成メン
バーでスタンバイREDOログが正しく構成されていることも確認してください。
REDO転送の再構成中に何らかの一時的な中断が発生する可能性とその期間は、目的の変更を完了す
るために必要なコマンドの特定のシーケンスを事前に計画することによって最小限に抑えることが
できます。REDO転送の変更が実装されるシーケンスを実行する場合は、変更が行われている間、下
流のターゲットがREDOをまったく受信しない方法より、複数のソースからREDOを一時的に受信す
る方法の方が望ましいことに注意してください。
例1： プライマリ・データベースとスタンバイ・データベース
これは、プライマリ・データベースdb01とフィジカル・スタンバイ・データベースdb02で構成され
る、もっとも基本的なData Guard構成です。最大可用性保護モードの例を目的としているため、こ
の2つのデータベースが、ローカル・サイトとリモート・サイト間でSYNC REDO転送が動作可能なよ
うに配置されていることを前提にしています。
5
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
この例は、構成内の各データベースでLogXptModeプロパティをSYNCに設定した場合に相当します。
残りの例はRedoRoutesプロパティの値の設定を必要とし、LogXptModeプロパティだけを使用して
構成することはできないことに注意してください。
例2： 基本的なActive Data Guard Far Sync構成
Active Data Guard Far Syncでは、プライマリ・データベースからREDOを受け取った後、そのREDO
をData Guard構成の他のメンバーに送信する新しい種類のREDO宛先（Far Syncインスタンス）を使
用します。Far Syncインスタンスは、制御ファイル、スタンバイREDOログ・ファイル、およびアー
カイブ・ログ・ファイルだけで構成されています（データファイルやメディア・リカバリは存在し
ません）。Active Data Guard Far Syncを使用すると、プライマリ・データベースのパフォーマンス
がWANネットワークの待機時間に影響されることなく、数百または数千マイル離れた場所に配置さ
れたリモート・スタンバイ・データベースへのデータ損失ゼロのフェイルオーバーが可能になりま
す。また、Far SyncをOracle Advanced Compressionオプションと組み合わせて使用すると、プライ
マリ・データベースのパフォーマンスに影響を与えることなくオフ・ホストでのREDO転送圧縮も可
能になるため、WAN帯域幅が節約されます。
Far Syncインスタンスにはデータファイルがないため、プライマリ・ロールを引き継ぐことはできま
せん。この例のプライマリ・データベースとスタンバイ・データベースは、それぞれFar Syncインス
タンスの動作可能なSYNC REDO転送の範囲内に配置されていますが、これらのデータベース自体は
この距離以上離れています。1つのFar Syncを使用することで、これらのデータベースをSYNC転送が
動作可能な標準的な距離の最大で2倍まで離して配置しても、この構成のFar Syncインスタンスfs01
によって、データベースdb01とデータベースdb02の間のデータ損失ゼロのフェイルオーバーが可能
になります。Far Syncインスタンスのリソースや管理の要件はカスケード・フィジカル・スタンバイ・
データベースの場合の要件より低いため、Far Syncインスタンスは、標準的なデータセンターより少
ないリソースでプロビジョニングされた環境内に配置できる可能性があります。
6
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
注： Far SyncインスタンスのRedoRoutesプロパティ値でLOCALキーワードを使用しようとすると、
エラーが生成されます。
注： Far Syncインスタンスへのスイッチオーバーを実行しようとすると、エラーが生成されます。
7
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
例3： より高度なFar Sync構成
この例は、ローカルとリモートの両方の場所でローカルのFar Syncインスタンスを使用して、2つの
遠く離れたデータベース間の両方向でのデータ損失ゼロのフェイルオーバーを可能にする方法を示
しています。初期のプライマリ・データベースdb01は、Far Syncインスタンスfs01のSYNC転送の範
囲内に配置されています。初期のスタンバイ・データベースdb02は、Far Syncインスタンスfs02の
SYNC転送の範囲内に配置されています。データベースdb01とdb02は、通常動作可能なSYNC転送の
範囲を超えて遠く離れています（数百から数千マイル）。プライマリ・データベース・サイトで障
害が発生した場合、ローカルのFar Syncインスタンスとリモート・スタンバイはFar Syncインスタン
スからスタンバイへの最後のREDO送信を調整して、まだスタンバイ・データベースで使用可能に
なっていない残りのすべてのREDOが確実に受信および適用されるようにします。このようにして、
スタンバイがプライマリ・データベースから遠く離れている場合でも、スタンバイへのデータ損失
ゼロの正常なフェイルオーバーが可能になります。プライマリ・データベースの障害発生時にデー
タ損失ゼロのフェイルオーバーを実行する機能は、（局所的な災害がデータベースとそのローカル
のFar Syncインスタンスの両方に影響を与える可能性が最小限に抑えられるように）各Far Syncイン
スタンスが、受信するREDOの送信元のデータベースと同じ場所に配置されていない場合に強化され
ることに注意してください。
8
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
例4： 基本的なカスケード接続されたフィジカル・スタンバイ構成
この例は、例2に対応しています（その例のFar Syncインスタンスがカスケード・フィジカル・スタ
ンバイ・データベースに置き換えられています）。この構成の3つのデータベースは、初期のプライ
マリ・データベースdb01がフィジカル・スタンバイ・データベースdb02のSYNC転送の範囲内に配
置され、またフィジカル・スタンバイ・データベースdb02もフィジカル・スタンバイ・データベー
スdb03のSYNC転送の範囲内になるように配置されています。データベースdb01とdb03は遠く離れ
すぎていて、これらのデータベース間で直接のSYNC転送をサポートできないため、リアルタイム・
カスケードを使用した最大可用性構成が実装されます。保護モードを保持するには、db02がプライ
マリ・ロールにある場合、db02は、SYNC転送を使用してdb01とdb03に直接REDOを送信する必要が
あります。db01またはdb03がプライマリ・ロールにある場合、db02は、リアルタイム・カスケード
を使用して残りのデータベースにREDOを送信するように構成されます。この場合、もっとも遠い下
流のスタンバイ・データベースは、（Oracle Database 12cのActive Data Guardリアルタイム・カス
ケードを使用した）ASYNC転送経由でREDOを受信します。
9
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
注： receiving current redo句は、データベースdb02とdb03の間でOracle Active Data Guardリアル
タイム・カスケードが有効になっていることを示すために使用されます。
10
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
この例で（Far Syncの代わりに）カスケード・スタンバイを使用する利点は、現在のプライマリ・デー
タベースに障害が発生した場合、新しいプライマリが引き続きデータ損失ゼロの保護を維持できる
点にあります。
例5： より高度なカスケード接続された構成
この例では、それぞれ2つのデータベースを含む2つのデータセンターを想定しています。最初のデー
タセンターはデータベースdb01とdb02をホストし、2番目のデータセンターはデータベースdb03と
db04をホストしています。db01はプライマリ・ロールにある場合、SYNC転送を使用してデータベー
スdb02にREDOを送信します。このデータベースが次に、リアルタイム・カスケードを使用してデー
タベースdb03とdb04にREDOを送信します。db02がプライマリ・ロールにある場合、db02は、SYNC
転送を使用してデータベースdb01にREDOを送信します。このデータベースが次に、リアルタイム・
カスケードを使用してデータベースdb03とdb04にREDOを送信します。2番目のデータセンター内の
データベースがプライマリ・ロールにある場合は、REDO転送が同様の方法で構成されます。どちら
の場合も、ローカル・スタンバイがHAを提供し、ハードウェアとソフトウェアのローリング・アッ
プグレードを容易にし、さらにREDOの送信をプライマリ・データベースからオフロードするのに対
して、リモート・データセンター内のデータベースはDR保護機能を提供し、リモートの場所でのよ
り迅速なレポート作成を可能にします。
11
Oracle Maximum Availability
Architecture Oracle Data GuardおよびOracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
結論
Data Guard Brokerの新しいRedoRoutesプロパティを使用すると、現在どのデータベースがプライ
マリ・ロールで動作しているかに基づいてリモート宛先が望ましいREDO転送方法を自動的に使用で
きる、Active Data Guard Far Syncまたはリアルタイム・カスケードを使用した高度なREDO転送トポ
ロジを作成できます。Oracle Database 12cの新しいREDO転送機能により、以前のリリースでは不可
能だった高度なREDO転送トポロジの容易な構成および管理が可能になります。
12
Oracle Data Guardおよび
Oracle Active Data Guard 12cのREDO転送を
構成するためのベスト・プラクティス
2014年2月
著者： Laurence Clarke
貢献者： Larry Carpenter、Nitin Karkhanis、
Robert McGuirk、Joseph Meeks
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
海外からのお問い合わせ窓口：
電話： +1.650.5067000
ファクシミリ： +1.650.506.7200
www.oracle.com.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内
容は予告なく変更されることがあります。本文書は、その内容に誤りがないことを保証するものではなく、また、口頭による明示的保証や法律
による黙示的保証を含め、商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではあり
ません。オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものと
します。本文書はオラクルの書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段に
よっても再作成または送信することはできません。
OracleおよびJavaはOracleおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。
AMD、Opteron、AMDロゴおよびAMD Opteronロゴは、Advanced Micro Devicesの商標または登録商標です。IntelおよびIntel XeonはIntel
Corporationの商標または登録商標です。すべてのSPARC商標はライセンスに基づいて使用されるSPARC International, Inc.の商標または登録
商標です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。1010