Oracle 11g Data Guard 时间同步必须用 chronyd 平滑校准，禁用 ntpdate 阶跃调整；主备需共用内网 NTP 源，配置 iburst、minpoll/maxpoll、makestep 1.0 3、rtcsync 且禁用 local stratum；克隆虚拟机须清 drift 文件并重设 RTC。
oracle 11g data guard 同步异常若由系统时间不一致引发，根本原因不是 dg 自身逻辑出错，而是底层归档日志校验、scn 推进、心跳检测等机制严重依赖时间一致性；时间偏差超 500ms 就可能触发 ora-00353、ora-00355 或备库 media recovery 卡住。必须优先修复主机时间，而非调 dg 参数。
为什么不能只用 ntpdate 临时校准
在 Data Guard 环境中，直接执行 ntpdate 是危险操作：它会强制阶跃（step）调整时间，导致 Oracle 实例内部 SCN 时间戳与 OS 时间脱节，引发归档日志序列混乱或 redo 应用中断。更严重的是，如果主备节点分别执行 ntpdate 且未同步操作窗口，极易造成时间差瞬间放大，触发 CRS-4639（RAC 场景）或 DG broker 拒绝切换。
正确做法是启用持续、平滑的 NTP/chrony 服务，并确保主备节点使用同一时间源、相同配置策略：
-
ntpd在 Oracle 11g RAC 或 DG 中已不推荐，因其默认不启用makestep且无法防止重启后时间倒退 - CentOS 7+/Oracle Linux 7+ 必须用
chronyd，且/etc/chrony.conf中必须显式启用rtcsync和makestep 1.0 3 - 主备服务器应指向同一个内网 NTP 服务器（如
server 192.168.10.1 iburst），避免因上游源漂移不同步
chrony.conf 关键配置项必须检查
以下配置不是可选项，而是 Data Guard 稳定运行的底线要求。任意节点遗漏都会导致后续 chronyc tracking 显示 Offset 长期 >500ms：
-
iburst：首次连接时快速发起 4 次请求，缩短初始同步延迟 -
minpoll 4 maxpoll 6：将轮询间隔压到 16–64 秒，比默认（64–1024 秒）更敏感，适配 DG 高频心跳 -
makestep 1.0 3：仅允许开机后前 3 秒做 ≤1 秒阶跃校正，避免运行中突跳破坏 SCN 连续性 -
rtcsync：强制内核每 11 分钟将系统时间写入 RTC，防止服务器重启后时间大幅倒退（常见于虚拟机克隆环境） - 禁用
local stratum行：避免 chronyd 在失联时降级为本地时钟源，造成主备自说自话
验证是否真正生效，不能只看 systemctl status chronyd
服务 running ≠ 时间已同步。必须逐节点执行三步验证：
- 运行
chronyc tracking，确认System time行的Offset绝对值 Root delay - 运行
chronyc sources -v，检查输出中是否有带^*标记的源（表示当前优选源），且该源 IP 与配置一致 - 在所有节点上同时执行
date; chronyc tracking | grep -E "(Offset|System time)"，横向比对时间差 —— 主备偏差应稳定在 ±200ms 内
若某节点 Offset 持续 >1s，先查 chronyc makestep 是否被拒绝（说明已过开机前 3 秒窗口），此时需临时停 chronyd，用 sudo chronyd -q 'makestep 1.0 -1' 强制校准一次，再启服务。
虚拟机环境下特别注意克隆导致的时间源污染
Data Guard 备库若来自克隆（尤其是测试环境复用生产备库镜像），极大概率继承原主机的 /var/lib/chrony/drift 偏移记录和 RTC 时间，导致新实例启动后时间直接偏移数分钟。这不是配置错误，而是状态残留：
- 克隆后首次启动前，必须清空
/var/lib/chrony/drift并执行hwclock --set --date="2026-05-15 07:00:00"手动设 RTC 到合理值 - 确认
/etc/chrony.conf中无local stratum 10类似行，避免 chronyd 自建伪时间源 - 检查
systemctl list-timers | grep chrony，确保没有残留的定时任务干扰（如旧脚本每 5 分钟跑一次ntpdate）
时间同步不是“配完就完”的一次性动作，而是 DG 生命周期里持续需要盯住的基础设施层 —— 它不出问题时无人察觉，一出就是 ORA-00353 这类归档损坏级故障，且恢复窗口极短。
