昨天（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