物理备库能跑起来的核心是三件事：主库归档必须开、网络连通性必须稳、db_unique_name和log_archive_config必须双向配对；其他步骤出错90%卡在这三处。
物理备库能跑起来，核心就三件事：主库归档必须开、网络连通性必须稳、DB_UNIQUE_NAME 和 LOG_ARCHIVE_CONFIG 必须对得上。其他步骤出错，90% 都卡在这三处。
主库必须开启强制归档并验证归档路径
物理备库靠重做日志同步，主库不归档，备库就收不到任何数据。不是“开了归档模式”就行，还得确认归档日志真能写出去。
- 执行
ARCHIVE LOG LIST，确认输出中包含Database log mode: Archive Mode且Automatic archival: Enabled - 检查
LOG_ARCHIVE_DEST_1是否指向本地有效路径，比如'LOCATION=/u01/app/oracle/fast_recovery_area/ORCL/archivelog'，且该目录有 Oracle 用户写权限 - 手动切一次日志：
ALTER SYSTEM SWITCH LOGFILE;，再查SELECT NAME, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY FIRST_TIME DESC FETCH FIRST 5 ROWS ONLY;，确保有新归档生成 - 如果看到
ORA-00258: manual archiving in NOARCHIVELOG mode或归档目标状态为ERROR（查V$ARCHIVE_DEST_STATUS），说明归档没真正生效
主备库的 DB_UNIQUE_NAME 和 LOG_ARCHIVE_CONFIG 必须双向声明
这是 Data Guard 的“身份协议”，漏掉任一方向，ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 就会报 ORA-16664: unable to receive the result from a database。
- 主库和备库各自的
DB_UNIQUE_NAME必须不同，例如主库设为orcl_primary，备库设为orcl_standby；修改后需重启实例 -
LOG_ARCHIVE_CONFIG要写成'DG_CONFIG=(orcl_primary,orcl_standby)'—— 两边都得配，不能只在主库配 - 主库的
LOG_ARCHIVE_DEST_2指向备库，格式为：'SERVICE=orcl_standby ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl_standby' - 备库的
LOG_ARCHIVE_DEST_2反向指向主库（用于 Switchover 后角色反转），内容类似但DB_UNIQUE_NAME改为主库名
备库启动到 MOUNT 状态前必须完成 Standby Controlfile 和密码文件同步
很多人在 RMAN Duplicate 后直接 STARTUP OPEN，结果报 ORA-01103: database name 'ORCL' in control file is not 'ORCL_STANDBY' —— 这说明控制文件还是主库的。
- 用 RMAN 创建物理备库时，必须加
FROM ACTIVE DATABASE或使用备份 + 归档恢复，最终通过RESTORE STANDBY CONTROLFILE生成专用备库控制文件 - 备库的控制文件里记录的是主库的
DB_NAME，但启动时 Oracle 会校验DB_UNIQUE_NAME，所以必须用ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;启动，而不是OPEN - 密码文件必须从主库拷贝过来（
orapw$ORACLE_SID），否则备库无法通过SYS远程连接主库传输日志，报错如ORA-01017: invalid username/password - 确认
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE在两边都已设置
验证 Redo Apply 是否真正运行，别只看进程存在
看到 MRP0 进程在 V$PROCESS 里，不代表日志在应用。常见假象是 MRP0 一直在，但 APPLIED_SCN 卡住不动。
- 查
SELECT PROCESS, STATUS, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;，重点看MRP0的STATUS是APPLYING_LOG，不是WAIT_FOR_LOG或IDLE - 对比主备库的
SELECT CURRENT_SCN FROM V$DATABASE;和SELECT MAX(APPLIED_SCN) FROM V$ARCHIVED_LOG;，差值超过几万就要警惕 - 如果备库一直卡在
WAIT_FOR_GAP，说明中间缺归档 —— 检查主库V$ARCHIVE_GAP，手动把缺失段从主库 scp 过来，再用RECOVER AUTOMATIC STANDBY DATABASE; - 启用实时应用（
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;）前，务必确认主库已开启FORCE LOGGING，否则 DML 可能不写重做
最易被忽略的是：备库的 STANDBY_FILE_MANAGEMENT 默认是 MANUAL，一旦主库新增表空间或数据文件，备库不会自动创建对应文件，后续 ALTER DATABASE RECOVER 会直接报错 ORA-01111，必须提前设为 AUTO。这个参数改完不用重启，但必须在备库 MOUNT 状态下执行。
