必须先执行crsctl check ctss确认ctss是否已退为observer模式；若是，则彻底清理所有节点的ntp/chrony配置及服务，重启ctssd并验证offset稳定在±10ms内。
crsctl check ctss 显示 observer mode 怎么办
这是最该先确认的状态，不是“有没有NTP”，而是“CTSS是否还在干活”。执行 crsctl check ctss，若返回 CTSS is in observer mode，说明 CTSS 已放弃控制权，正依赖外部时间服务——但此时 NTP 或 chronyd 很可能并不可靠，甚至根本没在跑。
- 立刻在所有节点运行
date -u +%s.%N取 3 次平均，计算最大差值：超过 ±500ms 即高风险；超 1s 常伴随ORA-00600 [kgxgncv1]或实例无法启动 - 查日志：
tail -20 $GRID_HOME/log/`hostname`/ctssd/ctssd.log，重点找Switching to observer mode、Failed to communicate with reference node、time drift too large - 别跳过这步：
ps -ef | grep -E "(ntpd|chronyd|systemd-timesyncd)"，确认有没有残留的系统级时间服务在跑
停用 NTP/chronyd 前必须删干净配置文件
Oracle 的判断逻辑极死板：/etc/ntp.conf 或 /etc/chrony.conf 存在 = NTP 启用 = CTSS 必须让权。移动或重命名不算清除，mv /etc/ntp.conf /etc/ntp.conf.bak 仍会被识别为存在。
- 停服务：
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 是否稳定
清理完 NTP/chronyd 残留后，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 mode，立即检查是否某节点漏删了/etc/chrony.conf，或存在未被发现的systemd-timesyncd
非要共存 NTP 和 CTSS？那 chronyd 配置必须含 makestep
合规场景下允许 NTP 与 CTSS 共存，但前提是 chronyd 只校准硬件时钟，不干预系统时钟——否则 CTSS 仍会 fallback。
- 配置
/etc/chrony.conf时务必加：makestep 1.0 -1（表示 ≤1 秒偏差走 slewing，>1 秒才允许跳变） - 所有 RAC 节点必须指向同一个内网 NTP 服务器，禁止混用公网 NTP（延迟抖动大、不可控）
- 防火墙要放行 UDP 123 端口——即使
ntpq -p显示正常，端口被拦截也会导致 offset 缓慢累积 -
date -s是高危操作，尤其当节点间时间差已超 15 秒时，会破坏 GCS 时间戳、触发 OCR 写入冲突，绝对不能用
