15 Oracle Data Guardの使用例
これらのシナリオは、Oracle Data Guard構成の管理中に遭遇する可能性がある様々な状況を示します。それぞれ、ユーザー固有の環境に適応できます。
15.1 フェイルオーバー後のロジカル・スタンバイ・データベースの構成
プライマリ・データベースを別のスタンバイ・データベースにフェイルオーバーした後にロジカル・スタンバイ・データベースで実行する必要のあるステップを次に示します。
フェイルオーバーの発生後、ロジカル・スタンバイ・データベースは、元のプライマリ・データベースからの最後のREDOが適用されるまで、新規プライマリ・データベースのスタンバイ・データベースとして機能できません。これは、フェイルオーバー中に新規のプライマリ・データベースで最後のREDOが適用される場合と同じです。実行する必要のあるステップは、新規プライマリ・データベースがフェイルオーバー前にフィジカル・スタンバイ・データベースであったかロジカル・スタンバイ・データベースであったかに応じて異なります。
15.1.1 新規プライマリ・データベースがフィジカル・スタンバイ・データベースだった場合
このステップでは、プライマリ・ロールを担う前はフィジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするようにロジカル・スタンバイ・データベースを構成する方法について説明します。
この使用例では、SATはロジカル・スタンバイ・データベース、NYCはプライマリ・データベースです。
-
SATデータベースで次の文を発行して、ログ・ファイルの自動リカバリを有効化するためにFAL_SERVERパラメータを構成します。
SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>'; SQL> ALTER SYSTEM SET FAL_CLIENT='<tns_name_to_local_database>';
-
PREPARE_FOR_NEW_PRIMARYルーチンを呼び出して、ロジカル・スタンバイ・データベースが新規プライマリ・データベースのスタンバイ・データベースとして機能できることを確認します。このステップの間、データに相違を生じさせるおそれのあるログ・ファイルのローカル・コピーは、ローカル・データベースから削除されます。その後、これらのログ・ファイルは、新しいプライマリ・データベースから直接、再アーカイブが要求されます。
SATデータベースで、次の文を発行します。
SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY( - > former_standby_type => 'PHYSICAL' - > dblink => 'nyc_link');
ノート:
ORA-16109
メッセージが戻され、alert.logに「LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required.」という警告が書き込まれる場合は、次のステップを実行します。-
データベースを警告に示されたSCNまでフラッシュバックします。
-
続行する前に、このステップを繰り返します。
ロジカル・スタンバイ・データベースをApply SCNまでフラッシュバックする方法の例は、「特定の適用済SCNへのロジカル・スタンバイ・データベースのフラッシュバック」を参照してください。
-
-
SATデータベースで、次のコマンドを発行してSQL Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
15.1.2 新規プライマリ・データベースがロジカル・スタンバイ・データベースだった場合
このステップでは、プライマリ・ロールを担う前はロジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするようにロジカル・スタンバイ・データベースを構成する方法について説明します。
この使用例では、SATはロジカル・スタンバイ・データベース、NYCはプライマリ・データベースです。
-
新規プライマリ・データベースで、ロジカル・スタンバイ・データベースのサポート準備が完了していることを確認します。NYCデータベースで、次の問合せにより値
NONE
が戻されることを確認します。それ以外の場合、新しいプライマリ・データベースは、ロジカル・スタンバイ・データベースに対するサポートを可能にするために必要な作業を完了していません。次に例を示します。SQL> SELECT PENDING_ROLE_CHANGE_TASKS FROM V$DATABASE;
古いプライマリ・データベースを修復しようとする前に、
NONE
の値が戻される必要があります。 -
SATデータベースで次の文を発行して、ログ・ファイルの自動リカバリを有効化するためにFAL_SERVERパラメータを構成します。
SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>'; SQL> ALTER SYSTEM SET FAL_CLIENT='<tns_name_to_local_database>';
-
PREPARE_FOR_NEW_PRIMARY
ルーチンを呼び出して、ロジカル・スタンバイ・データベースが新規プライマリのスタンバイとして機能できることを確認します。このステップの間、データに相違を生じさせるおそれのあるログ・ファイルのローカル・コピーは、ローカル・データベースから削除されます。その後、これらのログ・ファイルは、新しいプライマリ・データベースから直接、再アーカイブが要求されます。SATデータベースで、次の文を発行します。
SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY( - > former_standby_type => 'LOGICAL' - > dblink => 'nyc_link');
ノート:
ORA-16109
メッセージが戻され、alert.logファイルに「LOGSTDBY: prepare_for_new_primary failure -- applied too far, flashback required」
という警告が書き込まれる場合は、次のステップを実行します。-
データベースを警告に示されたSCNまでフラッシュバックします。
-
続行する前に、このステップを繰り返します。
ロジカル・スタンバイ・データベースをApply SCNまでフラッシュバックする方法の例は、「特定の適用済SCNへのロジカル・スタンバイ・データベースのフラッシュバック」を参照してください。
-
-
SATデータベースで、次のコマンドを発行してSQL Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY nyc_link;
この文は、常にリアルタイム適用オプションを有効化せずに発行する必要があります。ロジカル・スタンバイ・データベースでリアルタイム適用を有効化する必要がある場合は、前述の文が正常終了するまで待機してから、次の文を発行します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
15.2 フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換
フェイルオーバーの発生後、元のプライマリ・データベースは、修正され、新しい構成のスタンバイ・データベースとして確立されるまで、Oracle Data Guard構成に含められません。
これを行うには、フラッシュバック・データベース機能を使用して、障害の発生したプライマリ・データベースを障害発生前の時点にフラッシュバックし、その後新しい構成内のフィジカルまたはロジカル・スタンバイ・データベースに変換します。この項では、次の項目について説明します。
-
障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバック
ノート:
フェイルオーバー前に、元のプライマリ・データベースでフラッシュバック・データベースが使用可能になっている必要があります。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
-
特定の適用済SCNへのロジカル・スタンバイ・データベースのフラッシュバック
関連項目:
失敗したプライマリ・データベースを新しいデータベースとして自動回復する(フラッシュバック・データベースを使用するかわりに)方法は、『Oracle Data Guard Broker』を参照してください。
15.2.1 障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへのフラッシュバックに関する項
このステップは、古いプライマリ・データベースをフィジカル・スタンバイ・データベースとしてOracle Data Guard構成に戻します。
次のステップでは、フィジカル・スタンバイ・データベースに対してフェイルオーバーが実行され、ファイルオーバーの際に古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。
-
新しいプライマリ・データベース上で次の問合せを発行し、古いスタンバイ・データベースが新しいプライマリ・データベースになったSCNを判別します。
SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
-
必要に応じて古いプライマリ・データベースを停止し、マウントして、前のステップで判別した
STANDBY_BECAME_PRIMARY_SCN
の値にフラッシュバックします。SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> FLASHBACK DATABASE TO SCN standby_became_primary_scn;
-
データベースをフィジカル・スタンバイ・データベースに変換するには、古いプライマリ・データベースで次の文を発行します。
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
-
新しいフィジカル・スタンバイ・データベースへのREDO転送を開始するには、新しいプライマリ・データベースで次のステップを実行します。
-
次の問合せを発行し、アーカイブ宛先の現在の状態を調べます。
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, - > ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
-
必要に応じて、宛先を使用可能にします。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
-
スタンバイ・データベースが新しいプライマリ・データベースからのREDOデータの受信を確実に開始するよう、ログ・スイッチを実行し、これが成功したことを確認します。次のSQL文を新しいプライマリ・データベースで発行します。
SQL> ALTER SYSTEM SWITCH LOGFILE; SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION,- > ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
新しいスタンバイ・データベースで、REDO転送サービスがREDOデータを別のデータベースに転送しないよう、
LOG_ARCHIVE_DEST_
n
初期化パラメータも変更する必要があります。
-
-
新しいフィジカル・スタンバイ・データベースでREDO Applyを開始します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
REDO Applyは、ロールの推移により生成されるREDOレコードが検出されるたびに自動的に停止するため、新しいプライマリ・データベースがプライマリ・データベースとなったSCNを超えて適用されるまで、1回以上再起動する必要があります。障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の(障害発生前の)ロールに推移できます。詳細は、「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」を参照してください。
15.2.2 障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバック
このステップは、新しいプライマリ・データベースから古いプライマリ・データベースを正式にインスタンス化せずに、古いプライマリ・データベースを新しいロジカル・スタンバイ・データベースとしてOracle Data Guard構成に戻します。
次のステップでは、Oracle Data Guard構成ですでにロジカル・スタンバイ・データベースを使用したフェイルオーバーが実行済で、古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。
15.2.3 特定の適用済SCNへのロジカル・スタンバイ・データベースのフラッシュバック
15.3 Open Resetlogs文の発行後のフラッシュバック・データベースの使用
Oracle Data Guard構成のプライマリ・データベースで、スタンバイ・データベースがリアルタイム適用を使用しているというエラーが発生した場合、同じエラーがスタンバイ・データベースにも適用されます。フラッシュバック・データベースが有効になっている場合は、プライマリ・データベースとスタンバイ・データベースをエラー前の状態に戻すことができます。
これを行うには、プライマリ・データベースでFLASHBACK DATABASE
文とOPEN RESETLOGS
文を実行してから、適用サービスを再起動する前に、スタンバイ・データベースで同様のFLASHBACK STANDBY DATABASE
文を発行します。(フラッシュバック・データベースが有効化されていない場合は、プライマリ・データベースのポイント・イン・タイム・リカバリを実行後、「フィジカル・スタンバイ・データベースの作成」と「ロジカル・スタンバイ・データベースの作成」で説明しているスタンバイ・データベースの再作成が必要です。)
15.3.1 特定時点へのフィジカル・スタンバイ・データベースのフラッシュバック
これらのステップでは、プライマリ・データベースでOPEN RESETLOGS
文を発行した後、フィジカル・スタンバイ・データベースの再作成を回避する方法を説明します。
15.3.2 特定時点へのロジカル・スタンバイ・データベースのフラッシュバック
これらのステップでは、プライマリ・データベースをフラッシュバックし、OPEN RESETLOGS
文を発行してオープンした後、ロジカル・スタンバイ・データベースの再作成を回避する方法を説明します。
ノート:
SQL Applyは、プライマリ・データベースでリセットログ操作の発生を検出すると、ロジカル・スタンバイ・データベースをフラッシュバックしなくてもマイニングできる場合は、REDOの正しいブランチを自動的にマイニングします。それ以外の場合、SQL Applyは「ORA-1346:
指定されたリセット・ログscnを超えてLogMinerがREDOを処理しました」エラーで停止します。この項では、SQL Applyはこのエラーですでに停止していると仮定しています。
15.4 NOLOGGING句を指定した後のリカバリ
一部のSQL文では、NOLOGGING
句を指定して、操作がオンラインREDOログ・ファイルに記録されないようにできます。
実際には、REDOレコードは引き続きオンラインREDOログ・ファイルに書き込まれますが、このレコードにはデータが関連付けられていません。これによりスタンバイ・サイトでのログ・アプリケーションまたはデータ・アクセス・エラーが発生し、このログ・ファイルを適用するには手動でのリカバリが必要になることがあります。ロジカル・スタンバイとフィジカル・スタンバイのどちらを使用するかに応じて次の操作を行うことで、これらのエラーを防止できます。
-
ロジカル・スタンバイ-
CREATE DATABASE
またはALTER DATABASE
文でFORCE LOGGING
句を指定します。 -
フィジカル・スタンバイ - 適切なロギング・モードの有効化の説明に従って、Data Guard構成の使用方法に適したロギング・モードを指定します。
現在のロギング・モードは、V$DATABASE.FORCE_LOGGING
列(CDBの場合)またはDBA_PDBS.FORCE_LOGGING
列(PDBの場合)で確認できます。
15.4.1 ロジカル・スタンバイ・データベースのリカバリ・ステップ
ロジカル・スタンバイ・データベースでは、SQL ApplyでNOLOGGING
句を使用してスキップされていない表で実行された操作のREDOレコードが検出されると、次のエラーで停止します。
ORA-16211 unsupported record found in the archived redo log
NOLOGGING
句を指定した後のリカバリには、「ロジカル・スタンバイ・データベースでの表の追加または再作成」に説明されているように、プライマリ・データベースから1つ以上の表を再作成します。
ノート:
通常、NOLOGGING
句の使用はお薦めしません。このため、プライマリ・データベース内の特定の表でNOLOGGING
句を使用する操作が実行されることが事前にわかっている場合は、これらの表に関連付けられているSQL文をロジカル・スタンバイ・データベースに適用しないようにできます。これは、DBMS_LOGSTDBY.SKIP
プロシージャを使用して行うことができます。
15.4.2 フィジカル・スタンバイ・データベースのリカバリ・ステップ
REDOがフィジカル・スタンバイ・データベースに適用されると、データファイルの一部がリカバリ不能とマークされます。フィジカル・スタンバイ・データベースにフェイルオーバーするか、読取り専用アクセスでスタンバイ・データベースをオープンし、UNRECOVERABLE
のマークが付けられたブロックの範囲を読み取ろうとすると、次のようなエラー・メッセージが表示されます。
ORA-01578: ORACLE data block corrupted (file # 1, block # 2521) ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf' ORA-26040: Data block was loaded using the NOLOGGING option
STANDBY NOLOGGING FOR LOAD PERFORMANCE
モードを使用した場合も、フィジカル・スタンバイで実行された問合せがNOLOGGING操作による破損ブロックをレポートすることがあります。ただし、そのスタンバイでActive Data Guard構成の一部として管理リカバリが実行されている場合は、プライマリから置換ブロックが自動的にフェッチされます。(管理リカバリはALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT
文を使用して開始されます。)管理リカバリは、そのようなブロックが最初に作成された直後にそのすべてをフェッチしようとし、それらの修正を成功するまで試行し続けます。管理リカバリが開始されるたびに、前のリカバリ・セッションで未処理だったブロックの修正が再開されます。この自動リカバリは、STANDBY NOLOGGING FOR LOAD PERFORMANCE
モードを有効にして生成されたREDOが原因で発生した破損ブロックにのみ適用されます。従来のログに記録されない操作によって破損したブロックには、次の手順を使用する必要があります。このステップは、ログに記録されないすべてのブロックをリカバリする簡単な方法を示しています。(リカバリ不能な操作の後にバックアップが必要かどうかの決定 およびフィジカル・スタンバイ・データベースの一部分のリカバリなど、その他のアプローチについては後続の項を参照してください。)
-
スタンバイでリカバリを停止します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
-
RMANをスタンバイに接続し、次のコマンドを発行して、ログに記録されないブロックをリカバリします。
RMAN> RECOVER DATABASE NONLOGGED BLOCK;
ログに記録されないブロックがスイッチオーバー後にのみ検出される場合、これらの2つのステップを使用できますが、プライマリ・データベースを(開かずに)単にマウントして、RMANをプライマリに接続する必要があります。
RMANの
RECOVER
コマンドで、ログに記録されないブロックの一部をリカバリできないこともあります。これが起きる理由については、RMANコマンドが実行されたデータベースのアラート・ログに詳しく記載されています。最も一般的な理由は、プライマリで最近ブロックが変更されたが、まだ対応するデータファイルに書き込まれていないためです。つまり、スタンバイに送信されたブロックが古すぎて、スタンバイでリカバリ不能なブロックを置き換えることができないのです。 これを解決するには、ブロックをデータファイルに書き込んだ後で、再びRECOVER
コマンドを発行します。
次に、RECOVER
コマンドを実行して一部のブロックがリカバリ不能になった場合の、アラート・ログ・エントリの例を示します。
Started Nonlogged Block Replacement recovery on file 7 (ospid 13005 rcvid 11319003446180375696)
Finished Nonlogged Block Replacement recovery on file 7. 5 blocks remain
Statistics for replacement block source database (service=dg3tns)
(Use of it stopped due to error 12942 received from it)
Blocks requested 5, blocks received 0.
Reason replacement blocks accepted or rejected Blocks Last block
-------------------------------------------------------- ---------- ----------
Not received: Rejected by sender. Wrong state or SCN 5 21
この例では、スタンバイでコマンドが実行され、プライマリはブロックを送信せず、かわりに次のOracleエラーをレポートしました。
ORA-12942: database incarnation at source does not match
アラート・ログを調べたところ、プライマリでFLASHBACK DATABASE
およびOPEN RESETLOGS
コマンドが実行されたが、スタンバイはフラッシュバックされていないことが判明しました。つまり、スタンバイは現在REDOの孤立したブランチにいるため、プライマリは正しいバージョンであることが確認されているデータ・ブロックを提供できなかったのです。
ノート:
Data Guard構成に複数のスタンバイがある場合、スタンバイで実行されるRMANのRECOVER
コマンドは、プライマリからのみブロックを取得しようとします。RECOVER
コマンドをプライマリで実行した場合、適切なブロックを取得する可能性が最も高い1つのスタンバイ(通常、プライマリと最も密接に同期しているスタンバイ)からのみブロックを取得しようとします。
15.4.3 リカバリ不能処理後にバックアップが必要かどうかの判断
プライマリ・データベースでリカバリ不能な操作を実行した場合、新しいバックアップ操作が必要かどうかを判別する必要があります。
これを行うには、次のステップを実行します。
V$DATAFILE
ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
15.4.4 フィジカル・スタンバイ・データベースの一部分のリカバリ・ステップ
RMANのRECOVER ... NONLOGGED BLOCK
コマンドを使用して、データ・ファイルのセット、表領域のセット、または単に1つのプラガブル・データベース(PDB)およびマルチテナント・コンテナ・データベース(CDB)に属するブロックをリカバリできます。
この機能は、一部のデータ・ファイルに、ログに記録されないブロックを残すことが容認される場合に便利です(たとえば、現在削除されているオブジェクトに行をロードした結果として、ログに記録されないブロックが作成されたことがはっきりと分かっている場合など)。
V$NONLOGGED_BLOCK
ビューには通常、各データ・ファイルの既知の無効なブロックの範囲がリストされ、エントリはメディア・リカバリの一環として保持されます。ただし、情報が完全でないことがあります。通常、これはOracle Database 12cリリース1 (12.1)より前のリリースからアップグレードした後、またはデータ・ファイルのオペレーティング・システム・バックアップをリストアした後などです。次にメディア・リカバリを実行すると、失効エントリは削除されて新たに無効化されたブロックが記録されますが、前の無効なブロックはV$NONLOGGED_BLOCK
にエントリがありません。 データ・ファイルにV$NONLOGGED_BLOCK
エントリがない場合でも、V$DATAFILE
ビューのFIRST_NONLOGGED_SCN
列を使用して、データ・ファイルに少なくとも1つの無効なブロックが存在することを確認できます。
RMANコマンドVALIDATE ... NONLOGGED BLOCK
を使用して、V$NONLOGGED_BLOCK
のエントリをデータ・ファイルと再び同期できます。それには、既存の範囲が完全かどうかを判断し、完全でない場合は、必要なデータ・ファイルをスキャンして無効なブロックを識別し、それらがV$NONLOGGED_BLOCK
のエントリによって取得されるようにします。 VALIDATE ... NONLOGGED BLOCK
コマンドには、単にデータ・ファイルのセット、表領域のセット、またはPDBやCDBを検証するための、RECOVER ... NONLOGGED BLOCK
と同じオプションがあります。
ノート:
V$NONLOGGED_BLOCK
ビューのエントリは無効なブロックのスーパーセットであるため、無効なブロックに近い正常なブロックがいくつか含まれる可能性があります。 たとえば、ブロック100で始まるファイル7のエントリに、50のブロックが含まれる場合、これら50のブロックは一部または全部が無効であるか、いずれも無効ではありません。 VALIDATE
コマンドを実行すると、無効なブロックがない範囲はなくなり、範囲の最初と最後のブロックも無効なブロックになります。 ただし、制御ファイルで保持できる範囲の合計数には制限があるため、同じファイルの範囲を結合しなければならないことがあり、それが通常のブロックが範囲に含められる原因となります。
オフライン・データ・ファイルのみを検証またはリカバリする場合は、RMANコマンドの実行時に、それらが属するデータベースを開くことができます。
15.5 OMFまたはOracle ASMを使用するスタンバイ・データベースの作成
スタンバイ・データベースを作成するときは、プライマリ・データベースでOracle Managed Files (OMF)またはOracle Automatic Storage Management (Oracle ASM)を使用する場合に実行する必要のある追加ステップがあります。
この項の説明は、すでにフィジカル・スタンバイ・データベースの作成方法を理解しており、RMAN、OMFおよびOracle ASM機能に習熟していることを前提としています。
スタンバイ・データベースを作成する前に、次の準備作業を実行します。
-
プライマリ・データベースで強制ロギングを使用可能にします。
-
プライマリ・データベースでアーカイブを使用可能にします。
-
プライマリ・データベースで必要な初期化パラメータをすべて設定します。
-
スタンバイ・データベース用に初期化パラメータ・ファイルを作成します。
-
プライマリ・データベースがOMFを使用するよう構成されている場合、スタンバイ・データベースもOMFを使用するよう構成することをお薦めします。これを行うには、
DB_CREATE_FILE_DEST
およびDB_CREATE_ONLINE_LOG_DEST_
n
初期化パラメータに適切な値を設定します。プライマリおよびスタンバイ・データベースの両方で同じディスク・グループ名が使用されている場合、メンテナンスや後のロールの推移が簡易化されます。ノート:
スタンバイにOMFパラメータが設定されている場合は、そのスタンバイの新しいファイルはプライマリでの作成方法とは関係なく、常にOMFとして作成されます。したがって、
DB_FILE_NAME_CONVERT
およびDB_CREATE_FILE_DEST
パラメータの両方がスタンバイに設定されている場合は、DB_CREATE_FILE_DEST
パラメータが優先されます。 -
STANDBY_FILE_MANAGEMENT
初期化パラメータにAUTO
を設定します。 -
スタンバイ・データベースに接続するために、必要に応じてOracle Netを構成します。
-
REDO転送の認証を構成します。詳細は、「REDO転送の認証の構成」を参照してください。
-
制御ファイルをマウントせずにスタンバイ・データベース・インスタンスを起動します。
スタンバイ・データベースを作成するには、次の作業を実行します。
-
スタンバイ・データベースでOracle ASMを使用する場合、スタンバイ・データベース・システムにOracle ASMインスタンスが存在していなければ、インスタンスを作成します。
-
RMANの
BACKUP
コマンドを使用して、プライマリ・データベースのデータファイル、アーカイブ・ログ・ファイルおよびスタンバイ制御ファイルのコピーが含まれているバックアップ・セットを作成します。 -
RMANの
DUPLICATE FOR STANDBY
コマンドを使用して、バックアップ・セットのデータファイル、アーカイブREDOログ・ファイルおよびスタンバイ制御ファイルをスタンバイ・データベースの格納場所にコピーします。DUPLICATE FOR STANDBY
コマンドは、スタンバイ・インスタンスで実際のデータ移動を実行します。バックアップ・セットがテープ上にある場合、スタンバイ・インスタンスがバックアップ・セットを読み取れるように、メディア・マネージャを構成しておく必要があります。バックアップ・セットがディスク上にある場合は、ネットワーク・ファイル記憶域(NFS)でプライマリ・パス名を使用できるようにするか、スタンバイ・システムにコピーしてRMANのCATALOG BACKUPPIECE
コマンドを使用し、バックアップ・ピースをカタログに追加してからリストアを行うことで、スタンバイ・インスタンスがバックアップ・ピースを読み取れるようにする必要があります。
これらのステップを完了した後、「フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認」のステップを実行してフィジカル・スタンバイ・データベースの構成を確認します。
ロジカル・スタンバイ・データベースを作成するには、「ロジカル・スタンバイ・データベースの作成」で説明されているスタンバイ・データベースの作成プロセスを実行しますが、次の点を変更します。
これらのステップを完了した後、「ロジカル・スタンバイ・データベースのオープン」のステップを実行してロジカル・スタンバイ・データベースの起動、リカバリおよび検証を行います。
関連項目:
-
OMFの詳細は、『Oracle Database管理者ガイド』を参照してください。
-
Oracle ASMの詳細は、Oracle Automatic Storage Management管理者ガイドを参照
-
RMANの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
15.6 プライマリ・データベースでの書込みの欠落エラーからのリカバリ
Oracle Data Guard構成でのメディア・リカバリの実行中に、フィジカル・スタンバイ・データベースを使用してプライマリ・データベースで書込みの欠落によるデータ破損エラーを検出できます。
これは、プライマリ・データベースのREDOログに格納されているブロックのSCNをフィジカル・スタンバイ・データベースのブロックのSCNと比較して行います。プライマリ・データベースのブロックのSCNがスタンバイ・データベースのSCNよりも小さい場合は、プライマリ・データベースで書込みの欠落が発生しています。
そのような状況で、書込み欠落の検出(DB_LOST_WRITE_PROTECT
初期化パラメータで設定)がプライマリとスタンバイ両方のレベルで有効な場合、スタンバイでリカバリを試行するとORA-752
エラーになります。書込み欠落の検出が有効でない場合、リカバリを試行するとORA-600
[3020]
エラーになります。ただし、ORA-600
[3020]
エラーがすべて、プライマリにおける書込み欠落に起因するとはかぎりません。したがって、この項で説明するガイドラインに従う前にOracle Supportの担当者と協力し、ORA-600
[3020]
エラーの根本原因が本当に、プライマリで発生した書込みの欠落なのかどうかを判断します。My Oracle Supportのノート1265884.1 (http://support.oracle.com
)の『Resolving ORA-752 or ORA-600 [3020] During Standby Recovery』も参照してください。
ノート:
書込み欠落のエラーはプライマリによってブロックがキャッシュに読み取られた後、対応するREDOをスタンバイのブロックと比較した場合にのみ検出されるので、プライマリおよびスタンバイの両方で読取りや検証がまだ行われていない未検出ブロックが存在している可能性があります。古いブロックを読み取るまでに問合せや更新のためにスタンバイ上で使用したブロックのうち、現在適用しているREDOのSCNまでの全ブロックはスタンバイによる検証済なので、古いブロックが現行のデータベース操作に影響を及ぼすことはありません。
プライマリの書込みの欠落エラーがスタンバイで検出されると、失効したブロックごとに次のようなブロック・エラー・メッセージが1つ以上スタンバイ・データベースのアラート・ファイルに出力されます。
Tue Dec 12 19:09:48 2006 STANDBY REDO APPLICATION HAS DETECTED THAT THE PRIMARY DATABASE LOST A DISK WRITE OF BLOCK 26, FILE 7 NO REDO AT OR AFTER SCN 389667 CAN BE USED FOR RECOVERY. . . .
次に、アラート・ファイルは、ORA-00752
エラーがスタンバイ・データベースに発生し、管理リカバリが取り消されたことを示します。
Slave exiting with ORA-752 exception Errors in file /oracle/log/diag/rdbms/dgstwrite2/stwrite2/trace/stwrite2_pr00_23532.trc: ORA-00752: recovery detected a lost write of a data block ORA-10567: Redo is inconsistent with data block (file# 7, block# 26) ORA-10564: tablespace TBS_2 ORA-01110: data file 7: '/oracle/dbs/btbs_21.f' ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 57503 . . .
次に、スタンバイ・データベースは、アラート・ファイルに出力されたSCN時点で、このエラーによるデータファイルの破損がない、一貫した状態にリカバリされます。
Recovery interrupted! Recovered data files to a consistent state at change 389569
この最後のメッセージは、アラート・ファイルのかなり後の方に表示されることがあり、ブロック・エラー・メッセージより小さいSCNの場合もあります。また、プライマリ・データベースは、すでにデータファイルに破損があってもエラーが表示されずに動作している場合があります。
このようなエラーからリカバリするための推奨手順は、次のステップに示すように、フィジカル・スタンバイにフェイルオーバーします。
プライマリで書込みの欠落が検出された後のフィジカル・スタンバイへのフェイルオーバーのステップ
-
プライマリ・データベースを停止します。ブロック・エラー・メッセージに出力されたSCN以降のデータがすべて消失します。
-
スタンバイ・データベースで次のSQL文を発行してプライマリに変換します。
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE; Database altered. Tue Dec 12 19:15:23 2006 alter database activate standby database ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE (stwrite2) RESETLOGS after incomplete recovery UNTIL CHANGE 389569 Resetting resetlogs activation ID 612657558 (0x24846996) Online log /oracle/dbs/bt_log1.f: Thread 1 Group 1 was previously cleared Online log /oracle/dbs/bt_log2.f: Thread 1 Group 2 was previously cleared Standby became primary SCN: 389567 Tue Dec 12 19:15:23 2006 Setting recovery target incarnation to 3 Converting standby mount to primary mount. ACTIVATE STANDBY: Complete - Database mounted as primary (stwrite2) Completed: alter database activate standby database
-
新しいプライマリのバックアップを行います。データベースの完全なバックアップ・コピーがなければ、フェイルオーバー後の変更をリカバリすることができないので、バックアップをすぐに実行することは安全策として必要な作業です。フェイルオーバーを行うと元のプライマリ・データベースはOracle Data Guard構成に含まれなくなり、その他のすべてのスタンバイ・データベースが新しいプライマリ・データベースからREDOデータの受信と適用を行うようになります。
-
新規プライマリ・データベースをオープンします。
-
オプションのステップとして、失敗したプライマリをフィジカル・スタンバイとして再作成します。これはステップ3で新しいプライマリで作成したデータベース・バックアップを使用して実行できます。(この場合は、フラッシュバック・データベースまたはOracle Data Guardブローカを使用して、元のプライマリ・データベースを回復することはできません。)新しいプライマリから作成したバックアップを使用して作成したフィジカル・スタンバイは、古いスタンバイと同じデータ・ファイルを保持することに注意してください。したがって、新しいスタンバイでは同じブロックを比較するため、古いスタンバイがアクティブ化される前に存在していた未検出の書込みの欠落は、新しいスタンバイによって検出されません。プライマリまたはスタンバイで発生した新しい書込みの欠落はすべて検出されます。
関連項目:
書込み欠落の検出有効化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
15.7 DBCOMPプロシージャを使用した欠落書込みおよびその他の不一致の検出
PL/SQLプロシージャDBMS_DBCOMP.DBCOMP
を使用して、欠落書込みの検出およびプライマリ・データベースとフィジカル・スタンバイ・データベースの間の不一致の検出も可能です。
DBMS_DBCOMP.DBCOMP
プロシージャでは、プライマリ・データベースとフィジカル・スタンバイ・データベースの同じデータ・ブロックが比較されます。このプロシージャはいつでも実行できます。(DB_LOST_WRITE_PROTECT
初期化パラメータを有効化する必要はありません。)
V$SESSION_LONGOPS
ビューを問い合せると、継続中のブロック比較操作の進捗状況を監視できます。
ノート:
ロジカル・スタンバイ・データベース、遠隔同期インスタンスおよびカスケード・スタンバイは、DBMS_DBCOMP.DBCOMP
プロシージャのターゲット・データベースにはなれません。
DBMS_DBCOMP.DBCOMP
プロシージャでは、1つのプライマリ・データベースと1つ以上のフィジカル・スタンバイ・データベースがあることを前提としています。データベースはブロック比較の前に少なくともマウントされている必要があります。
次の例の場合、一意の名前のdgmain
を持ったプライマリ・データベースがあり、フィジカル・スタンバイ・データベースの名前がdgmainb
、dgmainc
、dgmaind
などであると仮定します。
例15-1 プライマリおよびすべてのスタンバイがマウントまたはオープンされており、DBCOMPがプライマリから実行される場合
この場合、DBCOMP
プロシージャをプラマリ・データベースから実行すると、指定されたデータ・ファイルはプライマリとすべてのフィジカル・スタンバイ・データベースの間でブロック単位で比較されます。たとえば、次の問合せを実行するとします。
SQL> exec sys.dbms_dbcomp.dbcomp(‘1’,’BlockCompare’,:retval);
生成される出力ファイルはBlockCompare_dgmainb_1
およびBlockCompare_dgmainc_d_1
です。
例15-2 プライマリおよびすべてのスタンバイがマウントまたはオープンされており、DBCOMPがスタンバイから実行される場合
この場合、DBCOMP
プロシージャをスタンバイ・データベースの1つ(たとえばdgmainb
)から実行すると、指定されたデータ・ファイルはプライマリと特定のスタンバイ・データベースの間でのみ比較されます。その他のスタンバイ・データベースは考慮されません。たとえば、次の問合せを実行するとします。
SQL> exec sys.dbms_dbcomp.dbcomp(‘1’,’BlockCompare’,:retval);
生成される出力ファイルはBlockCompare_dgmain_1
です。
例15-3 プライマリがマウントまたはオープンされているが、スタンバイはすべてがマウントまたはオープンされているとはかぎらず、DBCOMPがプライマリから実行される場合
この場合、DBCOMP
プロシージャをプラマリで実行すると、指定されたデータ・ファイルはプライマリ・データベースとマウントまたはオープンされたフィジカル・スタンバイ・データベースの間で比較されます。マウントもオープンもされていないスタンバイ・データベースの場合、処理はされません。
例15-4 プライマリがマウントまたはオープンされているが、スタンバイはすべてがマウントまたはオープンされているとはかぎらず、DBCOMPがスタンバイから実行される場合
この場合、指定されたデータ・ファイルはプライマリとDBCOMP
プロシージャの実行元のスタンバイの間で比較されます。
例15-5 プライマリがマウントされていないが、複数のスタンバイがマウントまたはオープンされている場合
プライマリ・データベースはマウントもオープンもされていないため、DBCOMP
プロシージャは、比較するプライマリとフィジカル・スタンバイ・データベースの適切なペアを見つけることができません。ORA
エラー・メッセージは返されませんが、次のようなメッセージが対応する出力ファイルに出力されます: Remote database is not in the primary role
.
例15-6 プライマリがマウントまたはオープンされているが、マウントまたはオープンされているスタンバイがない場合
プライマリとフィジカル・スタンバイ・データベースの適切なペアが見つからないため、対応する出力ファイルにメッセージが出力されますが、ORA
エラーは返されません。
15.8 RMANバックアップを使用した障害が発生したプライマリのスタンバイ・データベースへの変換
障害が発生したプライマリ・データベースを変換するには、プライマリでフラッシュバック・データベース機能を有効にし、必要に応じて次のいずれかの手順に従うことをお薦めします。
これらの項の手順では、障害が発生したプライマリをフィジカル・スタンバイまたはロジカル・スタンバイに変換する最も速い方法を説明しています。しかし、障害が発生したプライマリでフラッシュバック・データベースが無効になっている場合でも、次のトピックで説明するように、障害が発生したプライマリのローカル・バックアップを使用して、障害が発生したプライマリをフィジカル・スタンバイまたはロジカル・スタンバイに変換できます。
15.8.1 RMANバックアップを使用した、障害が発生したプライマリのフィジカル・スタンバイへの変換
このステップでは、RMANバックアップを使用して障害が発生したプライマリをフィジカル・スタンバイに変換する方法について説明します。
この手順には、古いプライマリのCOMPATIBLE
初期化パラメータが11.0.0以上に設定されている必要があります。
-
新しいプライマリ・データベース上で次の問合せを発行し、古いスタンバイ・データベースが新しいプライマリ・データベースになったSCNを判別します。
SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
-
スタンバイが新しいプライマリになったSCN(
standby_became_primary_scn
)に古いプライマリが到達する前に作成したバックアップを使用して、データベースをリストアします。次に、Point-in-Timeリカバリを実行して、古いプライマリをそれと同じ時点までリカバリします。次のRMANコマンドを発行します。
RMAN> RUN { SET UNTIL SCN <standby_became_primary_scn + 1>; RESTORE DATABASE; RECOVER DATABASE; }
ユーザー管理リカバリでは、先にデータベースを手動でリストアできます。通常、フェイルオーバー前の、数時間を要したバックアップは古くなっています。そのため、障害が発生したプライマリは次のコマンドを使用してリカバリできます。
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CHANGE - > <standby_became_primary_scn + 1>;
フラッシュバック・データベースを使用する再インスタンス化とは異なり、この手順では
standby_became_primary_scn
に1を加算します。データファイルの場合、SCNまでフラッシュバックすることは、そのSCNに1を加算するまでリカバリすることと同義です。 -
古いプライマリ・データベースで次のステップを実行します。
-
古いプライマリ・データベースで次の文を発行します。
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
-
データベースを停止して、再開します。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;
-
-
次のコマンドを発行します。
SQL> ALTER DATABASE OPEN READ ONLY;
このステップの目的は、ディクショナリ・チェックを使用して制御ファイルをデータベースと同期させることです。このコマンドの後に、ディクショナリ・チェックで示されたアクションがないかアラート・ログをチェックします。通常、フェイルオーバー中に古いプライマリがデータファイルを追加または削除している途中でなければ、ユーザー・アクションは必要ありません。
-
Oracle Active Data Guardオプション用にライセンスを購入しているときに、フィジカル・スタンバイ・データベースをアクティブ問合せモードで使用する場合は、このステップをスキップします。それ以外の場合は、スタンバイ・データベースをMOUNT状態にします。
次に例を示します。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;
-
新しいスタンバイ・データベースの作成前に、新しいプライマリ・データベースは、リモート宛先へのREDOの転送を停止しているはずです。REDO転送サービスを再開するには、新しいプライマリ・データベースで次のステップを実行します。
-
次の問合せを発行し、アーカイブ宛先の現在の状態を調べます。
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, - > ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
-
必要に応じて、宛先を使用可能にします。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
-
スタンバイ・データベースが新しいプライマリ・データベースからのREDOデータの受信を確実に開始するよう、ログ・スイッチを実行し、これが成功したことを確認します。
ノート:
これは、新しいプライマリに続いて、古いプライマリが新しいスタンバイになるために重要なステップです。このステップが実行されないと、古いプライマリは誤ったデータベース・ブランチにリカバリされます。問題を修正する唯一の方法は、古いプライマリを再度変換することです。
SQLプロンプトで次の文を入力します。
SQL> ALTER SYSTEM SWITCH LOGFILE; SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, - > ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
新しいスタンバイ・データベースで、REDO転送サービスがREDOデータを別のデータベースに転送しないよう、
LOG_ARCHIVE_DEST_
n
初期化パラメータも変更する必要があります。1つのサーバー・パラメータ・ファイル(SPFILE)でプライマリおよびスタンバイ・データベース・ロールの両方がVALID_FOR
属性で設定されている場合、このステップを実行する必要はありません。これにより、Oracle Data Guard構成は、ロールの推移後も正しく動作します。
-
-
次のようにして、新しいフィジカル・スタンバイ・データベースでREDO Applyを開始します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の(障害発生前の)ロールに推移できます。詳細は、「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」を参照してください。
15.8.2 RMANバックアップを使用した障害が発生したプライマリのロジカル・スタンバイへの変換
このステップでは、RMANバックアップを使用して障害が発生したプライマリをロジカル・スタンバイに変換する方法について説明します。
-
新しいプライマリ・データベースで次の問合せを発行し、障害が発生したプライマリ・データベースをリカバリするSCNを判別します。
SQL> SELECT APPLIED_SCN RECOVERY_SCN FROM V$LOGSTDBY_PROGRESS;
また、新しいプライマリ・データベースで、次のようにして、アーカイブ・ログの処理に使用するSCNを判別します。
-
すべてのスタンバイREDOログを必ずアーカイブしておきます。次の問合せを発行し、戻される
NONE
の値を検索します。データベースのサイズおよびアーカイブする必要があるログの数によって、NONE
のステータスが戻されるまでしばらく時間がかかることがあります。SQL> SELECT PENDING_ROLE_CHANGE_TASKS FROM V$DATABASE;
-
NONE
のステータスが戻されたら、次の問合せを実行し、このリカバリの一環としてアーカイブ・ログの処理のためのSCNを取得します。SQL> SELECT VALUE ARCHIVE_SCN FROM SYSTEM.LOGSTDBY$PARAMETERS - > WHERE NAME='STANDBY_BECAME_PRIMARY_SCN';
-
-
フェイルオーバー操作以後に作成されたアーカイブ・ログをすべて、障害が発生したプライマリ・データベースから削除します。障害が発生したプライマリ・データベースがスタンバイから分離されていた場合は、現行のプライマリ・データベースと一貫性がない不一致のアーカイブ・ログが存在する可能性があります。これらの不一致のアーカイブ・ログを適用しないようにするには、バックアップおよび高速リカバリ領域から削除する必要があります。次のRMANコマンドを使用すると、関連アーカイブ・ログを高速リカバリ領域から削除できます。
RMAN> DELETE FORCE ARCHIVELOG FROM SCN ARCHIVE_SCN;
削除されると、これらの不一致のログおよび後続のトランザクションはリカバリできなくなります。
-
新しいプライマリ・データベースで、次の問合せを発行し、バックアップからリカバリする前に、障害が発生したプライマリ・データベースにコピーする必要があるログ・ファイルの最小セットを判別します。
SQL> SELECT file_name FROM DBA_LOGSTDBY_LOG WHERE next_change# > ARCHIVE_SCN;
必要なスタンバイ・ログを取得し、バックアップ・セットを新しいスタンバイにコピーして新しい高速フラッシュ・リカバリ領域にリストアします。これらのログはスタンバイREDOログから得られるため、スタンバイの標準アーカイブの一部ではありません。RMANユーティリティでは、部分的なファイル名を使用して正しい場所からファイルを取得できます。
次に、RMANの
BACKUP
コマンドの使用例を示します。RMAN> BACKUP AS COPY DEVICE TYPE DISK FORMAT '/tmp/test/%U' > ARCHIVELOG LIKE '<partial file names from above>%';
次に、RMANの
RESTORE
コマンドの使用例を示します。RMAN> CATALOG START WITH '/tmp/test'; RMAN> RESTORE ARCHIVELOG FROM SEQUENCE 33 UNTIL SEQUENCE 35;
-
元のプライマリの全データファイルのバックアップをリストアし、
RECOVERY_SCN + 1
までリカバリします。現行の制御ファイルを利用することをお薦めします。-
データベースを制限モードで起動して、データベースのオープン後に
GUARD ALL
コマンドが発行されるまでローグ・トランザクションから保護します。 -
バックアップを使用して障害が発生したプライマリ・データベースのデータファイルをリストアします。
-
フラッシュバック・データベースが有効な場合は、無効にします(
USING BACKUP CONTROLFILE
句に必要)。 -
SQL*Plusで、
RECOVERY_SCN +1
までPoint-in-Timeリカバリを実行します。
現行の制御ファイルを使用してもバックアップ制御ファイルを使用しても、
USING BACKUP CONTROLFILE
句を指定してリストアされるアーカイブ・ログを指すことができるようにする必要があります。指定しないと、リカバリ・プロセスでは、ステップ3で取得したログではなく、オンラインREDOログへのアクセスが試行されることがあります。ステップ3で取得した順序の入力を求められた場合は、次のようにリストアされるアーカイブ・ログのコピーのファイル名を指定します。SQL> RECOVER DATABASE UNTIL CHANGE RECOVERY_SCN + 1 USING BACKUP CONTROLFILE;
-
-
RESETLOGSオプションを指定してデータベースをオープンします。
SQL> ALTER DATABASE OPEN RESETLOGS;
-
Database Guardの有効化
SQL> ALTER DATABASE GUARD ALL;
-
新しいプライマリ・データベースへのデータベース・リンクを作成してSQL Applyを開始します。
SQL> CREATE PUBLIC DATABASE LINK myLink - > CONNECT TO SYSTEM IDENTIFIED BY password - > USING 'service name of new primary database';
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY myLink;
この時点で、制限セッション(
ALTER SYSTEM DISABLE RESTRICTED SESSION
)を無効にできます。つまり、データベースを再起動してステップ4cのフラッシュバックを再度有効にする必要がある場合は、RESTRICTED SESSION
をオフにして再起動します。
15.9 フィジカル・スタンバイの再作成を伴わないプライマリの文字セットの変更
Oracle Data Guardでは、構成内のフィジカル・スタンバイ・データベースを再作成することなく、プライマリ・データベースのデータベース文字セットと各国語文字セットの両方を変更できます。
プライマリ・データベースの文字セット変換の実行中に、中断を最小限に抑えて、フィジカル・スタンバイ・データベースを使用し続けることができます。
文字セット移行プロセスは、考えられる問題の調査や問題を解決する方法の特定など、準備ステップで構成されます。これらの準備ステップの実行中、Oracle Data Guard構成は変わらず動作でき、フィジカル・スタンバイを維持するために何ら追加のステップは必要ありません。準備ステップの完了後、実際の変換が実行されます。これにはシステム・データ(メタデータ)およびユーザー・データの両方への変更が含まれる可能性があります。Oracle Data Guardに特有のいくつかの手順を、変換の一部として実行する必要があります。これらを実行する手順には、Database Migration Assistant for Unicode (DMU)やその他の適切な文字セットの変換ツールにより実行されるステップが組み入れられています。
このプロセスに必要なステップの詳細は、http://support.oracle.com
にあるMy Oracle Support ノート1124165.1を参照してください。
15.10 プライマリでのPDB PITRまたはPDBフラッシュバック後にスタンバイで必要なアクション
プライマリでPDB PITRまたはPDBフラッシュバックを実行した後、スタンバイ上のPDBまたはフラッシュバックをリストアしてプライマリをスタンバイに継がせることができます。
プライマリでPDB PITRまたはPDBフラッシュバックを実行し、操作の開始に関するREDOが初めて検出されると、スタンバイでのMRPはエラーORA-39874
に続いて補助エラーORA-39873
で終了します。次に、アラート・ログに出力されるメッセージの例を示します。
Recovery of pluggable database PDB1 aborted due to pluggable database open resetlog marker. To continue recovery, restore all data files for this PDB to checkpoint SCN lower than 1437261, or timestamp before 11/15/2012 16:38:49, and restart recovery MRP0: Background Media Recovery terminated with error 39874 ORA-39874: Pluggable Database PDB1 recovery halted ORA-39873: Restore all data files to a checkpoint SCN lower than 1437261.
スタンバイでメディア・リカバリをこれ以上続ける前に、そのPDBのすべてのデータファイルをリストアする必要があります。それは、次の2つの方法で行うことができます。
-
スタンバイでフラッシュバックが有効化されている場合は、スタンバイでPDBフラッシュバックを使用してから、スタンバイ管理リカバリを再開できます。下の「フラッシュバックが有効化されている場合のリカバリの実行」を参照してください。
-
スタンバイでフラッシュバックが有効化されていない場合、プライマリでPDBがリカバリされた時点より前に作成したバックアップから、リカバリを実行できます。下の「フラッシュバックが有効化されていない場合のリカバリの実行」を参照してください。
どちらの方法でも、プライマリでPDB PITRまたはフラッシュバックが行われたPDBは、スタンバイがプライマリに追い付くまで、スタンバイで開くことができません。
フラッシュバックが有効化されている場合のリカバリの実行
スタンバイでフラッシュバックが有効化されている場合は、スタンバイでPDBをフラッシュバックしてから、スタンバイ管理リカバリを再開できます。
-
影響を受けるPDBおよびPITR SCNを特定します。
リカバリが停止したPDBの名前は
ORA-39874
メッセージに、PITR SCNはORA-39873
メッセージに表示されます。 -
スタンバイ・データベースがまだ開いている場合は、それを閉じます。
SQL> ALTER DATABASE CLOSE;
-
スタンバイでプラガブル・データベースをフラッシュバックします。
SQL> FLASHBACK PLUGGABLE DATABASE pdb1 TO SCN 1437260;
TO SCN
とUNTIL SCN
はセマンティックが異なるため、FLASHBACK PLUGGABLE DATABASE
コマンドのSCNは、前の例のように1437261
ではなく1437260
です。 -
スタンバイでメディア・リカバリを再開します。
SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT;
フラッシュバックが有効化されていない場合のリカバリの実行