ORACLE 使用"_ALLOW_RESETLOGS_CORRUPTION"進行崩潰恢復
什麽情況可能使用該參數
有些時侯可能你的庫處於非歸檔的模式下，而你的聯機重做日誌又currupted,你的數據文件不能完成完全的恢復。而這時當你試圖打開數據庫時，oracle提示你用resetlogs選項，當你使用該選項時oracle又不允許你使用該選項，總之你想打開數據庫，可就是打不開。
1、最好做一個物理的庫的全備
2、使用sqlplus 啟動庫至mount
sqlplus /nolog
sql>connect internal
sql>startup mount
3、確保所有的數據文件都處於"END BACKUP"狀態
sql>set pages 0 feedback off lines 132
sql>spool alter_df.sql
sql>SELECT ‘alter database datafile ‘||file_name||‘ END BACKUP;‘ from v$datafile;
sql>spool off
sql>@alter_df.sql
4、試著打開數據庫
sql>alter database open;
如數據庫成功打開，余下的都不需要做了，到此為止
5、如果你在打開時被要求進行恢復，使用"UNTIL CANCEL"這種進行恢復,然後再發出ALTER DATABASE OPEN RESETLOGS這個命令
sql>recover database until cancel;
sql>alter database open resetlogs;
6、如果數據庫仍不能打開，把庫down掉
sql>shutdown immediate
7、在init.ora中加入如下參數
_allow_resetlogs_corruption=TRUE
8、執行如下語句
sql>connect internal
sql>startup mount
sql>@alter_df.sql
sql>alter database open
9、如在alter database open時仍舊報錯，使用until cancel恢復
sql>recover database until cancel;
sql>alter database open resetlogs;
10、經過"9",數據庫一定被打開了，數據庫被打開後，馬上執行一個full export
11、down掉庫,去掉_all_resetlogs_corrupt參數
12、重建庫
13、import並完成恢復
14、建議執行一下ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;
---------------------
作者：茄肥貓
來源：CSDN
原文：https://blog.csdn.net/lively1982/article/details/18267241
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！
=======================================================================================
使用_allow_resetlogs_corruption 打開無歸檔日誌 rman 備份庫，運維DBA反映服務器宕機後，開啟數據庫報錯ORA-01194 ORA-01110，
分析原因為Oracle SCN不一致導致數據庫無法啟動，使用 _allow_resetlogs_corruption 打開數據庫
1.rman還原恢復操作
--還原數據庫 RMAN> restore database; --恢復數據庫 RMAN> recover database; Starting recover at 2012-03-08 21:20:45 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=65 device type=DISK starting media recovery RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 03/08/2012 21:20:47 RMAN-06053: unable to perform media recovery because of missing log RMAN-06025: no backup of archived log for thread 1 with sequence 2936 and starting SCN of 25991695 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 2935 and starting SCN of 25991652 found to restore RMAN-06025: no backup of archived log for thread 1 with sequence 2934 and starting SCN of 25991649 found to restore …………………… RMAN-06025: no backup of archived log for thread 1 with sequence 2902 and starting SCN of 25991156 found to restore 這裏報日誌缺少，實際上是備份的數據庫文件後，沒有備份歸檔日誌，歸檔日誌全部丟失
進行不完全恢復
SQL> recover database until cancel;
ORA-00279: change 25991194 generated at 03/08/2012 20:33:58 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/archivelog/chf/1_2902_752334071.dbf
ORA-00280: change 25991194 for thread 1 is in sequence #2902
Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: ‘/opt/oracle/oradata/chf/system01.dbf‘
ORA-01112: media recovery not started
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: ‘/opt/oracle/oradata/chf/system01.dbf‘
2.查看相關SCN
SQL> select file#,to_char(checkpoint_change#,‘999999999999‘) from v$datafile;
FILE# TO_CHAR(CHECK
---------- -------------
1 25992214
2 25992214
3 25992214
4 25992214
5 25992214
6 25992214
7 25992214
8 25992214
9 25992214
10 25992214
11 25992214
FILE# TO_CHAR(CHECK
---------- -------------
13 25992214
14 25992214
13 rows selected.
SQL> select file#,online_status,to_char(change#,‘999999999999‘) from v$recover_file;
FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
1 ONLINE 25991194
2 ONLINE 25991194
3 ONLINE 25991194
4 ONLINE 25991194
5 ONLINE 25991194
6 ONLINE 25991194
7 ONLINE 25991194
8 ONLINE 25991194
9 ONLINE 25991194
10 ONLINE 25991194
11 ONLINE 25991194
FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
13 ONLINE 25991194
14 ONLINE 25991194
13 rows selected.
SQL> select file#,to_char(checkpoint_change#,‘999999999999‘) from v$datafile_header;
FILE# TO_CHAR(CHECK
---------- -------------
1 25991194
2 25991194
3 25991194
4 25991194
5 25991194
6 25991194
7 25991194
8 25991194
9 25991194
10 25991194
11 25991194
FILE# TO_CHAR(CHECK
---------- -------------
13 25991194
14 25991194
13 rows selected.
--發現數據文件scn和控制文件不一致，重建控制文件，然後查詢相關scn
SQL> select file#,to_char(checkpoint_change#,‘999999999999‘) from v$datafile;
FILE# TO_CHAR(CHECK
---------- -------------
1 25991194
2 25991194
3 25991194
4 25991194
5 25991194
6 25991194
7 25991194
8 25991194
9 25991194
10 25991194
11 25991194
FILE# TO_CHAR(CHECK
---------- -------------
13 25991194
14 25991194
13 rows selected.
SQL> select file#,online_status,to_char(change#,‘999999999999‘) from v$recover_file;
FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
1 ONLINE 25991194
2 ONLINE 25991194
3 ONLINE 25991194
4 ONLINE 25991194
5 ONLINE 25991194
6 ONLINE 25991194
7 ONLINE 25991194
8 ONLINE 25991194
9 ONLINE 25991194
10 ONLINE 25991194
11 ONLINE 25991194
FILE# ONLINE_ TO_CHAR(CHANG
---------- ------- -------------
13 ONLINE 25991194
14 ONLINE 25991194
13 rows selected.
SQL> select file#,to_char(checkpoint_change#,‘999999999999‘) from v$datafile_header;
FILE# TO_CHAR(CHECK
---------- -------------
1 25991194
2 25991194
3 25991194
4 25991194
5 25991194
6 25991194
7 25991194
8 25991194
9 25991194
10 25991194
11 25991194
FILE# TO_CHAR(CHECK
---------- -------------
13 25991194
14 25991194
13 rows selected.
--此時所有scn均一致
3.嘗試打開數據庫
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: ‘/opt/oracle/oradata/chf/system01.dbf‘
SQL> recover database using backup controlfile until cancel;
ORA-00279: change 25991194 generated at 03/08/2012 20:33:58 needed for thread 1
ORA-00289: suggestion : /opt/oracle/oradata/archivelog/chf/1_2902_752334071.dbf
ORA-00280: change 25991194 for thread 1 is in sequence #2902
Specify log: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: ‘/opt/oracle/oradata/chf/system01.dbf‘
ORA-01112: media recovery not started
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: ‘/opt/oracle/oradata/chf/system01.dbf‘
5.使用隱含參數打開數據庫
SQL> create pfile=‘/tmp/pfile‘ from spfile; File created. -------/tmp/pfile中加上---------- _allow_resetlogs_corruption= TRUE --------------------------------- SQL> startup mount pfile=‘/tmp/pfile‘ force ORACLE instance started. Total System Global Area 622149632 bytes Fixed Size 2230912 bytes Variable Size 419431808 bytes Database Buffers 192937984 bytes Redo Buffers 7548928 bytes Database mounted. SQL> alter database open resetlogs; Database altered. SQL> select open_mode from v$database; OPEN_MODE -------------------- READ WRITE
總結
這次的試驗沒有多少實際意義，但是可以說明幾個問題：
1.所有的數據文件的scn都一致，甚至和控制文件的也一致，數據庫不一定可以open成功
(懷疑是數據文件中的scn大於data header scn)
2.對於這樣的問題，如果使用bbed修改所有數據文件header的scn不知道是否可以解決
3.如果rman只備份了數據文件而沒有任何一個歸檔日誌，數據庫通過隱含參數還是可以open，搶救數據
ORACLE 使用"_ALLOW_RESETLOGS_CORRUPTION"進行崩潰恢復