必须先执行crsctl check ctss确认CTSS是否已退为observer模式；若是，则彻底清理所有节点的NTP/chrony配置及服务，重启ctssd并验证offset稳定在±10ms内。
Oracle RAC节点时间漂移不是“调个date就能好”的问题，而是CTSS服务已失效的明确信号——只要crsctl check ctss返回CTSS is in observer mode，就说明集群失去了自主同步能力，必须按Oracle底层逻辑清理、重启、验证，否则时间差会持续扩大，最终触发ORA-00600 [kgxgncv1]或实例驱逐。
先确认ctssd是不是已退为observer mode
这是所有修复动作的前提，跳过这步等于蒙眼修车。
- 在每个节点执行
crsctl check ctss，若输出含CTSS is in observer mode，立刻停手，别去改ntp.conf或跑ntpdate - 同时在所有节点运行
date -u +%s.%N取3次平均，算最大差值：超过±500ms即高风险；超1s时实例很可能无法启动 - 查日志：
tail -20 $GRID_HOME/log/`hostname`/ctssd/ctssd.log，重点找Switching to observer mode或Failed to communicate with reference node
彻底清空NTP/chronyd残留配置
Oracle判断极死板：只要/etc/ntp.conf或/etc/chrony.conf存在，就认定NTP启用，强制ctssd退为observer——mv不算清除，rm -f才是唯一有效操作。
- 停服务：
systemctl stop ntpd、systemctl stop chronyd（两个都得停，别只停一个） - 禁自启：
systemctl disable ntpd、systemctl disable chronyd - 删配置：
rm -f /etc/ntp.conf /etc/chrony.conf（漏掉chrony.conf是常见失败原因） - 删PID：
rm -f /var/run/ntpd.pid /var/run/chronyd.pid - 确认无残留：
ps -ef | grep -E "(ntpd|chronyd)"结果里只应剩grep自身进程
重启ctssd并验证offset是否稳定在±10ms内
清理完NTP后，ctssd不会自动切回active，必须人工重启并观察收敛性，且稳定≠单次达标，而是持续波动不超阈值。
- 执行：
crsctl stop res ora.ctssd -init && crsctl start res ora.ctssd -init - 等2–3分钟，再跑
crsctl check ctss：正常应返回CTSS is in Active mode和类似Offset (in msec): 7的数值 - 用
watch -n 10 'crsctl check ctss'持续观察10分钟，确保offset无跳变、始终在±10ms内 - 若仍显示
observer mode，立即检查是否某节点漏删了/etc/chrony.conf，或存在未识别的systemd-timesyncd
非要共存NTP与CTSS？三个硬条件缺一不可
合规场景下允许NTP存在，但前提是它只校准硬件时钟、不干预系统时钟——否则ctssd照样fallback。这不是可选项，是Oracle明文规定的死条件。
-
/etc/chrony.conf中必须含makestep 1.0 3和rtcsync（防止重启倒退） -
/etc/ntp.conf中必须有tinker stepout 0和disable kernel -
/etc/sysconfig/ntpd中OPTIONS="-x"必须存在，且不能含-g - 绝对禁用
ntpdate、hwclock --systohc等任何绕过slewing逻辑的手动命令
真正难的不是执行命令，而是所有节点配置必须完全一致、所有残留必须清零、所有验证必须持续观察——少一个节点漏删chrony.conf，或某处防火墙拦截UDP 123端口，都会让offset缓慢累积，最终在凌晨三点突然报CRS-4535。
