如何搭建Oracle23ai Data Guard容灾方案？-Oracle-PHP中文网

oracle 23ai的data guard搭建本质与19c一致，但需特别注意：默认启用unified audit和automatic indexing影响归档体积；dbca虽默认开启force logging和归档模式，但仅限本地，跨库传输仍需手动配置log_archive_dest_n；必须验证v$database中log_mode为archivelog、force_logging为yes；监听须静态注册；rman建备库强制使用restore from service；log_archive_dest_2必须显式配置valid_for、lgwr、sync/async及affirm；需禁用auto_incremental backup以防mrp阻塞；db_unique_name须全局唯一且区分大小写，网络配置须完全一致。

如何搭建oracle23ai data guard容灾方案？

Oracle 23ai 的 Data Guard 搭建和传统版本（如19c）本质一致，但必须注意：23ai 默认启用 Unified Audit、Automatic Indexing 等新特性，这些会直接影响归档日志体积与传输延迟；且 DBCA 在 23ai 中默认创建的数据库已启用 FORCE LOGGING 和归档模式，但仅限本地归档——跨库传输仍需手动配置 log_archive_dest_n。

确认主库是否满足 DG 基础前提

别跳过这步。23ai 安装后看似“开箱即用”，但实际常因以下原因导致后续 RMAN 备份失败或日志无法传输：

ARCHIVE LOG LIST 显示 Database log mode: No Archive Mode —— 即使 DBCA 声称启用了归档，也可能因 spfile 中缺少 log_archive_start=true（23ai 已弃用该参数，但旧脚本残留会影响判断）；正确检查方式是执行 SELECT log_mode FROM v$database;，结果必须为 ARCHIVELOG
FORCE LOGGING 状态未真正生效：运行 SELECT force_logging FROM v$database;，返回 YES 才可靠；若为 NO，需执行 ALTER DATABASE FORCE LOGGING; 并等待当前事务结束（否则报错 ORA-01153）
主库监听未配置静态注册：备库 RMAN 连接时依赖 tnsnames.ora 中的服务名解析，而 23ai 默认使用动态注册（local_listener），若网络延迟高或监听重启，RMAN 可能报 ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

RMAN 创建物理备库必须用 `RESTORE FROM SERVICE`

这是 Oracle MAA（Maximum Availability Architecture）在 23ai 中的强制推荐方式，比传统“备份 → 传输 → 恢复”更可靠，尤其规避了 OMF（Oracle Managed Files）路径不一致问题：

oracle知识库

oracle知识库下载

下载

主库上执行：RMAN TARGET / AUXILIARY sys/password@standby_db CONNECT TARGET / CONNECT AUXILIARY sys/password@standby_db RESTORE STANDBY FROM SERVICE primary_db; —— 注意 primary_db 是主库在备库 tnsnames.ora 中定义的服务名，不是 SID
该命令自动处理控制文件重建、SRL（Standby Redo Log）创建、db_file_name_convert 和 log_file_name_convert 参数推导；若手动指定转换规则，23ai 要求路径末尾带斜杠（/u01/oradata/primary/），否则报 ORA-19802
执行后立即验证备库状态：SELECT open_mode, database_role FROM v$database; 应返回 MOUNTED 和 PHYSICAL STANDBY；若为 READ ONLY，说明误启用了 Active Data Guard 但未配置实时应用

`log_archive_dest_2` 配置必须显式启用 SYNC 或 ASYNC

23ai 默认不启用任何远程归档目标，即使你写了 log_archive_dest_2，若没加 VALID_FOR 和传输模式，日志只写本地磁盘，不发往备库：

正确示例：ALTER SYSTEM SET log_archive_dest_2='SERVICE=standby_db VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db LGWR SYNC AFFIRM' SCOPE=BOTH;
LGWR 必须指定（23ai 不再支持 ARCH 传输模式用于物理备库）；AFFIRM 表示主库等待备库写入 SRL 后才提交，是 MAXIMUM PROTECTION 模式必需项
常见错误：漏掉 VALID_FOR —— 导致主库切换角色后该 dest 仍尝试发送，报 ORA-16057: DGID not set；或误用 ASYNC 却配了 AFFIRM，引发 ORA-16714
验证传输是否就绪：SELECT status, error FROM v$archive_dest WHERE dest_id = 2; 返回 VALID 且 error 为空才表示通路正常

启动日志应用前必须关闭 `AUTO_INCREMENTAL BACKUP`

23ai 默认开启的增量备份策略会干扰 MRP（Managed Recovery Process）进程对归档日志的连续读取，表现为备库日志应用停滞、v$managed_standby 中 STATE 长期为 WAIT_FOR_LOG：

在备库 MOUNT 状态下执行：ALTER SYSTEM SET backup_tape_io_slaves=0 SCOPE=BOTH;（禁用磁带相关后台进程）
停用自动备份：EXEC DBMS_SCHEDULER.DISABLE('MAINTENANCE_WINDOW_GROUP'); —— 23ai 的维护窗口会触发 BACKUP DATABASE PLUS ARCHIVELOG，与 MRP 争抢归档日志句柄
然后启动应用：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
验证是否生效：SELECT process, status, sequence# FROM v$managed_standby WHERE process = 'MRP0';，status 应为 APPLYING_LOG，sequence# 持续递增

最易被忽略的是：23ai 中 DB_UNIQUE_NAME 必须全局唯一且区分大小写，主备库若仅靠 SID 区分（如都叫 orcl），DG Broker 会拒绝注册，报 DGM-17016；另外，所有网络配置（包括防火墙、SELinux、sqlnet.ora 中的 SQLNET.ENCRYPTION_SERVER）必须完全一致，否则 LNS 进程连接超时后静默失败，日志里只留一行 WARNING: Failed to connect to destination，无具体错误码。