必须先执行crsctl check ctss确认CTSS是否已退为observer模式；若是，则彻底清理所有节点的NTP/chrony配置及服务，重启ctssd并验证offset稳定在±10ms内。
先看 ctssd 是不是已退成 observer mode
节点离线往往不是时间差本身造成的，而是 ctssd 失去控制权后，各节点各自漂移，最终触发 crs 拒绝启动或实例驱逐。最该第一时间确认的，就是 ctssd 状态是否已降级。
在每个节点上执行：crsctl check ctss。如果返回 CTSS is in observer mode，说明 Oracle 已放弃时间同步主导权，转而“旁观” NTP —— 但此时 NTP 很可能并不可靠，甚至根本没在跑。
- 同时运行
date对比所有节点，差值超过±500ms就属高风险；超过1s常伴随ORA-00600 [kgxgncv1]或实例无法启动 - 查日志：
tail -20 $GRID_HOME/log/`hostname`/ctssd/ctssd.log，重点关注Switching to observer mode或Failed to communicate with reference node - 别跳过这步：直接
ps -ef | grep ntpd和systemctl status chronyd，确认有没有残留的系统级时间服务在跑
停 NTP 前必须清干净所有残留
Oracle 的判断逻辑很死板：/etc/ntp.conf 存在 = NTP 启用 = ctssd 必须 observer。只停服务不删配置，等于白干。
- 停服务：
systemctl stop ntpd（或service ntpd stop）；若用chronyd，同样停：systemctl stop chronyd - 禁自启：
systemctl disable ntpd、systemctl disable chronyd - 删配置：
rm -f /etc/ntp.conf、rm -f /etc/chrony.conf（注意：不是mv，mv仍会被识别为存在） - 删 pid 文件：
rm -f /var/run/ntpd.pid、rm -f /var/run/chronyd.pid - 确认无残留：
ps -ef | grep ntp和ps -ef | grep chrony应仅剩grep自身进程
重启 ctssd 并验证 active 状态是否恢复
清理完 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（如Offset (in msec): 7） - 观察稳定性：
watch -n 10 'crsctl check ctss'，持续 10 分钟，确认 offset 波动稳定在±10ms内，无跳变 - 若仍显示
observer mode，说明某节点漏删了配置文件，或用了未被发现的其他时间服务（比如systemd-timesyncd）
跨网段或防火墙下 NTP 连通性容易被忽略
即使你选择保留 NTP（如合规要求），UDP 123 端口被拦截也会让 ntpq -p 显示正常，但实际 offset 缓慢累积，最终拖垮 CTSS。
- 验证连通性：
nc -uz <ntp-server-ip> 123</ntp-server-ip>或telnet <ntp-server-ip> 123</ntp-server-ip>（UDP 测试需用nc） - 检查中间设备：交换机 ACL、安全组策略、主机防火墙（
iptables -L -n或firewall-cmd --list-all）是否放行 UDP 123 - 若无法打通，要么调整网络策略，要么彻底禁用 NTP 改用 CTSS —— 强行共存却没通端口，比不用还危险
真正棘手的从来不是怎么重启服务，而是某个节点悄悄留着 /etc/ntp.conf，或者运维同事在另一台机器上开了 chronyd 却没通知你。CTSS 的 observer mode 是个沉默的告警器，它不报错，只等时间差滚大到集群崩掉才亮红灯。
