使用_allow_resetlogs_corruption打開無歸檔日誌rman備份庫

使用_allow_resetlogs_corruption打開無歸檔日誌rman備份庫

 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'

查看相關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均一致

嘗試打開數據庫

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'

使用隱含參數打開數據庫

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，搶救數據