oracle日志檔案相關問題彙總。
此種情況下，由于是正常關閉資料庫，資料檔案，redo檔案以及控制檔案SCN是一直的，redo檔案中的所有操作記錄都已經歸檔，是以如果在這種情況下丢失所有redo的話，恢複是很簡單的，一般思路是：
Startup mount
Recover database until cancel;
Alter database open resetlogs;(執行此指令後，oracle會重建立立redo檔案)
執行完以上操作後，馬上全備資料庫。
試驗一：
用指令清空日志組方法
1、檢視原來表中資料
SQL>; conn test/test
Connected.
SQL>; select * from test;
TEL
----------
1
2
3
2、插入新資料
SQL>; insert into test values(4);
1 row created.
SQL> commit;
Commit complete.
3、 正常關閉資料庫
4、 利用os command删除所有redo檔案。
5、 啟動資料庫
SQL>startup
ORACLE instance started.
Total System Global Area 353862792 bytes
Fixed Size 730248 bytes
Variable Size 285212672 bytes
Database Buffers 67108864 bytes
Redo Buffers 811008 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/T3/ORACLE/oradata/ORA9/redo01.log'
6、 檢視目前日志狀态
SQL>; select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- ----------
1 1 2 104857600 1 YES INACTIVE
487837 01-9月 -05
2 1 4 104857600 1 NO CURRENT
487955 01-9月 -05
3 1 3 104857600 1 YES INACTIVE
487839 01-9月 -05
看來redo01.log不是目前日志，對于這類非目前日志可以直接clear,系統會重新自動生成一個redo檔案。
7、SQL> alter database clear logfile group 1;
Database altered.
7、 繼續啟動db
SQL>; alter database open;
alter database open
*
ERROR at line 1:
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/T3/ORACLE/oradata/ORA9/redo02.log'
8、 看來redo也得恢複，但是redo02是目前redo,直接clear是不行的
SQL>; alter database clear logfile group 2;
alter database clear logfile group 2
ORA-00350: log 2 of thread 1 needs to be archived
嘗試clear unarchived logfile group ,報錯：
SQL> alter database clear unarchived logfile group 2;
alter database clear unarchived logfile group 2
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
看來他是因為找不到這個檔案，從有效的備份中cp一個過來看看
SQL>！ cp /T3/ORACLE/oradatabak/redo02* /T3/ORACLE/oradata/ORA9
SQL>alter database clear unarchived logfile group 2;
搞定……….
9、 按照oracle的某些做法也是可以的
SQL>alter database clear unarchived logfile group 1 unrecoverable datafile;
10、但是對于非目前日志就都可以，下面看看redo03
SQL>; alter database clear logfile group 3;
結論：
如果資料庫是正常shutdown,非目前日志都可以直接clear來重新生成，而且不丢失資料，因為正常關閉db,資料已經寫入dbf檔案了。唯獨目前日志不可以，目前日志必須首先從有效的備份中拷貝一個日志檔案過來，然後用
alter database clear unarchived logfile group n 或alter database clear unarchived logfile group n,除此之外，還可以用下面的方法來做
試驗方法二：
用cancel模式恢複資料庫
前面的出錯提示，步驟都一樣，唯獨恢複的方法不一樣
看看丢失了哪些redo
SQL> host ls /T3/ORACLE/oradarta/ORA9/redo*
/T3/ORACLE/oradarta/ORA9/redo*: No such file or directory
看來redo都丢了
直接recover
SQL>recover database until cancel;
Media recovery complete.
這個時候redo還沒有生成
SQL>; host ls /T3/ORACLE/oradata/ORA9/redo*
/T3/ORACLE/oradata/ORA9/redo*: No such file or directory
啟動資料庫
SQL>; alter database open ;
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL>alter database open resetlogs;
（注意，這裡必須用resetlogs,否則會錯誤的
SQL>alter database open noresetlogs;
alter database open noresetlogs
SQL>
Resetlogs其實就是根據控制檔案讓系統自動重新生成redo,如果noresetlog的話，就不會重新生成redo,缺少了檔案，db自然無法啟動）
SQL>host ls /T3/ORACLE/oradata/ORA9/redo*
/T3/ORACLE/oradata/ORA9/redo01.log /T3/ORACLE/oradata/ORA9/redo02.log /T3/ORACLE/oradata/ORA9/redo03.log
檢驗
SQL>select * from test.test;
4
資料一點兒都沒有丢失。
如果資料庫是正常關閉的，用recover database until cancel可以輕松恢複或者說重建立立所有的redo，不再區分是否是目前日志，而且由于正常關閉，不會丢失任何資料，唯一可能丢失的情況就是如果日志還沒有歸檔。
這種恢複方法 由于要resetlogs,是以在恢複完成後，日志清零，以前的備份不再起作用，是以建議立即備份。
SQL>archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /T3/ORACLE/arch
Oldest online log sequence 0
Next log sequence to archive 1
Current log sequence 1
SQL>;
實驗三：
通過重新生成控制檔案來恢複redo
前面的都一樣，隻是處理方法不一樣
SQL>; startup
SQL>alter database backup controlfile to trace;
SQL>; shutdown immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
2、 修改一下剛才生成的那個檔案
CREATE CONTROLFILE REUSE DATABASE "ORA9" RESETLOGS ARCHIVELOG
-- SET STANDBY TO MAXIMIZE PERFORMANCE
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 '/T3/ORACLE/oradata/ORA9/redo01.log' SIZE 100M,
GROUP 2 '/T3/ORACLE/oradata/ORA9/redo02.log' SIZE 100M,
GROUP 3 '/T3/ORACLE/oradata/ORA9/redo03.log' SIZE 100M
-- STANDBY LOGFILE
DATAFILE
'/T3/ORACLE/oradata/ORA9/system01.dbf',
'/T3/ORACLE/oradata/ORA9/undotbs01.dbf',
'/T3/ORACLE/oradata/ORA9/cwmlite01.dbf',
'/T3/ORACLE/oradata/ORA9/drsys01.dbf',
'/T3/ORACLE/oradata/ORA9/example01.dbf',
'/T3/ORACLE/oradata/ORA9/indx01.dbf',
'/T3/ORACLE/oradata/ORA9/odm01.dbf',
'/T3/ORACLE/oradata/ORA9/tools01.dbf',
'/T3/ORACLE/oradata/ORA9/users01.dbf',
'/T3/ORACLE/oradata/ORA9/xdb01.dbf',
'/T3/ORACLE/oradata/ORA9/test01.dbf'
CHARACTER SET ZHS16GBK
;
另存為一個腳本，運作
SQL>@clone.sql
Control file created.
搞定……………
結論：這種方法的關鍵是重新建立控制檔案，後面的步驟和前面的道理一樣的。
前面的三種方法都是假設db是正常關閉的，資料已經寫入資料庫檔案中，是以不會有資料存在于redo中，是以clear的話也不會有資料丢失。
試驗五：丢失目前日志組的成員
1、SQL>; select * from v$logfile;
GROUP# STATUS TYPE MEMBER
---------- ------- ---------- ----------
3 ONLINE
/T3/ORACLE/oradata/ORA9/redo03.log
2 ONLINE
/T3/ORACLE/oradata/ORA9/redo02.log
1 ONLINE
/T3/ORACLE/oradata/ORA9/redo01.log
---------- ------- ------- -----------
/T3/ORACLE/oradata/ORA9/redo01a.log
/T3/ORACLE/oradata/ORA9/redo02a.log
/T3/ORACLE/oradata/ORA9/redo03a.log
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
1 1 2 104857600 2 YES INACTIVE
554599 02-9月 -05
2 1 3 104857600 2 YES INACTIVE
554601 02-9月 -05
3 1 4 104857600 2 NO CURRENT
554603 02-9月 -05
3、 模拟插入資料
SQL>; insert into test values(5);
SQL>; commit
2 ;
4、 shutdown db,模拟删除一個目前日志成員
$ cd oradata/ORA9
$ ls redo03*
redo03.log redo03a.log
$ rm redo03a.log
5、 啟動db,表面沒有錯誤
SQL> startup
Database opened.
6、 檢視日至成員
SQL>; select * from v$logfile;
GROUP# STATUS TYPE
---------- ------- -------
MEMBER
--------------------------------------------
3 ONLINE
2 ONLINE
1 ONLINE
---------- ------- ------- ----------
1 ONLINE
2 ONLINE
3 INVALID ONLINE
7、 删除出問題的聯機日志檔案
SQL> alter database drop logfile member '/T3/ORACLE/oradata/ORA9/redo03a.log';
alter database drop logfile member '/T3/ORACLE/oradata/ORA9/redo03a.log'
ORA-01609: log 3 is the current log for thread 1 - cannot drop members
ORA-00312: online log 3 thread 1: '/T3/ORACLE/oradata/ORA9/redo03.log'
ORA-00312: online log 3 thread 1: '/T3/ORACLE/oradata/ORA9/redo03a.log'
看來目前日志成員是不允許删除的。
SQL>alter system switch logfile;
System altered.
1 1 5 104857600 2 NO CURRENT
557687 02-9月 -05
554601 02-9月 -05
3 1 4 104857600 2 YES ACTIVE
SQL> alter database add logfile member '/T3/ORACLE/oradata/ORA9/redo03a.log' to group 3;
GROUP# STATUS TYPE
---------- ------- ------
-----------------------------------------
--------------------------------------------------
3 INVALID ONLINE
看來還得切換一下日至
SQL>select * from v$logfile;
-----------------------------------------------
至此，大功告成…………….
隻要日志組的member不是一個，出現前面的4種可能性是非常小的，即使出現了也有相應的恢複方法，是以不必驚慌；
如果memer多于1個，即使壞了其中的幾個，也不會 影響資料庫的正常啟動，啟動後，再進行相應的操作即可， 是以這個時候每天察看alert.log就顯得非常重要了。
（1）：資料庫非法關閉後丢失全部redo
（2）：丢失的redo檔案是非目前的，或者說是不活動的。
（3）：丢失或者損壞的redo檔案是目前的。
下面分别說明如下：
修改系統參數方法：
1、 插入資料
SQL>; commit;
2、 強行關閉
SQL>; shutdown abort
3、 手工模拟删除全部redo
4、 啟動db
ORA-00313: open failed for members of log group 3 of thread 1
5、 嘗試使用前3中方法中最簡單的
SQL>; recover database until cancel;
ORA-00279: change 550174 generated at 09/02/2005 16:00:19 needed for thread 1
ORA-00289: suggestion : /T3/ORACLE/arch/1_1.dbf
ORA-00280: change 550174 for thread 1 is in sequence #1
Specify log: {<RET>;=suggested | filename | AUTO | CANCEL}
看來不行
6、 修改initsid.ora，加入一行
_allow_resetlogs_corruption=true
7、 啟動with pfile
Total System Global Area 320308312 bytes
Fixed Size 730200 bytes
Database Buffers 33554432 bytes
SQL>; alter database open resetlogs;
8、 檢驗資料
SQL>; select * from test.test;
看到了吧，我們前面由于執行了SHUTDOWN ABORT,這時候對資料的修改還沒有儲存到資料檔案中，雖然執行了COMMIT,這個時候還在聯機日志中，等待CKPT觸發DBWR寫入DATAFILE,但是這個時候執行了SHUTDOWN ABORT,redo被删除後，裡面的資訊也就丢了，造成資料丢失。
9、 備份，去掉那個隐含參數。
大家都清楚，聯機日志分為目前聯機日志和非目前聯機日志，非目前聯機日志的損壞是比較簡單的，一般通過clear指令就可以解決問題。
1、啟動資料庫，遇到ORA-00312 or ORA-00313錯誤，如
ORA-00312:online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
從這裡我們知道日志組1的資料檔案損壞了
從報警檔案可以看到更詳細的資訊
2、檢視V$log視圖
SQL> select group#,sequence#,archived,status from v$log;
GROUP# SEQUENCE# ARCHIVED STATUS
---------- ---------- -------- ---------- ------
1 1 YES INACTIVE
2 2 YES INACTIVE
3 3 NO CURRENT
可以知道，該組是非目前狀态，而且已經歸檔。
3、用CLEAR指令重建該日志檔案
SQL>alter database clear logfile group 1;
如果是該日志組還沒有歸檔，則需要用
SQL>alter database clear unarchived logfile group 1;
4、打開資料庫，重新備份資料庫
SQL>alter database open;
說明：
1、如果損壞的是非目前的聯機日志檔案，一般隻需要clear就可以重建該日志檔案，但是如果該資料庫處于歸檔狀态但該日志還沒有歸檔，就需要強行clear。
2、建議clear，特别是強行clear後作一次資料庫的全備份。
3、此方法适用于歸檔與非歸檔資料庫。
歸檔模式下目前日志的損壞有兩種情況，
一、是資料庫是正常關閉，日志檔案中沒有未決的事務需要執行個體恢複，目前日志組的損壞其實就是上文的實驗1案例，首先從備份中恢複一個目前的redo檔案，這也是冷備份時建議同時備份redo的原因。然後可以直接用alter database clear unarchived logfile group n來重建。最後open。
二、是日志組中有活動的事務，資料庫需要媒體恢複，日志組需要用來同步，有兩種補救辦法：
A. 最好的辦法就是通過不完全恢複，可以保證資料庫的一緻性，但是這種辦法要求在歸檔方式下，并且有可用的備份。
B. 通過強制性恢複，但是可能導緻資料庫不一緻。（如果資料庫沒有備份，又不在歸檔模式下，之能采取這種方法）
下面分别用來說明這兩種恢複方法
1．1 通過備份來恢複
1、打開資料庫，會遇到一個類似的錯誤
ORA-00312: online log 1 thread 1: 'D:\ORACLE\ORADATA\TEST\REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) 系統找不到指定的檔案
2、檢視V$log，發現是目前日志
---------- ---------- -------- ----------------
1 1 NO CURRENT
3 3 YES INACTIVE
3、發現clear不成功
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
ORA-01624: log 1 needed for crash recovery of thread 1
4、拷貝有效的資料庫的全備份，并不完全恢複資料庫
可以采用擷取最近的SCN的辦法用until scn恢複或用until cnacel恢複
recover database until cancel
先選擇auto，盡量恢複可以利用的歸檔日志，然後重新
這次輸入cancel，完成不完全恢複，也就是說恢複兩次。
如：
SQL> recover database until cancel;
Auto
……
Cancel;
5、利用alter database open resetlogs打開資料庫
1、這種辦法恢複的資料庫是一緻的不完全恢複，會丢失目前聯機日志中的事務資料
2、這種方法适合于歸檔資料庫并且有可用的資料庫全備份。
3、恢複成功之後，記得再做一次資料庫的全備份。
4、建議聯機日志檔案一定要實作鏡相在不同的磁盤上，避免這種情況的發生，因為任何資料的丢失對于生産來說都是不容許的。
1.2 如果沒有備份，進行強制性恢複
4、把資料庫down掉
SQL>shutdown immediate
5、在init<sid>.ora中加入如下參數
_allow_resetlogs_corruption=TRUE
6、重新啟動資料庫,利用until cancel恢複
Cancel
如果出錯，不再理會，發出
7、如果幸運，資料庫可以open，資料庫被打開後，馬上執行一個full export
8、shutdown資料庫,去掉_all_resetlogs_corrupt參數
9、重建庫
10、import并完成恢複
11、建議執行一下ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;
1、該恢複方法是沒有辦法之後的恢複方法，一般情況下建議不要采用，因為該方法可能導緻資料庫的不一緻
2、該方法也丢失資料，但是丢失的資料沒有上一種方法的資料多，主要是未寫入資料檔案的已送出或未送出資料。
3、建議成功後嚴格執行以上的7到11步，完成資料庫的檢查與分析
4、全部完成後做一次資料庫的全備份
5、建議聯機日志檔案一定要實作鏡相在不同的磁盤上，避免這種情況的發生，因為任何資料的丢失對于生産來說都是不容許的。
問題：
上面的第7步，如果不能打開資料庫，oracle此時可能會報ORA-00600: 内部錯誤代碼，參數: [2662],之類的錯誤，針對這個問題說明如下：
1：ORA-600 [2662] "Block SCN is ahead of Current SCN"，說明目前資料庫的資料塊的SCN早于目前的SCN，主要是和存儲在UGA變量中的dependent SCN進行比較，如果目前的SCN小于它，資料庫就會産生這個ORA-600 [2662]的錯誤了.
2：于是想到使用ADJUST_SCN事件來調整目前的SCN，使其大于dependent SCN.
3：此時我們可以通過Oracle的内部事件來調整SCN:
出現ORA-00600: 内部錯誤代碼，參數: [2662],之類的錯誤可能會出現在打開資料庫之前，也可能出現在通過用_allow_resetlogs_corruption=TRUE隐含參數打開資料庫之後。
調整SCN有兩種常用方法:
1.通過immediate trace name方式(在資料庫Open狀态下，即通過用_allow_resetlogs_corruption=TRUE隐含參數打開資料庫之後報錯600)
alter session set events 'IMMEDIATE trace name ADJUST_SCN level x';
2.通過10015事件(在資料庫無法打開，mount狀态下)
alter session set events '10015 trace name adjust_scn level x';
注:level 1為增進SCN 10億 (1 billion) (1024*1024*1024),通常Level 1已經足夠。也可以根據實際情況适當調整。
打賞
<b></b>贊
<b></b>收藏
<b></b>評論
分享
微網誌
微信
舉報
上一篇：ORACLE 11G DATA GUARD配置全過程
下一篇：ORACLE中表死鎖的處理
![oracle中的start with connect by用法[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)