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

最新推荐文章于 2021-09-05 09:26:10 发布

couxia20140426

最新推荐文章于 2021-09-05 09:26:10 发布

阅读量392

点赞数

文章标签：数据库

本文详细介绍了gccrmultiblockrequest等待事件的工作原理及其对数据库性能的影响。该事件通常出现在RAC环境中，涉及跨节点的数据块传输过程。文章还提供了解决此问题的方法，包括调整应用部署方式及优化节点间数据传输。

摘要由CSDN通过智能技术生成

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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/58242/viewspace-967787/