日志传输中断通常因归档路径、状态或角色配置异常所致，95%可通过reset+enable+补传恢复；需查v$archive_dest定位错误目标，重置状态并启用通道，再手动补传积压日志，同时确认备库rfs和mrp进程正常运行。
日志传输中断不是“数据库坏了”，而是归档路径、状态或角色配置卡在某个环节——95% 的情况靠 RESET + ENABLE + 补传就能恢复，别一上来就清日志或重建备库。
查 v$archive_dest 确认哪个 destination 报错
先定位问题靶点。运行：
SELECT dest_id, status, target, error FROM v$archive_dest WHERE status != 'VALID';
常见现象：
-
status = ERROR且error列含ORA-16086（SRL 写不进）、ORA-16055（FAL 拒绝补传）或ORA-00308（归档路径打不开） -
status = INACTIVE：说明该 destination 被显式DEFER过，但没人再ENABLE -
target = 'standby'却status = VALID：可能只是主库归档成功，但没发到备库——得继续看备库的v$managed_standby
注意：dest_id = 1 通常是本地归档，dest_id = 2 才是发往备库的；别只盯着 dest_id = 2，漏掉 dest_id = 1 失效会导致后续所有归档失败。
重置状态并启用传输通道
光改路径或参数没用，必须重置 destination 内部状态。三步缺一不可：
- 执行
ALTER SYSTEM SET log_archive_dest_state_2 = RESET;：清空错误计数器和缓存，否则error字段会一直卡在旧值上 - 执行
ALTER SYSTEM SET log_archive_dest_state_2 = ENABLE;：重新激活传输，但不会自动补传积压日志 - 手动触发一次归档：
ALTER SYSTEM ARCHIVE LOG CURRENT;，验证是否真能发出去
容易踩的坑：
- 改完
log_archive_dest_2路径后，忘了执行RESET和ENABLE，新路径永远不生效 - 用了 Data Guard Broker，
ALTER SYSTEM修改被 DGMGRL 配置覆盖，必须同步在 DGMGRL 中EDIT DATABASE ... SET PROPERTY - 备库处于
OPEN READ ONLY状态，log_archive_dest_state_n在备库上设了也没用——它只在 MOUNTED 状态下才参与日志接收
补传中断期间积压的归档日志
传输恢复后，主库不会自动把中断时生成的归档补过去。必须人工介入：
- 在备库查缺口：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM v$archive_gap; - 去主库找对应归档：
LIST ARCHIVELOG FROM SEQUENCE <code>low_seqUNTIL SEQUENCEhigh_seqTHREADthread#; - 用
COPY ARCHIVELOG或scp传到备库归档目录（路径必须严格匹配log_archive_dest_2值） - 逐个注册：
ALTER DATABASE REGISTER PHYSICAL LOGFILE '<code>full_path'; —— 不要跳过这步，否则备库看不到这些文件
关键细节：
- 别直接
cp归档文件到备库目录就完事，缺少控制文件注册，v$archived_log里不会出现记录 - 如果
v$archive_gap返回空，不代表没 gap——可能是 MRP 进程已停，视图未刷新；先确认MRP0状态是否为APPLYING_LOG - RAC 环境下，每个
THREAD#要单独查、单独补，别只看 thread 1
检查备库 SRL 和 MRP 是否真在干活
传输通了，不代表备库在应用。重点看两个进程：
-
RFS（Remote File Server）：在备库上运行，负责接收主库发来的归档或 redo。查v$managed_standby，PROCESS = 'RFS'的STATUS应为WRITING或IDLE（有数据时会变WRITING） -
MRP0（Managed Recovery Process）：负责应用日志。状态必须是APPLYING_LOG，WAIT_FOR_LOG或IDLE都意味着卡住
卡住常见原因：
- 备库
STANDBY REDO LOG全是UNASSIGNED：说明没创建或没启用，需ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE启动 MRP - 闪回区撑满：
v$flash_recovery_area_usage中PERCENT_SPACE_RECLAIMABLE = 0，RMAN 清理不掉旧归档，得先DELETE ARCHIVELOG - 归档文件名被手动改过（比如加了
.bak后缀），MRP 无法识别，报ORA-00334
最易被忽略的一点：备库 log_archive_dest_state_n 看似是 ENABLE，但实际因权限/磁盘满/路径不存在导致内部状态失效——v$archive_dest 的 status 列才是唯一可信依据，别信参数值本身。
