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私网到交换机主备线路问题导致。