Diagnostiquer la cause d'une éviction de nœud / d'un redémarrage inattendu de nœud

Commande

# 1) When, which node, evicted by whom: CRS alert log (on every node)
grep -E "CRS-1601|CRS-1607|CRS-1608|CRS-1609|CRS-1610|CRS-1611|CRS-1612|CRS-8011" \
  $ORACLE_BASE/diag/crs/$(hostname -s)/crs/trace/alert.log
# 2) CSS details: was the network heartbeat or the disk heartbeat lost
grep -iE "evict|misscount|heartbeat|disk HB|network HB" \
  $ORACLE_BASE/diag/crs/$(hostname -s)/crs/trace/ocssd.trc | tail -100
# 3) Who triggered the reboot (cssdagent/cssdmonitor):
ls -lt $ORACLE_BASE/diag/crs/$(hostname -s)/crs/trace/ohasd_cssd*.trc
# 4) OS resources at the time of the event (Cluster Health Monitor):
oclumon dumpnodeview -allnodes -s "2026-01-15 03:10:00" -e "2026-01-15 03:20:00"
# 5) Diagnostic collection from all nodes (AHF/TFA):
tfactl diagcollect -crs -os -last 4h
# 6) OS side: /var/log/messages, journalctl -k (OOM, NIC, multipath, I/O errors)

Ce que fait la commande

Suit dans l'ordre la chaîne d'éviction de nœud : messages CRS-16xx dans l'alert log CRS, pertes de heartbeat dans ocssd.trc, métriques OS de CHM et journaux de tous les nœuds collectés avec TFA.

Quand l'utiliser

Lorsqu'un nœud redémarre de façon inattendue ou est évincé du cluster, pour l'analyse de cause racine (RCA) et un SR auprès du support Oracle.

Attention

Collectez les journaux de chaque nœud couvrant l'heure de l'événement ; les fichiers trace tournent et des preuves peuvent être perdues. Vérifiez que les fuseaux horaires sont identiques sur les nœuds (CTSS/NTP). N'appliquez pas de "corrections" comme l'augmentation de misscount avant d'avoir collecté les preuves.