必须开启FORCE LOGGING，否则直接路径插入等操作产生的变更可能不写redo，导致RMAN复制漏块、备库启动报ORA-01110或应用中断；执行ALTER DATABASE FORCE LOGGING前需处于MOUNT状态，且SELECT FORCE_LOGGING FROM V$DATABASE须返回YES。
直接用 rman duplicate from active database 是 oracle 19c 物理备库最省事的构建方式——不用备份集、不拷文件、不手动还原控制文件，主备库网络直连，rman 自动拉数据、建 standby 控制文件、恢复归档、启动 mrp，一气呵成。
为什么必须开 FORCE LOGGING 才能用 Active Duplication
Active Duplication 依赖主库实时读取数据块和重做流。如果没开 FORCE LOGGING，像 INSERT /*+ APPEND */、CREATE TABLE AS SELECT 这类操作产生的变更可能不写 redo，RMAN 复制时就漏掉块，导致备库启动后报 ORA-01110 或应用中断。
- 检查是否生效：
SELECT FORCE_LOGGING FROM V$DATABASE;必须返回YES - 开启命令需在
MOUNT状态下执行：ALTER DATABASE FORCE LOGGING; - 开启后对高并发直接路径插入有轻微性能影响，但这是物理 DG 数据一致性的硬门槛，不能跳过
RMAN DUPLICATE FOR STANDBY 的关键参数避坑点
DUPLICATE TARGET DATABASE FOR STANDBY 默认会尝试复制主库控制文件，而物理备库必须用自己的空控制文件（或从备份还原），否则启动时报 ORA-01102 或日志序列错乱。
- 必须加
FROM ACTIVE DATABASE，显式跳过控制文件复制逻辑 - 必须指定
NOFILENAMECHECK，否则 RMAN 检查到主备路径相同会拒绝执行 - 必须配置
DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT，否则数据文件路径冲突（尤其当主备目录结构不完全一致时） - 密码文件不能复用：备库要单独用
ORAPWD生成，例如orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=xxx entries=10
备库参数里 DB_UNIQUE_NAME 和 LOG_ARCHIVE_CONFIG 必须双向对齐
物理 DG 不是单向“主→备”，而是靠这两个参数建立双向身份识别。漏配或值不一致，V$ARCHIVE_DEST_STATUS 里 STATUS 就是 ERROR 或 DEFERRED，日志根本传不过去。
- 主库
init.ora至少含：DB_UNIQUE_NAME=prod、LOG_ARCHIVE_CONFIG='DG_CONFIG=(prod,standby)'、LOG_ARCHIVE_DEST_2='SERVICE=standby ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby' - 备库对应设为：
DB_UNIQUE_NAME=standby、LOG_ARCHIVE_CONFIG='DG_CONFIG=(prod,standby)'（注意：值必须和主库完全一样，不是只写自己） - 别忘了
STANDBY_FILE_MANAGEMENT=AUTO，否则新增表空间不会自动同步
Active Duplication 后必须验证的三件事
命令跑完不等于 DG 就通了。很多环境卡在监听、网络解析或 SRL 缺失上，等真切换才发现问题。
- 确认主备
tnsnames.ora都能tnsping通对方服务名，且lsnrctl status显示静态注册已生效 - 检查备库是否有 standby redo log：
SELECT GROUP#, SEQUENCE#, STATUS FROM V$STANDBY_LOG;—— 没 SRL 会导致最大保护模式无法启用，且角色切换后可能丢日志 - 启动日志应用前先查：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;确保MRP0进程存在且STATUS = APPLYING_LOG
最容易被忽略的是：Active Duplication 虽快，但它不自动创建 standby redo log，也不校验监听是否真正注册成功；这些都得人工补全，否则后续切换或故障演练必踩坑。
