11gリリース1（11.1）
E05755-03
 目次 |
 索引 |
| Oracle Data Guard 概要および管理 11gリリース1（11.1） E05755-03 |
|
この章では、フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースの管理方法について説明します。次の項目で構成されています。
Data Guard Brokerを使用してフィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースの管理を簡素化する方法の詳細は、『Oracle Data Guard Broker』を参照してください。
この項では、フィジカル・スタンバイ・データベースを起動および停止する方法について説明します。
フィジカル・スタンバイ・データベースを起動するには、SQL*Plus STARTUPコマンドを使用します。SQL*Plus STARTUPコマンドは、引数を指定せずに起動すると、フィジカル・スタンバイ・データベースを読取り専用モードで起動、マウントおよびオープンします。
フィジカル・スタンバイ・データベースは、マウントまたはオープンされると、プライマリ・データベースからREDOデータを受信できます。
REDO Applyの詳細は7.3項を、フィジカル・スタンバイ・データベースを読取り専用モードでオープンする方法の詳細は9.2項を参照してください。
REDO Applyを停止してフィジカル・スタンバイ・データベースを停止するには、SQL*Plus SHUTDOWNコマンドを使用します。停止処理が完了するまで、データベース停止を開始したセッションに制御が戻されません。
プライマリ・データベースが起動して稼働している場合は、フィジカル・スタンバイ・データベースを停止する前に、プライマリ・データベースでスタンバイ宛先を遅延し、ログ・スイッチを実行します。
フィジカル・スタンバイ・データベースは、読取り専用アクセス用にオープンし、問合せをプライマリ・データベースからオフロードするために使用できます。
Oracle Active Data Guardオプションのライセンスを購入済の場合、REDO Applyがアクティブである間は、フィジカル・スタンバイ・データベースをオープンできます。この機能は、リアルタイム問合せと呼ばれます。詳細は、9.2.1項を参照してください。
Oracle Active Data Guardオプションのライセンスを未購入の場合、REDO Applyがアクティブである間は、フィジカル・スタンバイ・データベースをオープンできません。そのため、フィジカル・スタンバイ・データベース・インスタンスのオープン時またはREDO Applyの開始時には、次のルールに従う必要があります。
フィジカル・スタンバイ・データベースは、Oracle Active Data Guardオプションのライセンスを購入済の場合、REDO Applyがアクティブである間は読取り専用アクセス用にオープンできます。この機能は、リアルタイム問合せと呼ばれます。
フィジカル・スタンバイ・データベース・インスタンスは、REDO Applyがそのインスタンスまたは他のマウント済インスタンスでアクティブである場合、オープンできません。次のSQL文を使用してREDO Applyを停止し、スタンバイ・インスタンスを読取り専用でオープンしてREDO Applyを再開します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; SQL> ALTER DATABASE OPEN; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 2> DISCONNECT;
REDO Applyは、他のインスタンスがオープンされている場合、マウント済フィジカル・スタンバイ・インスタンスでは開始できません。REDO Applyを開始する予定のインスタンスは、REDO Applyの開始前にオープンしておく必要があります。
フィジカル・スタンバイ適用インスタンスが（強制終了やノード・クラッシュなどにより）異常終了すると、フィジカル・スタンバイ・データベースのオープンは「ORA-16004: バックアップ・データベースをリカバリしてください。」エラーとなります。このエラーが発生した場合は、REDO Applyを開始した後、フィジカル・スタンバイ・データベースを再度オープンする前にREDO Applyを停止する必要があります。
例9-1で、Bostonというフィジカル・スタンバイ・データベース・インスタンスの障害およびリカバリと、リカバリ後にREDO ApplyがアクティブであるときのBostonのオープン（リアルタイム問合せ）を説明します。
この例の初めに、フィジカル・スタンバイ・インスタンスのBostonをREDO Applyがアクティブの状態でマウントします。次に、Bostonは停電のためにクラッシュし、再起動されます。
SQL> STARTUP ORACLE instance started. Total System Global Area 234364928 bytes Fixed Size 1298908 bytes Variable Size 209718820 bytes Database Buffers 16777216 bytes Redo Buffers 6569984 bytes Database mounted. ORA-16004: backup database requires recovery ORA-01196: file 1 is inconsistent due to a failed media recovery session ORA-01110: data file 1: '/scratch/datafiles/oracle/dbs/system1.f'
フィジカル・スタンバイ・データベースは、REDO ApplyがアクティブであるときにBostonインスタンスがクラッシュしたため、一貫性が欠如しています。REDO Applyを開始して、データベースが一貫性のあるSCNまでリカバリできるようにします。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; Database altered.
1分ほど待機した後、REDO Applyを停止します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; Database altered.
アラート・ログには、通常予想される警告「ORA-16037: 管理リカバリ操作の取消がユーザーからリクエストされました。」がリストされます。
この時点で、Bostonは一貫性のあるSCNまでリカバリされました。
Bostonをオープンし、REDO Applyを開始します。
SQL> ALTER DATABASE OPEN; Database altered. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING 2> CURRENT LOGFILE DISCONNECT; Database altered.
この時点で、Bostonはオープンされ、REDO Applyはアクティブです。つまり、リアルタイム問合せは有効です。
プライマリ・データベースに対して行われる構造の変更のほとんどは、REDOデータによってフィジカル・スタンバイ・データベースに自動的に伝播します。表9-1に、フィジカル・スタンバイ・データベースで手動操作が必要なプライマリ・データベースの構造および構成の変更を示します。
STANDBY_FILE_MANAGEMENTデータベース初期化パラメータは、プライマリ・データベースへのデータファイルの追加をフィジカル・スタンバイ・データベースに自動的に伝播するかどうかを制御します。
STANDBY_FILE_MANAGEMENTパラメータがAUTOに設定されている場合、プライマリ・データベースに作成された新しいデータファイルはフィジカル・スタンバイ・データベースに自動的に作成されます。
STANDBY_FILE_MANAGEMENTデータベース・パラメータがMANUALに設定されている場合、新しいデータファイルがプライマリ・データベースに追加されると、そのファイルは、プライマリ・データベースからフィジカル・スタンバイ・データベースに手動でコピーする必要があります。
別のデータベースの既存のデータファイルがプライマリ・データベースにコピーされた場合、同様にそのファイルをスタンバイ・データベースにコピーする必要があり、STANDBY_FILE_MANAGEMENTパラメータの設定に関係なくスタンバイ制御ファイルを再作成する必要があります。
STANDBY_FILE_MANAGEMENTパラメータをAUTOに設定すると、新しいデータファイルがプライマリ・データベースに追加または削除されるたびに、手動操作しなくても対応する変更がスタンバイ・データベースに加えられます。これは、スタンバイ・データベースでファイル・システムが使用されている場合です。スタンバイ・データベースでデータファイルにRAWデバイスが使用されている場合もSTANDBY_FILE_MANAGEMENTパラメータは機能しますが、手動操作が必要です。この手動操作では、REDO Applyによって新しいデータファイルを作成するREDOデータが適用される前に、RAWデバイスの存在を確認します。
プライマリ・データベースで、データファイルがRAWデバイスに常駐する新規表領域を作成します。それと同時に、スタンバイ・データベースでも同じRAWデバイスを作成します。次に例を示します。
SQL> CREATE TABLESPACE MTS2 - > DATAFILE '/dev/raw/raw100' size 1m; Tablespace created. SQL> ALTER SYSTEM SWITCH LOGFILE; System altered.
スタンバイ・データベースでは、RAWデバイスが存在するため自動的にデータファイルが追加されます。スタンバイ・アラート・ログには次のように示されます。
Fri Apr 8 09:49:31 2005 Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/
o1_mf_1_7_15ffgt0z_.arc Recovery created file /dev/raw/raw100 Successfully added datafile 6 to media recovery Datafile #6: '/dev/raw/raw100' Media Recovery Waiting for thread 1 sequence 8 (in transit)
ただし、プライマリ・システム上でRAWデバイスが作成されてもスタンバイ上で作成されなければ、REDO Applyはファイル作成エラーにより停止します。たとえば、プライマリ・データベースで次の文を発行します。
SQL> CREATE TABLESPACE MTS3 - > DATAFILE '/dev/raw/raw101' size 1m; Tablespace created. SQL> ALTER SYSTEM SWITCH LOGFILE; System altered.
スタンバイ・システムには、RAWデバイス/dev/raw/raw101が作成されていません。アーカイブをリカバリすると、スタンバイ・アラート・ログに次のメッセージが示されます。
Fri Apr 8 10:00:22 2005 Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_08/o1_ mf_1_8_15ffjrov_.arc File #7 added to control file as 'UNNAMED00007'. Originally created as: '/dev/raw/raw101' Recovery was unable to create the file as: '/dev/raw/raw101' MRP0: Background Media Recovery terminated with error 1274 Fri Apr 8 10:00:22 2005 Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc: ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created ORA-01119: error in creating database file '/dev/raw/raw101' ORA-27041: unable to open file Linux Error: 13: Permission denied Additional information: 1 Some recovered datafiles maybe left media fuzzy Media recovery may continue but open resetlogs may fail Fri Apr 8 10:00:22 2005 Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc: ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created ORA-01119: error in creating database file '/dev/raw/raw101' ORA-27041: unable to open file Linux Error: 13: Permission denied Additional information: 1 Fri Apr 8 10:00:22 2005 MTS; MRP0: Background Media Recovery process shutdown ARCH: Connecting to console port...
9.3.1.1項で説明した問題を修正する手順は、次のとおりです。
V$DATAFILEビューを問い合せます。次に例を示します。
SQL> SELECT NAME FROM V$DATAFILE; NAME. -------------------------------------------------------------------------------- /u01/MILLER/MTS/system01.dbf /u01/MILLER/MTS/undotbs01.dbf /u01/MILLER/MTS/sysaux01.dbf /u01/MILLER/MTS/users01.dbf /u01/MILLER/MTS/mts.dbf /dev/raw/raw100 /u01/app/oracle/product/10.1.0/dbs/UNNAMED00007 SQL> ALTER SYSTEM SET - > STANDBY_FILE_MANAGEMENT=MANUAL; SQL> ALTER DATABASE CREATE DATAFILE 2 '/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007' 3 AS 4 '/dev/raw/raw101';
Fri Apr 8 10:09:30 2005 alter database create datafile '/dev/raw/raw101' as '/dev/raw/raw101' Fri Apr 8 10:09:30 2005 Completed: alter database create datafile '/dev/raw/raw101' a
STANDBY_FILE_MANAGEMENTをAUTOに設定してREDO Applyを再開します。
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO; SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT;
この時点で、REDO Applyは新規のRAWデバイスのデータファイルを使用し、リカバリが続行されます。
プライマリ・データベースから表領域またはデータファイルを削除した場合、対応するデータファイルをフィジカル・スタンバイ・データベースから削除する必要があります。次の例に、表領域を削除する方法を示します。
SQL> DROP TABLESPACE tbs_4; SQL> ALTER SYSTEM SWITCH LOGFILE;
削除されたデータファイルがデータベースに属していないことを確認するには、V$DATAFILEビューを問い合せます。
過去の変更を含むREDOデータがスタンバイ・データベースに適用された後、スタンバイ・システムで対応するデータファイルを削除します。次に例を示します。
% rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf
削除した表領域のREDO情報がスタンバイ・データベースで適用されたことを確認した後、プライマリ・データベースで表領域のデータファイルを削除できます。次に例を示します。
% rm /disk1/oracle/oradata/payroll/tbs_4.dbf
プライマリ・データベースでSQL DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES文を発行すると、プライマリ・データベースとスタンバイ・データベースの両方からデータファイルを削除できます。この文を使用するには、STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定する必要があります。たとえば、プライマリ・サイトで表領域を削除するには、次のように入力します。
SQL> DROP TABLESPACE INCLUDING CONTENTS - > AND DATAFILES tbs_4; SQL> ALTER SYSTEM SWITCH LOGFILE;
Oracleトランスポータブル表領域機能を使用すると、Oracleデータベースのサブセットを移動して、別のOracleデータベースにプラグインできます。これにより、実際には表領域がデータベース間で移動します。
フィジカル・スタンバイの使用中に表領域セットをプライマリ・データベースに移動またはコピーする手順は、次のとおりです。
データファイルは、DB_FILE_NAME_CONVERT初期化パラメータで定義したディレクトリにコピーする必要があります。DB_FILE_NAME_CONVERTが定義されていない場合は、トランスポータブル表領域を含むREDOデータが適用されて失敗した後に、ALTER DATABASE RENAME FILE文を発行してスタンバイ制御ファイルを変更します。STANDBY_FILE_MANAGEMENT初期化パラメータはAUTOに設定する必要があります。
データ・ポンプ・ユーティリティを起動して、表領域セットをプライマリ・データベースにプラグインします。スタンバイ・サイトでREDOデータが生成されて適用され、表領域がスタンバイ・データベースにプラグインされます。
トランスポータブル表領域の詳細は、『Oracle Database管理者ガイド』を参照してください。
プライマリ・データベースで1つ以上のデータファイルを改名した場合、その変更はスタンバイ・データベースに伝播されません。STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定しても変更処理は自動的に実行されないため、スタンバイ・データベースにある同じデータファイルを改名する場合は、スタンバイ・データベースで同じ変更を手動で行う必要があります。
次の手順では、プライマリ・データベースでデータファイルを改名し、その変更をスタンバイ・データベースに手動で伝播する方法について説明します。
SQL> ALTER TABLESPACE tbs_4 OFFLINE;
mvコマンドなどのオペレーティング・システム・コマンドを発行して、プライマリ・システム上のデータファイルを改名します。
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE
2> '/disk1/oracle/oradata/payroll/tbs_4.dbf' 3> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf'; SQL> ALTER TABLESPACE tbs_4 ONLINE;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> SHUTDOWN;
mvコマンドなどのオペレーティング・システム・コマンドを使用して、スタンバイ・サイトでデータファイルを改名します。
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/
tbs_x.dbf
SQL> STARTUP MOUNT;
STANDBY_FILE_MANAGEMENT初期化パラメータはMANUALに設定する必要があります。
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf' 2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 2> DISCONNECT FROM SESSION;
スタンバイ・システムで対応するデータファイルを改名しないでスタンバイ・データベース制御ファイルをリフレッシュしようとすると、スタンバイ・データベースは改名されたデータファイルの使用を試みますが、改名されたデータファイルは見つかりません。したがって、アラート・ログに次のようなエラー・メッセージが表示されます。
ORA-00283: recovery session canceled due to errors ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'
プライマリ・データベースでREDOログ・ファイル・グループを追加または削除した後に、フィジカル・スタンバイ・データベースのREDOログおよびスタンバイREDOログの構成を再評価し、必要に応じて調整する必要があります。
次の手順を実行して、フィジカル・スタンバイ・データベースでREDOログ・ファイル・グループまたはスタンバイREDOログ・ファイル・グループを追加または削除します。
STANDBY_FILE_MANAGEMENT初期化パラメータをAUTOに設定している場合は、値をMANUALに変更します。
STANDBY_FILE_MANAGEMENT初期化パラメータおよびREDO Applyオプションを元の状態にリストアします。
NOLOGGINGまたはUNRECOVERABLE句を使用してDMLまたはDDL操作を実行するとスタンバイ・データベースは無効になるため、修正のために多大なDBA管理アクティビティが必要になる場合があります。SQL ALTER DATABASEまたはSQL ALTER TABLESPACE文でFORCELOGGING句を指定すると、NOLOGGING 設定を上書きできます。ただし、この文はすでに無効になっているデータベースを修正しません。
NOLOGGING句を使用した後のリカバリの詳細は、13.4項を参照してください。
REMOTE_LOGIN_PASSWORDFILEデータベース初期化パラメータがSHAREDまたはEXCLUSIVEに設定されている場合、管理権限を付与または取り消すか、あるいは管理権限を持つユーザーのパスワードを変更した後に、フィジカル・スタンバイ・データベースのパスワード・ファイルをプライマリ・データベースの最新コピーで置き換える必要があります。
フィジカル・スタンバイ・データベースのパスワード・ファイルをリフレッシュできないと、REDO転送セッションの認証やSYSDBAまたはSYSOPERとしてのフィジカル・スタンバイ・データベースへの接続が失敗する可能性があります。
フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットは、プライマリ・データベースでTDEマスター暗号化キーがリセットされるたびに、プライマリ・データベースのデータベース暗号化ウォレットの最新コピーで置き換える必要があります。
フィジカル・スタンバイ・データベースのデータベース暗号化ウォレットをリフレッシュできないと、プライマリ・データベースでマスター暗号化キーがリセットされた後に変更された、フィジカル・スタンバイ・データベース上の暗号化された列にアクセスできません。
Data Guardでは、RESETLOGSオプションを使用してプライマリ・データベースがオープンされた後も、フィジカル・スタンバイ・データベースでリカバリを続行できます。プライマリ・データベースでALTER DATABASE OPEN RESETLOGS文を発行すると、データベースのインカネーションが変更され、REDOデータの新規ブランチが作成されます。
フィジカル・スタンバイ・データベースがREDOデータの新規ブランチを受信すると、REDO Applyではそれが自動的に使用されます。フィジカル・スタンバイ・データベースの場合、スタンバイ・データベースにより新規リセットログのSCNより後（REDOデータの新規ブランチの開始より後）のREDOデータが適用されていなければ、手動による介入は必要ありません。次の表に、スタンバイ・データベースとプライマリ・データベースのブランチを再同期化する方法を示します。
| スタンバイ・データベースの状態 | 操作 | 実行する手順 |
|---|---|---|
|
新規リセットログのSCNの後（REDOデータの新規ブランチの開始より後）のREDOデータが適用されていない場合 |
REDO Applyは自動的にREDOの新規ブランチを使用します。 |
手動による介入は必要ありません。MRPは、自動的にスタンバイ・データベースをREDOデータの新規ブランチと再同期化します。 |
|
新規リセットログのSCNの後（REDOデータの新規ブランチの開始より後）のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっている場合 |
スタンバイ・データベースは、REDOデータの将来の新規ブランチでリカバリされます。 |
MRPは、自動的にスタンバイ・データベースを新規ブランチと再同期化します。 |
|
新規リセットログのSCNの後（REDOデータの新規ブランチの開始より後）のREDOデータが適用され、スタンバイ・データベースでフラッシュバック・データベースが使用可能になっていない場合 |
指定のプライマリ・データベース・ブランチで、プライマリ・データベースとスタンバイの内容にずれが生じます。 |
第3章の手順に従ってフィジカル・スタンバイ・データベースを再作成します。 |
|
REDOデータの新規ブランチから介入するアーカイブREDOログ・ファイルが欠落している場合 |
MRPは欠落しているログ・ファイルが取得されるまで続行できません。 |
各ブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。 |
|
REDOデータの前のブランチの終わりからアーカイブREDOログ・ファイルが欠落している場合 |
MRPは欠落しているログ・ファイルが取得されるまで続行できません。 |
前のブランチから欠落しているアーカイブREDOログ・ファイルを検索して登録します。 |
データベース・インカネーション、OPEN RESETLOGS操作を使用したリカバリおよびフラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
この項では、プライマリ・データベースおよびスタンバイ・データベースを監視するために役立つ情報の検索方法について説明します。
表9-2に、一般的なプライマリ・データベースの管理アクションと、そのアクションに関する情報の参照先を示します。
この項では、動的パフォーマンス・ビューを使用してプライマリ・データベース、フィジカル・スタンバイ・データベースおよびスナップショット・スタンバイ・データベースを監視する方法について説明します。
次の動的パフォーマンス・ビューについて説明します。
次の問合せは、プライマリ・データベース、フィジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースのデータ保護モード、データ保護レベル、データベース・ロールおよびスイッチオーバー・ステータスを表示します。
SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL, - > DATABASE_ROLE ROLE, SWITCHOVER_STATUS - > FROM V$DATABASE;
次の問合せは、ファスト・スタート・フェイルオーバーのステータスを表示します。
SQL> SELECT FS_FAILOVER_STATUS "FSFO STATUS", - > FS_FAILOVER_CURRENT_TARGET TARGET, - > FS_FAILOVER_THRESHOLD THRESHOLD, - > FS_FAILOVER_OBSERVER_PRESENT "OBSERVER PRESENT" - > FROM V$DATABASE;
次の問合せは、フィジカル・スタンバイ・データベースでのREDO ApplyおよびREDO転送ステータスを表示します。
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#,- > BLOCK#, BLOCKS FROM V$MANAGED_STANDBY; PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS ------- ------------ ---------- ---------- ---------- ---------- RFS ATTACHED 1 947 72 72 MRP0 APPLYING_LOG 1 946 10 72
このサンプル出力は、RFSプロセスがREDOログ・ファイル順序番号947のアーカイブを完了したことを示しています。また、REDO ApplyがアーカイブREDOログ・ファイル順序番号946を適用していることも示しています。REDO Applyは現在、72ブロックのアーカイブREDOログ・ファイルのブロック番号10をリカバリしている最中です。
次の問合せは、フィジカル・スタンバイ・データベースまたはスナップショット・スタンバイ・データベースでプライマリ・データベースから受信したアーカイブREDOログ・ファイルに関する情報を表示します。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, - > NEXT_CHANGE# FROM V$ARCHIVED_LOG; THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# ---------- ---------- ------------- ------------ 1 945 74651 74739 1 946 74739 74772 1 947 74772 7474
このサンプル出力は、プライマリ・データベースから受信した3つのアーカイブREDOログ・ファイルを示しています。
次の問合せは、アーカイブ・ログの履歴情報を表示します。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, - > NEXT_CHANGE# FROM V$LOG_HISTORY;
次の問合せは、アラート・ログまたはサーバー・プロセス・トレース・ファイルにメッセージが書き込まれる原因となったData Guardイベントによって生成されたメッセージを表示します。
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
REDO Applyおよびメディア・リカバリのパフォーマンスを最適化する方法は、『Oracle Data Guard Redo Apply and Media Recovery Best Practices』ホワイト・ペーパーを参照してください。このホワイト・ペーパーは、次のURLからOracle Maximum Availability Architecture（MAA）のホームページにアクセスして入手することができます。
http://otn.oracle.com/deploy/availability/htdocs/maa.htm
スナップショット・スタンバイ・データベースは、全面的に更新可能なスタンバイ・データベースで、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換して作成します。スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信およびアーカイブしますが、適用はしません。プライマリ・データベースから受信したREDOデータは、スナップショット・スタンバイ・データベースへのローカル更新がすべて破棄された後、スナップショット・スタンバイ・データベースが変換されてフィジカル・スタンバイ・データベースに戻ると適用されます。
スナップショット・スタンバイ・データベースは、通常、時間とともにプライマリ・データベースとは異なってきます。これは、プライマリ・データベースからのREDOデータが受信時に適用されないためです。スナップショット・スタンバイ・データベースに対するローカル更新が原因で、相違はさらに大きくなります。しかし、プライマリ・データベースのデータは完全に保護されます。これは、任意の時点でスナップショット・スタンバイを変換してフィジカル・スタンバイ・データベースに戻すことができ、その後にプライマリから受信したREDOデータが適用されるためです。
スナップショット・スタンバイ・データベースには、フィジカル・スタンバイ・データベースと同様の、障害時リカバリおよびデータ保護のメリットがあります。スナップショット・スタンバイ・データベースは、プライマリ・データベースの一時的かつ更新可能なスナップショットを保持することにメリットがあれば、管理上の複雑さやプライマリ・データベースの障害からリカバリする時間が増えてもかまわない場合に最もよく使用されます。
次の手順を実行して、フィジカル・スタンバイ・データベースをスナップショット・スタンバイ・データベースに変換します。
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;
データベースは変換後にディスマウントされ、再起動する必要があります。
スナップショット・スタンバイ・データベースは読取り/書込みモードでオープンされ、全体を更新できます。
スナップショット・スタンバイ・データベースには、次の特性があります。
次の手順を実行して、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに変換します。
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
データベースは変換後にディスマウントされ、再起動する必要があります。
データベースがスナップショット・スタンバイ・データベースの間に受信したREDOデータは、REDO Applyが開始されると自動的に適用されます。
|
 Copyright © 1999, 2008 Oracle Corporation. All Rights Reserved. |
|