再牛的数据库，也抗不住奇葩的SQL

说崩就崩的数据库

客户的测试环境数据库频繁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数据库，也存在很多的限制，也有自己的边界。对于运维来说要多去了解这些限制，多向开发人员去宣讲；而对开发来说也要多学习和遵守这些限制，不要让自己开发的程序和支持其运行的数据库行走在危险的边缘。彼此的理解和尊重才是最好的相处之道！