實驗環境：OEL 5.7 + Oracle 10.2.0.5
Tips：該引數僅在特殊恢復場景下使用，需要在專業Oracle工程師指導下進行操作。

• 1.隱藏引數說明
• 2.故障場景再現
• 3.非常規恢復

1.隱藏引數說明

查詢隱藏引數"_allow_resetlogs_corruption"及說明：

set linesize 333
col name for a35
col description for a66
col value for a30
SELECT i.ksppinm name,  
   i.ksppdesc description,  
   CV.ksppstvl VALUE
FROM   sys.x$ksppi i, sys.x$ksppcv CV  
   WHERE   i.inst_id = USERENV ('Instance')  
   AND CV.inst_id = USERENV ('Instance')  
   AND i.indx = CV.indx  
   AND i.ksppinm LIKE '%&keyword%' 
ORDER BY 1; 

Enter value for keyword: allow_resetlog
old   8:    AND i.ksppinm LIKE '%&keyword%'
new   8:    AND i.ksppinm LIKE '%allow_resetlog%'

NAME                                DESCRIPTION                                                        VALUE
----------------------------------- ------------------------------------------------------------------ ------------------------------
_allow_resetlogs_corruption         allow resetlogs even if it will cause corruption                   FALSE
 

通過這個隱藏引數非常規恢復的庫，原則建議還是要重建庫的。其實在alert日誌中也會看到有這樣的建議：

Wed Dec 26 00:00:41 CST 2018
alter database open resetlogs
Wed Dec 26 00:00:41 CST 2018
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.

2.故障場景再現

模擬常規開庫失敗的場景：

SQL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#
------------------
       10013731555
       10014045643
       10014045643
       10014045643
       10014045643
       10014045643
       10014045643
       10014045643
       10014045643

9 rows selected.


SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open


SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '+ZHAOJINGYU/jy/datafile/system.256.839673875'
 

說明：這個環境是模擬資料檔案1丟失，最終從備份restore出來一箇舊的檔案，但由於種種原因，總之沒有後續的歸檔去做recover，導致無法追平。
此時就可嘗試使用_allow_resetlogs_corruption隱藏引數強制開庫：

SQL> alter system set "_allow_resetlogs_corruption" = true scope=spfile;
SQL> shutdown immediate
SQL> startup mount
SQL> alter database open resetlogs;

此時再去查詢資料檔案頭的SCN已經一致：

SQL> select checkpoint_change# from v$datafile_header;

  CHECKPOINT_CHANGE#
--------------------
         10014022016
         10014022016
         10014022016
         10014022016
         10014022016
         10014022016
         10014022016
         10014022016
         10014022016

9 rows selected.

注意處理完畢後及時改回這個隱藏引數為false：

alter system set "_allow_resetlogs_corruption" = false scope=spfile;

其他注意事項：如果開庫遇到ORA-600 [2662]類錯誤，可以參考之前隨筆：

• Oracle推進SCN系列：使用oradebug在mount狀態下推進SCN

最終通過推進SCN的手段來解決ORA-600 [2662]類問題。
其實這個場景其實可能會遇到各種問題，都屬於非常規恢復範疇，後續我會計劃去繼續測試驗證一些常見場景及解決方案。