事故发生在18年1月30号，公司Oracle实例发生重启，影响我宝业务26s，经分析是RD（本人）批量清洗数据时，触发了Oracle的Bug（编号：12578873）导致。
将故障trace文件提交给Oracle官方，确认是Oracle的一个Bug 12578873,并给出修复Patch。
Oracle官方给出解释是由于SQL绑定变量数超过65535次，触发了Oracle的一个Bug，引起实例重启。
下面贴出来的是批量执行的Mybatis SQL：
看了上面的SQL，说一下我们这次故障发生的场景: RD在清洗一个用户绑卡表的不兼容数据，单次清洗数据超过了65535条。
我们知道上面是一个简单的批量执行语句，但是通过分析可知，MyBatis将循环拼接成一个类似下面的匿名SQL块送给数据库做预分析。MyBatis底层机制是将mapper xml 转换成JDBC中 PreparedStatement预处理，整块代码送给Oracle数据库一次性做变量绑定。Oracle会一次性的对这些SQL顺序绑定变量（尽管block里面是很多单单条SQL组成），这样随着循环体内元素数量变大，需要的变量也会顺序增长，而Oracle只预设了一次性分配65535个变量的阈值，当需要绑定的变量个数超过这个阈值时，就报错了，甚至触发Bug，导致数据库实例Down掉。
begin
update xxx set id=:1 where id=:2;
update xxx set id=:1 where id=:2;
.....
end;
我们查阅资料发现，Oracle在批量执行的时候，是使用的上面的形式打包成一个巨大的SQL，而MYSQL是循环成单条SQL批量执行，因此MYSQL不存在这样的问题。
基础服务部将次Bug提交给Oracle官方之后，随即拿到了官方给出的修复Patch，我们在测试环境打上补丁之后，测试超过65535条数据更新，虽执行失败，但服务器实例未宕机重启，可以确认是该SQL引起。
其实到目前分析看来，主要的责任还是在RD，单次更新数据超过6万条就是一个隐患巨大的方案，RD在开发时为了节省网络通信的开销使用批量SQL的方式可以理解，但是在代码中一定要做数据分割，控制单次数据执行再2000条以内还是比较稳妥的解决方式。
