| Oracle® Data Guard概要および管理 11gリリース2 (11.2) B56302-06 |
|
 前 |
 次 |
Data Guard構成は、プライマリ・ロールで機能する1つのデータベース、およびスタンバイ・ロールで機能する1つ以上のデータベースで構成されています。データベースの現行のロールを確認するには、V$DATABASEビューのDATABASE_ROLE列を問い合せます。
Data Guard構成内のスタンバイ・データベースの数、位置、タイプおよびプライマリ・データベースからのREDOデータを各スタンバイ・データベースに伝播する方法に応じて、プライマリ・データベースの停止に対して設定できるロール管理オプションが決定します。
この章では、Data Guard構成でロール・トランジションを管理する方法について説明します。この付録には、次の項があります。
|
注意: この章では、SQL文を使用して、手動でロールの推移を実行する方法について説明します。ブローカにより管理されるData Guard構成でロールの推移を実行する場合は、この章で説明する手順は使用しないでください。『Oracle Data Guard Broker』で提供されているトランジション・プロシージャを代わりに使用する必要があります。 |
データベースは、プライマリまたはスタンバイという相互に排他的なロールのいずれかで動作します。Data Guardを使用すると、この章で説明しているSQL文を発行するか、Data Guardブローカのいずれかのインタフェースを使用して、これらのロールを動的に変更することができます。Oracle Data Guardは、次のロール・トランジションをサポートしています。
プライマリ・データベースが、スタンバイ・データベースの1つを使用してロールを切り替えられるようにします。スイッチオーバー時には、データは消失しません。スイッチオーバーの完了後、各データベースは、新しいロールとともにData Guard構成に継続して含まれます。
プライマリ・データベースの障害時に、スタンバイ・データベースをプライマリ・ロールに変更します。障害の前にプライマリ・データベースが最大保護モードまたは最大可用性モードで動作していなかった場合、データ消失が発生することがあります。フラッシュバック・データベースがプライマリ・データベースで使用可能になっている場合は、障害の原因が修正された後、元どおり新しいプライマリ・データベースのスタンバイに戻すことができます。
8.1.1項「ロールの推移の準備」では、停止時間およびデータ消失のリスクを最小限にするために、どのロールの推移を選択するかについて説明します。8.1.3項「スイッチオーバー」および8.1.4項「フェイルオーバー」では、それぞれスイッチオーバーとフェイルオーバーの詳細を説明します。
|
関連項目: ブローカの管理対象のフェイルオーバーが発生した場合にデータベース・クライアントが使用可能なイベント通知、およびデータベース接続フェイルオーバー・サポートの詳細は、『Oracle Data Guard Broker』を参照してください。 |
各データベースが、担う予定のロールについて正しく構成されていることを確認します。プライマリ・データベースとスタンバイ・データベースでデータベース初期化パラメータ、ARCHIVELOGモード、スタンバイREDOログ、オンラインREDOログを構成する方法の詳細は、第3章「フィジカル・スタンバイ・データベースの作成」および第4章「ロジカル・スタンバイ・データベースの作成」を参照してください。
|
注意: スイッチオーバーまたはフェイルオーバーの発生時に、すべてのスタンバイ・サイトが新しいプライマリ・データベースから引き続きREDOデータを受信するように、各スタンバイ・データベース上でLOG_ARCHIVE_DEST_nおよびLOG_ARCHIVE_DEST_STATE_nパラメータを定義する必要があります。 |
プライマリ・データベースでV$ARCHIVE_DEST_STATUSビューを問い合せて、スタンバイ・データベースにREDO転送エラー、またはREDOギャップがないことを確認します。
たとえば、LOG_ARCHIVE_DEST_2に関連付けられているスタンバイ・データベースのステータスをチェックするには、次の問合せを使用します。
SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2; STATUS GAP_STATUS --------- ------------------------ VALID NO GAP
スタンバイ・データベースに対応する行のSTATUS列の値がVALID、GAP_STATUS列の値がNOGAPになるまで、次に進まないでください。
スタンバイ・データベースに存在する一時ファイルが、プライマリ・データベースの一時ファイルと一致することを確認します。
新たにプライマリ・データベースになるスタンバイ・データベースで現在有効になっているREDOの適用遅延を解除します。
Oracle RACプライマリ・データベースからフィジカル・スタンバイ・データベースにスイッチオーバーを実行するには、1つのプライマリ・データベース・インスタンス以外はすべて停止します。このとき停止したプライマリ・データベース・インスタンスは、スイッチオーバーの完了後に起動できます。
リアルタイム問合せモードにあるフィジカル・スタンバイ・データベースへのスイッチオーバーを実行する前に、できるだけ迅速に、クリーンにロール・トランジションを実施させるために、そのスタンバイ・データベースのすべてのインスタンスを、マウント済だがオープンされていない状態にすることを検討します。
複数のスタンバイ・データベースがあるData Guard構成の場合、ロールの推移のターゲット・スタンバイ・データベースを選択する際には、多数の要因を考慮する必要があります。次のような要因があります。
スタンバイ・データベースのローカリティ。
スタンバイ・データベースの機能(CPU数、使用可能なI/O帯域幅などのハードウェア仕様)。
ロールの推移の実行所要時間。これは、スタンバイ・データベースがREDOデータの適用に関してどの程度遅れているか、およびアプリケーションの可用性とデータ消失をどの程度柔軟にトレードオフできるかに影響を受けます。
スタンバイ・データベースのタイプ。
ロールの推移のターゲットとして選択されたスタンバイのタイプにより、構成内の他のスタンバイ・データベースがロールの推移後にどのように動作するか決定されます。ロールの推移前、新しいプライマリがフィジカル・スタンバイだった場合、構成内の他のスタンバイ・データベースは新しいプライマリのスタンバイになります。ロールの推移前、新しいプライマリがロジカル・スタンバイだった場合、構成内の他のすべてのロジカル・スタンバイは新しいプライマリのスタンバイになりますが、構成内のフィジカル・スタンバイは、古いプライマリのスタンバイのままであるため、新しいプライマリを保護しません。後者の場合、次回のスイッチオーバーまたはフェイルオーバーで元のプライマリ・データベースに戻ると、すべてのスタンバイは現行のプライマリのスタンバイとしての元のロールに戻ります。これらの理由により、フィジカル・スタンバイとロジカル・スタンバイの両方が含まれる構成内におけるロールの推移の最適なターゲットは、通常、フィジカル・スタンバイです。
|
注意: スナップショット・スタンバイは、ロールの推移のターゲットにはできません。スナップショット・スタンバイ・データベースをロールの推移のターゲットとして使用する場合、最初にこのデータベースをフィジカル・スタンバイ・データベースに変換し、プライマリ・データベースから受信したすべてのREDOを適用できるようにします。9.7.3項「フィジカル・スタンバイ・データベースへのスナップショット・スタンバイ・データベースの変換」を参照してください。 |
Data GuardにはV$DATAGUARD_STATSビューが用意されています。このビューを使用して、スタンバイ・データベースのデータの最新性から見た各スタンバイ・データベースと、使用可能なREDOデータがすべてスタンバイ・データベースに適用された場合の、ロール・トランジションの実行所要時間を評価することができます。次に例を示します。
SQL> COLUMN NAME FORMAT A24 SQL> COLUMN VALUE FORMAT A16 SQL> COLUMN DATUM_TIME FORMAT A24 SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS; NAME VALUE DATUM_TIME ------------------------ ---------------- ------------------------ transport lag +00 00:00:00 06/18/2009 12:22:06 apply lag +00 00:00:00 06/18/2009 12:22:06 apply finish time +00 00:00:00.000 estimated startup time 9
この問合せの出力は、スタンバイ・データベースが、プライマリ・データベースにより生成されたすべてのREDOを受信し、適用したことを示しています。これらの統計は、2009年6月18日12:22.06にプライマリ・データベースから受信したデータを使用して計算されたものです。
apply lagおよびtransport lagメトリックは、プライマリ・データベースから受信されるデータに基づいて計算されます。これらのメトリックは、プライマリ・データベースとスタンバイ・データベースの間の通信が中断されると失効します。apply lagおよびtransport lagメトリックのDATUM_TIME列の値が変化していないことは、プライマリ・データベースとスタンバイ・データベース間の通信障害と考えられる原因で、これらのメトリックが更新されずに失効したことを示しています。
スイッチオーバーは、通常、オペレーティング・システムやハードウェアのアップグレード、またはOracleデータベース・ソフトウェアとパッチ・セットのローリング・アップグレードなど、計画的な停止によるプライマリ・データベースの停止時間を短縮するために使用します(第12章「SQL Applyを使用したOracle Databaseのアップグレード」を参照)。
スイッチオーバーは、2つのフェーズで実行されます。最初のフェーズで、既存のプライマリ・データベースがスタンバイ・ロールに推移します。2番目のフェーズで、スタンバイ・データベースがプライマリ・ロールに推移します。
図8-1は、データベースのロールを切り替える前の2つのサイトにあるData Guard構成を示します。この構成では、プライマリ・データベースはサンフランシスコにあり、スタンバイ・データベースはボストンにあります。
図8-2に、元のプライマリ・データベースがスタンバイ・データベースにスイッチオーバーされた後、元のスタンバイ・データベースがまだ新しいプライマリ・データベースになっていないData Guard環境を示します。このとき、Data Guard構成には一時的に2つのスタンバイ・データベースが存在することになります。
図8-3は、スイッチオーバー実行後のData Guard環境を示します。元のスタンバイ・データベースは新しいプライマリ・データベースになります。現在、プライマリ・データベースはボストンにあり、スタンバイ・データベースはサンフランシスコにあります。
8.1.1項に示した前提条件が満たされていることを確認します。また、スイッチオーバーの場合は、次の前提条件が満たされている必要があります。
フィジカル・スタンバイ・データベースが関与するスイッチオーバーの場合は、プライマリ・データベースがオープンし、REDO Applyがスタンバイ・データベースでアクティブであることを確認します。REDO Applyの詳細は、7.3項「REDOデータのフィジカル・スタンバイ・データベースへの適用」を参照してください。
ロジカル・スタンバイ・データベースが関与するスイッチオーバーの場合は、プライマリおよびスタンバイ・データベース・インスタンスの両方がオープンし、SQL Applyがアクティブであることを確認します。REDO Applyの詳細は、7.4項「REDOデータのロジカル・スタンバイ・データベースへの適用」を参照してください。
通常、フェイルオーバーは、プライマリ・データベースが使用不可能になり、適正な時間内にプライマリ・データベースをリストアしてサービスを再開できない場合にのみ使用します。フェイルオーバー時に実行するアクションは、フェイルオーバーに関与するスタンバイ・データベースがロジカルかフィジカルか、フェイルオーバー時のData Guard構成の状態、およびフェイルオーバーを開始するために使用する特定のSQL文によって異なります。
図8-4に、サンフランシスコにあるプライマリ・データベースからボストンにあるフィジカル・スタンバイ・データベースへのフェイルオーバーの結果を示します。
フェイルオーバーの準備
|
注意: フェイルオーバーのために選択した物理スタンバイ・データベースで管理されているスタンバイ・リカバリが、ORA-752またはORA-600 [3020]のエラーで停止した場合は、このまま第13.6項「プライマリ・データベースでの書込みの欠落エラーからのリカバリ」に進んでください。
データ破損からのリカバリの詳細は、『Oracle Database高可用性ベスト・プラクティス』を参照してください。 |
可能な場合は、フェイルオーバーを実行する前に、使用可能な未適用のプライマリ・データベースREDOデータを可能なかぎりスタンバイ・データベースに転送する必要があります。
8.1.1項「ロールの推移の準備」に示した前提条件が満たされていることを確認します。また、フェイルオーバーの場合は、次の前提条件が満たされている必要があります。
最大保護モードで実行中のスタンバイ・データベースがフェイルオーバーに関与する場合は、スタンバイ・データベースで次の文を発行して、データベースを最大パフォーマンス・モードにします。
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
適切なスタンバイ・データベースが使用できる場合は、フェイルオーバーが完了した後に、新しいプライマリ・データベースで希望の保護モードをリセットできます。
最大保護モードに設定されているスタンバイ・データベースはフェイルオーバーできないため、この作業が必要になります。さらに、最大保護モードのプライマリ・データベースがスタンバイ・データベースと通信中の場合は、スタンバイ・データベースを最大保護モードから最大パフォーマンス・モードに変更するためにALTER DATABASE文を発行しても失敗します。フェイルオーバーを実行すると元のプライマリ・データベースはData Guard構成から削除されるため、この機能によって、最大保護モードで実行されているプライマリ・データベースを計画外のフェイルオーバーの影響から保護します。
後続のセクションでは、フィジカル・スタンバイ・データベースに対するスイッチオーバーまたはフェイルオーバーの実行方法を説明します。
この項では、フィジカル・スタンバイ・データベースへのスイッチオーバーの実行方法を説明します。スイッチオーバーは、プライマリ・データベースで開始し、ターゲット・スタンバイ・データベースで完了します。
プライマリ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO STANDBY 1 row selected
値TO STANDBYまたはSESSIONS ACTIVEは、プライマリ・データベースをスタンバイ・ロールに切替え可能であることを示します。これらのいずれの値も戻されない場合、REDO転送が正しく構成されていないか、正しく機能していないため、スイッチオーバーは不可能です。REDO転送の構成および監視の詳細は、第6章を参照してください。
プライマリ・データベースで次のSQL文を発行してスタンバイ・ロールに切り替えます。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH - > SESSION SHUTDOWN;
この文では、プライマリ・データベースをフィジカル・スタンバイ・データベースに変換します。現行の制御ファイルは、スイッチオーバーの前にカレントSQLセッション・トレース・ファイルにバックアップされます。これによって、必要に応じて現行の制御ファイルを再作成できるようになります。
|
注意: 前の手順で実行した問合せでTO STANDBYの値が戻された場合、WITH SESSION SHUTDOWN句をスイッチオーバー文から省略できます。 |
SQL> SHUTDOWN ABORT; SQL> STARTUP MOUNT;
スイッチオーバー・プロセスのこの時点では、元のプライマリ・データベースがフィジカル・スタンバイ・データベースです(図8-2を参照)。
|
注意: Oracle Database 11gリリース2 (11.2.0.4)以降では、ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN文が発行されるとデータベース・インスタンスがデフォルトで停止するため、この手順でSHUTDOWN ABORT文を発行する必要はありません。 |
スタンバイ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO_PRIMARY 1 row selected
値TO STANDBYまたはSESSIONS ACTIVEは、スタンバイ・データベースでプライマリ・ロールに切り替える準備が完了していることを示します。これらのいずれの値も戻されない場合、REDO applyがアクティブで、REDO転送が正しく構成されて機能していることを確認します。値TO PRIMARYまたはSESSIONS ACTIVEが戻されるまで、この列の問合せを続行します。
次のSQL文をターゲット・フィジカル・スタンバイ・データベースで発行します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
|
注意: 前の手順で実行した問合せでTO PRIMARYの値が戻された場合、WITH SESSION SHUTDOWN句をスイッチオーバー文から省略できます。 |
SQL> ALTER DATABASE OPEN;
次に例を示します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE - > DISCONNECT FROM SESSION;
次に例を示します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE - > DISCONNECT FROM SESSION;
この項では、フィジカル・スタンバイ・データベースへのフェイルオーバーの実行方法を説明します。
プライマリ・データベースをマウントできる場合、プライマリ・データベースからスタンバイ・データベースに、未送信でアーカイブされた現行のREDOをフラッシュすることが可能です。この操作が正常に終了した場合、プライマリ・データベースがデータ消失ゼロのデータ保護モードで実行されていなくても、データの消失がないようにフェイルオーバーすることができます。
ターゲット・スタンバイ・データベースでREDO Applyがアクティブであることを確認します。
プライマリ・データベースをマウントします。オープンはしないでください。プライマリ・データベースをマウントできない場合は、手順2に進みます。
次のSQL文をプライマリ・データベースで発行します。
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
target_db_nameには、プライマリ・データベースからフラッシュされたREDOを受信するスタンバイ・データベースのDB_UNIQUE_NAMEを指定します。
この文は、未送信のREDOをすべて、プライマリ・データベースからスタンバイ・データベースにフラッシュし、このREDOがスタンバイ・データベースに適用されるまで待機します。
この文がエラーなしに終了した場合は、手順5に進みます。この文でエラーが出た場合、または完了するまで待てないため、この文を停止しなければならない場合は、手順2に進みます。
ターゲット・スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せ、個々のREDOスレッドについて、最も大きなログ順序番号を取得します。
次に例を示します。
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) -
> OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
THREAD LAST
---------- ----------
1 100
可能であれば、各プライマリ・データベースREDOスレッドに対する最新のアーカイブREDOログ・ファイルがスタンバイ・データベースになければ、これをコピーし、登録します。これは、REDOスレッドごとに実行する必要があります。
次に例を示します。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
ターゲット・スタンバイ・データベースでV$ARCHIVE_GAPビューを問い合せ、ターゲット・スタンバイ・データベースにREDOギャップがあるかどうか判別します。
次に例を示します。
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 90 92
この例では、スレッド1の順序番号90、91および92のアーカイブREDOログ・ファイルがギャップです。
可能であれば、欠落しているすべてのアーカイブREDOログ・ファイルを、プライマリ・データベースからターゲット・スタンバイ・データベースにコピーして登録します。これは、REDOスレッドごとに実行する必要があります。
次に例を示します。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
手順3で実行する問合せでは、順序番号が最も大きいギャップに関する情報のみが表示されます。ギャップを解決した後、行が戻されなくなるまで問合せを繰り返します。
手順2から手順4を実行した後、アーカイブREDOログ・ファイルのすべてのギャップを解決できない場合(障害の発生したプライマリ・データベースのホスト・システムへのアクセス権がない場合など)、フェイルオーバー時にデータが消失する可能性があります。
次のSQL文をターゲット・スタンバイ・データベースで発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
次のSQL文をターゲット・スタンバイ・データベースで発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
この文がエラーなしに終了した場合は、手順7に進みます。
エラーが発生した場合、受信されたREDOデータに適用されていないものがあります。エラーの原因を解決し、文を再発行してから次の手順に進みます。
手順3および手順4で解決されなかったREDOギャップがある場合、REDOギャップがあることを知らせるエラーが表示されることに注意してください。
エラー状態を解決できない場合でも、ターゲット・スタンバイ・データベースで次のSQL文を発行してフェイルオーバーを実行できます(一部のデータが消失する可能性があります)。
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
ACTIVATE文が完了した後、手順9に進みます。
ターゲット・スタンバイ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO PRIMARY 1 row selected
値TO STANDBYまたはSESSIONS ACTIVEは、スタンバイ・データベースでプライマリ・ロールに切り替える準備ができていることを示します。これらのいずれの値も戻されない場合、REDO Applyがアクティブで、TO PRIMARYまたはSESSIONS ACTIVEのいずれかが戻されるまでこのビューを問い合せ続けることを確認します。
次のSQL文をターゲット・スタンバイ・データベースで発行します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
|
注意: 前の手順で実行されたSWITCHOVER_STATUS列の問合せでTO PRIMARYが戻された場合、WITH SESSION SHUTDOWN句をスイッチオーバー文から省略できます。 |
SQL> ALTER DATABASE OPEN;
新しいプライマリ・データベースの全体バックアップを作成することをお薦めします。
次に例を示します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE - > DISCONNECT FROM SESSION;
フェイルオーバーの完了後、元のプライマリ・データベースは13.2項または13.7項で説明する方法に従って、新しいプライマリ・データベースのフィジカル・スタンバイ・データベースに変換できます。あるいは、3.2項で説明した方法に従って、新しいプライマリ・データベースのバックアップからフィジカル・スタンバイ・データベースとして再作成できます。
元のプライマリ・データベースをスタンバイ・ロールで実行したら、スイッチオーバーを実行してプライマリ・ロールにリストアできます。
後続の項では、ロジカル・スタンバイ・データベースが関与するスイッチオーバーおよびフェイルオーバーの実行方法を説明します。
|
注意: ロジカル・スタンバイでは、データベース・サービスはレプリケートしません。ロジカル・スタンバイに対するフェイルオーバーまたはスイッチオーバーのイベントでは、プライマリでのサービスに接続している中間層が接続できなくなる(サービスの作成がレプリケートされないため)か、正しくないエディションに接続するようになります(サービス属性の変更がレプリケートされないため)。Oracle Clusterwareでは、管理するサービスをロジカル・スタンバイにレプリケートしません。それらのプライマリとスタンバイ間での同期を手動で維持する必要があります。Oracle Clusterwareの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
プライマリ・データベースとロジカル・スタンバイ・データベースとの間でスイッチオーバーを実行する場合、スイッチオーバーは、常にプライマリ・データベースで開始し、ロジカル・スタンバイ・データベースで完了してください。次の手順を記載されているとおりの順序で実行しなかった場合、スイッチオーバーは成功しません。
スイッチオーバーを実行できるかどうかを確認するには、現行のプライマリ・データベースでV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO STANDBY 1 row selected
SWITCHOVER_STATUS列の値TO STANDBYまたはSESSIONS ACTIVEは、プライマリ・データベースをロジカル・スタンバイ・ロールに切替え可能であることを示します。これらの値のいずれかが表示されない場合は、Data Guard構成が正常に機能していることを確認してください(たとえば、LOG_ARCHIVE_DEST_nパラメータのすべての値が正しく指定されていることを確認します)。V$DATABASEビューのSWITCHOVER_STATUS列に有効なその他の値の詳細は、『Oracle Databaseリファレンス』を参照してください。
ロジカル・スタンバイ・データベース・ロール用に現行のプライマリ・データベースを準備するには、プライマリ・データベースで次のSQL文を発行します。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
この文は現行プライマリ・データベースに対して、間もなくロジカル・スタンバイ・ロールに切り替わり、新しいプライマリ・データベースからREDOデータを受信し始めることを通知します。LogMinerディクショナリの受信に備えてプライマリ・データベースでこの手順を実行し、手順3で説明したように、現行のロジカル・スタンバイ・データベースのREDOストリームに記録できるようにします。
この操作に成功すると、V$DATABASE.SWITCHOVER_STATUS列に値PREPARING SWITCHOVERが表示されます。
スイッチオーバーのターゲットであるロジカル・スタンバイ・データベースでLogMinerディクショナリを作成するには、次の文を使用します。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
また、この文は、現行のプライマリ・データベース、およびData Guard構成内の他のスタンバイ・データベースにREDOデータの転送を開始するロジカル・スタンバイ・データベースで、REDO転送サービスを開始します。このロジカル・スタンバイ・データベースからREDOデータを受信するサイトは、REDOデータを受け入れますが、適用はしません。
ロジカル・スタンバイ・データベースのV$DATABASE.SWITCHOVER_STATUSには、LogMinerディクショナリがREDOストリームに記録されている間、最初はPREPARING DICTIONARYが表示されます。正常に完了すると、SWITCHOVER_STATUS列にPREPARING SWITCHOVERが表示されます。
プライマリ・データベースからロジカル・スタンバイ・ロールへのロール・トランジションを完了するには、プライマリ・データベースのV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せることで、プライマリ・データベースがLogMinerディクショナリを受信したことを確認する必要があります。LogMinerディクショナリを受信しなければ、現行のプライマリ・データベースが以降のプライマリ・データベースから受信するREDOレコードを解釈できないため、スイッチオーバーを続行することができません。SWITCHOVER_STATUS列にスイッチオーバーの進捗が示されています。
問合せがTO LOGICAL STANDBY値を戻した場合は、手順5に進むことができます。次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO LOGICAL STANDBY 1 row selected
|
注意: 次の文を示された順序で発行すると、スイッチオーバー操作を取り消すことができます。
|
プライマリ・データベースからロジカル・スタンバイ・データベース・ロールへのロールの推移を完了するには、次のSQL文を発行します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
この文は、プライマリ・データベースで現在のトランザクションがすべて終了するまで待機し、新規ユーザーによる新規トランザクションの開始を防止して、スイッチオーバーがコミットされる時点を設定します。
この文を実行すると、ユーザーはロジカル・スタンバイ・データベースでメンテナンスされているデータの変更もできなくなります。スイッチオーバーを迅速に実行するには、スイッチオーバー文を発行する前に、プライマリ・データベースが静止状態で更新アクティビティが実行されていないことを確認してください(たとえば、すべてのユーザーをプライマリ・データベースから一時的にログオフします)。V$TRANSACTIONビューを問い合せると、この文の実行を遅延させる可能性のある現在進行中のトランザクションのステータス情報を取得できます。
この時点でプライマリ・データベースのロールが推移して、スタンバイ・データベース・ロールで実行されます。
プライマリ・データベースをロジカル・スタンバイ・データベース・ロールに推移した場合は、データベースを停止して再起動する必要はありません。
プライマリ・データベースからロジカル・スタンバイ・ロールへのロールの推移を完了し、構成内のスタンバイ・データベースがスイッチオーバー通知を受け取った後、ターゲット・スタンバイ・データベースでV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せ、ターゲット・スタンバイ・データベースがスイッチオーバー通知を処理したかどうかを確認する必要があります。使用可能なすべてのREDOレコードがロジカル・スタンバイ・データベースに適用されると、SQL Applyは予想されるロールの推移の準備を自動的に停止します。
スイッチオーバー中にSWITCHOVER_STATUS値が更新され、進捗を示します。ステータスがTO PRIMARYの場合は、手順7に進むことができます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO PRIMARY 1 row selected
V$DATABASEビューのSWITCHOVER_STATUS列に有効なその他の値の詳細は、『Oracle Databaseリファレンス』を参照してください。
プライマリ・ロールに切り替えるロジカル・スタンバイ・データベースで、次のSQL文を使用し、ロジカル・スタンバイ・データベースをプライマリ・ロールに切り替えます。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Data Guard構成内のロジカル・スタンバイ・データベースは、停止して再起動する必要はありません。8.1.2項で説明したように、構成内の他のすべてのロジカル・スタンバイは新しいプライマリのスタンバイになりますが、フィジカル・スタンバイ・データベースは、元のプライマリ・データベースのスタンバイのままです。
新しいロジカル・スタンバイ・データベースでSQL Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
この項では、ロジカル・スタンバイ・データベースが関与するフェイルオーバーの実行方法を説明します。ロジカル・スタンバイ・データベースが関与するフェイルオーバーによるロールの推移では、障害の発生したプライマリ・データベースとすべてのロジカル・スタンバイ・データベースで対処措置を実行する必要があります。障害の発生したプライマリ・データベースでフラッシュバック・データベースが有効化されていない場合は、現行のプライマリ・データベースから作成したバックアップを使用してデータベースを再作成する必要があります。それ以外の場合は、13.2項で説明する手順に従って、障害の発生したプライマリ・データベースを新しいプライマリ・データベースのロジカル・スタンバイ・データベースに変換できます。
構成に対する保護モードおよびREDO転送サービスに対して選択した属性に従って、プライマリ・データベースの修正の一部またはすべてを自動的にリカバリすることも可能です。
プライマリ・データベースをマウントできる場合、プライマリ・データベースからスタンバイ・データベースに、未送信でアーカイブされた現行のREDOをフラッシュすることが可能です。この操作が正常に終了した場合、プライマリ・データベースがデータ消失ゼロのデータ保護モードで実行されていなくても、データの消失がないようにフェイルオーバーすることができます。
ターゲット・スタンバイ・データベースでREDO Applyがアクティブであることを確認します。
プライマリ・データベースをマウントします。オープンはしないでください。
次のSQL文をプライマリ・データベースで発行します。
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
target_db_nameには、プライマリ・データベースからフラッシュされたREDOを受信するスタンバイ・データベースのDB_UNIQUE_NAMEを指定します。
この文は、未送信のREDOをすべて、プライマリ・データベースからスタンバイ・データベースにフラッシュし、このREDOがスタンバイ・データベースに適用されるまで待機します。
構成に含まれるコンポーネントの状態によっては、プライマリ・データベースのアーカイブREDOログ・ファイルにアクセスできる場合があります。アクセスする場合の手順は、次のとおりです。
ロジカル・スタンバイ・データベースでアーカイブREDOログ・ファイルが欠落しているかどうかを判断します。
欠落しているログ・ファイルを、プライマリ・データベースからロジカル・スタンバイ・データベースにコピーします。
コピーしたログ・ファイルを登録します。
次の文を発行して、アーカイブREDOログ・ファイルをロジカル・スタンバイ・データベースに登録できます。次に例を示します。
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE - > '/disk1/oracle/dbs/log-%r_%s_%t.arc'; Database altered.
ロールベースの宛先をまだ構成していない場合は、新しいプライマリ・データベースのリモート・ロジカル・スタンバイ宛先に対応する初期化パラメータを特定して、これらの宛先ごとにREDOデータのアーカイブを手動で使用可能にします。
たとえば、LOG_ARCHIVE_DEST_2パラメータで定義したリモート宛先のアーカイブを可能にするには、次の文を発行します。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
後で新しいプライマリ・データベースを再起動した場合にもこの変更を保持するには、適切なテキスト初期化パラメータ・ファイルまたはサーバー・パラメータ・ファイルを更新します。通常、データベースがプライマリ・ロールで動作する場合はリモート宛先へのアーカイブを可能にし、データベースがスタンバイ・ロールで動作する場合はリモート宛先へのアーカイブを不可能にする必要があります。
ターゲット・ロジカル・スタンバイ・データベース(新規プライマリ・ロールに推移させるデータベース)で、次の文を発行します。
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;
この文はRFSプロセスを停止し、ロジカル・スタンバイ・データベースがプライマリ・データベースになる前にスタンバイREDOログ・ファイルに残っているREDOデータを適用し、SQL Applyを停止して、データベースをプライマリ・データベース・ロールでアクティブ化します。
FINISH APPLY句が指定されていない場合、現行のスタンバイREDOログ・ファイルの未適用のREDOは、スタンバイ・データベースがプライマリ・データベースになるまで適用されません。
13.1項で説明する方法に従って、既存のロジカル・スタンバイ・データベースが新しいプライマリ・データベースを引き続き保護できるようにします。
Data Guardデータベース・フェイルオーバー直後に、新しいプライマリ・データベースのバックアップを行います。データベースの完全なバックアップ・コピーがなければ、フェイルオーバー後の変更をリカバリすることができないので、バックアップをすぐに実行することは安全策として必要な作業です。
フェイルオーバーの完了後、元のプライマリ・データベースは13.2項で説明する方法に従って、新しいプライマリ・データベースのロジカル・スタンバイ・データベースに変換できます。あるいは、第4章で説明したように、新しいプライマリ・データベースのバックアップからロジカル・スタンバイ・データベースとして再作成できます。
元のプライマリ・データベースをスタンバイ・データベースに変換したら、スイッチオーバーを実行してプライマリ・ロールにリストアできます。
ロール・トランジションの後に、オプションでFLASHBACK DATABASEコマンドを使用してデータベースをロール・トランジション前のある時点、またはシステム変更番号(SCN)に戻すことができます。プライマリ・データベースのフラッシュバックを行う場合、同じ(または以前の)SCNまたは時刻にすべてのスタンバイ・データベースをフラッシュバックする必要があります。この方法でプライマリまたはスタンバイ・データベースのフラッシュバックを行う場合は、過去のスイッチオーバーを気にする必要はありません。SCN/時刻が過去の任意の時点でのスイッチオーバーより前の場合、Oracleは自動的に過去のスイッチオーバーを越えてフラッシュバックを行うことができます。
|
注意: ロールの推移が発生する前に、データベースでフラッシュバック・データベースを有効化しておく必要があります。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
スイッチオーバー後にFLASHBACK DATABASEコマンドを使用して、データベースをスイッチオーバー発生前の時点またはシステム変更番号(SCN)に戻すことができます。
スイッチオーバーにフィジカル・スタンバイ・データベースが関与していた場合、フラッシュバック操作中はプライマリおよびスタンバイ・データベース・ロールが保持されます。つまり、データベースが実行中のロールは、フラッシュバックした時点またはターゲットSCNまでデータベースがフラッシュバックされても変化しません。スイッチオーバー後からフラッシュバックの前までフィジカル・スタンバイ・ロールで実行されていたデータベースは、フラッシュバック・データベース操作後もフィジカル・スタンバイ・データベースで実行されます。
スイッチオーバーにロジカル・スタンバイ・データベースが関与していた場合、フラッシュバックするとスタンバイ・データベースのロールはフラッシュバックした時点またはターゲットSCNでのロールに変更されます。
フラッシュバック・データベースを使用して、障害の発生したプライマリ・データベースをフェイルオーバー発生前の時点に変換してから、スタンバイ・データベースに変換できます。詳細な手順は、13.2項「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」を参照してください。
