gc cr block lost

故障现象
1月3日上午10时，一客户数据库实例1重启，当业务切换到实例2时，实例2也重启。
故障分析
日志分析：

下面信息摘取自LMON trace

*** 2013-01-0310:04:12.203

kjfmrcvrchk:receiver LMS[4] has no heartbeat for 251 sec (1357178400.1357178651.0).

kjfmrcvrchk:receiver LMS[4] not in running mode

kjfmrcvrchk:Dumping callstack of lms4

Submittingasynchronized dump request [20]

kjfmrcvrchk:receivers are not healthy. kill instance.

ksuitm: waitingup to [5] seconds before killing DIAG(13789)

从以上LMON TRACE中可以看出10:04:12检测到进程LMS失去心跳251秒，5秒后将kill实例。因此从实例1的告警日志中可以看出，数据库在10:04:17时报LMON detects unhealthy receivers,被LMON进程kill的信息，详细信息如下：

Thu Jan 0309:55:11 EAT 2013

Thread 1advanced to log sequence 9754 (LGWR switch)

  Current log# 1 seq# 9754 mem# 0:/vghn03/oradata/esshn/vghn03_1_rd12.log

  Current log# 1 seq# 9754 mem# 1:/vghn02/oradata/esshn/vghn02_1_rd11.log

Thu Jan 0310:04:17 EAT 2013

LMON detectsunhealthy receivers.

Please checkLMON and DIAG trace files for detail.

Thu Jan 0310:04:17 EAT 2013

LMON (ospid:13793) is terminating the instance.

LMON:terminating instance due to error 481

Thu Jan 0310:04:17 EAT 2013

System statedump is made for local instance

System Statedumped to trace file /oracle/admin/esshn/bdump/esshn1_diag_13789.trc

Thu Jan 0310:04:22 EAT 2013

Shutting downinstance (abort)

License highwater mark = 3088

Thu Jan 0310:04:23 EAT 2013

Instanceterminated by LMON, pid = 13793

Thu Jan 0310:04:27 EAT 2013

Instanceterminated by USER, pid = 12422

 

AWR分析：

Snap Id

Snap Time

Sessions

Cursors/Session

Begin Snap:

14904

03-Jan-13 09:00:24

919

14.1

End Snap:

14905

03-Jan-13 09:30:33

963

15.1

Elapsed:

 

30.15 (mins)

 

 

DB Time:

 

530.35 (mins)

 

 

 

Top 5 Timed Events

Event

Waits

Time(s)

Avg Wait(ms)

% Total Call Time

Wait Class

CPU time

 

25,967

 

81.6

 

gc cr block lost

3,289

2,035

619

6.4

Cluster

gc current block lost

1,670

1,052

630

3.3

Cluster

gc buffer busy

14,473

996

69

3.1

Cluster

gc cr multi block request

91,238

678

7

2.1

Cluster

获取数据库故障半小时前的awr，我们可以看出gc * blocklost事件很高，这说明数据块在私网传输时丢失，说明网络存在问题，在一个健康的系统中，该等待事件次数正常为0。请检查网络硬件是否正常、参数是否配置正确。详细参考ID 563566.1文档说明。

从OSW和AWR看出节点1 gc block lost等待事件一直发生，并且incomplete headers和bad checksums持续增加，如下图所示。节点2 没有gc block lost，在这个时间段incomplete headers和bad checksums也未增加，可以确认节点1的私有网络存在严重问题。另，让主机工程师检查了相同业务其他省的数据库incomplete headers和bad checksums均为0。请联系系统管理员和网络管理员检查该数据库节点1为什么节点1 incomplete headers和bad checksums持续增加？

另外，关于操作系统socket_udp_rcvbuf_default参数设置是否直接导致本次故障，因缺少故障前的socket overflows统计信息，暂无法断定。该值指定了UDP接受包时的cache大小，若设置较小往往会导致socket overflows持续增加。从目前收集的信息来看，gc block lost增加时，socket overflows并没有增加，建议继续用OSW继续监控，防止故障再次重现时缺少足够的信息分析。对于socket_udp_rcvbuf_default设置建议为socket_udp_sndbuf_default的两倍。

从目前收集到的信息来看，故障前出现大量的gc * block lost等待事件，该事件与网络有关，该事件频繁发生会导致实例重启。

从OSW和AWR日志可以看出实例1重启由私有网络问题导致，实例2重启由bug8455559导致。

根据两天的现场监控分析建议：

1)   请联系管理员检查该数据库主机上为什么存在大量的incomplete headers和bad checksums，并且节点1目前该值还持续增加？

2)   确保socket_udp_rcvbuf_default至少是socket_udp_sndbuf_default的两倍。参考Tuning Inter-Instance Performance in RAC and OPS (Doc ID 181489.1)。

该问题处理到这里，数据库方面基本就到底了，对于incomplete headers和bad checksums，可以肯定是硬件问题导致的，但厂家们检查后都说他们没有问题。

为了推进问题的处理，建议客户对两个节点间的线路进行检测。

最终问题是由节点2私网到交换机主备线路问题导致。