关闭DRM触发的cr request retry与gc cr block lost

来源:互联网 发布:网络视频营销策略 编辑:程序博客网 时间:2024/06/05 21:13

某用户割接现场保障,全部数据进库后,8点全网上线前最后一轮压测,截取AWR中发现如下等待
 
  Event                                 Waits    Time (s)   (ms)   Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
CPU time                                          9,961          73.3
gc cr block 2-way                   220,355         772      4    5.7    Cluster
db file sequential read             105,042         509      5    3.7   User I/O
cr request retry                        519         462    890    3.4      Other
gc buffer busy                       15,690         405     26    3.0    Cluster


~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
CPU time                                          9,646          53.2
gc cr block lost                      4,691       3,456    737   19.1    Cluster
gc buffer busy                       63,299       2,375     38   13.1    Cluster
gc cr multi block request           191,379         725      4    4.0    Cluster
db file sequential read             392,292         686      2    3.8   User I/O

心里有点发凉,cr request retry与gc cr block lost 这两个等待事件一般由于内联网络通讯故障造成,
这个在上线前两小时突然出来,有点令人发指。赶紧要求局方安排网络临检,同时CHECK UDP参数,
两个节点都为SOLARIS 64位版本,
ndd /dev/udp udp_xmit_hiwat      65535
ndd /dev/udp udp_recv_hiwat      65535

正常,netstat -s检查UDP丢包也未发生。前端业务反应业务未有变慢趋势。网络临检结果一切正常。
这有点妖异了。
求助于万能的META,原来是关闭DRM的BUG。
Description

 A query on an object that gets truncated during execution spins forever with
CR failure retry waits when _gc_affinity_time=0 .
 
Rediscovery Notes:
 You may be hitting this bug if all of the following are true:
  - affected version is 10.2.0.5
  - object affinity is disabled (_gc_affinity_time=0)
  - query spins forever showing alternating waits for
       "gc cr failure" / "cr request retry"
  - object is being truncated during query execution
  - LE dump shows "INVALID" pkey

 @ id1: 0x8e49 id2: 0x10000 pkey: INVALID block: (1/36425)
 
Workaround
 Do not set _gc_affinity_time=0 .
 
因为性能原因,所有的库我都会关闭DRM,业务压测中有对临时表truncate的动作。于是。。。就出现了这样的等待事件。
如今,业务上线一周,一切正常。

警示:在等待事件中发现cr request retry与gc cr block lost,还是优先怀疑内联网络的问题,然后再考虑关闭DRM触发的BUG。

0 0
原创粉丝点击