ibatis引起的cache buffers chains很高

前些日志，使用ibatis读Oracle数据时，有一条SQL在本地Windows服务器很快，在AIX服务器上非常缓慢，
症状：cache buffers chains非常多!

经查发现，有条SQL语句执行有问题，在plsql developer中执行非常快，在服务器上通过ibatis执行非常慢，
通过开发人员修改该SQL，直接通过jdbc调用后，该SQL执行正常！

该问题与开发人员争论很久，这种事情，不好说了。。。

cache buffers chains当 一个数据块读入sga区，相应的buffer header会被放置到hash列表上,我们称其这hash chains,chain在中文的意为链条或串的意思，表达就是关连性.如果一个进程想访问或修改hash chain上的block,它首先要获得"cache buffers chains" latch。

cache buffers chains latch等待高大体有两个方面：

1、写的比较差的sql
cache buffers chains latch很大程度与逻辑读有关，所以要观注v$sql中BUFFER_GETS/EXECUTIONS大的语句。
同时每一个逻辑读需要一个latch get 操作及一个cpu操作，这样的sql也会很耗cpu资源。

2、热块
即多个进程读同一个或几个block的状况，这要考虑应用的设计了，为什么会出现这样的情况，改善可以这样：

联合v$session_wait及x$bh视图找到相应的热块进程优化
示例sql

代码:


SELECT A.HLADDR, A.FILE#, A.DBABLK, A.TCH, A.OBJ, B.OBJECT_NAME

  FROM X$BH A, DBA_OBJECTS B

 WHERE (A.OBJ = B.OBJECT_ID OR A.OBJ = B.DATA_OBJECT_ID)

   AND A.HLADDR = &P1RAW

UNION

SELECT HLADDR, FILE#, DBABLK, TCH, OBJ, NULL

  FROM X$BH

 WHERE OBJ IN (SELECT OBJ

                 FROM X$BH

                WHERE HLADDR = &P1RAW

               MINUS

               SELECT OBJECT_ID

                 FROM DBA_OBJECTS

               MINUS

               SELECT DATA_OBJECT_ID FROM DBA_OBJECTS)

   AND HLADDR = &P1RAW

 ORDER BY 4;

改变热块的途径就是尽量让一个block存少一些数据，比如加大pctfree参数.同时化化应用分散热块很重要。

cache buffers lru chain
这也是一个内存结构，用于标识哪些buffer操作状态的，比如哪些是"脏数据"需要DBWn回写到数据文件。可以适当加大_DB_BLOCK_LRU_LATCHES及提升DBWn的写速度得以解决。

cache buffers lru chain多也是bad sql语句的一个征兆，表明了buffer cache操作很频繁。比如做全表扫描或重复的扫描一个选择性很差的索引都会造成cache buffers lru chain的竞争。通过v$session_wait,v$session,v$sqltext找到相关的语句进行优化也很必要。