RMAN DUPLICATE FROM ACTIVE DATABASE 能直接从运行中的主库拉取数据建备库，但80%失败源于环境未配齐：主库必须启用ARCHIVELOG和FORCE LOGGING（缺一不可），辅助实例须启动至NOMOUNT且密码文件严格同步，命令中FOR STANDBY和NOREDO不可省略，路径转换参数及STANDBY_FILE_MANAGEMENT=AUTO也必须显式配置。
RMAN DUPLICATE FROM ACTIVE DATABASE 能直接从运行中的主库拉数据建备库，但80%失败不在复制过程，而在环境没配齐——主库缺FORCE LOGGING、辅助实例没启到NOMOUNT、密码文件不同步，三者任一缺失都会卡在第一步。
主库必须开 ARCHIVELOG 和 FORCE LOGGING
只开归档不够，FORCE LOGGING是Data Guard日志应用一致性的硬门槛。不启用会导致备库后续报ORA-01113: file 1 needs media recovery或ALTER DATABASE RECOVER MANAGED STANDBY DATABASE挂住。
- 检查命令：
SELECT log_mode, force_logging FROM v$database—— 必须同时返回ARCHIVELOG和YES - 若未开归档：先
SHUTDOWN IMMEDIATE→STARTUP MOUNT→ALTER DATABASE ARCHIVELOG→ALTER DATABASE OPEN - 若未开强制日志：同样需
STARTUP MOUNT后执行ALTER DATABASE FORCE LOGGING（无需重启OPEN） - 注意：
FORCE LOGGING会略增REDO量，但OLTP场景影响可忽略，不可跳过
辅助实例必须 NOMOUNT 启动且密码文件严格一致
辅助实例不是“备库”，只是一个空壳进程，只靠参数文件和密码文件启动。RMAN连接时用SYS身份，密码错或文件权限不对，立刻报RMAN-06403: could not obtain a fully authorized session。
- 辅助实例的
DB_NAME可与主库相同，但DB_UNIQUE_NAME必须不同（如主库prod，备库设为prod_stby） - 密码文件必须用
orapwd重建，且entries≥2（RMAN内部并发连接需要） - Windows下建议先删掉旧
orapwxxx再生成，避免文件锁导致覆盖失败 - 启动命令必须是
startup nomount；挂载控制文件或startup mount会直接失败
RMAN DUPLICATE 命令里 FOR STANDBY 和 NOREDO 不可省略
漏掉FOR STANDBY会建出非Data Guard兼容结构；漏掉NOREDO会让RMAN尝试传online redo log——而主库正在写，这些日志随时被覆盖，必然失败。
-
FOR STANDBY：明确目标是物理备库，影响控制文件结构和后续MRP进程识别 -
FROM ACTIVE DATABASE：启用在线块拉取，跳过备份环节 -
NOFILENAMECHECK：主备路径不同时必须加，否则RMAN检测到同名文件直接退出 -
NOREDO：最关键的坑点——它告诉RMAN只传归档日志，online redo log不传，后续由MRP进程持续应用
路径转换和初始化参数必须显式设置
即使主备目录结构一模一样，Oracle 11g+也要求显式声明DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT，否则控制文件创建失败或数据文件重命名出错，报ORA-01511。
- 推荐在
DUPLICATE命令中用SET子句指定，比如：SET DB_FILE_NAME_CONVERT '/u01/oradata/ORCL/', '/u02/oradata/STBY/' -
STANDBY_FILE_MANAGEMENT=AUTO必须在备库SPFILE中设置，否则新增数据文件不会自动同步 - 如果主库用RAC，备库是单机，还需在备库参数中去掉
cluster_interconnects（若主库pfile里有） -
compatible参数值不能低于主库，建议保持一致（如主库是11.2.0.4，备库SPFILE也设为该值）
最容易被忽略的是STANDBY_FILE_MANAGEMENT=AUTO和DB_UNIQUE_NAME的唯一性——前者不设，备库加表空间后主库DML无法同步；后者重复，DG Broker根本无法识别备库角色。
