翻译自:

How to quickly check that Database is consistent after incomplete recovery (Point in Time Recovery) before OPEN RESETLOGS (Doc ID 1354256.1)

% export NLS_DATE_FORMAT=‘dd-mon-rr hh24:mi:ss‘
% rman target /

> set nls_date_format=dd-mon-rr:hh24:mi:ss                
> rman target /

RMAN> LIST BACKUP OF DATABASE COMPLETED AFTER ‘<date>‘;
 or 
RMAN> LIST BACKUP OF DATABASE COMPLETED AFTER ‘sysdate -n‘;

SQL> alter session set nls_date_format=‘DD-MON-YYYY HH24:MI:SS‘;

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                                 5311260 31-AUG-2011 23:10:14          6
YES ONLINE                                 5311260 31-AUG-2011 23:10:14          1

SQL> select file#, substr(name, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# from v$datafile_header where fuzzy=‘YES‘ ;


     FILE# SUBSTR(NAME,1,50)                                  SUBSTR(TABLESPA UNDO_OPT_CURRENT_CHANGE#
---------- -------------------------------------------------- --------------- ------------------------
         3 /u01/app/oracle/oradata/prod111/undotbs01.dbf      UNDOTBS1                         5117431

SQL> alter database datafile <file#> offline ;

SQL> select status, enabled, count(*) from v$datafile group by status, enabled ;

STATUS  ENABLED      COUNT(*)
------- ---------- ----------
SYSTEM  DISABLED            1
ONLINE  READ WRITE          4
RECOVER DISABLED            2

SQL> select file#, substr(name, 1, 50), status, error, recover from v$datafile_header;

SQL> alter database datafile <file#> ONLINE ;

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                                 5311260 31-AUG-2011 23:10:14          7

SQL> ALTER DATABASE OPEN RESETLOGS ;


ORA-01194: file 4 needs more recovery to be consistent
ORA-01110: data file 3: ‘/u01/app/oracle/oradata/prod111/undotbs02.dbf‘

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 ;


FILE#      NAME                                               CHECKPOINT_CHANG ABSOLUTE_FUZZY_S     MIN_PIT_SCN
---------- -------------------------------------------------- ---------------- ---------------- ----------------
         4 /u01/app/oracle/oradata/prod111/undotbs01.dbf               5311260          5311524          5311524
         6 /u01/app/oracle/oradata/prod111/system01.dbf                5311260          5311379          5311524

SQL> -- V$ARCHIVED_LOG
SQL> --
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;

SQL> -- V$LOG_HISTORY  view does not have a column NEXT_TIME
SQL> --
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>

RMAN> RUN 
{ 
 SET UNTIL SEQUENCE 531 THREAD 1;
 RECOVER DATABASE;
}

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;

Dictionary check beginning
Tablespace ‘TEMP‘ #3 found in data dictionary, <(============================== (1)
but not in the controlfile. Adding to controlfile.
Tablespace ‘USERS‘ #4 found in data dictionary, 
but not in the controlfile. Adding to controlfile.
File #4 found in data dictionary but not in controlfile.
Creating OFFLINE file ‘MISSING00004‘ in the controlfile. <(==================== (2)
File #5 is online, but is part of an offline tablespace. <(==================== (3)
data file 5: ‘/u01/app/oracle/oradata/prod111/example01.dbf‘
File #7 found in data dictionary but not in controlfile. <(==================== (2)
Creating OFFLINE file ‘MISSING00007‘ in the controlfile.
File #8 is offline, but is part of an online tablespace. <(==================== (4)
data file 8: ‘/u01/app/oracle/oradata/prod111/mydata02.dbf‘
File #9 is online, but is part of an offline tablespace. <(==================== (3)
data file 9: ‘/u01/app/oracle/oradata/prod111/example02.dbf‘
Dictionary check complete

(1) Check if the temp files exist. If not, add them as per your preference: 

(2) It appears that the tablespace was brought offline using "ALTER TABLESPACE USERS OFFLINE" command. So, verify if the missing files really exist with original name. You may need to consult your pear DBAs, or refer alert.log / RMAN backup log or any such information which may provide clue about the actual file name. 

If you find the file, try to rename them. If not, we can offline the datafile or drop associated tablespace:

Before proceeding, let‘s query the status for these files in alert.log:

So, we can attempt to correct the "ERROR" as displayed in above query depending on the availability of file / archived logs and other possible factors. 

Let‘s continue,

(3) It seems that tablespace was brought offline inconsistently ( ALTER TABLESPACE EXAMPLE OFFLINE IMMEDIATE ). If the archived log generated at that time has got applied, the file may be back online : 
 

(4) This tablespace MYDATA has 2 datafiles File# 6 & 8. It appears that File# 8 was brought offline ( using ALTER DATABASE DATAFILE 8 OFFLINE ) and it was OFFLINE before OPEN RESETLOGS. If the archived log generated at that time has got applied during recovery or all the archived logs are available for recovery since that time, the file may be back online :

Please note that it is not always possible to recover and bring the file online which is failing with error " ORA-01190: control file or data file x is from before the last RESETLOGS".


(5) There can be a scenario where the tablespace was in READ ONLY mode before OPEN RESETLOGS. Please check below Article on that:


Note 266991.1 Recovering READONLY tablespace backups made before a RESETLOGS Open

REFERENCES

[翻译自mos文章]不完全恢复之后,open resetlogs之前,怎么快速的检查数据库是否处于一致性的状态?