? ?昨天（2007-12-27日）維護某省移動一個平臺的工程師報告數據庫實例不可用，只能重新啟動！這還得了，業務無論如何不能停。
??? 趕快登錄到那個服務器上去檢查。
??? 通過日志分析，我看到導致實例不可用，其實質就是由于07445錯誤導致數據庫實例崩潰。接著分析詳細的日志信息: 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系統上了！
?? 難道真是操作系統出了什么問題，看看操作系統的相關日志，表面上看沒有任何報錯信息。
?? 會不會是ORACLE的BUG？
?? 了解應用情況，發現在刪除某張表的時候會出現這種情況，并且通過錯誤日志也看的出來，但是奇怪一個簡單的SQL怎么會造成實例崩潰呢？
??? 搜速相關信息，通過檢查9.2.0.6 Bug Categories，在分類中發現一個可能的錯誤：
Process May Dump (ORA-7445) / Abend / Abort
3199908??????Dump (in kkmmctbf) from a DELETE TRIGGER compiled in DEBUG mode ????
??? 趕快檢查被刪除的表，COOL!果真在其上有一個基于DELETE的TRIGGER!
??? 檢查這個TRIGGER的狀態：
??? 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狀態！
??? 一個因為在DEBUG狀態，且是基于DELETE的TRIGGER觸發了這個ORACLE的BUG！
??? ......
??? 現在要么改這個TRIGGER的狀態，要么打補丁（9.2.0.6）。第一種選擇是明智而快捷且安裝的。重新編譯，檢查不是DEBUG狀態。應用啟動，正常運行。

??? 上線數據庫中的數據庫內部的程序開發對象，例如：PACKAGE、FUNCTION等是堅決不能存在DUBUG狀態的。不但影響性能而且容易引起某些莫名的錯誤。
???? 當然ORACLE也常常需要懷疑一下，畢竟再好的程序也是人編的 -:)
???
-------------------系統說明
OS:REDHAT AS4

DATABASE:ORACLE 9.2.0.4

本文轉自Be the miracle!博客51CTO博客，原文鏈接http://blog.51cto.com/miracle/57178如需轉載請自行聯系原作者

Larry.Yue

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的ORA-07445导致实例崩溃的解决【The solution of instance crush by ORA-07445】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。