在一次性能调优中，发现用户大量的direct path read等待，正常理解这应该是一个大表的全表扫，我们捕获了该SQL发现两层嵌套走索引，索引需要回表。
所以显然这里不是全表扫描，我们检查了表结构，以及select后的查询字段发现都有lob字段，其次通过ASH的physical read统计，都是lob字段，所以我们怀疑是大量的
Lob 读导致了direct path read ,我们从MOS找到一篇文章 "Direct path read" Wait Event During LOB Access (Doc ID 2287482.1)，比较清楚地描述了这个问题
既然找到问题解决也就很简单

方案1：关闭直接路径读（这个是部分关闭），这个问题是当时原厂工程师的建议，我们的方案更强项与后者，cache lob
动态生效：（需要在集群每个节点都执行！）
alter system set events '10949 trace name context forever,level 1';
重启生效：（1个游戏账号拍卖节点都执行！）
alter system set event='10949 trace name context forever, level 1' scope=spfile sid='*';

方案2：Cache相关的lob字段
ALTER TABLE <tabname> MODIFY LOB (<lobname>) ( CACHE| CACHE READS );
这个方案也是动态生效，不需要重启实例。

采用方案1后，direct path read极大缓解，其实其中还有一个read by other session等待严重的会话，这个是并发读（一般是全表扫导致），我们通过
一个普通索引解决了，这里是想说明其实direct path read对IO的压力会恶化read by other session，因为会话需要等待其他会话从磁盘向内存读数据，但是这个通过索引解决是
最有效的方法。