The consistent gets Oracle metric is the number of times a consistent read (a logical RAM buffer I/O) was requested to get data from a data block.

翻译过来就是：为了保证一致性读时，从需要的数据块读取数据的次数（翻译得很烂）。注意这里的consistent gets一致性读，和oracle的特性之一consistent read一致性读不是同一个东西。

简单点说，在trace里面表示处理这个sql的时候需要在一致性读上处理多少个块。这些块产生的主要原因就是由于在查询过程中其他会话对数据块进行操作，并对我所需要的块做了修改，但是由于我的查询是在这些修改之前调用的，所以需要对回滚段中的前映象进行查询，以保证数据的一致性，所以就产生了一致性读的数据块。

有了这个重要的线索，再一次回头分析sql语句，各个表的数据都不大，so大胆猜测问题出在三个函数里面。于是依次屏蔽三个，执行这个sql，果然不出所料，在将 getyetlimit 屏蔽之后，这个sql语句只花了1秒。。。  

分析此function（表名已改）

create or replace function GETYETLIMIT(lbiid in varchar2)
  return number is
  Result       number;
  totallimit   number;
  accountstate varchar2(10);
begin
  select LBI_ACCOUNT_CODE, LBI_FACT_TIME_LIMIT
    into accountstate, totallimit
    from cccccc
   where lbi_id = lbiid;
  select case
           when substr(accountstate, 0, 2) = 'SL' then
            totallimit
           else
            round(sum(t.PM_PAID_MANAGEFEE + t.PM_PAID_PRINCIPAL +
                t.PM_PAID_INTEREST) /
            sum(t.PM_MANAGEFEE + t.PM_INTEREST + t.PM_PRINCIPAL) *
            totallimit,2)
         end into Result
    from pppppp t
   where t.pm_account_id in (select act_id from aaaaa where act_clbi_id= lbiid);
  return(Result);
end GETYETLIMIT;

估计就是这个in造成的。这里说下in和exist的区别：

对于in 和 exists的区别: 如果子查询得出的结果集记录较少，主查询中的表较大且又有索引时应该用in, 反之如果外层的主查询记录较少，子查询中的表大，又有索引时使用exists。其实我们区分in和exists主要是造成了驱动顺序的改变（这是性能变化的关键），如果是exists，那么以外层表为驱动表，先被访问，如果是IN，那么先执行子查询，所以我们会以驱动表的快速返回为目标，那么就会考虑到索引及结果集的关系了 ，另外IN时不对NULL进行处理。

将这个in改成 = ，最终问题解决，查询只花了3秒。