oracle rac节点时间不同步时，必须先检查crsctl check ctss是否为observer mode；若是，则彻底清理所有节点的/etc/ntp.conf和/etc/chrony.conf、停用并禁启chronyd/ntpd、删除pid文件，再重启ctssd并验证offset稳定在±10ms内。
oracle 19c rac节点间时钟不同步，不能靠date -s硬调、不能只启部分节点的chronyd、也不能留着空的/etc/ntp.conf文件——只要有一个节点的系统时间同步服务配置不一致或残留未清，ctss就会退为observer mode，整个集群失去自适应同步能力，时间差会持续扩大，最终触发ora-00600 [kgxgncv1]或crs-4535。
crsctl check ctss 显示 observer mode 怎么办
这是最该先确认的状态，不是“有没有NTP”，而是“CTSS是否还在干活”。
- 执行
crsctl check ctss，若返回CTSS is in observer mode，说明CTSS已放弃控制权，正依赖外部时间服务（但很可能并不可靠） - 立刻在所有节点运行
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前必须删干净/etc/ntp.conf和/etc/chrony.conf
Oracle判断逻辑极死板：文件存在 = NTP启用 = CTSS必须让权。移动或重命名不算清除，mv /etc/ntp.conf /etc/ntp.conf.bak仍会被识别为存在。
- 停服务：
systemctl stop chronyd（或ntpd），再systemctl disable chronyd - 删配置：
rm -f /etc/ntp.conf /etc/chrony.conf（两个都得删，别漏掉chrony.conf） - 删PID：
rm -f /var/run/chronyd.pid /var/run/ntpd.pid - 确认无残留：
ps -ef | grep -E "(chronyd|ntpd)"，只应剩grep自身进程
重启ctssd后验证offset是否稳定在±10ms内
清理完NTP残留后，CTSS不会自动切回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，立即检查是否某节点漏删了/etc/chrony.conf（尤其容易忽略）
非要对接统一NTP服务器？那chronyd配置必须含makestep和rtcsync
合规场景下允许NTP与CTSS共存，但前提是NTP只校准硬件时钟，不干预系统时钟——否则CTSS仍会fallback。
-
/etc/chrony.conf中必须有：makestep 1.0 3（开机前3秒允许阶跃校正）、rtcsync（防重启倒退）、iburst（加速初始同步） - 注释掉所有
pool行，只保留可信内网NTP源，例如：server 10.10.1.1 iburst - 验证方式不是
systemctl status，而是：chronyc tracking看Offset绝对值≤500ms，chronyc sources -v确认有^*主源且MS列为u - 注意：UDP 123端口跨网段常被防火墙拦截，
ntpq -p显示在线≠实际同步有效，务必实测date -u +%s.%N差值
真正麻烦的不是配错参数，而是多个节点配置不一致、或某个节点悄悄启了systemd-timesyncd却没关——这种“几乎一样但差一点”的状态，会让CTSS在active和observer之间反复横跳，时间差缓慢累积到崩溃阈值才暴露。
