oracle data guard 不支持双向同步，因其物理备库强制只读、逻辑备库开启读写即脱离同步链路，且归档配置不支持循环指向；真正可行的双向同步方案只有goldengate。
oracle data guard 本身不支持真正的双向同步；所谓“dg双向同步”，实际是用两个独立的 dg 配置（主→备a、主→备b）拼出逻辑双活，或退而求其次用 goldengate 实现跨库 dml 双向复制。强行在 dg 中配置双向日志传输会导致归档冲突、ora-16664 / ora-10873 等错误，且 oracle 官方明确不支持同一数据库同时作为主库和物理备库运行。
为什么 DG 不能做双向同步
DG 的物理备库只允许应用重做（apply），不允许写入；逻辑备库虽可读写，但一旦打开（ALTER DATABASE OPEN RESETLOGS），就脱离 DG 同步链路，无法再接收主库新重做——这是架构级限制，不是参数能绕过的。
- 物理备库强制只读，
v$database.open_mode永远是MOUNTED或READ ONLY WITH APPLY，没有READ WRITE选项 - 逻辑备库开启读写后，
ALTER DATABASE START LOGICAL STANDBY APPLY会失败，因为重做流与本地修改冲突 -
LOG_ARCHIVE_DEST_n不支持循环指向：主库设SERVICE=standby，备库再设SERVICE=primary，启动时会报ORA-16664: unable to receive the result from another database
真正可行的双活方案只有 GoldenGate
GoldenGate 是 Oracle 官方唯一支持双向同步的企业级工具，它在源端捕获 DML（通过 ADD TRANDATA 启用补充日志），在目标端回放，不依赖重做流，也不要求数据库角色固定。
- 必须两端都启用附加日志：
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS，否则 UPDATE/DELETE 无法识别行标识 - OGG 用户需有
SELECT ANY TRANSACTION和FLASHBACK ANY TABLE权限，否则 extract 进程启动失败 - 双向冲突需靠
MAP ... COLMAP+RESOLVE CONFLICT规则处理，例如用时间戳或序列号判断最后写入者 - 网络延迟高时，
replicat进程容易卡在WAITING FOR TXN，需调大TRANLOGOPTIONS中的MAXTRANSOPS和READTRANSACTIONS
常见误操作：把 DG 和 GoldenGate 混搭导致归档堆积
有人试图在 DG 备库上直接装 OGG，让 extract 从备库的归档读取——这会破坏 DG 的 ARCHIVE_LAG_TARGET 控制，且 OGG 无法解析物理备库的归档格式（它只认逻辑日志或在线重做日志）。
- OGG extract 必须连主库（或逻辑备库），不能连物理备库；物理备库的归档是二进制块，OGG 解析不了
- 若主库已配 DG，OGG extract 应使用
EXTTRAIL写本地队列，而非直连备库监听器 -
log_archive_dest_2若同时指向 DG 备库和 OGG 目标端，归档会因任一目标不可达而卡住，必须拆成两个独立DEST - 验证方式：在主库执行
INSERT INTO t1 VALUES (1); COMMIT;后，立刻查备库t1表——DG 同步延迟秒级，OGG 双向延迟通常在 100ms~2s，超时即配置失效
双活的本质是业务层分流+数据层冲突消解，不是数据库自动对齐。哪怕用了 GoldenGate，也要在应用侧控制写入路由（比如按用户 ID 哈希分片），否则冲突规则再完善也扛不住高频同键更新。
