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.