oracle的 SQL解析过高，版本过高，如何分析？

收集AWR，TOP等待事件有反馈数据库的解析出现严重的问题，cursor:mutexX占了超50%的DBTIME,同时cursor:mutexS伴随出现。同时mutex函数kkscsAddChildNode [KKSPRTLOC28]和kkscsPruneChild [KKSPRTLOC27]增加和裁剪子游标时产生了问题，数据库存在highversionSQL,version高于200的都是数 据库的递归SQL，最大的达到了7000多。同时收集ASH报告，里面会有差的SQL.

mutex很像latch，mutex是一种低级的粒度串行机制控制访问SGA中的共享数据结构，但是相比mutex更小更轻量并且更快，get时少几倍的指令调用，在10gr2版本引入，属于KGX(KernelGenericMutexModule).每个结构对象都有自己的mutex保护，父游标和子游标都有各自的mutex;每个结构又被 多个的mutex保护，在11GR2中有超过60种原因会导致不能重用已存在的childcursor，hardparse产生新的childcursor；softparse选择已存在的childcursor，查找已存在的childcursor时，持有的是cursor:mutexS,而增加新的ChildCursor持有的是cursor:mutexX.

详细见附件