Analizando una caída de un nodo de un RAC nos encontramos una falta de comunicación entre los nodos:

    2019-09-16 12:59:26.113 [OCSSD(99989)]CRS-1612: Falta la comunicación de red con el nodo nodo2 (2) para el 50% de intervalo de timeout. Este nodo del cluster se eliminará en 14.880 segundos

    2019-09-16 12:59:34.114 [OCSSD(99989)]CRS-1611: Falta la comunicación de red con el nodo nodo2 (2) para el 75% de intervalo de timeout. Este nodo del cluster se eliminará en 6.880 segundos

    2019-09-16 12:59:38.117 [OCSSD(99989)]CRS-1610: Falta la comunicación de red con el nodo nodo2 (2) para el 90% de intervalo de timeout. Este nodo del cluster se eliminará en 2.880 segundos

    2019-09-16 12:59:41.500 [OCSSD(99989)]CRS-1607: El nodo nodo2 se ha expulsado en la encarnación del cluster 450925382; detalles en (:CSSNM00007:) en /u01/app/grid/diag/crs/nodo1/crs/trace/ocssd.trc.

    2019-09-16 13:00:12.095 [OCSSD(99989)]CRS-1601: Reconfiguración de CSSD terminada. Los nodos activos son nodo1 .

    2019-09-16 13:00:12.193 [CRSD(42822)]CRS-5504: Se ha notificado un evento de nodo caído para el nodo 'nodo2'.

    2019-09-16 13:00:19.700 [CRSD(42822)]CRS-2773: El servidor 'nodo2' se ha eliminado del pool 'Generic'.

    2019-09-16 13:00:19.703 [CRSD(42822)]CRS-2773: El servidor 'nodo2' se ha eliminado del pool 'ora.cdbxxx'.

    2019-09-16 13:00:19.704 [CRSD(42822)]CRS-2773: El servidor 'nodo2' se ha eliminado del pool 'ora.cdbxxx_des'.

    2019-09-16 13:00:19.706 [CRSD(42822)]CRS-2773: El servidor 'nodo2' se ha eliminado del pool 'ora.cdbxxx'.

    2019-09-16 13:00:19.707 [CRSD(42822)]CRS-2773: El servidor 'nodo2' se ha eliminado del pool 'ora.cdbxxx_prod'.

    2019-09-16 13:13:46.147 [OCSSD(99989)]CRS-1601: Reconfiguración de CSSD terminada. Los nodos activos son nodo1 nodo2 .

    2019-09-16 13:14:05.934 [CRSD(42822)]CRS-2772: El servidor 'nodo2' ya se ha asignado al pool 'Generic'

    2019-09-16 13:14:05.939 [CRSD(42822)]CRS-2772: El servidor 'nodo2' ya se ha asignado al pool 'ora.cdbxxx'

    2019-09-16 13:14:05.939 [CRSD(42822)]CRS-2772: El servidor 'nodo2' ya se ha asignado al pool 'ora.cdbxxx'

    2019-09-16 13:14:05.940 [CRSD(42822)]CRS-2772: El servidor 'nodo2' ya se ha asignado al pool 'ora.cdbxxx_prod'

    2019-09-16 13:14:05.941 [CRSD(42822)]CRS-2772: El servidor 'nodo2' ya se ha asignado al pool 'ora.cdbxxx_des'

Una de las posibles causas es un consumo excesivo de CPU, que confirmamos haciendo un top en el servidor

      PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                                                     
     45282 oracle    20   0 12.244g   2892   2892 R 100.0  0.0 203706:34 ora_scm0_cdbxxx                                                                                                                                             
     11001 oracle    20   0 12.231g  35896  32492 S  64.0  0.1 519:37.66 oracle_11001_cd                                                                                                                                             
     31766 oracle    20   0 12.231g  88436  82516 S  11.2  0.2   0:22.03 oracle_31766_cd                                                                                                                                             
     45509 oracle    20   0 12.243g  13924  12732 S   9.2  0.0   1119:59 ora_lgwr_cdbpro                                                                                                                                             
     14639 oracle    20   0 12.232g  95700  90096 S   4.3  0.2   0:46.31 oracle_14639_cd                                                                                                                                             
     10305 oracle    20   0 12.231g  85588  80520 S   3.3  0.2   0:53.33 oracle_10305_cd    

El consumo excesivo se debe a un bug de Oracle, 12.2 RAC DB Background process SCM0 consuming excessive CPU (Doc ID 2373451.1), en el que sugieren como workaround deshabilitar el parámetro dlm_stats_collect para evitar que vuelva a suceder.

Al ser un parámetro que no supone ningún riesgo lo modificamos, y confirmamos que no tiene efectos negativos en 12.2 debido a que dichas estadísticas ya no se usan en 12.2, así como versiones posteriores:

    Note: Disabling dlm_stats_collect (ie setting to 0) has no negative effect in 12.2.  

    This is because the stats are not yet used in 12.2 (the features that would use these stats service based affinity and cache warmup are also disabled in 12.2 by default). 

    Versions 18 and 19 may have them enabled, so re-evaluate at that time.

Por lo que confirmamos que dlm_stats_collect en versiones > 12.2 , no, gracias.