oracle的FCB

问题情境：近来项目中遇到了一个问题，程序在批量执行的时候，一直在卡，没有锁资源被独占，也没有堆栈等的溢出，没有办法在生产环境下直接解决这个问题，只有试着跟一下代码，看看有没有效果，固然发现了问题的原因，一条查询的sql在一直执行，今天我就要说这条sql

这是一条特别大的sql文件,程序在运行第一次的时候，可以很快的执行，但是程序在第二次进行运行的时候，就运行不出来了，
解决的办法：这个问题的原因是因为oracle优化器在对sql进行执行时，先会在缓冲池中找以前是否有执行过这样的sql，如果有的话，oracle就不会再为该sql创建新的执行计划，而是用已经有的执行计划进行处理，这个也就是我们说的硬解析与软解析的问题，但是在oracle11后，oracle数据库引进了一个叫FCB的东西，我们知道oracle在为sql创建执行计划的时候，首先要对写的sql中的数据量之类的进行一个估量，然后根据估量来判断执行计划应该怎么走，当第一次sql查询的时候，返回的结果，oracle会根据估量与实际产生的值进行对比，如果它觉得执行已经有的执行计划不是最优的时，在第二次进行执行时候，oracle将再次创建一个执行计划，这些理论我们可以通过VSQL与VSQLAREA来查看
当然我们可能够会说我们是不是可以通过数据库启动的时候配置参数来解决这个问题呢，我想应该是有的（没有查过），但是我觉得那样不是很好的解决办法，肯定还是自己的sql有问题，因为oracle的执行计划就像是oracle自己定制的标准与规范似的，我们要用它就应该按照它的规范了，也就是从自己的sql入手来出发
后来经过慢慢的拆分那个大sql，发现是一张表中的数据量有1000多万，但是没有对表进行分区，就想着看数据量少点实什么情况，发现当数据量小的时候，是可以查出来的，然后就想着给这个大数据量的表进行分区，然后继续排查问题，当数据量相对小了的时候，发现oracle显示的执行计划就比较准确了（应该是数据量大的时候，oracle自己没有准确的估量出执行成本，导致显示的执行成本不准确），此刻通过执行计划，明显看出了2个问题，一个是unoin 操作耗时，通过询问业务场景，发现2个unoin之间并没有重复的东西，因此将union改成union all，另外就是发现没有走索引，本来数据量大的那张表中是有索引的，但是没有走，最后分析加了个联合索引，然后发现执行效率立马就上来了
问题解决

总结：我们一直在说在写sql的时候，我们要主要的sql优化策略，但是在真正写的时候，还是没有注意到，因为当时数据量少你不是很容易发现问题，只可以通过经验来判断，但是随着程序的数据积累，慢慢的程序就跑不动了，这时才发现是自己当时在写代码的时候一不留神导致的