Oracle显示表裂开,如何从日志中快速定位RAC脑裂的初步原因

RAC集群脑裂一直是让DBA十分头痛的事情。实际上RAC集群作为一种高可用架构，其中某个节点故障，是不会对应用造成太大的影响的，如果应用系统做了针对RAC集群的应用架构上的优化，实际上无论是通过TAF自动切换(其中的SELECT语句都可以无缝切换，不会产生应用中断)还是通过FCF(Fast Connection Failover，可以实现亚秒级应用自动切换，只要应用中针对FCF切换做了错误捕捉，重新执行失败的SQL，则在应用前端基本上感受不到切换的产生)，都可以让应用几乎不受影响。

和TAF不同,FCF是通过FAN的模式进行故障切换的。TAF是由客户端发起的，因此客户端需要知道实例故障，然后根据TNS的定义去找到还活着的实例，然后再去重连。考虑到网络延时等因素，这个过程需要几十秒钟到几分钟的时间才能完成。而FCF通过Oracle的ONS服务(Oracle Notify Services)来实现。当Oracle的某个实例发生状态变化的时候，ONS会把实例状态以秒级的延时推送给所有的客户端，客户端接收到这个消息后，可以根据策略自动重连，从而实现快速的切换。这个技术虽然早就出现了，不过我们的应用开发商往往不知道这个功能，因此在我们所见到的客户系统中应用甚少。虽然前端应用的高可用可以得到保障，后端的DBA不能忽视RAC脑裂的发生，因此每次RAC集群脑裂，DBA都必须给主管领导一个合理的解释。实际上，Oracle的ALERT LOG中对脑裂有十分友好的记录，因此通过ALERT LOG，我们就可以很快的把RAC集群脑裂的初步原因分析清楚了。今天老白就用一个最近发生的案例，简单的和大家分享一下RAC集群脑裂，ALERT LOG的快速分析方法。Fri Jan 08 13:10:39 202

Reconfiguration started (old inc 20, new inc 22)

List of instances:

1 2 3 (myinst: 2)

Global Resource Directory frozen

* dead instance detected - domain 0 invalid = TRUE

Communication channels reestablished

Fri Jan 08 13:10:39 2021

* domain 0 valid = 0 according to instance 1

Master broadcasted resource hash value bitmaps

Non-local Process blocks cleaned out

Fri Jan 08 13:10:39 2021

LMS 2: 1 GCS shadows cancelled, 1 closed, 0 Xw survived

Fri Jan 08 13:10:39 2021

LMS 0: 3 GCS shadows cancelled, 0 closed, 0 Xw survived

Fri Jan 08 13:10:39 2021

Fri Jan 08 13:10:39 2021

LMS 5: 4 GCS shadows cancelled, 1 closed, 0 Xw survived

LMS 1: 5 GCS shadows cancelled, 1 closed, 0 Xw survived

Fri Jan 08 13:10:39 2021

Fri Jan 08 13:10:39 2021

LMS 3: 3 GCS shadows cancelled, 0 closed, 0 Xw survived

LMS 4: 7 GCS shadows cancelled, 3 closed, 0 Xw survived

Set master node info

Submitted all remote-enqueue requests

Dwn-cvts replayed, VALBLKs dubious

All grantable enqueues granted

Fri Jan 08 13:10:43 2021

minact-scn: Inst 2 is now the master inc#:22 mmon proc-id:549600 status:0x7

minact-scn status: grec-scn:0x0000.00000000 gmin-scn:0x0e5a.226955aa gcalc-scn:0x0e5a.22792954

minact-scn: master found reconf/inst-rec before recscn scan old-inc#:22 new-inc#:22

Submitted all GCS remote-cache requests

Fix write in gcs resources

Reconfiguration complete"Reconfiguration started"表示一次集群脑裂的开始。我们可以从List of instances列表中找到出现问题的实例。

上面的例子中，本实例是2，而本次脑裂中被确认活着的实例是1，2，3，那么很明显，没出现在列表上的实例就是被驱逐的实例。在这个例子中就是4号实例。从下面看到，通讯通道已经重置了。 本次脑裂从 13:10:39开始，到13：10：43结束，持续了4秒钟，在此期间，集群是处于冻结状态的，所有的GES/GCS服务都无法进行，这个时间段里，应用系统肯定受到了一定的影响。从这个日志中，我们也可以看出，这次脑裂结束后，2号实例成为了MASTER实例。

既然知道了4号实例死了，那么我们就检查一下13:10:39时段附近4号实例的ALERT LOG。

在13:10:37的时候，USER (ospid: 473075): terminating the instance。从这个信息我们可以看出，当时是用户进程终结了实例，这种情况大多数是DBA直接SHUTDOWN ABORT了这个实例。在这个案例中，定位问题还是比较简单的。当然也有可能是其他原因导致了实例故障，根据没有出现在instance list上的实例的相关时段的日志进行分析就可以了。