V$ARCHIVE_DEST_STATUS的STATUS和ERROR字段反映真实运行状态,STATUS为ERROR或DEFERRED、ERROR非空、RECOVERY_MODE非MANAGED REAL TIME APPLY均表明归档传输异常,需结合log_archive_config、VALID_FOR配置及RESET/ENABLE操作综合排查。
直接看 v$archive_dest_status 的 status 和 error 字段,别信 show parameter 里写的值——参数对了,状态照样可能是 error 或 deferred。
V$ARCHIVE_DEST_STATUS,不是 V$ARCHIVE_DEST
V$ARCHIVE_DEST 只显示初始化参数配置,而 V$ARCHIVE_DEST_STATUS 才反映真实运行时状态。主库上执行:
SELECT DEST_ID, STATUS, ERROR, TRANSMIT_MODE, RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
重点盯三处:
STATUS 是 ERROR 或 DEFERRED?不是 VALID 或 ALTERNATE 就说明传输链路已断ERROR 列非空?常见值如 ORA-16055、ORA-16086、ORA-12541、ORA-16047,每种对应不同根因RECOVERY_MODE 在备库端是否为 MANAGED REAL TIME APPLY?如果是 IDLE,MRP0 进程根本没跑起来log_archive_config 缺失或大小写不一致,会导致静默失败主库和备库都必须显式配置 log_archive_config,且所有 DB_UNIQUE_NAME 必须完全一致(含大小写、空格、引号)。漏配或写错一个,就会触发 ORA-16047: DGID mismatch,但 ERROR 字段可能只显示“DGID mismatch”,不提示具体缺谁。
检查方法:
SHOW PARAMETER log_archive_config
若返回空值、NULL 或内容不全,立即补全:
ALTER SYSTEM SET log_archive_config='DG_CONFIG=(PRIMARY_DB,STANDBY_DB)' SCOPE=BOTH SID='*';
注意:这个参数修改后必须重启数据库才生效,仅 SCOPE=BOTH 不够,尤其备库常被忽略。
VALID_FOR 配错会让归档路径“形同虚设”哪怕路径、服务名、权限全对,只要 VALID_FOR 不匹配当前实例角色和日志类型,Oracle 就直接跳过该目标,不报错也不尝试传输。
主库归档到备库的标准写法是:
LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'
常见错误包括:
VALID_FOR=(STANDBY_LOGFILES,PRIMARY_ROLE):主库不生成 standby redo log,这条路永远走不通LOG_ARCHIVE_DEST_1 但 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE):备库角色是 STANDBY_ROLE,条件不满足VALID_FOR=(ONLINE_LOGFILES,STANDBY_ROLE)
验证是否生效,查:
SELECT DEST_ID, VALID_TYPE, VALID_ROLE, STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
ERROR 不更新?先 RESET 再 ENABLE
很多情况下,ERROR 字段一直显示旧错误(比如磁盘满修复后仍报 ORA-19809),是因为 Oracle 内部错误计数器没清。不能只改路径或重启监听就完事。
标准操作顺序是:
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=RESET;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
ALTER SYSTEM ARCHIVE LOG CURRENT;
切记:ENABLE 不会自动补传积压日志,中断期间的归档必须用 RMAN 手动拷贝 + 备库 RECOVER 补上;直接 cp 文件到备库归档目录无效,控制文件没注册,MRP0 无法识别。
最常被跳过的一步:改完路径、修完空间、配好 log_archive_config 后,忘了确认 LOG_ARCHIVE_DEST_STATE_n 是否仍是 DEFER 或卡在 ERROR —— 新配置全白搭,通道实际锁死了。