主库必须启用FORCE LOGGING和ARCHIVELOG模式，否则DUPLICATE或BACKUP FOR STANDBY失败且备库无法应用日志；需验证log_mode和force_logging均为YES，并正确配置LGWR SYNC传输、Standby Redo Log及FAL参数。
主库必须先满足 FORCE LOGGING + ARCHIVELOG 模式
不满足这两项，DUPLICATE 或 BACKUP FOR STANDBY 都会失败，且备库后续无法应用日志。常见错误是只开了归档但没开强制日志：ORA-16664: unable to receive the result from a database 或同步卡在 APPLYING_LOG 但实际无日志流入。
验证命令必须都返回 YES：
SELECT log_mode, force_logging FROM v$database;-
ARCHIVE LOG LIST确认Automatic archival Enabled
若未启用，顺序执行（需 MOUNT 状态）：
SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE FORCE LOGGING; ALTER DATABASE OPEN;
使用 RMAN DUPLICATE FROM ACTIVE DATABASE 创建物理备库
这是最常用、最稳妥的在线创建方式，无需提前备份，主库持续提供服务。但要求主备网络通畅、TNS 配置正确、密码文件一致。
关键前提：
- 主库和备库
db_name相同，db_unique_name不同（如orcl_primary/orcl_standby） - 备库已安装相同版本 Oracle 软件，但**不建库**，仅配置监听和
tnsnames.ora - 主库密码文件（
orapw<sid>）必须复制到备库同路径，并确保SYS口令完全一致 - 备库
listener.ora中需注册服务名<db_unique_name>_DGMGRL（DG Broker 场景下必需，非 Broker 可省略）
典型 RMAN 命令（在备库主机执行）：
RMAN TARGET sys/oracle@orcl_primary AUXILIARY /
DUPLICATE TARGET DATABASE FOR STANDBY
FROM ACTIVE DATABASE
NOFILENAMECHECK
DB_FILE_NAME_CONVERT '/u01/oradata/orcl/','/u01/oradata/orcl/'
LOGFILE
GROUP 1 ('/u01/oradata/orcl/standby_redo01.log') SIZE 200M,
GROUP 2 ('/u01/oradata/orcl/standby_redo02.log') SIZE 200M;注意：NOFILENAMECHECK 仅适用于主备目录结构完全一致；若路径不同，必须用 DB_FILE_NAME_CONVERT 映射，否则报 ORA-19505。
备库启动后必须立即添加 Standby Redo Log
没加 SRL，备库能启动，但日志传输会成功、应用会静默失败——v$managed_standby 显示 MRP0 进程存在，但 STATUS 为 WAIT_FOR_LOG，且 v$archive_dest_status 中 STATUS 是 VALID，但 ERROR 字段为空，极易误判。
添加原则严格匹配主库 Online Redo Log：
- 大小必须一致（查主库：
SELECT bytes FROM v$log;） - 组数 = 主库在线日志组数 + 1（单实例）；RAC 则按线程计算
- 路径建议独立于 Online Redo，避免 I/O 冲突
示例（主库 3 组 200MB Online Redo）：
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/u01/oradata/orcl/srl04.log' SIZE 200M; ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 '/u01/oradata/orcl/srl05.log' SIZE 200M; ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 '/u01/oradata/orcl/srl06.log' SIZE 200M; ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 '/u01/oradata/orcl/srl07.log' SIZE 200M;
验证：SELECT group#, bytes, status FROM v$standby_log; 应看到至少 4 组状态为 UNASSIGNED。
启动实时应用前，务必检查 FAL 和归档目标配置
很多备库“看似同步”，实则靠主库归档日志拉取（ARCH 传输），而非实时接收（LGWR SYNC）。这会导致延迟不可控，且切换时丢失未传日志。
主库参数必须显式启用 LGWR 传输：
-
LOG_ARCHIVE_DEST_2='SERVICE=orcl_standby LGWR SYNC AFFIRM'（AFFIRM表示主库等待备库写入 SRL 后才提交） LOG_ARCHIVE_DEST_STATE_2=ENABLE-
FAL_SERVER='orcl_standby'和FAL_CLIENT='orcl_primary'（用于断点续传缺失日志）
备库启动 MRP 后，确认日志流是实时的：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
然后查：SELECT process, status, sequence#, block# FROM v$managed_standby; 若 PROCESS = 'RFS' 的 STATUS 是 IDLE，且 MRP0 的 SEQUENCE# 与主库 v$archived_log 最新序号差 ≤ 1，才算真正实时。
最容易被忽略的是：主库 LOG_ARCHIVE_CONFIG 必须包含两个 DB_UNIQUE_NAME，否则 SERVICE=xxx 解析失败，LGWR 传输直接退化为 ARCH 模式。
