バックアップからデータベースを復元し、多くのアーカイブを適用して一貫性を保つことができます。ここで、開いているリセットログが正常に機能することを確認します。
不完全なリカバリ後にデータベースの整合性を確認する方法は次のとおりです
以下のステートメントは、日付形式を拡張形式に設定します。これは、分析で何度も必要になるためです
。SQL> alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS' ;
チェック1：
目的：データファイルが目的の時点（PIT）に回復され、一貫していることを確認します（FUZZY =NO）
現在のステータスとPITを照会します（データファイルが存在するまでのP-oint I-n T-ime）物理データファイルから直接データファイルヘッダーを読み取ることによるデータファイルの回復）：
SQL> select fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) from v$datafile_header group by fuzzy, status, error, recover, checkpoint_change#, checkpoint_time ;
- checkpoint_time / checkpoint_change＃が目的のUNTIL TIME/SCNと一致していることを確認します。そうでない場合、より多くのアーカイブログが利用可能であれば、データベースをさらに回復します。
- 一部のデータファイルでFUZZY=YESの場合、より多くのリカバリが必要であることを意味します。アーカイブされたログがこれ以上利用できない場合は、そのようなデータファイルを特定し、それらのデータファイルのデータが失われるため、オフラインにできるかどうかを判断します。データファイルがSYSTEMまたはUNDOテーブルスペースに属している場合、適切な分析なしにそのようなデータファイルをオフラインにすることはできません/してはなりません。その他のアクションについては、Oracleサポートにご相談ください。
SQL> select file#, substr(name, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# from v$datafile_header where fuzzy='YES' ;
場合によっては、テーブルスペース名がUNDOテーブルスペースであることを示していない場合、列UNDO_OPT_CURRENT_CHANGE＃にゼロ以外の値が表示されている場合は、データファイルにUNDOセグメントが含まれていることを示しています。
データファイルをオフラインにするには：
SQL> alter database datafile offline ;
チェック1は、次の場合に合格と見なすことができます。
+すべてのデータファイルが目的の時点まで回復されたことを確認しました。
+システム、UNDO、およびすべての目的のデータファイルに対してFuzzy=NO。 Fuzzy =YESのデータファイルの場合、それらをさらに回復するか、アーカイブされたログがそれ以上利用できない場合はオフラインにします。
チェック2：
目的：status=RECOVERのファイルが意図せずオフラインになっていないことを確認します
SQL> select status, enabled, count(*) from v$datafile group by status, enabled ; STATUS ENABLED COUNT(*) ------- ---------- ---------- SYSTEM DISABLED 1 ONLINE READ WRITE 1114 RECOVER DISABLED 2
ファイルがRECOVERステータスの場合は、オフラインかどうかを確認します：
SQL> select file#, substr(name, 1, 50), status, error, recover from v$datafile_header ;
これらのファイルのデータにアクセスできるようにする場合は、オンラインにします：
SQL> alter database datafile ONLINE ;
OPEN RESETLOGSの時点でファイルがオフラインのままである場合、同じOPENEDデータベースでデータファイルを再びオンラインに戻すことはできません。
チェック2は、次の場合に合格と見なすことができます。
a）目的のデータファイルがすべてオフラインではありません
チェック3：
目的：追加のファジーチェック（絶対ファジーチェック）
場合によっては、目的のすべてのデータファイルに対してFuzzy =NOおよび同じcheckpoint_change＃が表示されることがあります。それでも一部のデータファイルはあいまいで、OPENRESETLOGSはエラーを返します。例：
SQL> select fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*) from v$datafile_header group by fuzzy, status, error, recover, checkpoint_change#, checkpoint_time ; FUZ STATUS ERROR REC CHECKPOINT_CHANGE# CHECKPOINT_TIME COUNT(*) --- ------- --------------- --- ------------------ -------------------- ---------- NO ONLINE 5375858580 31-OCT-2011 23:10:14 7 SQL> ALTER DATABASE OPEN RESETLOGS ; ORA-01194: file 14 needs more recovery to be consistent ORA-01110: data file 3: '/u01/app/oracle/oradata/TEST/undotbs02.dbf' Hence, we should perform additional fuzzy check known as Absolute Fuzzy Check:
SQL> select hxfil file#, substr(hxfnm, 1, 50) name, fhscn checkpoint_change#, fhafs Absolute_Fuzzy_SCN, max(fhafs) over () Min_PIT_SCN from x$kcvfh where fhafs!=0 ;
注：列Min_PIT_SCNは、ANALYTICALの「MAX（）OVER（）」関数を適用したため、複数の行に対しても同じ値を返します。
上記のクエリは、データファイルの整合性を保ち、開く準備をするために、少なくともSCN5311524までリカバリを実行する必要があることを示しています。 checkpoint_change＃はMin_PIT_SCNよりも小さいため、データファイルはより多くの回復を要求します。
チェック3は、次の場合に合格と見なすことができます。
a）上記のクエリから選択された行がない（つまり、すべてのデータファイルでMin_PIT_SCNが0（ゼロ）である）
b）Min_PIT_SCNがCheckpoint_Change＃
チェック4：必要なアーカイブログ
制御ファイルを照会して、リカバリに必要な最新のアーカイブログを見つけます。バックアップが2011年8月31日23:20:14に完了したとしましょう：
SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> SELECT THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG
WHERE '31-AUG-11 23:20:14' BETWEEN FIRST_TIME AND NEXT_TIME;
上記のクエリが行を返さない場合は、情報が制御ファイルから古くなっている可能性があります。v$log_historyに対して次のクエリを実行してください。
SQL> ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-RR HH24:MI:SS';
SQL> select a.THREAD#, a.SEQUENCE#, a.FIRST_TIME
from V$LOG_HISTORY a
where FIRST_TIME =
( SELECT MAX(b.FIRST_TIME)
FROM V$LOG_HISTORY b
WHERE b.FIRST_TIME < to_date('31-AUG-11 23:20:14', 'DD-MON-RR HH24:MI:SS') ) ; SQL>
The sequence# returned by the above query is the log sequence current at the time the backup ended - let say 530 thread 1.
最小限のリカバリを使用する場合:(返されたシーケンス番号+1）
RMAN> RUN
{
SET UNTIL SEQUENCE 531 THREAD 1;
RECOVER DATABASE;
}
これがRAC実装の場合は、代わりにこのSQLを使用して制御ファイルを照会します。
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# FROM V$ARCHIVED_LOG WHERE '31-AUG-11 23:20:14' BETWEEN FIRST_TIME AND NEXT_TIME;
最小限の回復のために、上記のクエリによって返されるNEXT_CHANGE＃が最も低いログシーケンスとスレッドを使用します。
チェック4は、次の場合に合格と見なすことができます。
バックアップ時からバックアップの終了までのすべてのアーカイブログは、リカバリ中に使用できます
チェック5（OPEN RESETLOGSが成功した後）：
OPENRESETLOGSアクティビティの時間についてalert.logを監視します。辞書のチェック中に、次のようなメッセージが表示される場合があります。
制御ファイルにオフラインファイル「MISSING00004」を作成しています
ファイルが見つかったら、名前を変更してみてください。そうでない場合は、データファイルをオフラインにするか、関連するテーブルスペースを削除できます。
SQL> select file#, status, enabled, substr(name, 1, 50) from v$datafile where name like '%MISSING%' ; FILE# STATUS ENABLED SUBSTR(NAME,1,50) -------- ------- ---------- -------------------------------------------------- 4 OFFLINE DISABLED /<path>/MISSING000 7 OFFLINE DISABLED /<path>/MISSING000 SQL> alter database datafile 4 online ; alter database datafile 4 online * ERROR at line 1: ORA-01157: cannot identify/lock data file 4 - see DBWR trace file ORA-01111: name for data file 4 is unknown - rename to correct file ORA-01110: data file 4: '/<oracle_home path>/dbs/MISSING00004' SQL> alter database rename file 'MISSING00004' to '/<path>/users01.dbf' ; Database altered. SQL> alter database rename file 'MISSING00007' to '/<path>/users02.dbf' ; Database altered. SQL> select tablespace_name, status from dba_tablespaces where tablespace_name in (select tablespace_name from dba_data_files where file_id in (4, 7)) ; TABLESPACE_NAME STATUS ------------------------------ --------- USERS OFFLINE SQL> ALTER TABLESPACE USERS ONLINE ; Tablespace altered.
これが、不完全なリカバリ後にデータベースの整合性をチェックする方法に役立つことを願っています。フィードバックを提供してください
また読む
oracleでアーカイブログシーケンス番号を見つける方法
RMANバックアップコマンド
RMANリストバックアップコマンド
RMANを使用してデータベースをリカバリする方法