物理备库必须用SYNC模式才能满足RPO=0要求,需配置NET_TIMEOUT=10、REOPEN=5、DELAY=0,并确保网络延迟≤5ms;启用MAXIMUM PROTECTION后备库不可用将导致主库自动shutdown。
Oracle 23ai 的 Data Guard 默认仍沿用 ASYNC 传输,但只要主库发生意外宕机,ASYNC 下未传完的 redo 就会丢失。真要实现零数据丢失(RPO=0),必须显式配置 SYNC 模式,并确认网络延迟 ≤ 5ms —— 这不是建议,是硬性前提。
常见错误是只改了 LOG_ARCHIVE_DEST_2 的 SYNC 关键字,却漏掉配套参数:NET_TIMEOUT(默认 30 秒,应设为 10)、REOPEN(建议 5)、DELAY 必须为 0。否则主库可能因等待备库响应而挂起写入。
V$DATAGUARD_CONFIG 中 PROTECTION_MODE 是否为 MAXIMUM PROTECTION
MAXIMUM PROTECTION 后,备库不可用时主库会自动 shutdown,不能靠人工干预绕过ENABLE PLUGGABLE DATABASE 选项,若主库含 PDB,备库初始化时必须同步开启该特性,否则 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 会报 ORA-65169
很多人以为配好物理备库就能立刻分担查询压力,但 Oracle 23ai 默认关闭 Active Data Guard 功能。即使备库已启动 RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE,执行 SELECT 仍会报 ORA-16000(database open for read-only access)。
必须手动执行:ALTER DATABASE OPEN READ ONLY(首次)→ 再执行 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT。顺序不能反,否则备库会退回到 MOUNT 状态。
STANDBY_MAX_DATA_DELAY 参数(单位秒),用于控制“允许的最大延迟阈值”,超过即自动暂停应用;默认为 0(禁用),需按业务容忍度显式设置V$ARCHIVED_LOG 中 APPLIED 字段可能显示 YES,但实际查询看到的是延迟 2~3 秒前的数据 —— 这是正常现象,由日志传输+应用流水线导致DBMS_STATS 不会自动同步到主库,且可能干扰物理备库的块级一致性校验主备距离超 200km 或网络抖动频繁时,直接 SYNC 会导致主库事务响应时间飙升。Oracle 23ai 要求在这种场景下引入 Far Sync 实例 —— 它不存数据,只接收并转发 redo,且必须部署在主备之间网络质量最好的第三地点。
Far Sync 实例不是可选组件,而是架构强制项。漏配会导致 Data Guard Broker 报错 ORA-16778(redo transport error),且 Broker 自动 failover 会被拒绝。
DB_UNIQUE_NAME 必须在主库的 LOG_ARCHIVE_CONFIG 中声明,格式如:'DG_CONFIG=(primary,far_sync,standby)'
SYNC,Far Sync 到备库用 ASYNC,这是唯一被 Oracle 23ai 认证的跨区域拓扑ALTER DATABASE START FAR SYNC 即可如果你在主库用了 VECTOR 类型列或创建了向量索引,这些对象不会随 redo 日志同步到物理备库。备库启动后执行 SELECT 会报 ORA-40698(vector index not found),因为向量索引是内存结构 + 本地文件存储,不参与块级复制。
目前唯一可行方案是:主库每次新增/重建向量索引后,手动在备库执行相同 DDL。没有自动化机制,也不能用 DBMS_METADATA 导出导入 —— 23ai 尚未开放向量元数据的标准化导出接口。
CREATE VECTOR INDEX,不能跳过