11gリリース1（11.1）
E05755-03
 目次 |
 索引 |
| Oracle Data Guard 概要および管理 11gリリース1（11.1） E05755-03 |
|
Data Guard構成は、プライマリ・ロールで機能する1つのデータベース、およびスタンバイ・ロールで機能する1つ以上のデータベースで構成されています。通常、各データベースのロールは変更されません。ただし、プライマリ・データベースが停止したときにData Guardを使用してサービスを維持する場合は、構成内の現行のプライマリ・データベースと1つのスタンバイ・データベース間でロールの推移を開始する必要があります。データベースの現行のロールを確認するには、V$DATABASEビューのDATABASE_ROLE列を問い合せます。
Data Guard構成内のスタンバイ・データベースの数、位置、タイプおよびプライマリ・データベースからのREDOデータを各スタンバイ・データベースに伝播する方法に応じて、プライマリ・データベースの停止に対して設定できるロール管理オプションが決定します。
この章では、Data Guard構成でロールの推移を管理する方法について説明します。この章は、次の項目で構成されています。
この章で説明するロールの推移は、SQL文を使用して手動で起動します。Oracle Data Guard Brokerを使用し、ロールの推移を単純化してフェイルオーバーを自動化することもできます。
データベースは、相互に排他的な2つのロールのいずれかで実行されます。すなわち、プライマリとスタンバイです。Data Guardでは、この章で説明するSQL文を発行するか、Data Guard BrokerのGUIまたはコマンドライン・インタフェースを使用して、これらのロールを動的に変更できます。Oracle Data Guardは、次のロールの推移をサポートしています。
プライマリ・データベースが、スタンバイ・データベースの1つを使用してロールを切り替えられるようにします。スイッチオーバー時には、データは消失しません。スイッチオーバーの完了後、各データベースは、新しいロールとともにData Guard構成に継続して含まれます。
プライマリ・データベースの障害時に、スタンバイ・データベースをプライマリ・ロールに変更します。障害の前にプライマリ・データベースが最大保護モードまたは最大可用性モードで動作していなかった場合、データ消失が発生することがあります。フラッシュバック・データベースがプライマリ・データベースで使用可能になっている場合は、障害の原因が修正された後、元どおり新しいプライマリ・データベースのスタンバイに戻すことができます。
8.1.1項「ロールの推移の準備」では、停止時間およびデータ消失のリスクを最小限にするために、どのロールの推移を選択するかについて説明します。8.1.3項「スイッチオーバー」および8.1.4項「フェイルオーバー」では、それぞれスイッチオーバーとフェイルオーバーの詳細を説明します。
ロールの推移を開始する前に、次の準備を実行します。
Oracle RACフィジカル・スタンバイ・データベースへのスイッチオーバーまたはフェイルオーバーを実行するには、1つのスタンバイ・データベース・インスタンス以外はすべて停止します。このとき停止したスタンバイ・データベース・インスタンスは、ロールの推移の完了後に再起動できます。
複数のスタンバイ・データベースがあるData Guard構成の場合、ロールの推移のターゲット・スタンバイ・データベースを選択する際には、多数の要因を考慮する必要があります。次のような要因があります。
ロールの推移のターゲットとして選択されたスタンバイのタイプにより、構成内の他のスタンバイ・データベースがロールの推移後にどのように動作するか決定されます。ロールの推移前、新しいプライマリがフィジカル・スタンバイだった場合、構成内の他のスタンバイ・データベースは新しいプライマリのスタンバイになります。ロールの推移前、新しいプライマリがロジカル・スタンバイだった場合、構成内の他のすべてのロジカル・スタンバイは新しいプライマリのスタンバイになりますが、構成内のフィジカル・スタンバイは、古いプライマリのスタンバイのままであるため、新しいプライマリを保護しません。後者の場合、次回のスイッチオーバーまたはフェイルオーバーで元のプライマリ・データベースに戻ると、すべてのスタンバイは現行のプライマリのスタンバイとしての元のロールに戻ります。これらの理由により、フィジカル・スタンバイとロジカル・スタンバイの両方が含まれる構成内におけるロールの推移の最適なターゲットは、通常、フィジカル・スタンバイです。
Data GuardにはV$DATAGUARD_STATSビューが用意されています。このビューを使用して、スタンバイ・データベースのデータの最新性から見た各スタンバイ・データベースと、使用可能なREDOデータがすべてスタンバイ・データベースに適用された場合の、ロールの推移の実行所要時間を評価することができます。次に例を示します。
SQL> COLUMN NAME FORMAT A18 SQL> COLUMN VALUE FORMAT A16 SQL> COLUMN TIME_COMPUTED FORMAT A24 SQL> SELECT * FROM V$DATAGUARD_STATS; NAME VALUE TIME_COMPUTED ------------------ ---------------- ------------------------ apply finish time +00 00:00:02.4 15-MAY-2005 10:32:49 second(1) interval apply lag +00 0:00:04 15-MAY-2005 10:32:49 second(0) interval transport lag +00 00:00:00 15-MAY-2005 10:32:49 second(0) interval
それぞれの統計の計算時刻は、TIME_COMPUTED列に示されています。V$DATATGUARD_STATS.TIME_COMPUTED列は、V$DATATGUARD_STATS行のメトリックが計算されるときに取得されるタイムスタンプです。この列は、関連付けられたメトリックの鮮度を示します。この例は、このスタンバイ・データベースではトランスポート・ラグがないこと、適用サービスでは過去4秒間に生成されたREDOが適用されていないこと（apply lag）、および適用サービスで未適用のREDOの適用が完了するまでに2.4秒かかること（apply finish time）を示しています。APPLY LAGおよびTRANSPORT LAGメトリックは、プライマリ・データベースから受信される情報に基づいて計算されます。これらのメトリックは、プライマリ・データベースとスタンバイ・データベース間の通信が中断されると失効します。APPLY LAGおよびTRANSPORT LAGメトリックについてこの列の値が変化しない場合、これらのメトリックが更新されていない（失効した）ことを示し、プライマリ・データベースとスタンバイ・データベース間の通信障害がその原因と考えられます。
スイッチオーバーは、通常、オペレーティング・システムやハードウェアのアップグレード、またはOracleデータベース・ソフトウェアとパッチ・セットのローリング・アップグレードなど、計画的な停止によるプライマリ・データベースの停止時間を短縮するために使用します（第12章「SQL Applyを使用したOracle Databaseのアップグレード」を参照）。
スイッチオーバーは、2つのフェーズで実行されます。最初のフェーズで、既存のプライマリ・データベースがスタンバイ・ロールに推移します。2番目のフェーズで、スタンバイ・データベースがプライマリ・ロールに推移します。
図8-1は、データベースのロールを切り替える前の2つのサイトにあるData Guard構成を示します。この構成では、プライマリ・データベースはサンフランシスコにあり、スタンバイ・データベースはボストンにあります。
図8-2に、元のプライマリ・データベースがスタンバイ・データベースにスイッチオーバーされた後、元のスタンバイ・データベースがまだ新しいプライマリ・データベースになっていないData Guard環境を示します。このとき、Data Guard構成には一時的に2つのスタンバイ・データベースが存在することになります。
図8-3は、スイッチオーバー実行後のData Guard環境を示します。元のスタンバイ・データベースは新しいプライマリ・データベースになります。現在、プライマリ・データベースはボストンにあり、スタンバイ・データベースはサンフランシスコにあります。
8.1.1項に示した前提条件が満たされていることを確認します。また、スイッチオーバーの場合は、次の前提条件が満たされている必要があります。
通常、フェイルオーバーは、プライマリ・データベースが使用不可能になり、適正な時間内にプライマリ・データベースをリストアしてサービスを再開できない場合にのみ使用します。フェイルオーバー時に実行するアクションは、フェイルオーバーに関与するスタンバイ・データベースがロジカルかフィジカルか、フェイルオーバー時のData Guard構成の状態、およびフェイルオーバーを開始するために使用する特定のSQL文によって異なります。
図8-4に、サンフランシスコにあるプライマリ・データベースからボストンにあるフィジカル・スタンバイ・データベースへのフェイルオーバーの結果を示します。
可能な場合は、フェイルオーバーを実行する前に、使用可能な未適用のプライマリ・データベースREDOデータを可能なかぎりスタンバイ・データベースに転送する必要があります。
8.1.1項「ロールの推移の準備」に示した前提条件が満たされていることを確認します。また、フェイルオーバーの場合は、次の前提条件が満たされている必要があります。
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
適切なスタンバイ・データベースが使用できる場合は、フェイルオーバーが完了した後に、新しいプライマリ・データベースで希望の保護モードをリセットできます。
最大保護モードに設定されているスタンバイ・データベースはフェイルオーバーできないため、この作業が必要になります。さらに、最大保護モードのプライマリ・データベースがスタンバイ・データベースと通信中の場合は、スタンバイ・データベースを最大保護モードから最大パフォーマンス・モードに変更するためにALTER DATABASE文を発行しても失敗します。フェイルオーバーを実行すると元のプライマリ・データベースはData Guard構成から削除されるため、この機能によって、最大保護モードで実行されているプライマリ・データベースを計画外のフェイルオーバーの影響から保護します。
|
注意 スタンバイ・データベースが正しく更新されているかどうかをテストするために、スタンバイ・データベースにフェイルオーバーしないでください。かわりに、次のようにします。
|
ロールの推移が発生するたびに、DB_ROLE_CHANGEシステム・イベントにシグナルが送信されます。このシステム・イベントには、ロールの推移が発生したときにデータベースがオープンしている場合は、すぐにシグナルが送信されます。あるいはロールの推移が発生したときにデータベースがクローズしている場合は、次回オープン時にシグナルが送信されます。
DB_ROLE_CHANGEシステム・イベントを使用すると、ロールの推移が発生するたびに一連のアクションを実行するトリガーを起動できます。
この項では、フィジカル・スタンバイ・データベースに対するスイッチオーバーまたはフェイルオーバーの実行方法を説明します。
この項では、フィジカル・スタンバイ・データベースへのスイッチオーバーの実行方法を説明します。
スイッチオーバーは、プライマリ・データベースで開始し、ターゲット・スタンバイ・データベースで完了します。
プライマリ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO STANDBY 1 row selected
値TO STANDBYまたはSESSIONS ACTIVEは、プライマリ・データベースをスタンバイ・ロールに切替え可能であることを示します。これらのいずれの値も戻されない場合、REDO転送が正しく構成されていないか、正しく機能していないため、スイッチオーバーは不可能です。REDO転送の構成および監視の詳細は、第6章を参照してください。
プライマリ・データベースで次のSQL文を発行してスタンバイ・ロールに切り替えます。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
この文では、プライマリ・データベースをフィジカル・スタンバイ・データベースに変換します。現行の制御ファイルは、スイッチオーバーの前にカレントSQLセッション・トレース・ファイルにバックアップされます。これによって、必要に応じて現行の制御ファイルを再作成できるようになります。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT;
スイッチオーバー・プロセスのこの時点では、元のプライマリ・データベースがフィジカル・スタンバイ・データベースです（図8-2を参照）。
スタンバイ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO_PRIMARY 1 row selected
値TO STANDBYまたはSESSIONS ACTIVEは、スタンバイ・データベースでプライマリ・ロールに切り替える準備が完了していることを示します。これらのいずれの値も戻されない場合、REDO applyがアクティブで、REDO転送が正しく構成されて機能していることを確認します。値TO PRIMARYまたはSESSIONS ACTIVEが戻されるまで、この列の問合せを続行します。
次のSQL文をターゲット・フィジカル・スタンバイ・データベースで発行します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
SQL> ALTER DATABASE OPEN;
次に例を示します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
V$ARCHIVE_GAPビューを問い合せて、ターゲット・スタンバイ・データベースにREDOギャップがあるかどうか判別します。
次に例を示します。
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ---------- ------------- -------------- 1 90 92
この例では、スレッド1の順序90、91および92のアーカイブREDOログ・ファイルがギャップです。
可能であれば、欠落しているすべてのアーカイブREDOログ・ファイルを、プライマリ・データベースからターゲット・スタンバイ・データベースにコピーして登録します。スレッドごとに実行する必要があります。
次に例を示します。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
手順1 で実行する問合せでは、順序番号が最も大きいギャップに関する情報のみが表示されます。ギャップを解決した後、行が戻されなくなるまで問合せを繰り返します。
欠落したアーカイブREDOログ・ファイルが他に存在するかどうかを判断するには、ターゲット・スタンバイ・データベースでV$ARCHIVED_LOGビューを問い合せて、スレッドごとに最も大きい順序番号を取得します。
次に例を示します。
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) 2> OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG; THREAD LAST ---------- ---------- 1 100
可能であれば、ターゲット・スタンバイ・データベースで使用可能な最も大きい順序番号より大きい順序番号を含むアーカイブREDOログ・ファイルを、プライマリ・データベースからターゲット・スタンバイ・データベースにコピーして登録します。スレッドごとに実行する必要があります。
次に例を示します。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
欠落したアーカイブREDOログ・ファイルがターゲット・スタンバイ・データベースにコピーされたら、手順1 に戻り、追加のREDOギャップが発生していないかどうか確認します。
手順1 から手順3 を実行した後、アーカイブREDOログ・ファイルのすべてのギャップを解決できない場合（障害の発生したプライマリ・データベースのホスト・システムへのアクセス権がない場合など）、フェイルオーバー時にデータが消失する可能性があります。
次のSQL文を発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
次のSQL文を発行します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
この文がエラーなしに終了した場合、手順6 に進みます。
エラーが発生した場合、受信されたREDOデータに適用されていないものがあります。エラーの原因を解決し、文を再発行してから次の手順に進みます。
エラー状態を解決できない場合でも、次のSQL文を発行してフェイルオーバーを実行できます（一部のデータが消失する可能性があります）。
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
ACTIVATE文が完了した後、手順8 に進みます。
ターゲット・スタンバイ・データベースでV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO PRIMARY 1 row selected
値TO STANDBYまたはSESSIONS ACTIVEは、スタンバイ・データベースでプライマリ・ロールに切り替える準備ができていることを示します。これらのいずれの値も戻されない場合、REDO applyがアクティブで、TO PRIMARYまたはSESSIONS ACTIVEのいずれかが戻されるまでこのビューを問い合せ続けることを確認します。
次のSQL文を発行します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
SQL> ALTER DATABASE OPEN;
新しいプライマリ・データベースの全体バックアップを作成することをお薦めします。
フェイルオーバーの完了後、元のプライマリ・データベースは13.2項または13.7項で説明する方法に従って、新しいプライマリ・データベースのフィジカル・スタンバイ・データベースに変換できます。あるいは、3.2項で説明した方法に従って、新しいプライマリ・データベースのバックアップからフィジカル・スタンバイ・データベースとして再作成できます。
元のプライマリ・データベースをスタンバイ・ロールで実行したら、スイッチオーバーを実行してプライマリ・ロールにリストアできます。
この項では、ロジカル・スタンバイ・データベースが関与するスイッチオーバーおよびフェイルオーバーの実行方法を説明します。
プライマリ・データベースとロジカル・スタンバイ・データベースとの間でスイッチオーバーを実行する場合、スイッチオーバーは、常にプライマリ・データベースで開始し、ロジカル・スタンバイ・データベースで完了してください。次の手順を記載されているとおりの順序で実行しなかった場合、スイッチオーバーは成功しません。
スイッチオーバーを実行できるかどうかを確認するには、現行のプライマリ・データベースでV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO STANDBY 1 row selected
SWITCHOVER_STATUS列の値TO STANDBYまたはSESSIONS ACTIVEは、プライマリ・データベースをロジカル・スタンバイ・ロールに切替え可能であることを示します。これらの値のいずれかが表示されない場合は、Data Guard構成が正常に機能していることを確認してください（たとえば、LOG_ARCHIVE_DEST_nパラメータのすべての値が正しく指定されていることを確認します）。V$DATABASEビューのSWITCHOVER_STATUS列に対するその他の有効な値は、『Oracle Databaseリファレンス』を参照してください。
ロジカル・スタンバイ・データベース・ロール用に現行のプライマリ・データベースを準備するには、プライマリ・データベースで次のSQL文を発行します。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
この文は、現行のプライマリ・データベースがロジカル・スタンバイ・ロールに切り替わり、新しいプライマリ・データベースからREDOデータの受信を開始することを、現行のプライマリ・データベースに通知します。この手順は、現行のロジカル・スタンバイ・データベースのREDOストリームで記録されるLogMinerディクショナリを受信するための準備中に、プライマリ・データベースで実行します。手順3を参照してください。
この操作に成功すると、V$DATABASE.SWITCHOVER_STATUS列に値PREPARING SWITCHOVERが表示されます。
スイッチオーバーのターゲットであるロジカル・スタンバイ・データベースでLogMinerディクショナリを作成するには、次の文を使用します。
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
また、この文は、現行のプライマリ・データベース、およびData Guard構成内の他のスタンバイ・データベースにREDOデータの転送を開始するロジカル・スタンバイ・データベースで、REDO転送サービスを開始します。このロジカル・スタンバイ・データベースからREDOデータを受信するサイトは、REDOデータを受け入れますが、適用はしません。
このスイッチオーバーは、処理量とデータベースのサイズによって完了までに時間がかかる場合があります。
ロジカル・スタンバイ・データベースのV$DATABASE.SWITCHOVER_STATUSには、LogMinerディクショナリがREDOストリームに記録されている間、最初はPREPARING DICTIONARYが表示されます。正常に完了すると、SWITCHOVER_STATUS列にPREPARING SWITCHOVERが表示されます。
プライマリ・データベースからロジカル・スタンバイ・ロールへのロールの推移を完了する前に、プライマリ・データベースでV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せ、プライマリ・データベースでLogMinerディクショナリが受信されていることを確認します。LogMinerディクショナリが受信されていない場合、スイッチオーバーは進行できません。これは、現行のプライマリ・データベースでは、将来のプライマリ・データベースから送信されるREDOレコードを解析できないためです。SWITCHOVER_STATUS列は、スイッチオーバーの進捗を示します。
問合せがTO LOGICAL STANDBY値を戻した場合は、手順5に進むことができます。次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO LOGICAL STANDBY 1 row selected
プライマリ・データベースからロジカル・スタンバイ・データベース・ロールへのロールの推移を完了するには、次のSQL文を発行します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
この文は、プライマリ・データベースで現在のトランザクションがすべて終了するまで待機し、新規ユーザーによる新規トランザクションの開始を防止して、スイッチオーバーがコミットされる時点を設定します。
この文を実行すると、ユーザーはロジカル・スタンバイ・データベースでメンテナンスされているデータの変更もできなくなります。スイッチオーバーを迅速に実行するには、スイッチオーバー文を発行する前に、プライマリ・データベースが静止状態で更新アクティビティが実行されていないことを確認してください（たとえば、すべてのユーザーをプライマリ・データベースから一時的にログオフします）。V$TRANSACTIONビューを問い合せると、この文の実行を遅延させる可能性のある現在進行中のトランザクションのステータス情報を取得できます。
この時点でプライマリ・データベースのロールが推移して、スタンバイ・データベース・ロールで実行されます。
プライマリ・データベースをロジカル・スタンバイ・データベース・ロールに推移した場合は、データベースを停止して再起動する必要はありません。
プライマリ・データベースからロジカル・スタンバイ・ロールへのロールの推移を完了し、構成内のスタンバイ・データベースがスイッチオーバー通知を受け取った後、ターゲット・スタンバイ・データベースでV$DATABASE固定ビューのSWITCHOVER_STATUS列を問い合せ、ターゲット・スタンバイ・データベースがスイッチオーバー通知を処理したかどうかを確認する必要があります。使用可能なすべてのREDOレコードがロジカル・スタンバイ・データベースに適用されると、SQL Applyは予想されるロールの推移の準備を自動的に停止します。
スイッチオーバー中にSWITCHOVER_STATUS値が更新され、進捗を示します。ステータスがTO PRIMARYの場合は、手順7に進むことができます。
次に例を示します。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS ----------------- TO PRIMARY 1 row selected
V$DATABASEビューのSWITCHOVER_STATUS列に対するその他の有効な値は、『Oracle Databaseリファレンス』を参照してください。
プライマリ・ロールに切り替えるロジカル・スタンバイ・データベースで、次のSQL文を使用し、ロジカル・スタンバイ・データベースをプライマリ・ロールに切り替えます。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Data Guard構成内のロジカル・スタンバイ・データベースは、停止して再起動する必要はありません。8.1.2項で説明したように、構成内の他のすべてのロジカル・スタンバイは新しいプライマリのスタンバイになりますが、フィジカル・スタンバイ・データベースは、元のプライマリ・データベースのスタンバイのままです。
新しいロジカル・スタンバイ・データベースでSQL Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
この項では、ロジカル・スタンバイ・データベースが関与するフェイルオーバーの実行方法を説明します。ロジカル・スタンバイ・データベースが関与するフェイルオーバーによるロールの推移では、障害の発生したプライマリ・データベースとすべてのロジカル・スタンバイ・データベースで対処措置を実行する必要があります。障害の発生したプライマリ・データベースでフラッシュバック・データベースが有効化されていない場合は、現行のプライマリ・データベースから作成したバックアップを使用してデータベースを再作成する必要があります。それ以外の場合は、13.2項で説明する手順に従って、障害の発生したプライマリ・データベースを新しいプライマリ・データベースのロジカル・スタンバイ・データベースに変換できます。
構成に対する保護モードおよびREDO転送サービスに対して選択した属性に従って、プライマリ・データベースの修正の一部またはすべてを自動的にリカバリすることも可能です。
構成に含まれるコンポーネントの状態によっては、プライマリ・データベースのアーカイブREDOログ・ファイルにアクセスできる場合があります。アクセスする場合の手順は、次のとおりです。
次の文を発行して、アーカイブREDOログ・ファイルをロジカル・スタンバイ・データベースに登録できます。次に例を示します。
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 2> '/disk1/oracle/dbs/log-%r_%s_%t.arc'; Database altered.
ロールベースの宛先をまだ構成していない場合は、新しいプライマリ・データベースのリモート・ロジカル・スタンバイ宛先に対応する初期化パラメータを特定して、これらの宛先ごとにREDOデータのアーカイブを手動で使用可能にします。
たとえば、LOG_ARCHIVE_DEST_2パラメータで定義したリモート宛先のアーカイブを可能にするには、次の文を発行します。
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;
後で新しいプライマリ・データベースを再起動した場合にもこの変更を保持するには、適切なテキスト初期化パラメータ・ファイルまたはサーバー・パラメータ・ファイルを更新します。通常、データベースがプライマリ・ロールで動作する場合はリモート宛先へのアーカイブを可能にし、データベースがスタンバイ・ロールで動作する場合はリモート宛先へのアーカイブを不可能にする必要があります。
ターゲット・ロジカル・スタンバイ・データベース（新規プライマリ・ロールに推移させるデータベース）で、次の文を発行します。
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;
この文はRFSプロセスを停止し、ロジカル・スタンバイ・データベースがプライマリ・データベースになる前にスタンバイREDOログ・ファイルに残っているREDOデータを適用し、SQL Applyを停止して、データベースをプライマリ・データベース・ロールでアクティブ化します。
FINISH APPLY句が指定されていない場合、現行のスタンバイREDOログ・ファイルの未適用のREDOは、スタンバイ・データベースがプライマリ・データベースになるまで適用されません。
13.1項で説明する方法に従って、既存のロジカル・スタンバイ・データベースが新しいプライマリ・データベースを引き続き保護できるようにします。
Data Guardのデータベース・フェイルオーバー直後に、新しいプライマリ・データベースのバックアップを作成します。バックアップを即時に実行することは、必要な安全策です。これは、データベースの完全なバックアップ・コピーを作成せずにフェイルオーバーを行うと、変更をリカバリできないためです。
フェイルオーバーの完了後、元のプライマリ・データベースは13.2項で説明する方法に従って、新しいプライマリ・データベースのロジカル・スタンバイ・データベースに変換できます。あるいは、第4章で説明したように、新しいプライマリ・データベースのバックアップからロジカル・スタンバイ・データベースとして再作成できます。
元のプライマリ・データベースをスタンバイ・データベースに変換したら、スイッチオーバーを実行してプライマリ・ロールにリストアできます。
ロールの推移後に、必要に応じてFLASHBACK DATABASEコマンドを使用して、データベースをロールの推移が発生する前の時点またはシステム変更番号（SCN）まで戻すことができます。
フィジカル・スタンバイ・データベース環境では、Data Guard構成を維持するためにプライマリ・データベースとすべてのスタンバイ・データベースのフラッシュバックが必要になる場合があります。プライマリ・データベースを特定のSCNまたは時点までフラッシュバックする場合は、すべてのスタンバイ・データベースを同じ（またはそれ以前の）SCNまたは時点までフラッシュバックする必要があります。これにより、REDO Applyの開始後に、フィジカル・スタンバイ・データベースではプライマリ・データベースから受信したREDOデータの適用が自動的に開始されます。
この方法でプライマリ・データベースまたはスタンバイ・データベースをフラッシュバックすると、過去のスイッチオーバーを認識する必要がありません。Oracleでは、SCNまたは時点が過去のスイッチオーバーより前であれば、過去のスイッチオーバーにまたがって自動的にフラッシュバックできます。
スイッチオーバー後にFLASHBACK DATABASEコマンドを使用して、データベースをスイッチオーバー発生前の時点またはシステム変更番号（SCN）に戻すことができます。
スイッチオーバーにフィジカル・スタンバイ・データベースが関与していた場合、フラッシュバック操作中はプライマリおよびスタンバイ・データベース・ロールが保持されます。つまり、データベースが実行中のロールは、フラッシュバックした時点またはターゲットSCNまでデータベースがフラッシュバックされても変化しません。スイッチオーバー後からフラッシュバックの前までフィジカル・スタンバイ・ロールで実行されていたデータベースは、フラッシュバック・データベース操作後もフィジカル・スタンバイ・データベースで実行されます。
スイッチオーバーにロジカル・スタンバイ・データベースが関与していた場合、フラッシュバックするとスタンバイ・データベースのロールはフラッシュバックした時点またはターゲットSCNでのロールに変更されます。
フラッシュバック・データベースを使用して、障害の発生したプライマリ・データベースをフェイルオーバー発生前の時点に変換してから、スタンバイ・データベースに変換できます。詳細な手順は、13.2項「フラッシュバック・データベースを使用した障害が発生したプライマリのスタンバイ・データベースへの変換」を参照してください。
|
 Copyright © 1999, 2008 Oracle Corporation. All Rights Reserved. |
|