| Oracle® Data Guard概要および管理 11gリリース2 (11.2) B56302-06 |
|
 前 |
 次 |
この章では、Data Guard構成の管理中に遭遇する可能性がある例を説明します。使用例はそれぞれ、ユーザー固有の環境に適応できます。表13-1に、この章で説明する使用例を示します。
表13-1 Data Guardの使用例
この項では、プライマリ・データベースを別のスタンバイ・データベースにフェイルオーバーした後に、ロジカル・スタンバイ・データベースで実行する必要のある手順について説明します。フェイルオーバーの発生後、ロジカル・スタンバイ・データベースは、元のプライマリ・データベースからの最後のREDOが適用されるまで、新規プライマリ・データベースのスタンバイ・データベースとして機能できません。これは、フェイルオーバー中に新規のプライマリ・データベースで最後のREDOが適用される場合と同じです。実行する必要のある手順は、新規プライマリ・データベースがフェイルオーバー前にフィジカル・スタンバイ・データベースであったかロジカル・スタンバイ・データベースであったかに応じて異なります。
この使用例では、プライマリ・ロールを担う前はフィジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするように、ロジカル・スタンバイ・データベースを構成する方法について説明します。この使用例では、SATはロジカル・スタンバイ・データベース、NYCはプライマリ・データベースです。
SATデータベースで、次の文を発行します。
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.」という警告が書き込まれる場合は、次の手順を実行します。
ロジカル・スタンバイ・データベースをApply SCNまでフラッシュバックする方法の例は、13.2.3項を参照してください。 |
SATデータベースで、次の文を発行します。
SQL> START LOGICAL STANDBY APPLY IMMEDIATE;
この使用例では、プライマリ・ロールを担う前はロジカル・スタンバイ・データベースだった新規プライマリ・データベースをサポートするように、ロジカル・スタンバイ・データベースを構成する方法について説明します。この使用例では、SATはロジカル・スタンバイ・データベース、NYCはプライマリ・データベースです。
NYCデータベースで、次の問合せにより値READYが戻されることを確認します。それ以外の場合、新しいプライマリ・データベースは、ロジカル・スタンバイ・データベースに対するサポートを可能にするために必要な作業を完了していません。次に例を示します。
SQL> SELECT VALUE FROM SYSTEM.LOGSTDBY$PARAMETERS - > WHERE NAME = 'REINSTATEMENT_STATUS';
|
注意: VALUE列にNOT POSSIBLEが含まれている場合は、新規プライマリ・データベースでロジカル・スタンバイ・データベースを構成できず、データベースを元に戻す必要があることを意味します。 |
SATデータベースで、次の文を発行します。
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.」という警告が書き込まれる場合は、次の手順を実行します。
ロジカル・スタンバイ・データベースをApply SCNまでフラッシュバックする方法の例は、13.2.3項を参照してください。 |
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;
フェイルオーバーの発生後、元のプライマリ・データベースは、修正され、新しい構成のスタンバイ・データベースとして確立されるまで、Data Guard構成に含められません。これを行うには、フラッシュバック・データベース機能を使用して、障害の発生したプライマリ・データベースを障害発生前の時点にフラッシュバックし、その後新しい構成内のフィジカルまたはロジカル・スタンバイ・データベースに変換します。次の各項で、次の内容を説明します。
障害が発生したプライマリ・データベースのロジカル・スタンバイ・データベースへのフラッシュバック
|
注意: フェイルオーバー前に、元のプライマリ・データベースでフラッシュバック・データベースが使用可能になっている必要があります。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
特定の適用済SCNへのロジカル・スタンバイ・データベースのフラッシュバック
|
関連項目: 失敗したプライマリ・データベースを新しいデータベースとして自動回復する(フラッシュバック・データベースを使用する代わりに)方法は、『Oracle Data Guard Broker』を参照してください。 |
次の手順では、フィジカル・スタンバイ・データベースに対してフェイルオーバーが実行され、ファイルオーバーの際に古いプライマリ・データベースでフラッシュバック・データベースが使用可能にされていることを前提としています。この手順では、古いプライマリ・データベースをフィジカル・スタンバイ・データベースとして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 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初期化パラメータも変更する必要があります。
次のSQL文を新しいフィジカル・スタンバイ・データベースで発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE - > 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 - > FROM DBA_LOGSTDBY_HISTORY - > WHERE stream_sequence# = (SELECT MAX(stream_sequence#)-1 - > FROM DBA_LOGSTDBY_HISTORY);
SQL> FLASHBACK DATABASE TO SCN flashback_scn;
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;
フィジカル・スタンバイ(障害の発生したプライマリ)で、次の文を発行します。
SQL> ALTER SYSTEM SET FAL_SERVER='<tns_name_to_new_primary>';
フェイルオーバー操作以後に作成されたアーカイブ・ログをすべて、障害が発生したプライマリ・データベースから削除します。障害が発生したプライマリ・データベースがスタンバイから分離されていた場合は、現行のプライマリ・データベースと一貫性がない不一致のアーカイブ・ログが存在する可能性があります。これらの不一致のアーカイブ・ログを適用しないようにするには、バックアップおよび高速リカバリ領域から削除する必要があります。次のRecovery Managerコマンドを使用すると、関連アーカイブ・ログを高速リカバリ領域から削除できます。
RMAN> DELETE FORCE ARCHIVELOG FROM SCN ARCHIVE_SCN;
削除されると、これらの不一致のログおよび後続のトランザクションはリカバリできなくなります。
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 - > CONNECT TO system IDENTIFIED BY password - > 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) - > 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章で説明しているスタンバイ・データベースの再作成が必要です。)
次の手順では、プライマリ・データベースで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に進みます。
スタンバイ・データベースのSCNがプライマリ・データベースのSCNよりも大幅に遅れており、OPEN RESETLOGS文のREDOの新規ブランチがスタンバイに登録されている場合、適用サービスは、OPEN RESETLOGS文中も停止せずに継続することができます。この場合、適用サービスはREDOデータ内のOPEN RESETLOGS文に到達しても停止しないため、データベースのフラッシュバックは不要です。
フィジカル・スタンバイ・データベースでREDO Applyを開始するには、次の文を発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE - > USING CURRENT LOGFILE DISCONNECT;
スタンバイ・データベースはプライマリ・データベースからREDOを受信し、適用できます。
次の手順では、プライマリ・データベースをフラッシュバックし、OPEN RESETLOGS文を発行してオープンした後、ロジカル・スタンバイ・データベースの再作成を回避する方法を説明します。
|
注意: SQL Applyは、プライマリ・データベースでリセットログ操作の発生を検出すると、ロジカル・スタンバイ・データベースをフラッシュバックしなくてもマイニングできる場合は、REDOの正しいブランチを自動的にマイニングします。それ以外の場合、SQL Applyは「ORA-1346: 指定されたリセット・ログscnを超えてLogMinerがREDOを処理しました」エラーで停止します。この項では、SQL Applyはこのエラーですでに停止していると仮定しています。 |
プライマリ・データベースで、次の問合せを使用してRESETLOGS操作がプライマリ・データベースで発生したよりも2つ前のシステム変更番号(SCN)の値を取得します。
SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) AS FLASHBACK_SCN FROM V$DATABASE;
この手順では、PRIMARY_SCNのFLASHBACK_SCN値は手順1から得られたものです。
SQL> SELECT DBMS_LOGSTDBY.MAP_PRIMARY_SCN (PRIMARY_SCN => FLASHBACK_SCN) - > 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 resetlogs_id FROM V$DATABASE_INCARNATION WHERE status = 'CURRENT';
スタンバイ・データベースで次の問合せを発行します。
SQL> SELECT * FROM DBA_LOGSTDBY_LOG WHERE resetlogs_id = resetlogs_id_at_primary;
1以上の行が返された場合、これは、プライマリの新しいブランチからの登録されたログ・ファイルであることを確認します。
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つ以上の表を再作成します。
|
注意: 通常、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文を発行します。
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を繰り返します。アーカイブ・ギャップの手動による解決方法の詳細は、6.4.3.1項を参照してください。
プライマリ・データベースでリカバリ不能な操作を実行した場合は、次の手順に従って新しいバックアップ操作が必要かどうかを判断します。
プライマリ・データベースでV$DATAFILEビューの問合せを行い、Oracleデータベースが最新の無効なREDOデータを生成したシステム変更番号(SCN)または時刻を特定します。
プライマリ・データベースで次のSQL文を発行して、新たにバックアップを実行する必要があるかどうかを判断します。
SQL> 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)またはOracle Automatic Storage Management(Oracle ASM)を使用する場合に実行する必要のある追加手順を説明し、これらの章を補完します。
|
注意: この項の説明は、読者がすでにフィジカル・スタンバイ・データベースの作成方法を理解しており、Recovery Manager、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転送の認証を構成します。詳細は、3.1.2項「REDO転送の認証の構成」を参照してください。
制御ファイルをマウントせずにスタンバイ・データベース・インスタンスを起動します。
スタンバイ・データベースを作成するには、次の作業を実行します。
スタンバイ・データベースでOracle ASMを使用する場合、スタンバイ・データベース・システムにOracle ASMインスタンスが存在していなければ、インスタンスを作成します。
Recovery ManagerのBACKUPコマンドを使用して、プライマリ・データベースのデータファイル、アーカイブ・ログ・ファイルおよびスタンバイ制御ファイルのコピーが含まれているバックアップ・セットを作成します。
Recovery ManagerのDUPLICATE FOR STANDBYコマンドを使用して、バックアップ・セットのデータファイル、アーカイブREDOログ・ファイルおよびスタンバイ制御ファイルをスタンバイ・データベースの格納場所にコピーします。
DUPLICATE FOR STANDBYコマンドは、スタンバイ・インスタンスで実際のデータ移動を実行します。バックアップ・セットがテープ上にある場合、スタンバイ・インスタンスがバックアップ・セットを読み取れるように、メディア・マネージャを構成しておく必要があります。バックアップ・セットがディスク上にある場合は、NFSでプライマリ・パス名を使用できるようにするか、スタンバイ・システムにコピーしてRMANのCATALOG BACKUPPIECEコマンドを使用し、バックアップ・ピースをカタログに追加してからリストアを行うことで、スタンバイ・インスタンスがバックアップ・ピースを読み取れるようにする必要があります。
これらの手順を完了した後、3.2.7項の手順を実行してフィジカル・スタンバイ・データベースの構成を確認します。
ロジカル・スタンバイ・データベースを作成するには、第4章で説明されているスタンバイ・データベースの作成プロセスを実行しますが、次の点を変更します。
ロジカル・スタンバイ・データベースの場合、DB_CREATE_FILE_DESTパラメータを設定しても、OMFファイル名を強制的に作成しません。ただし、このパラメータをプライマリ・データベースで設定する場合、スタンバイ・データベースでも設定する必要があります。
プライマリ・システムでロジカル・スタンバイ制御ファイルを作成した後、このファイルをスタンバイ・システムにコピーするために、オペレーティング・システムのコマンドを使用しないでください。かわりにRecovery ManagerのRESTORE CONTROLFILEコマンドを使用して、ロジカル・スタンバイ制御ファイルのコピーをスタンバイ・システムにリストアします。
プライマリ・データベースでOMFファイルを使用する場合、スタンバイ・データベースに作成された新しいOMFファイルをスタンバイ・データベース制御ファイルが使用するよう、Recovery Managerを使用してスタンバイ・データベース制御ファイルを更新します。この操作を実行するには、次の例に示すように、スタンバイ・データベースにのみ接続します。
> 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よりも小さい場合は、プライマリ・データベースで書込みの欠落が発生しています。
そのような状況で、書込み欠落の検出(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
新しいプライマリのバックアップを行います。データベースの完全なバックアップ・コピーがなければ、フェイルオーバー後の変更をリカバリすることができないので、バックアップをすぐに実行することは安全策として必要な作業です。フェイルオーバーを行うと元のプライマリ・データベースはData Guard構成に含まれなくなり、その他のすべてのスタンバイ・データベースが新しいプライマリ・データベースからREDOデータの受信と適用を行うようになります。
新しいプライマリ・データベースをオープンします。
オプションの手順として、失敗したプライマリをフィジカル・スタンバイとして再作成します。これは手順3で新しいプライマリで作成したデータベース・バックアップを使用して実行します。(この場合は、フラッシュバック・データベースまたはData Guardブローカを使用して、元のプライマリ・データベースを回復することはできません。)
新しいプライマリから作成したバックアップを使用して作成したフィジカル・スタンバイは、古いスタンバイと同じデータファイルを保持することに注意してください。そのため、新しいスタンバイでは同じブロックを比較するので、古いスタンバイがアクティブ化される前に存在していた未検出の書込みの欠落は、新しいスタンバイによって検出されません。プライマリまたはスタンバイで発生した新しい書込みの欠落はすべての検出されます。
|
関連項目: 書込み欠落の検出有効化の詳細は、『Oracle 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;
この手順の目的は、ディクショナリ・チェックを使用して制御ファイルをデータベースと同期させることです。このコマンドの後に、ディクショナリ・チェックで示されたアクションがないかアラート・ログをチェックします。通常、フェイルオーバー中に古いプライマリがデータファイルを追加または削除している途中でなければ、ユーザー・アクションは必要ありません。
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属性で設定されている場合、この手順を実行する必要はありません。これにより、Data Guard構成は、ロールの推移後も正しく動作します。
次のようにして、新しいフィジカル・スタンバイ・データベースでREDO Applyを開始します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE - > USING CURRENT LOGFILE DISCONNECT;
障害が発生したプライマリ・データベースがリストアされてスタンバイ・ロールで稼働し始めた後、オプションでスイッチオーバーを実行し、それぞれのデータベースを元の(障害発生前の)ロールに推移できます。詳細は、8.2.1項「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」を参照してください。
この項の手順では、Recovery Managerバックアップを使用して障害が発生したプライマリをロジカル・スタンバイに変換する方法を説明します。
新しいプライマリ・データベースで次の問合せを発行し、障害が発生したプライマリ・データベースをリカバリするSCNを判別します。
SQL> SELECT APPLIED_SCN RECOVERY_SCN FROM V$LOGSTDBY_PROGRESS;
また、新しいプライマリ・データベースで、次のようにして、アーカイブ・ログの処理に使用するSCNを判別します。
すべてのスタンバイREDOログを必ずアーカイブしておきます。次の問合せを発行し、戻されるREADYの値を検索します。データベースのサイズおよびアーカイブする必要があるログの数によって、READYのステータスが戻されるまでしばらく時間がかかることがあります。
SQL> SELECT VALUE FROM SYSTEM.LOGSTDBY$PARAMETERS - > WHERE NAME='REINSTATEMENT_STATUS';
READYのステータスが戻されたら、次の問合せを実行し、このリカバリの一環としてアーカイブ・ログの処理のためのSCNを取得します。
SQL> SELECT VALUE ARCHIVE_SCN FROM SYSTEM.LOGSTDBY$PARAMETERS - > 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句に必要)。
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;
SQL> ALTER DATABASE OPEN RESETLOGS;
SQL> ALTER DATABASE GUARD ALL;
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)を無効にできます。つまり、データベースを再起動して手順4.3のフラッシュバックを再度有効にする必要がある場合は、RESTRICTED SESSIONをオフにして再起動します。
Oracle Data Guardでは、構成内のフィジカル・スタンバイ・データベースを再作成することなく、プライマリ・データベースのデータベース・キャラクタ・セットと各国語キャラクタ・セットの両方を変更できます。プライマリ・データベースのキャラクタ・セット変換の実行中に、中断を最小限に抑えて、フィジカル・スタンバイ・データベースを使用し続けることができます。
実際の変換を行う前に、いくつかのプロシージャを実行する必要があります。変換には、プライマリ・データベースを停止して、制限モードでオープンし、CSALTERスクリプトを実行する必要があります。システム・データとユーザー・データはどちらも新しいキャラクタ・セットに変換されます。
このプロセスに必要な手順の詳細は、http://support.oracle.comにあるMy Oracle Support Note 1124165.1を参照してください。Note 260192.1も読む必要があります。
|
注意: 廃止されたALTER DATABASE CHARACTER SET SQL文と同様に、CSALTERスクリプトはシステム管理者のみが使用するものです。システム管理者は、CSALTERを実行するための適切な条件があることを確認するために、データベース・キャラクタ・セット・スキャナをまず実行する必要があります。また、CSALTERを実行する前には、データベースをバックアップする必要があります。 |
|
関連項目: キャラクタ・セットを移行するためのCSALTERスクリプトの使用についての一般的な情報は、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。 |
