D Oracle Data GuardとOracle Real Application Clusters
Oracle Data Guardは、シングル・インスタンスとOracle Real Application Clusters(Oracle RAC)の複数インスタンス・データベースを自由に組み合せて構成することができます。
この付録ではOracle Data GuardをOracle RACデータベースと一緒に使用する場合の構成要件と考慮事項をまとめます。内容は次のとおりです。
D.1 Oracle RAC環境でのスタンバイ・データベースの構成
スタンバイ・データベースを構成すると、Oracle Real Application Clusters (Oracle RAC)を使用しているプライマリ・データベースを保護できます。
次の表では、プライマリ・データベースとスタンバイ・データベースのインスタンスの可能な組合せについて説明します。
インスタンスの組合せ | 単一インスタンス・スタンバイ・データベース | 複数インスタンス・スタンバイ・データベース |
---|---|---|
単一インスタンス・プライマリ・データベース |
可 |
可 |
複数インスタンス・プライマリ・データベース |
可 |
可 |
それぞれの組合せでは、プライマリ・データベースの各インスタンスが、REDOデータをスタンバイ・データベースのインスタンスへ転送します。Oracle Database 12cリリース2 (12.2.0.1)以降、複数インスタンスのREDO Applyも実行できます。
D.1.1 複数インスタンスのREDO Applyの設定
Oracle Database 12c
リリース2 (12.2.0.1)以降、新しい INSTANCES [ ALL | integer]
句がSQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
コマンドで使用できます。
次の制限があります。
-
この句は、Oracle Real Application Clusters (Oracle RAC)またはOracle RAC One Nodeデータベースのみに適用できます。
-
インメモリー列ストアは、Active Data Guard環境の複数インスタンスのREDO Applyでサポートされていません。複数インスタンスのREDO Applyが起動されると、これは無効になります。
ALL
オプションにより、リカバリが開始した時点でオープンまたはマウント状態にあるOracle RACスタンバイ・データベースのすべてのインスタンスでREDO Applyが実行されます。インスタンスはすべて同じオープンまたはマウント状態にある必要があります。状態の混合は許可されません。
integer
オプションは、REDO Applyが使用するインスタンスの数を、指定した数に制限します。integerには、1からスタンバイ・データベースのインスタンス数までの整数値を指定します。Redo Applyを実行するインスタンスはデータベースで選択され、ユーザーが特定のインスタンスを指定することはできません。
V$RECOVERY_PROGRESS
ビューは、リカバリが開始されたインスタンス(MRP0プロセスが存在)にのみ移入されます。
INSTANCES
句を省略すると、リカバリはコマンドが発行されたインスタンスでのみ発生します。
リカバリ・プロセスではインスタンス内にREDOを送信するため、REDO Applyのパフォーマンスはネットワークの帯域幅および待機時間と直接関係します。
D.1.2 複数インスタンス・プライマリ・データベースと単一インスタンス・スタンバイ・データベースの設定
この図では、プライマリ・データベース・インスタンスが2つあるOracle RACデータベース(複数インスタンス・プライマリ・データベース)が、単一インスタンス・スタンバイ・データベースへREDOデータを転送しています。
この場合は、プライマリ・データベースのインスタンス1がローカル・アーカイブREDOログ・ファイル1、2、3、4、5にREDOデータをアーカイブし、スタンバイ・データベース宛先にREDOデータを転送するのに対し、インスタンス2がローカル・アーカイブREDOログ・ファイル32、33、34、35、36にREDOデータをアーカイブし、同じスタンバイ・データベース宛先にREDOデータを転送します。スタンバイ・データベースでは、アーカイブREDOログ・ファイルを適用する正しい順序が自動的に判断されます。
図D-1にはスタンバイREDOログは示されていませんが、プライマリの両方のインスタンスに対しスタンバイでスタンバイREDOログを構成することがベスト・プラクティスです。インスタンス1およびインスタンス2にあるプライマリ・オンラインREDOログ・ファイルからのREDOは、まずインスタンス1およびインスタンス2のスタンバイREDOログでそれぞれ受信され、次にアーカイブされます。
Oracle RAC環境でのプライマリ・データベースの構成方法
スタンバイ・データベースを作成する前に、プライマリ・データベースが正しく構成されていることを確認する必要があります。これを行うには、いくつかの準備ステップを実行する必要があり、それによりデータベースは、1つ以上のスタンバイ・データベースに対するプライマリ・データベースとして機能する準備が整います。
単一インスタンス・スタンバイ・データベースの構成方法
アーカイブREDOログ・ファイルおよびスタンバイREDOログ・ファイルの場所を指定するには、LOG_ARCHIVE_DEST_
n
およびLOG_ARCHIVE_FORMAT
パラメータを定義します。
関連項目:
-
スタンバイREDOログの詳細は、「スタンバイREDOログの管理」を参照してください
-
フィジカル・スタンバイ・データベースを作成する際にプライマリ・データベースを構成する方法の詳細は、「フィジカル・スタンバイ・データベースの作成」を参照してください。
-
ロジカル・スタンバイ・データベースを作成する際にプライマリ・データベースを構成する方法の詳細は、「ロジカル・スタンバイ・データベースの作成」を参照してください。
D.1.3 Oracle RACプライマリおよびスタンバイ・データベースの設定
Oracle RACプライマリ・データベースは、REDOデータをOracle RACスタンバイ・データベースに送信するように設定されている必要があり、Oracle RACスタンバイ・データベースは、REDOデータを受信するように設定する必要があります。
D.1.3.1 REDOデータを受信するためのOracle RACスタンバイ・データベースの構成
これらのステップでは、プライマリ・データベースからREDOデータを受信するようにOracle RACスタンバイ・データベースを構成する方法について説明します。
- スタンバイ・データベースで、スタンバイREDOログを作成します。スタンバイREDOログのREDOログ・ファイルは、すべてのスタンバイ・データベース・インスタンスがアクセスできる場所(クラスタ・ファイル・システムやOracle ASMインスタンスなど)に存在する必要があります。スタンバイREDOログの作成の詳細は、「スタンバイREDOログの管理」を参照してください。
- スタンバイREDOログ・アーカイブを、各スタンバイ・インスタンス上に構成します。スタンバイREDOログはすべてのスタンバイ・インスタンスがアクセス可能な場所にアーカイブする必要があります。また、各スタンバイ・データベース・インスタンスは、同じ場所にスタンバイREDOログをアーカイブするように構成しておく必要があります。
D.1.3.2 REDOデータを送信するためのOracle RACプライマリ・データベースの構成
-
各プライマリ・データベース・インスタンスで同じ
LOG_ARCHIVE_DEST_n
パラメータを使用して、REDOデータを特定のスタンバイ・データベースに送信する。 -
特定のスタンバイ・データベースに対応する各
LOG_ARCHIVE_DEST_n
パラメータのSERVICE
属性を同じネット・サービス名に設定する。 -
ネット・サービス名は、アドレス・リストを含むOracle Net接続記述子に解決する必要があり、そのアドレス・リストには、各スタンバイ・データベース・インスタンスの接続データが含まれる必要がある。
REDOデータを別のデータベースに送信するようにOracleデータベース・インスタンスを構成する方法は、「REDOデータを送信するためのOracleデータベースの構成」を参照してください。
D.2 Oracle RAC環境での構成に関する考慮事項
Oracle Real Application Clusters (Oracle RAC)では、Oracle Data Guardの構成時にアーカイブREDOログ・ファイル名の形式とデータ保護モードに関して一定の要件があります。
次のトピックを参照してください。
D.2.1 アーカイブREDOログ・ファイル名の形式
アーカイブREDOログ・ファイル名の形式は、log_%parameterです。
%parameterには、表D-1のパラメータを1つ以上指定できます。
表D-1 LOG_ARCHIVE_FORMAT初期化パラメータのディレクティブ
ディレクティブ | 説明 |
---|---|
|
データベース・アクティブID |
|
0(ゼロ)を埋め込んだデータベース・アクティブID |
|
データベースID |
|
0(ゼロ)を埋め込んだデータベースID |
|
インスタンス・スレッド番号 |
|
0(ゼロ)を埋め込んだインスタンス・スレッド番号 |
|
ログ・ファイル順序番号 |
|
0(ゼロ)を埋め込んだログ・ファイル順序番号 |
|
リセットログID |
|
0(ゼロ)を埋め込んだリセットログID |
次に例を示します。
LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc
Oracle RACが、LOG_ARCHIVE_FORMAT
パラメータでアーカイブREDOログ・ファイルを一意に識別するためには、スレッド・パラメータ%tまたは%Tが必須です。
D.2.2 データ保護モード
Oracle RACプライマリ・データベースのいずれかのインスタンスでスタンバイ・データベースとの接続性が失われた場合、他のすべてのプライマリ・データベース・インスタンスでは、LOG_ARCHIVE_DEST_
n
REOPEN
属性で指定された秒数の間、スタンバイ・データベースへのREDO送信を停止し、その後すべてのプライマリ・データベース・インスタンスでスタンバイ・データベースへの再接続が試みられます。
次に、Oracle RAC環境における保護モードの動作を説明します。
-
最大保護の構成
接続を失った宛先が最後の
SYNC
宛先の場合、インスタンスは接続を失い、停止します。Oracle RAC構成内でスタンバイ宛先への接続を維持しているインスタンスは、接続を失ったインスタンスをリカバリし、スタンバイ宛先へのREDO送信を継続します。Oracle RAC構成内のすべてのインスタンスが最後のスタンバイ宛先への接続を失った場合にのみ、プライマリ・データベースが停止します。 -
最大可用性構成と最大パフォーマンス構成
Oracle RAC構成内でスタンバイ宛先への接続を維持しているインスタンスは、接続を失ったインスタンスをリカバリし、スタンバイ宛先へのREDO送信を継続します。Oracle RAC構成内のすべてのインスタンスがスタンバイ宛先への接続を失うと、プライマリ・データベースは最大パフォーマンス・モードで操作を続行します。最大パフォーマンス・モードでは、スタンバイ全体の障害時を除き、データ消失が最小限に抑えられます。
最大可用性保護モードは、特定の二重障害の場合(すべてのスタンバイ・データベースに障害が発生した後にプライマリ・データベースの障害が発生した場合など)を除いて、データ消失がないことを保証します。