11gリリース1（11.1）
E05755-03
 目次 |
 索引 |
| Oracle Data Guard 概要および管理 11gリリース1（11.1） E05755-03 |
|
この章では、Data Guard構成の管理中に遭遇する可能性がある例を説明します。使用例はそれぞれ、ユーザー固有の環境に適応できます。表13-1に、この章で説明する使用例を示します。
| 参照先 | 使用例 |
|---|---|
この項では、プライマリ・データベースを別のスタンバイ・データベースにフェイルオーバーした後に、ロジカル・スタンバイ・データベースで実行する必要のある手順について説明します。フェイルオーバーの発生後、ロジカル・スタンバイ・データベースは、元のプライマリ・データベースからの最後のREDOが適用されるまで、新規プライマリ・データベースのスタンバイ・データベースとして機能できません。これは、フェイルオーバー中に新規のプライマリ・データベースで最後のREDOが適用される場合と同じです。実行する必要のある手順は、新規プライマリ・データベースがフェイルオーバー前にフィジカル・スタンバイ・データベースであったかロジカル・スタンバイ・データベースであったかに応じて異なります。
この使用例では、プライマリ・ロールを担う前はフィジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするように、ロジカル・スタンバイ・データベースを構成する方法について説明します。この使用例では、SATはロジカル・スタンバイ・データベース、NYCはプライマリ・データベースです。
NYCデータベースで、次の文を発行します（LOG_ARCHIVE_DEST_4がSATデータベースにアーカイブするように構成されているとします）。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=DEFER; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
SATデータベースで、次の文を発行します。
SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY(- former_standby_type => 'PHYSICAL' - dblink => 'nyc_link');
|
注意
ロジカル・スタンバイ・データベースをApply SCNまでフラッシュバックする方法の例は、13.2.3項を参照してください。 |
NYCデータベースで、次の文を発行します（LOG_ARCHIVE_DEST_4がSATデータベースにアーカイブするように構成されているとします）。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=ENABLE; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
NYCデータベースで、次の問合せを発行して必要なSCNを判断します。
SQL> SELECT MAX(NEXT_CHANGE#) -1 AS WAIT_FOR_SCN FROM V$ARCHIVED_LOG;
SATデータベースで、次の文を発行します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
この文は、常にリアルタイム適用オプションを指定せずに発行する必要があることに注意してください。手順4 で戻された過去のWAIT_FOR_SCNがSQL Applyにより適用されるまで待機した後で、リアルタイム適用を有効化する必要があります。ロジカル・スタンバイ・データベースでリアルタイム適用を安全に再開できる時点を判断するには、V$LOGSTDBY_PROGRESSビューを監視します。
SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS;
戻される値が手順4で戻されたWAIT_FOR_SCN値以上の場合は、SQL Applyを停止し、リアルタイム適用オプションを指定して再開できます。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
この使用例では、プライマリ・ロールを担う前はロジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするように、ロジカル・スタンバイ・データベースを構成する方法について説明します。この使用例では、SATはロジカル・スタンバイ・データベース、NYCはプライマリ・データベースです。
NYCデータベースで、次の問合せにより値READYが戻されることを確認します。それ以外の場合、LSP1バックグラウンド・プロセスの処理が完了しておらず、このロジカル・スタンバイ・データベースの構成は待機する必要があります。次に例を示します。
SQL> SELECT VALUE FROM SYSTEM.LOGSTDBY$PARAMETERS 2> WHERE NAME = 'REINSTATEMENT_STATUS';
NYCデータベースで、次の文を発行します（LOG_ARCHIVE_DEST_4がSATデータベースにアーカイブするように構成されているとします）。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=DEFER; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
SATデータベースで、次の文を発行します。
SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY(- former_standby_type => 'LOGICAL' - dblink => 'nyc_link');
|
注意
ロジカル・スタンバイ・データベースをApply SCNまでフラッシュバックする方法の例は、13.2.3項を参照してください。 |
SATデータベースで、DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARYプロシージャの出力を調べます。このプロシージャでは、ローカル・システムにコピーする必要のあるログ・ファイルが識別されます。手順3でフェイルオーバーを非データ消失フェイルオーバーとして識別した場合は、表示されたログ・ファイルを新規プライマリ・データベースからコピーする必要があります。他のロジカル・スタンバイ・データベースまたは前のプライマリ・データベースからは取得しないでください。たとえば、Linuxシステムでは、grepコマンドを入力します。
%grep 'LOGSTDBY: Terminal log' alert_sat.log LOGSTDBY: Terminal log: [/oracle/dbs/hq_nyc_13.log]
SATデータベースで、端末のログ・ファイルをローカル・システムにコピーします。次の例に、この操作にLinuxコマンドを使用する方法を示します。
%cp /net/nyc/oracle/dbs/hq_nyc_13.log /net/sat/oracle/dbs/hq_sat_13.log
SATデータベースで、次の文を発行します。
SQL> ALTER DATABASE REGISTER OR REPLACE LOGICAL LOGFILE - '/net/sat/oracle/dbs/hq_sat_13.log';
SATデータベースで、次の文を発行します。
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;
NYCデータベースで、次の文を発行します（LOG_ARCHIVE_DEST_4がSATデータベースにアーカイブするように構成されているとします）。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4=ENABLE; SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
フェイルオーバーの発生後、元のプライマリ・データベースは、修正され、新しい構成のスタンバイ・データベースとして確立されるまで、Data Guard構成に含められません。これを行うには、フラッシュバック・データベース機能を使用して、障害の発生したプライマリ・データベースを障害発生前の時点にフラッシュバックし、その後新しい構成内のフィジカルまたはロジカル・スタンバイ・データベースに変換します。次の各項で、次の内容を説明します。
次の手順では、フィジカル・スタンバイ・データベースに対してフェイルオーバーが実行され、ファイルオーバーの際に古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。この手順では、古いプライマリ・データベースをフィジカル・スタンバイ・データベースとしてData Guard構成に戻します。
新しいプライマリ・データベース上で次の問合せを発行し、古いスタンバイ・データベースが新しいプライマリ・データベースになったSCNを判別します。
SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
必要に応じて古いプライマリ・データベースを停止し、マウントして、手順1 で判別した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;
制御ファイルからスタンバイ制御ファイルへ正常に変換後、この文はデータベースをマウントしません。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;
新しいプライマリ・データベースで次の手順を実行します。
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL 2> FROM V$ARCHIVE_DEST_STATUS;
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
SQL> ALTER SYSTEM SWITCH LOGFILE; SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL 2> FROM V$ARCHIVE_DEST_STATUS;
新しいスタンバイ・データベースで、REDO転送サービスがREDOデータを別のデータベースに転送しないよう、LOG_ARCHIVE_DEST_n初期化パラメータも変更する必要があります。
次のSQL文を新しいフィジカル・スタンバイ・データベースで発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE DISCONNECT;
REDO Applyは、ロールの推移により生成されるREDOレコードが検出されるたびに自動的に停止するため、新しいプライマリ・データベースがプライマリ・データベースとなったSCNを超えて適用されるまで、1回以上再起動する必要があります。障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の（障害発生前の）ロールに推移できます。詳細は、8.2.1項「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」を参照してください。
次の手順では、Data Guard構成ですでにロジカル・スタンバイ・データベースを使用したフェイルオーバーが実行済で、古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。この手順は、新しいプライマリ・データベースから古いプライマリ・データベースを正式にインスタンス化せずに、古いプライマリ・データベースを新しいロジカル・スタンバイ・データベースとしてData Guard構成に戻します。
フラッシュバックSCNは、障害が発生したプライマリ・データベースのフラッシュバック先となるSCNです。リカバリSCNは、障害が発生したプライマリ・データベースのリカバリ先となるSCNです。新しいプライマリで次の問合せを発行し、これらのSCNを特定します。
SQL> SELECT merge_change# AS FLASHBACK_SCN, processed_change# AS RECOVERY_SCN 2> FROM DBA_LOGSTDBY_HISTORY 3> WHERE stream_sequence# = (SELECT MAX(stream_sequence#)-1 4> FROM DBA_LOGSTDBY_HISTORY);
SQL> FLASHBACK DATABASE TO SCN flashback_scn;
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;
次の問合せによって特定されるログ・ファイルのみが、障害が発生したプライマリ・データベースを安全にリカバリできるアーカイブ・ログ・ファイルであるため、これらのファイルは非常に重要です。次の問合せから戻されるログ・ファイルが手順5で登録できない場合、障害が発生したプライマリをロジカル・スタンバイとして回復することはできません。そのような場合は、ロジカル・スタンバイを新しいプライマリから作成する必要があります。
SQL> SELECT file_name FROM DBA_LOGSTDBY_LOG 2> WHERE first_change# <= recovery_scn 3> AND next_change# > flashback_scn;
SQL> ALTER DATABASE REGISTER LOGFILE 'files_from_step _4';
SQL> RECOVER MANAGED STANDBY DATABASE UNTIL CHANGE recovery_scn;
SQL> ALTER DATABASE GUARD ALL;
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
SQL> ALTER DATABASE OPEN;
SQL> CREATE PUBLIC DATABASE LINK mylink 2> CONNECT TO system IDENTIFIED BY password 3> USING 'service_name_of_new_primary_database'; SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY mylink;
これで、ロールの可逆的な推移が完了しました。
スタンバイ・データベースのメリットの1つは、プライマリ・データベース・サービスに影響を与えずに、スタンバイ・データベースでフラッシュバック・データベースを実行できることです。データベースを特定の時点までフラッシュバックするタスクは簡単ですが、ロジカル・スタンバイ・データベースでは、既知のトランザクションがコミットされる直前の時点までフラッシュバックする操作が必要になる場合があります。このような必要が生じるのは、フェイルオーバー後に新しいプライマリ・データベースを使用してロジカル・スタンバイ・データベースを構成する場合です。
次の手順では、フラッシュバック・データベースとSQL Applyを使用して既知の適用済SCNまでリカバリする方法について説明します。
SQL> SELECT DBMS_LOGSTDBY.MAP_PRIMARY_SCN (PRIMARY_SCN => APPLIED_SCN) 2> AS TARGET_SCN FROM DUAL;
次のSQL文を発行し、ロジカル・スタンバイ・データベースを指定したSCNまでフラッシュバックし、RESETLOGSオプションを指定してロジカル・スタンバイ・データベースをオープンします。
SQL> SHUTDOWN; SQL> STARTUP MOUNT EXCLUSIVE; SQL> FLASHBACK DATABASE TO SCN <TARGET_SCN>; SQL> ALTER DATABASE OPEN RESETLOGS;
次の問合せを発行します。
SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS;
スタンバイ・データベースがリアルタイム適用を使用しているData Guard構成で、プライマリ・データベースでエラーが発生したとします。この場合、同じエラーがスタンバイ・データベースにも適用されます。
ただし、フラッシュバック・データベースが使用可能になっている場合、プライマリおよびスタンバイ・データベースをエラー前の状態に戻せます。これには、適用サービスを再開する前に、プライマリ・データベースでFLASHBACK DATABASEおよびOPEN RESETLOGS文を発行し、次に同様のFLASHBACK STANDBY DATABASE文をスタンバイ・データベースで発行します。（フラッシュバック・データベースが使用可能でない場合、第3章および第4章で説明されているように、プライマリ・データベースでPoint-in-Timeリカバリが実行された後、スタンバイ・データベースを再作成する必要があります。）
次の手順では、プライマリ・データベースでOPEN RESETLOGS文を発行した後、フィジカル・スタンバイ・データベースの再作成を回避する方法を説明します。
プライマリ・データベースで、次の問合せを使用してRESETLOGS操作がプライマリ・データベースで発生したよりも2つ前のシステム変更番号（SCN）の値を取得します。
SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;
スタンバイ・データベースで、次の問合せを使用して現行のSCNを取得します。
SQL> SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE;
CURRENT_SCNの値がresetlogs_change# - 2の値より大きい場合、次の文を発行してスタンバイ・データベースをフラッシュバックします。
SQL> FLASHBACK STANDBY DATABASE TO SCN resetlogs_change# -2;
CURRENT_SCNの値がresetlogs_change# - 2の値より小さい場合、手順4に進みます。
OPEN RESETLOGS文中も継続して動作できます。この場合、適用サービスはREDOデータ内のOPEN RESETLOGS文に到達しても停止しないため、データベースのフラッシュバックは不要です。
フィジカル・スタンバイ・データベースでREDO Applyを開始するには、次の文を発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE DISCONNECT;
スタンバイ・データベースはプライマリ・データベースからREDOを受信し、適用できます。
次の手順では、プライマリ・データベースをフラッシュバックし、OPEN RESETLOGS文を発行してオープンした後、ロジカル・スタンバイ・データベースの再作成を回避する方法を説明します。
プライマリ・データベースで、次の問合せを使用してRESETLOGS操作がプライマリ・データベースで発生したよりも2つ前のシステム変更番号（SCN）の値を取得します。
SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) AS FLASHBACK_SCN FROM V$DATABASE;
SQL> SELECT DBMS_LOGSTDBY.MAP_PRIMARY_SCN (PRIMARY_SCN => FLASHBACK_SCN) 2> AS TARGET_SCN FROM DUAL;
次のSQL文を発行し、ロジカル・スタンバイ・データベースを指定したSCNまでフラッシュバックし、RESETLOGSオプションを指定してロジカル・スタンバイ・データベースをオープンします。
SQL> SHUTDOWN; SQL> STARTUP MOUNT EXCLUSIVE; SQL> FLASHBACK DATABASE TO SCN <TARGET_SCN>; SQL> ALTER DATABASE OPEN RESETLOGS;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
一部のSQL文には、NOLOGGING句を指定するオプションがあります。このオプションによって、データベースに関する操作をオンラインREDOログ・ファイルに記録しないように指定できます。ユーザーがこの句を指定しても、REDOレコードはオンラインREDOログ・ファイルに書き込まれます。ただし、このレコードに関連したデータはありません。これが結果的に、スタンバイ・サイトでのログ適用エラーやデータ・アクセス・エラーの原因となり、ログ・ファイルの適用の再開で、手動によるリカバリが必要となります。
ロジカル・スタンバイ・データベースの場合は、SQL ApplyでNOLOGGING句を使用して対象の表で実行された操作のREDOレコードが検出されると、「ORA-16211 サポートされていないレコードが、アーカイブREDOログで見つかりました。」エラーで停止します。
NOLOGGING句を指定した後のリカバリには、10.5.5項に説明されているように、プライマリ・データベースから1つ以上の表を再作成します。
スタンバイ・サイトにコピーされたアーカイブ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; % cp tbs_1.dbf /backup SQL> ALTER TABLESPACE system END BACKUP;
欠落しているREDOデータが含まれているデータファイルを、プライマリ・サイトからリカバリ関連のファイルが格納されているフィジカル・スタンバイ・サイトにコピーします。
次のSQL文を発行します。
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> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
これらのエラー・メッセージは、アーカイブ・ギャップ内にある1つ以上のログ・ファイルが正常に適用されなかった場合に戻されます。これらのエラーを受け取った場合は、ギャップを手動で解決し、手順4を繰り返します。アーカイブ・ギャップの手動による解決方法の詳細は、6.3.3.1項を参照してください。
プライマリ・データベースでリカバリ不能な操作を実行した場合は、次の手順に従って新しいバックアップ操作が必要かどうかを判断します。
V$DATAFILEビューを問い合せ、システム変更番号（SCN）、またはOracleデータベースが無効なREDOデータを生成した最新の時刻を判別します。
SELECT UNRECOVERABLE_CHANGE#, TO_CHAR(UNRECOVERABLE_TIME, 'mm-dd-yyyy hh:mi:ss') FROM V$DATAFILE;
V$DATAFILEビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
第3章および第4章では、フィジカル・スタンバイ・データベースおよびロジカル・スタンバイ・データベースの作成方法を説明しました。この項では、プライマリ・データベースでOracle Managed Files（OMF）または自動ストレージ管理（ASM）を使用する場合に実行する必要のある追加手順を説明し、これらの章を補完します。
|
注意 この項の説明は、読者がすでにフィジカル・スタンバイ・データベースの作成方法を理解しており、Recovery Manager、OMFおよびASM機能に習熟していることを前提としています。詳細は、次の資料を参照してください。
|
スタンバイ・データベースを作成する前に、次の準備作業を実行します。
DB_CREATE_FILE_DESTおよびDB_CREATE_ONLINE_LOG_DEST_n初期化パラメータに適切な値を設定します。プライマリおよびスタンバイ・データベースの両方で同じディスク・グループ名が使用されている場合、メンテナンスや後のロールの推移が簡易化されます。
STANDBY_FILE_MANAGEMENT初期化パラメータにAUTOを設定します。
スタンバイ・データベースを作成するには、次の作業を実行します。
BACKUPコマンドを使用して、プライマリ・データベースのデータファイル、アーカイブ・ログ・ファイルおよびスタンバイ制御ファイルのコピーが含まれているバックアップ・セットを作成します。
DUPLICATE FOR STANDBYコマンドを使用して、バックアップ・セットのデータファイル、アーカイブREDOログ・ファイルおよびスタンバイ制御ファイルをスタンバイ・データベースの格納場所にコピーします。DUPLICATE FOR STANDBYコマンドは、スタンバイ・インスタンスでの実際のデータ移動を実行します。バックアップ・セットがテープ上に存在する場合、スタンバイ・インスタンスがバックアップ・セットを読み取れるよう、メディア・マネージャを構成する必要があります。バックアップ・セットがディスク上に存在する場合、バックアップ・ピースはスタンバイ・インスタンスによって読み取ることができる必要があります。これには、プライマリ・パス名をNFSを介して取得可能にするか、これらをスタンバイ・システムにコピーし、Recovery ManagerのCATALOG BACKUPPIECEコマンドを使用してバックアップ・ピースをリストア前にカタログに追加します。
これらの手順を完了した後、3.2.7項の手順を実行してフィジカル・スタンバイ・データベースの構成を確認します。
ロジカル・スタンバイ・データベースを作成するには、第4章で説明されているスタンバイ・データベースの作成プロセスを実行しますが、次の点を変更します。
DB_CREATE_FILE_DESTパラメータを設定しても、OMFファイル名を強制的に作成しません。ただし、このパラメータをプライマリ・データベースで設定する場合、スタンバイ・データベースでも設定する必要があります。
RESTORE CONTROLFILEコマンドを使用して、ロジカル・スタンバイ制御ファイルのコピーをスタンバイ・システムにリストアします。
> RMAN TARGET sys@lstdby target database Password: password RMAN> CATALOG START WITH '+stby_diskgroup'; RMAN> SWITCH DATABASE TO COPY;
これらの手順を完了した後、4.2.5項の手順を実行してロジカル・スタンバイ・データベースの起動、リカバリおよび検証を行います。
Data Guard構成でのメディア・リカバリの実行中に、フィジカル・スタンバイ・データベースを使用してプライマリ・データベースで書込みの欠落によるデータ破損エラーを検出できます。これは、プライマリ・データベースのREDOログに格納されているブロックのSCNをフィジカル・スタンバイ・データベースのブロックのSCNと比較して行います。プライマリ・データベースのブロックのSCNがスタンバイ・データベースの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の場合もあります。また、プライマリ・データベースは、すでにデータファイルに破損があってもエラーが表示されずに動作している場合があります。
このようなエラーからリカバリするための推奨手順は、次の手順に示すように、フィジカル・スタンバイにフェイルオーバーします。
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
新しいプライマリから作成したバックアップを使用して作成したフィジカル・スタンバイは、古いスタンバイと同じデータファイルを保持することに注意してください。そのため、新しいスタンバイでは同じブロックを比較するので、古いスタンバイがアクティブ化される前に存在していた未検出の書込みの欠落は、新しいスタンバイによって検出されません。プライマリまたはスタンバイで発生した新しい書込みの欠落はすべての検出されます。
障害が発生したプライマリ・データベースを変換するには、プライマリでフラッシュバック・データベース機能を有効にし、13.2.1項または13.2.2項で説明した手順に従うことをお薦めします。これらの項の手順では、障害が発生したプライマリをフィジカル・スタンバイまたはロジカル・スタンバイに変換する最も速い方法を説明しています。しかし、障害が発生したプライマリでフラッシュバック・データベースが無効になっている場合でも、次の項で説明するように、障害が発生したプライマリのローカル・バックアップを使用して、障害が発生したプライマリをフィジカル・スタンバイまたはロジカル・スタンバイに変換できます。
この項の手順では、Recovery Managerバックアップを使用して障害が発生したプライマリをフィジカル・スタンバイに変換する方法を説明します。この手順には、古いプライマリのCOMPATIBLE初期化パラメータが11.0.0以上に設定されている必要があります。
新しいプライマリ・データベース上で次の問合せを発行し、古いスタンバイ・データベースが新しいプライマリ・データベースになったSCNを判別します。
SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
スタンバイが新しいプライマリになったSCN（standby_became_primary_scn）に古いプライマリが到達する前に作成したバックアップを使用して、データベースをリストアします。次に、Point-in-Timeリカバリを実行して、古いプライマリをそれと同じ時点までリカバリします。
次のRecovery Managerコマンドを発行します。
RMAN> RUN { SET UNTIL SCN <standby_became_primary_scn + 1>; RESTORE DATABASE; RECOVER DATABASE; }
ユーザー管理リカバリでは、先にデータベースを手動でリストアできます。通常、フェイルオーバー前の、数時間を要したバックアップは古くなっています。そのため、障害が発生したプライマリは次のコマンドを使用してリカバリできます。
SQL> RECOVER DATABASE USIING 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;
この手順の目的は、ディクショナリ・チェックを使用して制御ファイルをデータベースと同期させることです。このコマンドの後に、ディクショナリ・チェックで示されたアクションがないかアラート・ログをチェックします。通常、フェイルオーバー中に古いプライマリがデータファイルを追加または削除している途中でなければ、ユーザー・アクションは必要ありません。
フィジカル・スタンバイは、読取り専用でオープンされている間、REDOを適用できます。しかし、読取り専用でオープンせずにフィジカル・スタンバイをリカバリする場合、次のように、必要に応じてフィジカル・スタンバイを停止し、再度マウントしてもかまいません。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;
新しいスタンバイ・データベースの作成前に、新しいプライマリ・データベースは、リモート宛先へのREDOの転送を停止しているはずです。REDO転送サービスを再開するには、新しいプライマリ・データベースで次の手順を実行します。
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL 2> FROM V$ARCHIVE_DEST_STATUS;
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
SQLプロンプトで次の文を入力します。
SQL> ALTER SYSTEM SWITCH LOGFILE; SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL 2> FROM V$ARCHIVE_DEST_STATUS;
新しいスタンバイ・データベースで、REDO転送サービスがREDOデータを別のデータベースに転送しないよう、LOG_ARCHIVE_DEST_n初期化パラメータも変更する必要があります。1つのサーバー・パラメータ・ファイル（SPFILE）でプライマリおよびスタンバイ・データベース・ロールの両方がVALID_FOR属性で設定されている場合、この手順を実行する必要はありません。これにより、Data Guard構成は、ロールの推移後も正しく動作します。
次のようにして、新しいフィジカル・スタンバイ・データベースでREDO Applyを開始します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE DISCONNECT;
障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の（障害発生前の）ロールに推移できます。詳細は、8.2.1項「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」を参照してください。
この項の手順では、Recovery Managerバックアップを使用して障害が発生したプライマリをロジカル・スタンバイに変換する方法を説明します。
新しいプライマリ・データベースで次の問合せを発行し、障害が発生したプライマリ・データベースをリカバリするSCNを判別します。
SQL> SELECT APPLIED_SCN RECOVERY_SCN FROM V$LOGSTDBY_PROGRESS;
また、新しいプライマリ・データベースで、次のようにして、アーカイブ・ログの処理に使用するSCNを判別します。
READYの値を検索します。データベースのサイズおよびアーカイブする必要があるログの数によって、READYのステータスが戻されるまでしばらく時間がかかることがあります。
SQL> SELECT VALUE FROM SYSTEM.LOGSTDBY$PARAMETERS WHERE
NAME='REINSTATEMENT_STATUS';
READYのステータスが戻されたら、次の問合せを実行し、このリカバリの一環としてアーカイブ・ログの処理のためのSCNを取得します。
SQL> SELECT VALUE ARCHIVE_SCN FROM SYSTEM.LOGSTDBY$PARAMETERS 2> WHERE NAME='STANDBY_BECAME_PRIMARY_SCN';
フェイルオーバー操作以後に作成されたアーカイブ・ログをすべて、障害が発生したプライマリ・データベースから削除します。障害が発生したプライマリ・データベースがスタンバイから分離されていた場合は、現行のプライマリ・データベースと一貫性がない不一致のアーカイブ・ログが存在する可能性があります。これらの不一致のアーカイブ・ログを適用しないようにするには、バックアップおよびフラッシュ・リカバリ領域から削除する必要があります。次のRecovery Managerコマンドを使用すると、関連アーカイブ・ログをフラッシュ・リカバリ領域から削除できます。
RMAN> DELETE ARCHIVELOG FROM SCN ARCHIVE_SCN;
削除されると、これらの不一致のログおよび後続のトランザクションはリカバリできなくなります。
新しいプライマリ・データベースで、次の問合せを発行し、バックアップからリカバリする前に、障害が発生したプライマリ・データベースにコピーする必要があるログ・ファイルの最小セットを判別します。
SQL> SELECT file_name FROM DBA_LOGSTDBY_LOG WHERE next_change# > ARCHIVE_SCN;
必要なスタンバイ・ログを取得し、バックアップ・セットを新しいスタンバイにコピーして新しいスタンバイ・フラッシュ・リカバリ領域にリストアします。これらのログはスタンバイREDOログから得られるため、スタンバイの標準アーカイブの一部ではありません。Recovery Managerユーティリティでは、部分的なファイル名を使用して正しい場所からファイルを取得できます。
次に、Recovery ManagerのBACKUPコマンドの使用例を示します。
RMAN> BACKUP AS COPY DEVICE TYPE DISK FORMAT '/tmp/test/%U' > ARCHIVELOG LIKE '<partial file names from above>%';
次に、Recovery ManagerのRESTOREコマンドの使用例を示します。
RMAN> CATALOG START WITH '/tmp/test'; RMAN> RESTORE ARCHIVELOG FROM SEQUENCE 33 UNTIL SEQUENCE 35;
元のプライマリの全データファイルのバックアップをリストアし、RECOVERY_SCN + 1までリカバリします。現行の制御ファイルを利用することをお薦めします。
GUARD ALLコマンドが発行されるまでローグ・トランザクションから保護します。
USING BACKUP CONTROLFILE句に必要）。
RECOVERY_SCN +1までPoint-in-Timeリカバリを実行します。
現行の制御ファイルを使用してもバックアップ制御ファイルを使用しても、USING BACKUP CONTROLFILE 句を指定してリストアされるアーカイブ・ログを指すことができるようにする必要があります。指定しないと、リカバリ・プロセスでは、手順3 で取得したログではなく、オンラインREDOログへのアクセスが試行されることがあります。手順3 で取得した順序の入力を求められた場合は、次のようにリストアされるアーカイブ・ログのコピーのファイル名を指定します。
SQL> RECOVER DATABASE UNTIL CHANGE RECOVERY_SCN + 1 USING BACKUP CONTROLFILE;
SQL> ALTER DATABASE OPEN RESETLOGS;
SQL> ALTER DATABASE GUARD ALL;
SQL> CREATE PUBLIC DATABASE LINK myLink 2> CONNECT TO SYSTEM IDENTIFIED BY password 3> USING 'service name of new primary database'; SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY myLink;
この時点で、制限セッション（ALTER SYSTEM DISABLE RESTRICTED SESSION）を無効にできます。つまり、データベースを再起動して手順4.3のフラッシュバックを再度有効にする必要がある場合は、RESTRICTED SESSIONをオフにして再起動します。
|
 Copyright © 1999, 2008 Oracle Corporation. All Rights Reserved. |
|