今年开始，Oracle 12.2的RAC逐渐开始在生产环境中部署多了起来（18c on premise 需要等到7月）。
诸位专家的12.2生产系统有可能会遇到一大个麻烦，一旦在生产中实例2主机crash以后，会发现crash掉的数据库
启动不了！
启动不了原因：
数据库启动到GC reconfiguration后，就会无法完成，直到超时。
2018-05-25T02:06:10.534432+08:00
Submitted all remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
2018-05-25T02:06:12.819677+08:00
All grantable enqueues granted
Submitted all GCS remote-cache requests
最后lms进程超时报错。 即使设置了_lm_sync_timeout=1200，同样会挂起超过20分钟超时。
而且
在crash节点reconfig的同时，存活节点会发生冻结。此时，在存活节点，会看到大量gc等待，library cache load lock，row cache low 等等。
留给DBA的绝对是一个sev 1的惨痛经历！
该问题已经在AIX, HP UX, LINUX平台上发现。通过总结，发现该问题的规律为：
SGA较大，一般都超过了100g
硬件配置低，心跳带宽较小，比如1000M以太网
硬件配置高，CPU核数较多，大于256甚至更多
第一种场景，SGA较大，硬件配置低，心跳带宽小，几乎100%会触发该问题，已经在数套系统中发现。发生的原因，可以理解为带宽不足。在osw中，可以在netstat中观察到大量的udp bad checksum， package dropped等消息。 在低配置硬件，1000Mor以下心跳网络，该问题几乎必然发生。
第二种场景，SGA较大，硬件配置高，心跳网络为10G以上，甚至40G的光纤网络，仍然可能发生该问题。在osw中，可以在netstat中观察到大量的udp bad checksum， package dropped等消息。 大家可能不理解，为什么带宽如此之大后仍然无法完成配置？ 我一次的遇到该问题，是在IBM 870，512核CPU，40g的心跳网络上发生。我在完成了数据库基准测试中的：cache fusion 测试后， 交给其它工程师完成高可用测试，在kill pmon后，发现数据库无法启动，挂起20分钟后，lms超时，实例crash。该问题已经在多个客户的高端配置环境中发现。
解决办法，救命良药
紧急救难：在crash节点开始启动后，在存活节点立刻刷新buffer cache
alter system flush shared_pool (可选）
alter system flush buffer_cache;
在刷新到gcs 和 ges资源后，crash节点可以在30秒以内完成GC reconfig。
Q? 刷cache影响生产怎么办？ A：两个选择：节点2无法启动，节点1最终积压奔溃，还是稍微影响节点1性能，换来整个集群的恢复。
适合于场景1和场景2。
把存活节点也重启了，同理也是清空了gcs资源，完成集群数据库恢复。适合于场景1和场景2。
降低gcs_server_processes的值，该思路是ACS专家付鹏提供。真实案例，高配硬件，10G以上心跳带宽，超过256核的CPU，默认的gcs server process超过了20个，启动过程中网络严重掉包。通过降低为8个以后，没有观察到网络掉包，并且很快完成了GC reconfig。这里暂时可以理解为gcs高并发导致网络阻塞，又或者本身gcs进程间的协调有问题（猜测）。适合于场景。
低配硬件尽快升级1000M心跳到10000M网络。适合于场景1。某系统升级到10000M后，在28秒内完成了GC reconfig。之前20分钟超时。
有趣的是，有两套案例，都是从10g升级到12c，复用的老硬件。但12.2的就会发生该问题。由此认为12.2的GC reconfig的资源需求远远大于10.2 。
该问题已经open了多SR到Oracle的全球售后，目前无开bug，或者有官方解决办法的消息。请保持关注Oracle官方发布。或者联系我们西区重案组。
防患于未然
在数据库进行基准性能测试的时候，一定要测试心跳网络：
对应的测试项目为 OTest cache fusion 测试，
在测试时间超过10分钟以后，在SGA中分配了大量的gcs和ges资源，立刻进行db crash测试（kill pmon），观测数据库能否顺利启动。
今年2月份，第一次发觉该问题，即是在进行同样的测试。
最后该问题的是由西区重案组专家王文杰和付鹏发现和汇总的。谢谢关注。
