Oracle 19c RAC节点时间不同步不会直接导致重启，但会触发CTSS退为observer mode，进而破坏心跳与缓存融合时序，最终引发节点驱逐；crsctl check ctss显示observer mode即确诊信号，须立即清理所有节点的/etc/ntp.conf和/etc/chrony.conf、停用并删除PID文件、重启ctssd，并验证offset稳定在±10ms内。
Oracle 19c RAC 不会因为 NTP 时间偏差“直接”触发节点重启，但会通过 CTSS 退为 observer mode，进而破坏集群心跳与缓存融合的时序基础，最终导致节点被驱逐（表现为自动重启）。
crsctl check ctss 显示 observer mode 就是故障起点
这不是警告，是确诊信号。只要执行 crsctl check ctss 返回 CTSS is in observer mode，说明 CTSS 已放弃同步职责，转而依赖外部时间服务——而这个依赖在 RAC 场景下几乎总是不可靠的。
- 所有节点必须立刻执行
date -u +%s.%N取三次平均，计算最大差值；超过 500ms 即高风险，超 1s 很可能触发ORA-00600 [kgxgncv1]或CRS-4535 - 查日志：
tail -20 $GRID_HOME/log/`hostname`/ctssd/ctssd.log，重点找Switching to observer mode或Failed to communicate with reference node - 哪怕只有一台节点残留
/etc/chrony.conf或/etc/ntp.conf（哪怕文件为空），CTSS 就会全局 fallback
删配置文件比停服务更重要
Oracle 的判断逻辑极死板：配置文件存在 = NTP 启用 = CTSS 必须让权。很多修复失败，是因为只做了 systemctl stop chronyd，却漏删了配置文件。
-
mv /etc/chrony.conf /etc/chrony.conf.bak仍会被识别为“存在”，必须rm -f /etc/chrony.conf /etc/ntp.conf - 删完后确认
ps -ef | grep -E "(chronyd|ntpd)"只剩 grep 自身进程 - 不清理
/var/run/chronyd.pid或/var/run/ntpd.pid，会导致端口或资源无法释放，后续重启失败
重启 ctssd 后 offset 必须稳定在 ±10ms 内
清理完 NTP 残留后，CTSS 不会自动切回 Active mode，必须人工干预并验证收敛性。
- 执行
crsctl stop res ora.ctssd -init && crsctl start res ora.ctssd -init，等 2–3 分钟再检查 - 正常应返回
CTSS is in Active mode和类似Offset (in msec): 7的数值 - 用
watch -n 10 'crsctl check ctss'持续观察 10 分钟，确保 offset 无跳变、波动始终在 ±10ms 内 - 若仍显示 observer，立即检查是否某节点漏删了
/etc/chrony.conf（尤其容易忽略）
真正危险的不是时间差本身，而是 CTSS 状态分裂：一个节点 active、另一个 observer，集群内部心跳和 cache fusion 的时序逻辑就彻底紊乱了。日志里频繁出现 Failed to communicate with reference node 或 Msg NOT meant for this member 就是典型表现。
