oracle 11g 原生不支持真正意义上的同城双活，因其data guard仅支持单主多备的单写架构，物理/逻辑备库均不可安全写入；可落地的是“同城高可用（物理备库）+异地容灾（逻辑备库）”三层单向同步架构。
Oracle 11g 原生不支持真正意义上的“同城双活”。所谓双活（即两个数据中心同时对外提供读写服务、数据强一致、故障零切换延迟），在 11g 中无法由 Data Guard 单独实现——它只支持一主多备的单写架构，备用库默认不可写，即使启用 Active Data Guard（需额外许可），也仅限只读查询，不能接受 DML。
但你可以用 Data Guard 搭建「同城高可用 + 异地容灾」的混合架构，这是 11g 生产环境中最现实、最稳妥的落地方式。
为什么不能在 11g 上做同城双活
根本限制来自 Data Guard 的日志应用机制：REDO Apply（物理备库）和 SQL Apply（逻辑备库）都依赖主库生成的重做流，且不允许反向同步。一旦两个库同时开放写入，必然产生冲突、分裂脑或数据覆盖，Oracle 不提供内置冲突检测与自动合并能力。
常见误操作包括：
- 手动在物理备库上
ALTER DATABASE OPEN READ WRITE→ 立即脱离 DG 管理，变成独立数据库，后续无法自动恢复同步 - 用逻辑备库接收主库变更，又反向写入主库 → 触发循环日志、ORA-16664 或 ORA-16826 错误
- 依赖 Broker 配置
Enable Fast-Start Failover后误以为能双向切换 → FSO 仍是单向主→备故障转移，不等于双活
11g 下可落地的同城+异地三层架构设计
典型拓扑是「A地主库 → A地同城物理备库（实时同步）→ B地异地逻辑备库（异步）」，三者角色固定、路径单向，符合 11g 能力边界：
-
Primary（A地生产中心）：承担全部读写，归档日志实时传输至同城备库；开启ARCHIVELOG和FORCE LOGGING -
Physical Standby（A地同城灾备中心，≤200km）：使用REDO APPLY实时应用日志，可配置为READ ONLY分担报表压力（需Active Data Guard许可） -
Logical Standby（B地异地灾备中心，>200km）：用SQL Apply将归档日志转换为 DML 重放，支持结构差异（如多建索引、加列），但要求主备表结构兼容，且不支持某些数据类型（如LONG、BFILE）
注意：Logical Standby 不能直接替代 Physical Standby 做同城高可用，因为 SQL Apply 有延迟、不保证块级一致性，也不支持快速启动故障切换（FSFO）。
Data Guard Broker 配置要点与易错项
用 DGMGRL 管理多节点比纯 SQL*Plus 更可靠，但几个参数极易配错：
-
LogXptMode必须匹配网络质量：同城用SYNC（最大可用模式），异地必须设为ASYNC，否则主库事务会因等待异地 ACK 而卡住 -
ProtectionMode在 11g 中只有三种可选：MAXIMUM PROTECTION（需至少一个 SYNC 备库在线）、MAXIMUM AVAILABILITY（推荐同城场景）、MAXIMUM PERFORMANCE（异地默认）；切勿在未配 SYNC 备库时强行设为前两者，否则START OBSERVER会失败 -
FastStartFailoverThreshold默认 30 秒，但在千兆专线同城环境下建议调低至 10–15 秒，避免因瞬时网络抖动触发误切换 - 所有节点的
DB_UNIQUE_NAME必须全局唯一且在tnsnames.ora中正确定义，Broker 才能识别角色关系；拼写错误会导致DGMGRL> SHOW CONFIGURATION显示ORA-16532
异地逻辑备库的初始化与日常维护陷阱
逻辑备库不是简单拷贝物理文件就能启动，必须从主库导出逻辑结构快照：
- 主库执行
DBMS_LOGSTDBY.BUILD→ 触发全量元数据捕获，否则ALTER DATABASE START LOGICAL STANDBY APPLY会报 ORA-16117 - 逻辑备库上禁止对被复制的表执行 DDL（如
ALTER TABLE ... ADD COLUMN），除非先停SQL Apply、执行 DDL、再用DBMS_LOGSTDBY.SKIP注册跳过该对象后续 DML - 监控
V$LOGSTDBY_PROGRESS中的APPLIED_SCN和NEWEST_SCN差值，若持续增长说明 SQL Apply 积压，常见于大事务（如批量 INSERT）或索引缺失导致 DML 执行慢 - 逻辑备库无法使用 RMAN 直接备份，必须通过
EXPDP导出或在主库侧做备份后还原到逻辑备库（需重建日志应用）
Data Guard 在 11g 中的价值不在“活”，而在“稳”——它不承诺双写并发，但能确保你在主库宕机后 30 秒内切出可用库，且异地副本在断网数小时后仍可追平数据。真正需要双活的业务，要么升级到 19c+ 使用 Shard 或 GoldenGate 构建应用层分流，要么接受 11g 的能力边界，把架构重心放在快速故障识别、切换流程固化和应用无感重连上。
