说崩就崩的数据库
客户的测试环境数据库频繁crash,而且据开发人员反馈是一条insert的SQL语句导致的。说实在话,随着Oracle数据库版本的演进,越来越少遇到宕机的案例,而这次竟然会因为一条insert导致实例崩溃,不由得让我好奇心大起。
拿到数据库告警日志和相关的trace文件,快速浏览了一下告警日志文件,有一个ORA-00600的报错。
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_pmon_118872.trc (incident=84019):
ORA-00600: internal error code, arguments: [17147], [0x0920CCFD0], [], [], [], [], [], [], [], [], [], []
根据这个报错和其生成的incident文件,匹配到一些和内存分配相关的case,刚好这个测试环境的内存等参数配置并不规范,因此建议先调整了memlock等内存相关的参数配置。
但是这个调整并没有解决问题,客户又一次尝试执行问题语句后,系统再次宕机。好在这一次提供了一个新的线索,数据库crash前报出了一个ORA-07445错误,根据这个错误我们找到了导致问题发生的真正原因。
Dump continued from file: /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_87354.trc
ORA-07445: exception encountered: core dump [opiaba()+639] [SIGSEGV] [ADDR:0x0] [PC:0x184BF07] [SI_KERNEL(general_protection)] []
在7445的trace文件中记录了问题发生时的insert语句,让人惊讶的是,这条SQL可不是客户想象中的简单SQL – 它的绑定变量数量多达63569个 (文件中记录的数量,实际应该不止,因为没有dump完数据库就崩溃了)。
分析其逻辑,这条语句是由多条insert语句组成的,应该是读取了某个原始文件,根据文件内容生成insert语句插入到数据库中。文件记录数有多有少,数量少的时候没问题,一旦记录数量超过某个值就会导致数据库崩溃。
很快我们根据ORA-07445 opiaba的关键字,找到了相关的Bug 12578873 : INSTANCE CRASH WITH CORE DUMP IN OPIABA WHEN USING MORE THAN 65535 BINDS。由于没有dump完,没有记录下故障发生时的call stack,但故障现象和触发场景几乎完全相同!好在这个问题在测试阶段就发现了,要是上到生产将会是一次严重的生产事故。
根据相关Bug的说明,绑定变量的数量的通过UB2MAXVAL来定义的,其上限是65536,超过这个数量就会触发故障。因为是架构上的限制,修改起来比较麻烦,Oracle研发通过调整绑定变量算法在一定程度上规避了这个问题。这个Bug影响11.2.0.2以上版本的Oracle数据库,在12.2中得到修复。受影响的版本可以通过应用Patch 12578873来进行问题的修复。
写在最后
在不少客户处开发和运维之间的冲突都比较多,究其原因,主要还是责任认定的问题。比如这次的故障,到底算是数据库的问题还是开发的问题,相信大家也会各执一词。从运维的角度来说,开发生成了一条非常规的SQL导致问题的发生;但是从开发的角度看,为什么就不能超过65536呢?为什么在19c上跑的好好的呢?本质上还是数据库的问题。
在故障的谜底揭开之前,这些都是问题。当我们找到谜底之后,就会发现,这其实是一个需要大家相互谅解的问题。即便是Oracle数据库,也存在很多的限制,也有自己的边界。对于运维来说要多去了解这些限制,多向开发人员去宣讲;而对开发来说也要多学习和遵守这些限制,不要让自己开发的程序和支持其运行的数据库行走在危险的边缘。彼此的理解和尊重才是最好的相处之道!