oracle錯誤備忘(ORA-00354,ORA-00353和ORA-00312的處理方法)
昨天根據客戶要求,增加了一個jasperreport實現的報表打印功能,然後在測試服務器上測試通過,因為看到測試數據庫上的數據都太“舊”了,我就從正式環境下導出了OA係統的數據,導出操作一切順利,在導入過程中卻由於網絡問題中斷(因為我是遠程導入,備份文件在我的機器上)。再次連接數據庫,一直報錯,說什麼隻允許內部連接。遠程重啟了下oracle服務,登錄數據庫還是不行,發現數據庫根本沒打開,通過sqlplus執行ORA-00312: 聯機日誌 1 線程 1:
看情況是日誌文件出錯,幸好是測試服務器,把我這個對oracle管理一竅不通的家夥急壞了。馬上baidu了下錯誤代碼,找到一篇文章:
在日誌文件損壞或者dump這些損壞的日誌文件的時候,通常回收到類似下麵的錯誤:
ORA-00353: log corruption near block 3740 change 0 time 04/11/2006 13:49:56
或者:
sys@TSMISC02>
這裏首先介紹一下oracle使用日誌文件的策略。每一個數據庫至少有兩個或多個日誌文件組(),每個組中至少有一個日誌成員()。日誌文件的主要功能是真實完整的記錄對數據庫作的全部修改。在出現故障時,如果不能將修改數據永久地寫入數據文件,則係統將利用日誌前滾來恢複數據庫數據文件。日誌文件主要是保護數據庫以防止故障。
如果至少能夠訪問一個組內的某一個成員,那麼就會對這個組內的可訪問成員繼續照常進行讀寫操作,也就是說,將忽略組內的不可用成員。如果在日誌切換時無法訪問下一個組的所有成員或者損壞的日誌文件時改組中日誌成員,數據庫的正常操作就無法進行了。這也就是常說的,為了防止日誌文件的故障或丟失,強烈建議鏡象日誌,即,在不同磁盤上維護至少兩個或多個日誌文件()副本的作用——隻要組內有一個可用的成員,就會繼續“正常”操作。
回到這裏,如果數據庫發生日誌文件的上述損壞,不管是哪種原因造成的,解決方法無外乎是使用完好的文件恢複已經損壞的文件,或者初始化損壞的文件組等等(日誌文件的故障處理不做這裏的重點介紹,我將會在其他的文章中逐一說明和舉例)。
我們這裏主要是使用了_disable_logging=true這個隱含參數(實際性能故障診斷時,你可以通過alert.log找到相關信息)造成了歸檔數據庫中,所有日誌不能歸檔,最終數據庫不能繼續操作的問題,因此解決方法就是:
(a)如果是使用了隱含參數,那麼去掉這個隱含參數:
alter system set "_disable_logging"=false scope=both;
(b)然後,初始化損壞的redo log:
alter database clear unarchived logfile '<logilename>';
例如:
sys@TSMISC02> alter system set "_disable_logging"=false scope=both;
sys@TSMISC02> alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo02.log';
sys@TSMISC02> alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo03.log';
sys@TSMISC02>
OK,馬上執行命令:
再打開數據庫,一切正常,重新導入,問題解決。
我需要加強下對oracle基本故障處理方麵知識的學習了。
文章轉自莊周夢蝶 ,原文發布時間5.17
最後更新:2017-05-17 11:37:02
上一篇:
Oracle數據庫的ORA-00257故障解決過程(轉載)
下一篇:
準備上班
FrameLayout.xml
Memory network (MemNN) & End to End memory network (MemN2N) & Dynamic memory network
PostgreSQL 10 PostGIS 兼容性 FIX
我國4G標準拓展國際市場取得重要突破
DBA入門之路:學習與進階之經驗談
文件圖片上傳
JS中數組排序
Java類集--Map接口、HashMap、IdentityHashMap、SortedMap
Modern Web Identity: Why Your Web Applications Should Be Offering OpenID, OAuth, And Probably Facebook Connect
"太極大師”戰不過10秒,武術大師連廣場舞大媽都打不過? 武術已成熱點話題!