ORA-07445案例一则

上周末两天早上6点左右,公司一套数据库alert日志中均会报出ORA-07445错误,详情如下:

ORA-07445: exception encountered: core dump [kkorminl()+306] [SIGSEGV] [ADDR:0x7FFED335CFF8] [PC:0x957496C] [Address not mapped to object] []

我们知道,类似于ORA-00600与ORA-07445的错误一般不能忽视,多数为数据库内部关键“致命”报错,可能是因为数据库Bug、数据库出现异常问题或操作系统异常多种原因造成的结果,对于此类错误,在公司众多套Oracle中并不罕见,有时会严重影响数据库可用性,有时仅仅抛出一个错误并不会造成任何的影响,针对此类错误我们要具体问题具体分析,严重与否并不能轻易的“经验主义”,针对ORA-00600与ORA-07445的麻痹大意往往会在你以为的风平浪静的潜意识中,给予你最措手不及的考验。

聚焦于本案例,周末两天均在6点左右报出,存在一定的周期性,已经出现两天,照这个节奏不知要持续多少天,为了优化我们的值班生态与避免此错误给大家造成针对ORA-07445麻痹大意的可能性,决定定位根因,解决问题。

数据库alert日志如下:

20191117-(1)

可以从日志中看到,该错误trace file为JOB进程抛出,契合了此错误周期性的特性,

20191117-(2)

从具体的Trace文件中可以看到此JOB作业归属于SQL_TUNNING_ADVISOR,

20191117-(3)

现在我针对此错误大概心里有个数了,随即用目前已得到的信息在Oracle MetLink中找到了解决方法:(Core dump file generation and ORA-07445 [kkorminl()] error (Doc ID 2198790.1)),经过对应数据库版本,Call_Stack信息基本可以确认为Bug导致:20191117-(5)

20191117-(6)

同时,Oracle也给出了解决方案,打Patch/禁用SQL Tunning Advisor/升级至12.1.0.2

20191117-(7)

基于Oracle的三种针对此错误的解决方案,我采用了禁用SQL Tunning Advisor功能来规避此错误的发生,经过一周的观察后,该报错不再出现。