您好,登錄后才能下訂單哦!
今天一個開發庫啟動不了了,發過來報錯一看是日志文件損壞了(見下圖),接著說了一下前因后果。說是年前服務器掉電了,然后就再沒有啟動起來過。今天有人用才想到要處理。
先說一下大體的思路,如果損壞的redo log是INACTIVE狀態的,也就是實例崩潰恢復用不到的redo log,那處理起來比較容易,直接alter database clear logfile group #;或alter database clear unarchived logfile group #;重建日志組就行了。建議重建日志文件級后對數據庫做一個全庫備份,特別是強制clear后,造成的歸檔日志文件斷層。在如果損壞的redo log是ACTIVE或CURRENT狀態的,也就是實例崩潰恢復需要用到的redo log,那處理起來就比較麻煩了,損壞這種redo log就意味著丟失數據。
redo log的三種狀態:
INACTIVE:日志對應的修改已經被寫入硬盤
ACTIVE:日志對應的修改還沒有被寫入硬盤
CURRENT:實例正在使用的日志文件
由于這個開發庫有種種的問題,恢復起來遇到了各種情況,這里用一個虛擬機上的數據庫演示如果CURRENT或ACTIVE狀態的日志文件損壞的情況下如何恢復。
1、構造場景
刪除一張表的數據但不提交,然后在另一個會話中把數據庫shutdown abort。再刪除所有的redo log文件。
#session 1 sys@ORCL>delete from zx; 2858 rows deleted. #session 2 sys@ORCL>select group#,status from v$log; GROUP# STATUS ---------- ------------------------------------------------ 1 INACTIVE 2 ACTIVE 3 CURRENT sys@ORCL>shutdown abort; ORACLE instance shut down. #刪除redo log文件 [oracle@rhel6 ~]$ cd /u02/app/oracle/oradata/orcl/ [oracle@rhel6 orcl]$ ls -l total 1944992 -rw-r----- 1 oracle oinstall 9748480 Feb 24 23:56 control01.ctl -rw-r----- 1 oracle oinstall 9748480 Feb 24 23:56 control02.ctl -rw-r----- 1 oracle oinstall 328343552 Feb 24 23:54 example01.dbf -rw-r----- 1 oracle oinstall 52429312 Feb 24 23:54 redo01.log -rw-r----- 1 oracle oinstall 52429312 Feb 24 23:55 redo02.log -rw-r----- 1 oracle oinstall 52429312 Feb 24 23:55 redo03.log -rw-r----- 1 oracle oinstall 545267712 Feb 24 23:54 sysaux01.dbf -rw-r----- 1 oracle oinstall 796925952 Feb 24 23:54 system01.dbf -rw-r----- 1 oracle oinstall 30416896 Feb 24 13:58 temp01.dbf -rw-r----- 1 oracle oinstall 110108672 Feb 24 23:54 undotbs01.dbf -rw-r----- 1 oracle oinstall 5251072 Feb 24 23:54 users01.dbf [oracle@rhel6 orcl]$ rm redo*log l[oracle@rhel6 orcl]$ ls -l total 1791212 -rw-r----- 1 oracle oinstall 9748480 Feb 24 23:56 control01.ctl -rw-r----- 1 oracle oinstall 9748480 Feb 24 23:56 control02.ctl -rw-r----- 1 oracle oinstall 328343552 Feb 24 23:54 example01.dbf -rw-r----- 1 oracle oinstall 545267712 Feb 24 23:54 sysaux01.dbf -rw-r----- 1 oracle oinstall 796925952 Feb 24 23:54 system01.dbf -rw-r----- 1 oracle oinstall 30416896 Feb 24 13:58 temp01.dbf -rw-r----- 1 oracle oinstall 110108672 Feb 24 23:54 undotbs01.dbf -rw-r----- 1 oracle oinstall 5251072 Feb 24 23:54 users01.dbf
2、啟動數據庫出現報錯
idle>startup ORACLE instance started. Total System Global Area 1603411968 bytes Fixed Size 2253664 bytes Variable Size 1476398240 bytes Database Buffers 117440512 bytes Redo Buffers 7319552 bytes Database mounted. ORA-00313: open failed for members of log group 2 of thread 1 ORA-00312: online log 2 thread 1: '/u02/app/oracle/oradata/orcl/redo02.log' ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory Additional information: 3
3、嘗試使用clear方式重建日志組出現報錯
idle>alter database clear logfile group 2; alter database clear logfile group 2 * ERROR at line 1: ORA-01624: log 2 needed for crash recovery of instance orcl (thread 1) ORA-00312: online log 2 thread 1: '/u02/app/oracle/oradata/orcl/redo02.log' idle>alter database clear unarchived logfile group 2; alter database clear unarchived logfile group 2 * ERROR at line 1: ORA-01624: log 2 needed for crash recovery of instance orcl (thread 1) ORA-00312: online log 2 thread 1: '/u02/app/oracle/oradata/orcl/redo02.log'
從報錯信息中可以看出log 2是實例崩潰恢復所需要的日志文件,不能直接重建。
4、這種情況下使用隱含參數_allow_resetlogs_corruption,創建pfile,把*._allow_resetlogs_corruption=TRUE加入到pfile中。然后mount數據庫,強制不完全恢復,再open resetlogs
idle>create pfile='/home/oracle/initorcl.ora' from spfile; File created. [oracle@rhel6 orcl]$ vi /home/oracle/initorcl.ora idle>shutdown immediate; ORA-01109: database not open Database dismounted. ORACLE instance shut down. idle>startup pfile='/home/oracle/initorcl.ora' mount; ORACLE instance started. Total System Global Area 1603411968 bytes Fixed Size 2253664 bytes Variable Size 1476398240 bytes Database Buffers 117440512 bytes Redo Buffers 7319552 bytes Database mounted. idle>show parameter _allow_ NAME TYPE VALUE ------------------------------------ --------------------------------- ------------------------------ _allow_resetlogs_corruption boolean TRUE idle>recover database until cancel; ORA-00279: change 1023441 generated at 02/24/2017 23:54:54 needed for thread 1 ORA-00289: suggestion : /u02/app/oracle/product/11.2.4/db1/dbs/arch2_2_936817668.dbf ORA-00280: change 1023441 for thread 1 is in sequence #2 Specify log: {<RET>=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: '/u02/app/oracle/oradata/orcl/system01.dbf' ORA-01112: media recovery not started idle>alter database open resetlogs; Database altered. idle>select open_mode from v$database; OPEN_MODE ------------------------------------------------------------ READ WRITE
可以看到現在數據庫已經被open了。
5、再次查看第一步中被刪除的數據的表,數據仍然存在說明丟失CURRENT或ACTIVE狀態的日志文件會導致數據丟失。
idle>select count(*) from zx; COUNT(*) ---------- 2858
以上是在虛擬機上做測試的恢復過程,但是對于前面說到的開發庫的恢復就沒有這個過程簡單了。可以說是解決了一個報錯又出來新的報錯。
在使用_allow_resetlogs_corruption參數執行不完全恢復,open resetlogs 時,遇到了ORA-01248
SQL> alter database open resetlogs; alter database open resetlogs * ERROR at line 1: ORA-01248: file 5 was created in the future of incomplete recovery
于是先把這個文件offline drop
SQL> alter database datafile 5 offline drop;
再次open resetlogs時又遇到了ORA-00704和ORA-01555
SQL> alter database open resetlogs; alter database open resetlogs * ERROR at line 1: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 ORA-01555: snapshot too old: rollback segment number 5 with name "_SYSSMU5_4116806824$" too small Process ID: 3396 Session ID: 573 Serial number: 51
由于現在的水平有限,在網上查資料也沒有能解決這一系列的問題,最后沒辦法只能重建庫,重新導數據了。
如果哪位遇到了類似的問題,而且解決了,也請分享一下經驗。
其實上午在模擬這個問題的時候,在open resetlogs時還遇到了一個經典的報錯ORA-600 [2662],這個錯誤可以參考eygle的博客http://www.eygle.com/archives/2005/12/oracle_diagnostics_howto_deal_2662_error.html
參考:http://iquicksandi.blog.163.com/blog/static/13228526220107642655204/
http://www.linuxidc.com/Linux/2012-02/53426.htm
http://www.killdb.com/2014/06/19/%E6%95%B0%E6%8D%AE%E5%BA%93open%E6%8A%A5%E9%94%99ora-01555-snapshot-too-old.html
http://www.askmaclean.com/archives/%E3%80%90oracle%E6%81%A2%E5%A4%8D%E3%80%91ora-704.html
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。