| Oracle® Data Guard概要および管理 12c リリース1 (12.1) B71304-07 |
|
 前 |
 次 |
Oracle Data Guard構成の管理中に遭遇する可能性がある様々な状況の、サンプル・シナリオが用意されています。次の使用例はそれぞれ、ユーザー固有の環境に適応できます。
この項では、プライマリ・データベースを別のスタンバイ・データベースにフェイルオーバーした後に、ロジカル・スタンバイ・データベースで実行する必要のある手順について説明します。フェイルオーバーの発生後、ロジカル・スタンバイ・データベースは、元のプライマリ・データベースからの最後のREDOが適用されるまで、新規プライマリ・データベースのスタンバイ・データベースとして機能できません。これは、フェイルオーバー中に新規のプライマリ・データベースで最後のREDOが適用される場合と同じです。実行する必要のある手順は、新規プライマリ・データベースがフェイルオーバー前にフィジカル・スタンバイ・データベースであったかロジカル・スタンバイ・データベースであったかに応じて異なります。
このシナリオの次の手順では、プライマリ・ロールを担う前はフィジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするように、ロジカル・スタンバイ・データベースを構成する方法について説明します。この使用例では、SATはロジカル・スタンバイ・データベース、NYCはプライマリ・データベースです。
SATデータベースで次の文を発行して、ログ・ファイルの自動リカバリを有効化するためにFAL_SERVERパラメータを構成します。
SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>';
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> SELECT PENDING_ROLE_CHANGE_TASKS FROM V$DATABASE;
注意:
古いプライマリ・データベースを修復しようとする前に、NONEの値が戻される必要があります。
このシナリオの次の手順では、プライマリ・ロールを担う前はロジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするように、ロジカル・スタンバイ・データベースを構成する方法について説明します。この使用例では、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>';
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;
フェイルオーバーの発生後、元のプライマリ・データベースは、修正され、新しい構成のスタンバイ・データベースとして確立されるまで、Oracle Data Guard構成に含められません。これを行うには、フラッシュバック・データベース機能を使用して、障害の発生したプライマリ・データベースを障害発生前の時点にフラッシュバックし、その後新しい構成内のフィジカルまたはロジカル・スタンバイ・データベースに変換します。次の各項で、次の内容を説明します。
障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバック
注意:
フェイルオーバー前に、元のプライマリ・データベースでフラッシュバック・データベースが使用可能になっている必要があります。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
特定の適用済SCNへのロジカル・スタンバイ・データベースのフラッシュバック
関連項目:
失敗したプライマリ・データベースを新しいデータベースとして自動回復する(フラッシュバック・データベースを使用するかわりに)方法は、『Oracle Data Guard Broker』を参照してください。
次の手順では、フィジカル・スタンバイ・データベースに対してフェイルオーバーが実行され、ファイルオーバーの際に古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。この手順では、古いプライマリ・データベースをフィジカル・スタンバイ・データベースとして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回以上再起動する必要があります。障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の(障害発生前の)ロールに推移できます。詳細は、「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」を参照してください。
次の手順では、Oracle Data Guard構成ですでにロジカル・スタンバイ・データベースを使用したフェイルオーバーが実行済で、古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。この手順は、新しいプライマリ・データベースから古いプライマリ・データベースを正式にインスタンス化せずに、古いプライマリ・データベースを新しいロジカル・スタンバイ・データベースとしてOracle Data Guard構成に戻します。
スタンバイ・データベースのメリットの1つは、プライマリ・データベース・サービスに影響を与えずに、スタンバイ・データベースでフラッシュバック・データベースを実行できることです。データベースを特定の時点までフラッシュバックするタスクは簡単ですが、ロジカル・スタンバイ・データベースでは、既知のトランザクションがコミットされる直前の時点までフラッシュバックする操作が必要になる場合があります。このような必要が生じるのは、フェイルオーバー後に新しいプライマリ・データベースを使用してロジカル・スタンバイ・データベースを構成する場合です。
次の手順では、フラッシュバック・データベースとSQL Applyを使用して既知の適用済SCNまでリカバリする方法について説明します。
スタンバイ・データベースがリアルタイム適用を使用しているOracle Data Guard構成で、プライマリ・データベースでエラーが発生したとします。この場合、同じエラーがスタンバイ・データベースにも適用されます。
ただし、フラッシュバック・データベースが有効化されている場合は、FLASHBACK DATABASEおよびOPEN RESETLOGS文をプライマリ・データベースに対して発行し、同様のFLASHBACK STANDBY DATABASE文をスタンバイ・データベースに発行した後に、適用サービスを再起動することで、プライマリとスタンバイ・データベースをエラー前の状態に戻すことができます。(フラッシュバック・データベースが有効化されていない場合は、プライマリ・データベースのポイント・イン・タイム・リカバリを実行後、「フィジカル・スタンバイ・データベースの作成」と「ロジカル・スタンバイ・データベースの作成」で説明しているスタンバイ・データベースの再作成が必要です。)
次の手順では、プライマリ・データベースでOPEN RESETLOGS文を発行した後、フィジカル・スタンバイ・データベースの再作成を回避する方法を説明します。
次の手順では、プライマリ・データベースをフラッシュバックし、OPEN RESETLOGS文を発行してオープンした後、ロジカル・スタンバイ・データベースの再作成を回避する方法を説明します。
注意:
SQL Applyは、プライマリ・データベースでリセットログ操作の発生を検出すると、ロジカル・スタンバイ・データベースをフラッシュバックしなくてもマイニングできる場合は、REDOの正しいブランチを自動的にマイニングします。それ以外の場合、SQL Applyは「ORA-1346: 指定されたリセット・ログscnを超えてLogMinerがREDOを処理しました」エラーで停止します。この項では、SQL Applyはこのエラーですでに停止していると仮定しています。
いくつかのSQL文で、ユーザーはオプションとしてNOLOGGING句を指定できます。このオプションを指定すると、データベース操作がオンラインREDOログ・ファイルに記録されません。ユーザーがこの句を指定しても、REDOはオンラインREDOログ・ファイルに書き込まれます。ただし、このレコードにはデータが関連付けられていません。これによりスタンバイ・サイトでのログ・アプリケーションまたはデータ・アクセス・エラーが発生し、このログ・ファイルを適用するには手動でのリカバリが必要になることがあります。
ロジカル・スタンバイ・データベースの場合は、SQL ApplyでNOLOGGING句を使用して対象の表で実行された操作のREDOレコードが検出されると、「ORA-16211: サポートされていないレコードが、アーカイブREDOログで見つかりました。」エラーで停止します。
NOLOGGING句を指定した後のリカバリには、「ロジカル・スタンバイ・データベースでの表の追加または再作成」に説明されているように、プライマリ・データベースから1つ以上の表を再作成します。
注意:
通常、NOLOGGING句の使用はお薦めしません。また、プライマリ・データベース内の特定の表でNOLOGGING句を使用する操作が実行されることが事前にわかっている場合は、DBMS_LOGSTDBY.SKIPプロシージャを使用して、これらの表に関連付けられているSQL文をロジカル・スタンバイ・データベースに適用しないようにできます。
スタンバイ・サイトにコピーされたアーカイブ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
NOLOGGING句が指定された後でリカバリするには、欠落しているREDOデータが含まれているデータファイルをプライマリ・サイトからフィジカル・スタンバイ・サイトにコピーする必要があります。次の手順に従ってください。
次のようにコピーするデータ・ファイルを決定します。
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE; NAME UNRECOVERABLE ----------------------------------------------------- ------------- /oracle/dbs/tbs_1.dbf 5216 /oracle/dbs/tbs_2.dbf 0 /oracle/dbs/tbs_3.dbf 0 /oracle/dbs/tbs_4.dbf 0 4 rows selected.
スタンバイ・データベースを問い合せます。
SQL> SELECT NAME, UNRECOVERABLE_CHANGE# FROM V$DATAFILE; NAME UNRECOVERABLE ----------------------------------------------------- ------------- /oracle/dbs/stdby/tbs_1.dbf 5186 /oracle/dbs/stdby/tbs_2.dbf 0 /oracle/dbs/stdby/tbs_3.dbf 0 /oracle/dbs/stdby/tbs_4.dbf 0 4 rows selected.
プライマリ・データベースの問合せ結果とスタンバイ・データベースの問合せ結果を比較します。
両方の問合せ結果のUNRECOVERABLE_CHANGE#列の値を比較します。プライマリ・データベースのUNRECOVERABLE_CHANGE#列の値の方が、スタンバイ・データベースの同じ列の値より大きい場合は、データファイルをプライマリ・サイトからスタンバイ・サイトへコピーする必要があります。
この例では、tbs_1.dbfデータファイルのプライマリ・データベースにあるUNRECOVERABLE_CHANGE#の値の方が大きいため、tbs_1.dbfデータファイルをスタンバイ・サイトにコピーする必要があります。
プライマリ・サイトで、次のSQL文を発行して、スタンバイ・サイトにコピーする必要があるデータファイルのバックアップを作成します。
SQL> ALTER TABLESPACE system BEGIN BACKUP; SQL> EXIT;
必要なデータファイルをローカル・ディレクトリにコピーします。
SQL> ALTER TABLESPACE system END BACKUP;
欠落しているREDOデータが含まれているデータファイルを、プライマリ・サイトからリカバリ関連のファイルが格納されているフィジカル・スタンバイ・サイトにコピーします。
スタンバイ・データベースに次のSQL文を発行して、Redo Applyを再開します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
REDO Applyを再開しようとすると、次のエラー・メッセージが(通常アラート・ログに)表示されることがあります。
ORA-00308: cannot open archived log 'standby1' ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3 ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01152: file 1 was not restored from a sufficiently old backup ORA-01110: data file 1: '/oracle/dbs/stdby/tbs_1.dbf'
ORA-00308エラーが表示され、REDO Applyが自動的に終了しない場合は、別の端末のウィンドウから次のSQL文を発行して、リカバリを取り消すことができます。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
これらのエラー・メッセージは、アーカイブ・ギャップ内にある1つ以上のログ・ファイルが正常に適用されなかった場合に戻されます。これらのエラーを受け取った場合は、ギャップを手動で解決し、手順4を繰り返します。アーカイブ・ギャップの手動による解決方法の詳細は、「手動によるギャップの解決」を参照してください。
「フィジカル・スタンバイ・データベースの作成」と「ロジカル・スタンバイ・データベース」で、フィジカルおよびロジカル・スタンバイ・データベースを作成する方法を説明しています。この項では、プライマリ・データベースでOracle Managed Files(OMF)またはOracle Automatic Storage Management(Oracle ASM)を使用する場合に実行する必要のある追加手順を説明し、これらの章を補完します。
注意:
この項の説明は、すでにフィジカル・スタンバイ・データベースの作成方法を理解しており、RMAN、OMFおよびOracle ASM機能に習熟していることを前提としています。詳細は、次の資料を参照してください。
フィジカルおよびロジカル・スタンバイ・データベースの作成の詳細は、「フィジカル・スタンバイ・データベースの作成」、「ロジカル・スタンバイ・データベース」および「Recovery Managerを使用したスタンバイ・データベースの作成」を参照してください。
OMFの詳細は、『Oracle Database管理者ガイド』を参照してください。
Oracle ASMの詳細は、Oracle Automatic Storage Management管理者ガイドを参照
RMANの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』および『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
スタンバイ・データベースを作成する前に、次の準備作業を実行します。
プライマリ・データベースで強制ロギングを使用可能にします。
プライマリ・データベースでアーカイブを使用可能にします。
プライマリ・データベースで必要な初期化パラメータをすべて設定します。
スタンバイ・データベース用に初期化パラメータ・ファイルを作成します。
プライマリ・データベースが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コマンドを使用し、バックアップ・ピースをカタログに追加してからリストアを行うことで、スタンバイ・インスタンスがバックアップ・ピースを読み取れるようにする必要があります。
これらの手順を完了した後、「フィジカル・スタンバイ・データベースが正しく実行されているかどうかの確認」の手順を実行してフィジカル・スタンバイ・データベースの構成を確認します。
ロジカル・スタンバイ・データベースを作成するには、「ロジカル・スタンバイ・データベースの作成」で説明されているスタンバイ・データベースの作成プロセスを実行しますが、次の点を変更します。
これらの手順を完了した後、「ロジカル・スタンバイ・データベースのオープン」の手順を実行してロジカル・スタンバイ・データベースの起動、リカバリおよび検証を行います。
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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
障害が発生したプライマリ・データベースを変換するには、プライマリでフラッシュバック・データベース機能を有効にし、「障害が発生したプライマリ・データベースのフィジカル・スタンバイ・データベースへのフラッシュバック」または「障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバック」で説明した手順に従うことをお薦めします。これらの項の手順では、障害が発生したプライマリをフィジカル・スタンバイまたはロジカル・スタンバイに変換する最も速い方法を説明しています。しかし、障害が発生したプライマリでフラッシュバック・データベースが無効になっている場合でも、次の項で説明するように、障害が発生したプライマリのローカル・バックアップを使用して、障害が発生したプライマリをフィジカル・スタンバイまたはロジカル・スタンバイに変換できます。
この項の手順では、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;
障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の(障害発生前の)ロールに推移できます。詳細は、「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」を参照してください。
この項の手順では、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 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をオフにして再起動します。
Oracle Data Guardでは、構成内のフィジカル・スタンバイ・データベースを再作成することなく、プライマリ・データベースのデータベース・キャラクタ・セットと各国語キャラクタ・セットの両方を変更できます。プライマリ・データベースのキャラクタ・セット変換の実行中に、中断を最小限に抑えて、フィジカル・スタンバイ・データベースを使用し続けることができます。
キャラクタ・セット移行プロセスは、考えられる問題の調査や問題を解決する方法の特定など、準備手順で構成されます。これらの準備手順の実行中、Oracle Data Guard構成は変わらず動作でき、フィジカル・スタンバイを維持するために何ら追加の手順は必要ありません。準備手順の完了後、実際の変換が実行されます。これにはシステム・データ(メタデータ)およびユーザー・データの両方への変更が含まれる可能性があります。Oracle Data Guardに特有のいくつかの手順を、変換の一部として実行する必要があります。これらを実行する手順には、Database Migration Assistant for Unicode (DMU)やその他の適切なキャラクタ・セットの変換ツールにより実行される手順が組み入れられています。
このプロセスに必要な手順の詳細は、http://support.oracle.comにあるMy Oracle Support Note 1124165.1を参照してください。
プラガブル・データベース(PDB)のPoint-in-Timeリカバリ(PITR)は、スタンバイではできません。しかし、プライマリではPDB PITRを実行できるため、その後にスタンバイでリカバリします。
プライマリでPDB PITRを実行し、PDB PITR操作の開始に関する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がリカバリされた時点より前に作成したバックアップから、そのPDB用のすべてのデータファイルをリストアする必要があります。補助エラーORA-39873は、Point-in-TimeリカバリSCNを示します。スタンバイで次の手順を実行します。
プライマリでPDB PITRが行われたPDBは、スタンバイ・リカバリでそのPDBのリセットログ操作によってリカバリしないかぎり、スタンバイで開くことができません。
関連項目:
PDBのPoint-in-Timeリカバリの実行の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
