crsctl check ctss 显示 observer mode 是时间失控的故障确认信号，表明节点间时钟偏差可能超±500ms，将导致scn同步异常、会话状态不一致及事务逻辑错误，须立即停ntp/chrony、清配置、重启ctssd并验证私网连通性。
Oracle RAC 本身不负责“用户状态同步”，比如登录会话、密码变更、账户锁定等——这些是数据库实例级或操作系统级行为，RAC 只保证数据块和缓存一致性，不传播会话状态。所谓“用户状态同步延迟”，实际是误判，根源在底层机制错配或配置疏漏。
crsctl check ctss 显示 observer mode 就意味着时间已失控
CTSS 进入 observer 模式不是警告，是故障确认信号。此时节点间时间差很可能已超 ±500ms，而 Oracle 的 GES/GCS 心跳、SCN 推进、事务提交依赖毫秒级时序。一旦 offset 波动剧烈，会出现：
- 会话在节点 A 登录成功，但在节点 B 查询
v$session看不到（非共享视图，但更可能是 SCN 同步卡顿导致查询结果未刷新） - 密码修改后，在另一节点仍能用旧密码登录（实为审计日志或密码文件未实时刷盘，与 RAC 无关）
-
ALTER USER ... ACCOUNT LOCK执行后，部分节点仍允许连接（常见于使用外部密码文件且未同步分发）
别碰 ntpdate，也别信“只启一个节点的 ntpd”
手动执行 ntpdate 或让某节点单独跑 ntpd 而不加 -x，会导致该节点时钟跳变（jump），触发 CTSS 全局 fallback 到 observer 模式。所有节点随即失去统一时间基准，后续任何依赖时间戳的操作（如审计记录、闪回查询、ADG 日志应用）都会出现逻辑断层。
必须统一操作：
- 停所有节点的
ntpd或chronyd：运行systemctl stop ntpd chronyd - 删干净配置文件：
rm -f /etc/ntp.conf /etc/chrony.conf（mv不行，Oracle 会扫描文件是否存在） - 删 PID 文件：
rm -f /var/run/ntpd.pid /var/run/chronyd.pid - 重启 CTSS：
crsctl stop res ora.ctssd -init && crsctl start res ora.ctssd -init
ctssd 日志里出现 “Failed to communicate with reference node” 就别查用户表了
这个错误说明 CTSS 已无法跟选举出的参考节点通信，大概率是私网不通、MTU 不一致或防火墙拦截 UDP 123/3097 端口。此时查 dba_users 或 v$session 毫无意义——问题不在用户元数据，而在集群心跳链路本身。
验证步骤：
- 先跑
cluvfy comp nodecon -n all -verbose，确认私网连通性与 MTU 一致 - 检查
/proc/sys/net/ipv4/ip_forward是否为 0（私网必须关转发） - 抓包看 CTSS 流量：
tcpdump -i <private_if> udp port 3097 -w ctss.pcap</private_if>，确认有双向通信 - 查
$GRID_HOME/log/`hostname`/ctssd/ctssd.log中最近 10 行是否含Switching to observer mode
真正影响“用户状态可见性”的，从来不是 RAC 多实例架构，而是时间不同步引发的 SCN 偏移、日志传输中断或 ASM 实例挂起。修复永远从 crsctl check ctss 开始，而不是翻用户表或重跑 DBMS_METADATA。只要 offset 不稳定在 ±10ms 内，其他所有排查都是在掩盖症状。
