必须先确认ctss是否退为observer模式；若是，需彻底清理所有节点的chrony/ntp配置及服务，启用makestep和rtcsync等关键参数，重启chronyd并验证offset≤500ms且各节点差值达标。
crsctl check ctss 返回 observer mode 怎么办
这是必须先确认的状态。只要看到 CTSS is in observer mode，说明 Oracle 已放弃时间同步权，正“旁观”外部服务——但此时 chronyd 很可能没配对、没生效，或只在部分节点运行。
立刻执行：crsctl check ctss，再在所有节点并行运行：date -u +%s.%N 取三次平均值，算出最大偏差。超过 ±500ms 就已触发 CRS-4639 风险；超 1s 可能导致实例无法启动。
常见误操作：
- 只停
chronyd服务，却没删/etc/chrony.conf——Oracle 认为“配置存在 = NTP 启用”，CTSS 就不会切回 active - 漏掉某节点的
/etc/chrony.conf或残留/etc/ntp.conf——集群中任一节点有任一配置文件，CTSS 全体退为 observer - 用
mv /etc/chrony.conf /etc/chrony.conf.bak代替rm -f /etc/chrony.conf——Oracle 不认重命名，只认文件是否存在
chrony.conf 必须启用的 RAC 关键参数
默认配置完全不满足 RAC 要求：不做阶跃校正、不写 RTC、同步间隔太松散，会导致重启后时间倒退或偏移长期超标。
编辑 /etc/chrony.conf（所有节点严格一致），确保包含以下最小安全集：
server 192.168.10.1 iburst minpoll 4 maxpoll 6 driftfile /var/lib/chrony/drift makestep 1.0 3 rtcsync logdir /var/log/chrony log measurements statistics tracking
关键点说明：
-
iburst：首次连接时发 8 个包，加速收敛初始偏移 -
minpoll 4 maxpoll 6：同步间隔缩至 16s–64s（默认是 64s–1024s），更敏感响应 drift -
makestep 1.0 3：允许开机后前 3 秒内做 ≤1s 的阶跃校正，避免缓慢 slewing 拖太久 -
rtcsync：强制内核每 11 分钟把系统时间写入硬件时钟，防止重启后时间大幅倒退
验证 chronyd 是否真正生效
重启 systemctl restart chronyd 后，不能只看服务状态。必须三步验证：
- 运行
chronyc tracking，检查Offset是否稳定在 ±500ms 内（理想是 ±10ms）；Root delay和Root dispersion应明显小于 100ms - 运行
chronyc sources -v，确认状态列出现^*（优选源），且 IP 是你配置的 NTP 服务器 - 所有节点并行执行：
date; chronyc tracking | grep -E "(Offset|System time)"，横向比对 offset 值，差值必须 ≤500ms
若仍不稳，立即查防火墙：firewall-cmd --list-ports 确保 UDP 123 开放；chronyc activity 看是否提示 No activity（说明根本连不上上游）。
CTSS 和 chronyd 能不能共存
能，但条件苛刻：chronyd 只能校准硬件时钟（靠 rtcsync），绝不能干预系统时钟（即不能用 makestep 对运行中系统做 step）。否则 CTSS 会再次 fallback 到 observer。
实际运维中，绝大多数 RAC 环境应二选一：
- 纯 CTSS 模式：删光
/etc/chrony.conf和/etc/ntp.conf，停并禁用chronyd，重启ora.ctssd，让 CTSS 进入Active mode（offset 通常稳定在 ±10ms） - 纯 chronyd 模式：确保所有节点配置完全一致、
makestep和rtcsync启用、上游 NTP 可靠，且 CTSS 保持 observer（这时它不干活，只监控）
混用失败的主因，从来不是参数写错，而是某个节点少删了一个配置文件，或 cron 里偷偷跑了 ntpdate ——CTSS 对“外部干预”极其敏感，一点异常就弃权。
