ORA-07445导致实例崩溃的解决【The solution of instance crush by ORA-07445】
生活随笔
收集整理的這篇文章主要介紹了
ORA-07445导致实例崩溃的解决【The solution of instance crush by ORA-07445】
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
? ?昨天（2007-12-27日）維護(hù)某省移動一個平臺的工程師報告數(shù)據(jù)庫實例不可用，只能重新啟動！這還得了，業(yè)務(wù)無論如何不能停。
??? 趕快登錄到那個服務(wù)器上去檢查。
??? 通過日志分析，我看到導(dǎo)致實例不可用，其實質(zhì)就是由于07445錯誤導(dǎo)致數(shù)據(jù)庫實例崩潰。接著分析詳細(xì)的日志信息: ORA-07445: exception encountered: core dump [kkmmctbf()+89] [SIGSEGV] [Address not mapped to object] [0x30] [] []
Current SQL statement for this session:
delete from t_XXXX where XXXX_id='66666666666' and xx_id='EEE' ????
??? 看看07445的錯誤解釋：
07445, 00000, "exception encountered: core dump [%s] [%s] [%s] [%s] [%s] [%s]"
// *Cause: An OS exception occurred which should result in the creation of a
//???????? core file.??This is an internal error.
// *Action: Contact your customer support representative.
?? 牛，推到OS系統(tǒng)上了！
?? 難道真是操作系統(tǒng)出了什么問題，看看操作系統(tǒng)的相關(guān)日志，表面上看沒有任何報錯信息。
?? 會不會是ORACLE的BUG？
?? 了解應(yīng)用情況，發(fā)現(xiàn)在刪除某張表的時候會出現(xiàn)這種情況，并且通過錯誤日志也看的出來，但是奇怪一個簡單的SQL怎么會造成實例崩潰呢？
??? 搜速相關(guān)信息，通過檢查9.2.0.6 Bug Categories，在分類中發(fā)現(xiàn)一個可能的錯誤：
Process May Dump (ORA-7445) / Abend / Abort
3199908??????Dump (in kkmmctbf) from a DELETE TRIGGER compiled in DEBUG mode ????
??? 趕快檢查被刪除的表，COOL!果真在其上有一個基于DELETE的TRIGGER!
??? 檢查這個TRIGGER的狀態(tài)：
??? select owner,object_name,object_type,debuginfo?
rom all_probe_objects?
where object_name='TRI_XXX' and object_type like 'TRIGGER';
OWNER??????? OBJECT_NAME??? OBJECT_TYPE???? D
------------ -------------- ---------------???? -
COPERATOR??? TRI_XXX??????? TRIGGER??????????????T
1 rows selected. ????
??? 天哪，真是DEBUG狀態(tài)！
??? 一個因為在DEBUG狀態(tài)，且是基于DELETE的TRIGGER觸發(fā)了這個ORACLE的BUG！
??? ......
??? 現(xiàn)在要么改這個TRIGGER的狀態(tài)，要么打補(bǔ)丁（9.2.0.6）。第一種選擇是明智而快捷且安裝的。重新編譯，檢查不是DEBUG狀態(tài)。應(yīng)用啟動，正常運行。
??? 上線數(shù)據(jù)庫中的數(shù)據(jù)庫內(nèi)部的程序開發(fā)對象，例如：PACKAGE、FUNCTION等是堅決不能存在DUBUG狀態(tài)的。不但影響性能而且容易引起某些莫名的錯誤。
???? 當(dāng)然ORACLE也常常需要懷疑一下，畢竟再好的程序也是人編的 -:)
???
-------------------系統(tǒng)說明
OS:REDHAT AS4
??? 趕快登錄到那個服務(wù)器上去檢查。
??? 通過日志分析，我看到導(dǎo)致實例不可用，其實質(zhì)就是由于07445錯誤導(dǎo)致數(shù)據(jù)庫實例崩潰。接著分析詳細(xì)的日志信息: ORA-07445: exception encountered: core dump [kkmmctbf()+89] [SIGSEGV] [Address not mapped to object] [0x30] [] []
Current SQL statement for this session:
delete from t_XXXX where XXXX_id='66666666666' and xx_id='EEE' ????
??? 看看07445的錯誤解釋：
07445, 00000, "exception encountered: core dump [%s] [%s] [%s] [%s] [%s] [%s]"
// *Cause: An OS exception occurred which should result in the creation of a
//???????? core file.??This is an internal error.
// *Action: Contact your customer support representative.
?? 牛，推到OS系統(tǒng)上了！
?? 難道真是操作系統(tǒng)出了什么問題，看看操作系統(tǒng)的相關(guān)日志，表面上看沒有任何報錯信息。
?? 會不會是ORACLE的BUG？
?? 了解應(yīng)用情況，發(fā)現(xiàn)在刪除某張表的時候會出現(xiàn)這種情況，并且通過錯誤日志也看的出來，但是奇怪一個簡單的SQL怎么會造成實例崩潰呢？
??? 搜速相關(guān)信息，通過檢查9.2.0.6 Bug Categories，在分類中發(fā)現(xiàn)一個可能的錯誤：
Process May Dump (ORA-7445) / Abend / Abort
3199908??????Dump (in kkmmctbf) from a DELETE TRIGGER compiled in DEBUG mode ????
??? 趕快檢查被刪除的表，COOL!果真在其上有一個基于DELETE的TRIGGER!
??? 檢查這個TRIGGER的狀態(tài)：
??? select owner,object_name,object_type,debuginfo?
rom all_probe_objects?
where object_name='TRI_XXX' and object_type like 'TRIGGER';
OWNER??????? OBJECT_NAME??? OBJECT_TYPE???? D
------------ -------------- ---------------???? -
COPERATOR??? TRI_XXX??????? TRIGGER??????????????T
1 rows selected. ????
??? 天哪，真是DEBUG狀態(tài)！
??? 一個因為在DEBUG狀態(tài)，且是基于DELETE的TRIGGER觸發(fā)了這個ORACLE的BUG！
??? ......
??? 現(xiàn)在要么改這個TRIGGER的狀態(tài)，要么打補(bǔ)丁（9.2.0.6）。第一種選擇是明智而快捷且安裝的。重新編譯，檢查不是DEBUG狀態(tài)。應(yīng)用啟動，正常運行。
??? 上線數(shù)據(jù)庫中的數(shù)據(jù)庫內(nèi)部的程序開發(fā)對象，例如：PACKAGE、FUNCTION等是堅決不能存在DUBUG狀態(tài)的。不但影響性能而且容易引起某些莫名的錯誤。
???? 當(dāng)然ORACLE也常常需要懷疑一下，畢竟再好的程序也是人編的 -:)
???
-------------------系統(tǒng)說明
OS:REDHAT AS4
DATABASE:ORACLE 9.2.0.4
本文轉(zhuǎn)自Be the miracle!博客51CTO博客，原文鏈接http://blog.51cto.com/miracle/57178如需轉(zhuǎn)載請自行聯(lián)系原作者
Larry.Yue
總結(jié)
以上是生活随笔為你收集整理的ORA-07445导致实例崩溃的解决【The solution of instance crush by ORA-07445】的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 使用jQuery.Ajax向ASP.NE
- 下一篇： Linux命令晋级