大半夜,接到客戶電話,數據庫掛了,下面所有客戶端連接不上了.由於是7*24小時業務,因此客戶很着急,讓客戶發了報錯截圖,第一感覺是歸檔日誌滿了,但是客戶那邊有定時刪除日誌腳本啊,不應該啊,報錯截圖如下
趕緊和客戶要了遠程進行查看,明顯歸檔日誌空間是足夠的.再檢查歸檔日誌路徑報錯,如下:
錯誤很明顯了,歸檔日誌在歸檔redo的時候發現了redo出現了寫丟失.
檢查alert日誌也是同樣的錯誤:
什麼是寫丟失呢?
寫丟失說明oracle在寫redo的日誌的時候,由於某種原因,一般可能是cache緩存問題,導致lowr進程在寫redo的時候發生了寫丟失.
而在進行歸檔的時候,對redo進行校驗發現redo日誌出現壞塊,因此無法進行歸檔.
可能產生寫丟失的原因:服務器問題,例如服務器cache,存儲問題例如存儲的cache故障,意外掉電等.
這裏明顯不是意外掉電,那麼就是有可能是服務器或者存儲cache故障導致.
我們這裏比較幸運的是redo的寫丟失並沒有導致數據庫直接宕機,僅僅是導致了日誌無法歸檔.
故障解決
由於只是redo日誌無法歸檔,因此我們可以進行手工強制清除未歸檔的日誌.
根據上面的報錯信息可以看到是100034號日誌無法歸檔.因此只需要清除此日誌,語法如下:
Alter database clear unarchived logfile group XXXX;
清除完成之後,重新設置一下歸檔日誌的狀態:
alter system set log_archive_dest_state_1=enable;
參考oracle官方文檔如下:
Database Crashe with ORA-16038/ORA-742 Errors (Doc ID 2064718.1)
SOLUTION
SQL> alter system dump logfile 'E:\ARCHIVELOGS\xxx\REDO03.LOG' validate;
Clear the log in order to enable the archival again
SQL> select group#,member from v$logfile;
SQL> alter database clear unarchived logfile group <group number>;
Should be group# 3 , if yes
After this , take a full backup, because the old one would not be useful anymore because of the lost of archive log sequence .
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=378047153651334&id=2064718.1&displayIndex=3&_afrWindowMode=0&_adf.ctrl-state=17nxrq8cj0_1056
