oracle data guard配置需主库开启归档和force logging，rman克隆须跳过控制文件并单独生成密码文件，主备db_unique_name与log_archive_config须双向配对，备库启动日志应用前需确保主库已传日志且网络解析正常。
主库必须开归档且 force logging，否则 dg 同步直接失败
oracle data guard 依赖归档日志传输，主库没开归档，备库连日志都收不到；更隐蔽的是，即使开了归档，如果没开 force logging，部分 dml（比如 nologging 操作、直接路径插入）产生的变更不会写入重做流，导致备库数据块不一致甚至应用中断。
实操建议：
- 检查归档状态：
ARCHIVE LOG LIST，确认为Database log mode: Archive Mode - 开启强制记录：
ALTER DATABASE FORCE LOGGING;（需在MOUNT状态下执行） - 验证是否生效：
SELECT FORCE_LOGGING FROM V$DATABASE;返回YES才算到位 - 注意：开启后会对高并发
INSERT /*+ APPEND */类操作有轻微性能影响，但这是 DG 数据一致性的底线
RMAN DUPLICATE TARGET DATABASE FOR STANDBY 要绕过控制文件和密码文件
用 RMAN 克隆备库时，DUPLICATE ... FOR STANDBY 默认会尝试复制主库的控制文件——这在物理 DG 场景下是错的：备库必须用自己的控制文件（空的或从备份还原），否则启动时报 ORA-01102: cannot mount database in EXCLUSIVE mode 或日志序列混乱。
实操建议：
- 务必加
FROM ACTIVE DATABASE或指定主库备份，同时显式跳过控制文件：NOFILENAMECHECK+ 手动映射DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT - 密码文件不能直接复制，必须在备库单独生成：
ORAPWD FILE=$ORACLE_HOME/dbs/orapw$ORACLE_SID PASSWORD=xxx ENTRIES=10 - 如果主库用 Oracle Wallet，备库也要单独配置，RMAN 不传 wallet 文件
- 常见报错：
RMAN-05501: aborting duplication of target database，大概率是控制文件路径冲突或密码文件缺失
备库参数文件里 DB_UNIQUE_NAME 和 LOG_ARCHIVE_CONFIG 必须双向配对
物理 DG 不是“主→备”单向配置，而是靠 LOG_ARCHIVE_CONFIG 声明双方身份，再靠 DB_UNIQUE_NAME 区分实例。漏掉任一端，日志传输就卡住，V$ARCHIVE_DEST_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)'（值完全一样！不是只写自己） -
LOG_ARCHIVE_DEST_1在备库要指向本地归档路径，且VALID_FOR=(ALL_LOGFILES,STANDBY_ROLE)，否则切换角色后归档失效 - 改完参数必须重启数据库（不是只 reload），否则
ALTER SYSTEM SET对 DG 参数无效
STARTUP MOUNT + ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT 那一步最易卡住
备库启动后，必须先 MOUNT，再启动日志应用。但很多人输完命令没反应，查 V$MANAGED_STANDBY 发现 PROCESS 是 MRP0 但 STATUS 是 WAIT_FOR_LOG，其实是主库还没开始传日志，或者网络/tnsnames.ora 里的 standby 服务名解析失败。
实操建议：
- 先在主库手动切一次日志：
ALTER SYSTEM SWITCH LOGFILE;，触发首次传输 - 立刻在备库查：
SELECT STATUS, TYPE, PROCESS, THREAD#, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY;，确认MRP0的SEQUENCE#在递增 - 如果一直
WAIT_FOR_LOG，立刻检查主库V$ARCHIVE_DEST_STATUS中DEST_ID=2的STATUS和ERROR列 - 别忘了监听器：备库的
listener.ora要有静态注册，否则主库连接SERVICE=standby会超时
真正麻烦的从来不是命令敲不对，而是主备之间那几处看似无关的配置项——比如一个没配的 LOG_ARCHIVE_CONFIG，能让整个 DG 卡在“已启动但无日志”状态几个小时，还查不出错在哪。
