Oracle 数据库 ORA-07445告警分析处理

某一天的早上，收到客户的微信信息，反馈系统新上线了一些功能模块，但是在测试运行的时候出现了异常的信息，导致测试失败。做了多年的系统运维，大家可想而知，系统更新难免遇到各种奇葩的古怪问题。

话不多说，直接让客户把相关的错误信息以及数据库告警日志发送过来分析。从数据库alert日志发现如下信息，其中的乱码问题可能是由于客户端字符集引起，不是本次分析的关键，所以就没有深究。

在分析问题之前，先介绍下客户的环境，操作系统使用的是centos 7.6 64位，数据库使用的版本是Oracle 19.3 CDB模式，有4个PDB在运行。

2021-10-29T15:42:15.265313+08:00
xxxxDB(3):Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x50] [PC:0x242FB33, kkegbyBasic()+339] [flags: 0x0, count: 1]
Errors in file /xxxxdb_log/diag/rdbms/csscdb/xxxxcdb/trace/xxxxcdb_ora_4134.trc (incident=38805) (PDBNAME=xxxxDB):
ORA-07445 : 出现异常错误: æ ¸å¿ƒè½¬å‚¨ [kkegbyBasic()+339] [SIGSEGV] [ADDR:0x50] [PC:0x242FB33] [Address not mapped to object] []
xxxxDB(3):Incident details in:
/xxxxdb_log/diag/rdbms/csscdb/xxxxcdb/incident/incdir_38805/xxxxcdb_ora_4134_i38805.trc
xxxxDB(3):Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2021-10-29T15:42:17.557500+08:00
Dumping diagnostic data in directory=[cdmp_20211029154217], requested by (instance=1, osid=4134), summary=[incident=38805].
2021-10-29T15:43:00.318779+08:00
xxxxDB(3):Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x50] [PC:0x242FB33, kkegbyBasic()+339] [flags: 0x0, count: 1]
Errors in file /xxxxdb_log/diag/rdbms/csscdb/xxxxcdb/trace/xxxxcdb_ora_4193.trc (incident=38470) (PDBNAME=xxxxDB):
ORA-07445: 出现异常错误: æ ¸å¿ƒè½¬å‚¨ [kkegbyBasic()+339] [SIGSEGV] [ADDR:0x50] [PC:0x242FB33] [Address not mapped to object] []
xxxxDB(3):Incident details in: /xxxxdb_log/diag/rdbms/csscdb/xxxxcdb/incident/incdir_38470/xxxxcdb_ora_4193_i38470.trc
xxxxDB(3):Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2021-10-29T15:43:02.437495+08:00
Dumping diagnostic data in directory=[cdmp_20211029154302], requested by (instance=1, osid=4193), summary=[incident=38470].

从上面的告警日志，我们抓取的关键点是
ORA-07445 kkegbyBasic()+339

从google搜索以上关键字信息，找到Doc ID描述的场景非常相似，这种错误是BUG导致，并提供了3种解决方案。

方案1：升级数据库版本

方案2：打补丁

方案3：修改隐含参数

对比3种方案，升级数据库版本耗时比较长，客户环境的系统属于24小时运行的，停机窗口比较短，而且还设计到跟应用系统的兼容性问题，客户不想升级版本。

修改隐含参数风险大。

最后用户采用了第二种方案，先在测试环境打补丁，耗时大概用了30分钟左右，最后验证没有问题，打完补丁之后，业务恢复正常。

最后把补丁应用到生产环境。

Sql Errors With ORA-07445 KkegbyBasic (Doc ID 2683269.1)