必须先启备库监听再启主库，否则主库虽能startup成功，但归档日志无法传输，dg同步链从一开始就是断的。
为什么必须先启备库监听再启主库
主库启动时会尝试连接备库的监听器（lsnrctl），如果备库监听没起来，主库虽能 startup 成功，但归档日志无法传输，dg 同步链从一开始就是断的——你看到 arch 进程在主库跑着，实际日志压根没发出去。
常见错误现象：SELECT STATUS FROM V$ARCHIVE_DEST WHERE DEST_ID = 2; 返回 ERROR 或 DEFERRED；主库 archive log list 显示 Archive Destination: /u01/arch（本地路径），而非指向备库的 service=standby_db。
- 监听必须在数据库实例启动前就位，否则主库初始化时会跳过远程归档配置
- 备库监听名不一定要叫
LISTENER，但主库LOG_ARCHIVE_DEST_2中的SERVICE=xxx必须与备库listener.ora里定义的服务名完全一致（大小写敏感） - 别依赖
lsnrctl start后立刻可用：用lsnrctl status确认输出里有STATUS of the LISTENER...ready且包含你的 DG 服务条目
备库启动顺序不能简写为 startup
备库不是普通单机库，startup 直接报错是常态。它必须分三步走：先 nomount，再 mount standby database，最后才能 open 并启动日志应用——跳任何一步都会卡在 ORA-01103: database name 'XXX' in control file is not 'YYY' 或 ORA-16664: unable to receive the result from a database。
-
startup nomount：只读控制文件，不碰数据文件，安全 -
alter database mount standby database：关键！带standby database子句，否则 Oracle 当成主库挂载，后续全错 -
alter database open：11g 及以后允许备库open read only，但必须在mount后执行，不能合并到startup - 最后才起日志应用：
alter database recover managed standby database using current logfile disconnect from session，漏掉using current logfile就只能手动传日志
主库启动后要立刻验证归档是否真通了
主库 startup 完毕只是开始，真正同步是否建立，得看归档日志有没有被主库成功推过去、备库有没有成功应用。靠“没报错”判断等于没验。
- 主库执行：
archive log current强制切一次归档，然后查select sequence#, first_time, next_time from v$log_history where rownum 记下最新序列号 - 备库立刻查：
select sequence#, applied from v$archived_log where sequence# >= [刚记下的序列号] order by sequence#;——applied='YES'才算落地 - 如果
applied='NO'，别急着重试，先看备库告警日志：tail -n 50 $ORACLE_BASE/diag/rdbms/standby_db/trace/alert_*.log，常见原因是网络不通、密码文件缺失或log_archive_dest_state_2=defer没开
重启窗口期拉太长会丢数据
主库和备库启动时间差超过 5 分钟，尤其主库已产生大量归档，备库很可能因归档 GAP 卡住——不是同步慢，而是根本收不到前面断掉的那几段日志，MRP 进程会停在某个序列号不动。
容易踩的坑：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 后直接 startup，忘了重新启用 MRP；或者备库 open 后没执行恢复命令，就以为“备库起来了”。
- 最稳做法：主库启动后，等 30 秒，再连备库执行一遍
alter database recover managed standby database using current logfile disconnect from session - 如果发现 GAP，别手忙脚乱删归档，先用
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;定位缺哪段，再从主库手工拷贝补上 - 生产环境建议把整个流程写成脚本，加上
sleep 10和check_lsnr_ready函数，避免人眼盯屏误判
监听没起来、备库没挂成 standby、主库归档目标没激活、时间差太大导致 GAP——这四点，任何一个漏检，重启后看着都“正常”，其实同步早断了。
