Chinaunix首页 | 论坛 | 博客
  • 博客访问: 547840
  • 博文数量: 128
  • 博客积分: 4000
  • 博客等级: 上校
  • 技术积分: 1345
  • 用 户 组: 普通用户
  • 注册时间: 2008-01-22 21:43
文章分类

全部博文(128)

文章存档

2009年(30)

2008年(98)

我的朋友

分类: Oracle

2009-05-07 16:19:25

前些日志,使用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) |
给主人留下些什么吧!~~