前些日志,使用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找到相关的语句进行优化也很必要。
阅读(1269) | 评论(0) | 转发(0) |