背景：
公司有一个通讯系统，主要是通讯数据到客户端程序所指定的数据库，目前支持sqlserver、mysql和oracle三种类型的数据库，此篇主要记录一次oracle数据库占用CPU飙高的问题。
症状：
oracle支持上线后，数家客户反馈他们的oracle数据库所在的服务器在程序运行一段时间后CPU飙升，此时查看数据库连接，发现我们的程序占用了大量的数据库连接，有时连接占满后导致在本地用plsql都连不上数据库，会报ORA-00020: maximum number of processes (1000) exceeded错误，严重影响了所有该数据库的使用者
解决过程：
由于是之前解决的，某些细节方面可能有疏漏，根据记忆写下大概的解决过程
一、首先在数据库连接满的情况下，由于登录不上oracle，需要先解决登录oracle的问题，通过查资料发现可以先杀掉一些oracle线程，ps -ef|grep LOCAL --可以看到很多连接
删除前10条LOCAL=NO的数据库连接：
ps -ef|grep LOCAL=NO|grep -v grep|awk '{print $2}'|head|xargs kill -9删除过多的连接后，使用plsql登录进数据库
注：关于LOCAL=NO的解释，可参看此文章Oracle 服务器 进程中的 LOCAL=NO 和 LOCAL=YES
二、查看使用jdbc连接数据库的程序产生的版本数(由于测试环境重现了该问题，所以确定jdbc连接的只有我们的程序)
select sql_id,version_count,SQL_TEXT from v$sqlarea where version_count>= 0 AND module = 'JDBC Thin Client' order by 2 desc ;
三、找到版本较高的前几个sqlid，查看每次接收的绑定变量的类型，每次的区别在哪里
select position,datatype_string,value_string,LAST_CAPTURED from v$sql_bind_capture where sql_id='amnppbv67qak4' --and rownum<=1000 AND value_string IS NOT NULL;可以发现相同sql的不同版本差异都在绑定变量的datatype_string值不同造成的，比如同样的字段，同样的绑定变量，第一次update时，传进来的值为null，则此时oracle会自动使用VARCHAR2(32)来接收，若下次传进来的值大于VARCHAR2(32)长度，则oracle会使用VARCHAR2(128)来接收(参考BIND_MISMATCH导致过多VERSION COUNT的问题)，则针对这个sql则会重新硬解析，生成一个新的版本和执行计划，此处会占用大量的服务器资源。
四、此时为了数据库可以尽快的恢复运转，可执行如下sql来清除shared_pool，执行后数据库可暂时恢复正常(好像执行该语句需先停止其他程序对该数据库的访问，否则会一直卡在那里)：
alter system flush shared_pool;综上，出现该问题的原因主要有两种情况：
1.待insert或update的表中有较多可空字段，jdbc执行语句时，传进去绑定变量时使用了statement.setObject()方法，此时即使是非字符型的字段，oracle也会使用VARCHAR2(32)来接收，而之后传进具体的值时，oracle就会根据字段类型使用新的类型来接收该绑定变量的值，同时硬解析生成新版本和执行计划；
2.通讯某些字符型字段特别多的表，且字段长度不固定的情况下，较大可能出现这种问题。
解决方法：
针对原因1，目前在程序中做了修改，除了clob等特殊类型外，日期或数值等类型字段，都统一使用statement.setString()方法去赋值，oracle可以自动转化为相对应的类型入库；
针对原因2，没有特别好的方法，参考BIND_MISMATCH导致过多VERSION COUNT的问题，设置了oracle接收绑定变量时，直接使用VARCHAR2(2000)来接收
alter system set events '10503 trace name context forever ,level 2000'此解决方法不是特别妥当，不过确实可以解决该问题，至于时候会引起其他问题，暂时还未发现。
该问题其实是由oracle的版本BUG引起的(截自由 bind_mismatch 引起的 大量 version_count 问题)
故升级oracle版本自然是最稳妥的解决方案，不过由于有些客户可能不愿意升级，所以此处提供了自己的解决方案，具体效果还需后续观察