Oracle 11g如何确保Data Guard最大可用性_配置SYC传输模式与断档策略

最大可用性模式需LGWR+SYNC+AFFIRM严格协同并配置NET_TIMEOUT：LGWR确保实时同步写入备库SRL，SYNC等待网络响应、AFFIRM强制刷盘，缺一不可；NET_TIMEOUT防止单点故障导致主库挂起，超时自动降级为异步；备库SRL数量与大小须≥主库Online Redo Log。 最大可用性模式（maximum availability）在oracle11g data guard 中不是“开个开关就生效”的配置，它依赖 lgwr + sync + affirm 三者严格协同，且必须配合才能真正兼顾数据不丢和主库不断。 LGWR 进程必须启用，不能用 ARCH 最大可用性要求重做日志实时、同步地传到备库的 （SRL），这只有 进程能做到。如果误配成 （归档进程传输），哪怕写了 ，实际也是异步归档触发，无法满足“提交前写入 SRL”的硬性条件。 检查方法： 确认输出中包含 ，而不是 或类似组合。 常见错误现象： 主库事务提交明显变慢，但备库 显示有归档， 却看不到 连接或 写 SRL 的记录 切换时提示 ，本质是最后一批重做根本没传过去 SYNC + AFFIRM 缺一不可 控制传输方式（等待网络响应）， 控制落盘行为（强制写入 SRL 并刷盘）。二者必须同时启用，否则 Oracle 不认为该路径满足最大可用性要求。 典型正确配置项： 容易踩的坑： 只写 忘了 ：备库 RFS 收到日志后仅写入文件系统缓存，断电即丢，主库仍会提交 → 实际退化为最高性能模式 写了 但备库没建 ：RFS 无法写入 SRL，直接报错 ，主库挂起或降级为异步 配错（比如写成 ）：主库启动时不加载该 dest，整个保护链失效 NET_TIMEOUT 是防止单点故障拖垮主库的关键 最大可用性模式下，主库默认会无限等待备库响应。一旦网络抖动、备库宕机或 SRL 满，主库事务全部卡住 —— 这在生产环境是不可接受的。 必须显式设置 （单位秒），例如： oracle知识库 oracle知识库下载 下载 含义是：主库发起 LGWR 同步请求后，30 秒内未收到备库确认（包括网络超时、RFS 未写完 SRL、SRL 空间不足等），自动降级为异步传输（ ），继续提供服务。 注意点： 不是“重试次数”，超时即降级，不会重试 降级后，主库 中该 dest 的 变为 ， 变为 ；需人工干预恢复（如 ） 降级期间产生的事务，若未传到备库，在后续 Switchover 时必然丢失 —— 所以要监控 和告警日志中的 记录 备库 SRL 数量与大小必须 ≥ 主库 Online Redo Log 这是最容易被忽略的底层约束。LGWR SYNC AFFIRM 要求每组在线日志（ ）都必须有对应的一组 SRL 接收并持久化。否则 RFS 无处可写，主库立即报错或降级。 检查命令： 确保结果行数 ≥ 行数，且单组大小 ≥ 对应 online redo log 组。 常见问题： 建备库时只按默认模板建了 3 组 SRL，但主库因高并发已扩到 6 组 online redo log → 第 4 组切换时 RFS 报 ，主库卡住 SRL 大小设为 50MB，而主库 online redo log 是 200MB → RFS 写满即停，后续日志无法接收，主库持续超时降级 补救操作必须在备库 MOUNT 状态下执行： ，不能 ONLINE 添加。