必须先执行crsctl check ctss确认CTSS是否已退为observer模式；若是，则彻底清理所有节点的NTP/chrony配置及服务，重启ctssd并验证offset稳定在±10ms内。
Oracle RAC时钟不同步，第一反应不是调时间，而是查 crsctl check ctss —— 如果返回 CTSS is in observer mode，说明集群时间同步机制已经失效，所有后续操作都得围绕这个状态修复，否则手动 date -s、重启 ntpd 或跑 cluvfy 都是白忙。
crsctl check ctss 显示 observer mode 怎么办
这是最关键的诊断信号，代表 CTSS 已放弃主动同步，转为“旁观”外部时间服务（但往往并不可靠）。它不是警告，是已发生的降级。
- 立刻在所有节点执行
date -u +%s.%N取 3 次平均，算最大差值：超过 500ms 就要干预，超 1s 可能导致实例无法启动 - 查日志：
tail -20 $GRID_HOME/log/`hostname`/ctssd/ctssd.log，重点搜Switching to observer mode和time drift too large - 别急着配 NTP —— 先确认是不是残留配置导致 CTSS 主动让权。Oracle 的判断逻辑极死板：
/etc/ntp.conf或/etc/chrony.conf文件存在 = NTP 启用 = CTSS 必须 observer
停用 NTP/chronyd 前必须删干净配置文件
只停服务不删配置，CTSS 仍会卡在 observer 模式。很多修复失败，就败在这一步。
- 停服务：
systemctl stop chronyd（或ntpd），再systemctl disable chronyd - 删配置：
rm -f /etc/ntp.conf /etc/chrony.conf—— 注意：不是mv，mv /etc/ntp.conf /etc/ntp.conf.bak仍会被识别为存在 - 删 PID：
rm -f /var/run/chronyd.pid /var/run/ntpd.pid - 确认无残留：
ps -ef | grep -E "(chronyd|ntpd)"，只应剩 grep 自身进程
重启 ctssd 后怎么验证是否真正恢复
清理完 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（尤其 Rocky/AlmaLinux 9 默认用 chrony）
非要对接统一 NTP 服务器怎么办
合规场景下允许 NTP 与 CTSS 共存，但前提是 NTP 只校准硬件时钟（RTC），不干预系统时钟（sysclock），否则 CTSS 会持续 fallback。
-
/etc/ntp.conf必须含：tinker stepout 0和disable kernel -
/etc/sysconfig/ntpd中OPTIONS必须为"-x"（平滑调整），严禁含-g - 绝对禁用
ntpdate—— 它强制跳变，直接踢出 CTSS - 验证方式：
ntpq -p看 offset 是否长期稳定在 ±5ms 内；ps -ef | grep ntpd确认参数里真有-x
最易被忽略的点：CTSS 的 active 状态不是“配完就来”，而是“清完才可能回来”，且必须所有节点同步清理、同步重启、同步验证。漏掉一个节点的 /etc/chrony.conf，整个集群就永远卡在 observer。
