ITPub博客

首页 > 应用开发 > IT综合 > 由gc cr multi block request等待事件想到的

由gc cr multi block request等待事件想到的

原创 IT综合 作者:bulkaunt 时间:2007-09-03 23:08:25 0 删除 编辑
gc cr multi block request实际就是global cache cr multi block request,10G以后global cache被简称为gc,在RAC应用系统里面,这是一个常见的等待事件。[@more@]

工作原理:

当进程请求数据库块时,首先会在本地的CACHE里面查看是否存在,这种查看是根据DBA (Data Block Address) 转化为cache buffers chains,然后再从hash bucket确认是否存在。
如果在本地没发现有块的CACHE,进程就会请求resource master授予共享访问给数据块,然后再去获取数据块的CACHE。
如果请求的BLOCK CACHE在远程的节点,resource master就会使用内部通讯把远程的CACHE传输到本地。当请求的CACHE BUFFER是共享模式的,远程节点就会克隆一个然后传输到本地。非则,就建立PI映像,然后传输到本地。


数据库现象:
会出现以下类似的等待

SQL> select name from v$event_name where name like 'gc%';

NAME
----------------------------------------------------------------
gc buffer busy
gc current request
gc cr request
gc cr disk request
gc cr multi block request
gc current multi block request
gc block recovery request

这些事件严重影响了数据库的性能,它可能造成查询,修改,建立索引,统计分析异常缓慢。

在V$SESSION里面,可以通过这个等待事件获取到具体的块,如:

SID EVENT P1 P2 P3 MESSAGE
---------- ---------- ---------- ---------- --------- -----------------------------------------------------------
3776 gc current request 542 1871579 33619969 Table Scan: CM_CU_CUSTOMER: 35059 out of 66457 Blocks done

这里的P1,P2,P3分别对应数据文件,块和类别


SQL> select name,PARAMETER1 ,PARAMETER2,PARAMETER3 from v$event_name where name='gc cr multi block request';

NAME PARAMETER1 PARAMETER2 PARAMETER3
------------------------------ ---------- ---------- ----------
gc cr multi block request file# block# class#

如果你“足够”快,可以通过XSBH视图在另一个节点查看到块

SQL> select count(*) from v$bh where FILE#=542 and block#=1871579;

COUNT(*)
----------
0

解决方法:

只要不需要去远程取块的CACHE,那这个等待事件就不会出现。因此,把应用部署在一个节点上,而不是两个节点上。当然,这个应用针对的使大对象,毕竟RAC内部CACHE的传输速度是非常块的都是以CS单位来计算。
如果不可能只在一个节点上部署应用,可以适当调整两节点传输参数和应用来获取平衡。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/58242/viewspace-967787/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2012-09-21

  • 博文量
    15
  • 访问量
    1135400