主库损坏但未传输的Redo日志是ADG中最危险的悬空数据，抢救优先级最高：先尝试用LOGMINER解析可读的在线日志，再扫描本地归档目录补缺，必须注册后才能被MRP识别应用，不可跳过GAP或误执行CLEAR LOGFILE。
主库损坏但未传输的Redo日志，是ADG环境中最危险的“悬空数据”——它既没到备库，也没被归档，一旦主库无法启动，这部分事务就面临永久丢失。能不能救，取决于损坏类型和日志所处位置。
在线重做日志（Online Redo Logs）还能读吗？
这是抢救的第一优先级。只要磁盘物理完好、文件未被覆盖或清零，ALTER DATABASE CLEAR LOGFILE之前必须先尝试提取内容。
- 若主库实例能
MOUNT但不能OPEN（比如控制文件损坏但日志文件完好），可直接用LOGMINER分析当前ONLINE REDO LOG组：启动时指定UTL_FILE_DIR，运行DBMS_LOGMNR.ADD_LOGFILE加入最新日志组，再START_LOGMNR解析未提交/已提交但未同步的DML - 若主库完全无法启动（如
ORA-00313报当前日志组丢失），需确认日志文件是否真实删除：检查v$log和v$logfile中路径是否存在，用ls -l看文件大小和修改时间；误删但未被覆盖时，可用extundelete（ext4）或xfs_undelete（xfs）抢救原始文件 - 切勿对疑似可用的日志组执行
CLEAR LOGFILE—— 这会清空内容并重置序列号，等于主动销毁证据
归档日志（Archived Logs）还在主库本地吗？
很多环境把归档目标设为本地 USE_DB_RECOVERY_FILE_DEST 或共享目录，主库宕机后这些文件往往还在。关键在识别哪些是“已生成但未传输”的归档。
- 查主库最后成功传到备库的归档序列：
SELECT MAX(sequence#) FROM v$archived_log WHERE applied='YES'（需能MOUNT）；再对比本地归档目录下最大序列号，差值就是待抢救范围 - 注意归档路径中可能有多个目的地（
log_archive_dest_1,_2...），用SHOW PARAMETER log_archive_dest确认所有有效路径，逐个扫描*.arc文件 - 如果归档目录用了 ASM，需通过
ASMCMD进入对应+FRA/.../ARCHIVELOG/路径，用ls -lt按时间排序找最新一批 - 发现缺失序列号（如 1001, 1002, 1004），别急着复制——先用
strings /path/to/arch_1003.arc | head -20看文件头是否真为空或损坏；ORA-00386 类错误常表现为归档日志末尾截断，这种文件即使拷过去，备库MRP进程也会报错跳过
备库能否跳过 GAP 直接应用后续日志？
不能。物理备库的 MRP 进程严格按序列号顺序应用，缺一个就卡住，状态显示 APPLYING_LOG 但实际停滞。强行重启 MRP 不解决问题。
- 确认 GAP 后，必须补全缺失日志：从主库本地归档目录复制，或从 RMAN 备份中还原（
RESTORE ARCHIVELOG FROM TIME '...'） - 复制到备库后，必须用
ALTER DATABASE REGISTER LOGFILE '/path/to/arch_xxx.arc'注册，否则v$archived_log不可见，MRP 不识别 - 注册后执行
RECOVER MANAGED STANDBY DATABASE DISCONNECT，MRP 会自动从断点续上；若仍卡住，查v$managed_standby中PROCESS列为MRP0的STATUS和SEQUENCE#，比对是否与刚注册的日志序列一致 - 特别注意：如果主库损坏前启用了
STANDBY_ARCHIVE_DEST并配置了远程归档，部分日志可能已半途传到备库的ARCHIVE_LAG_TARGET目录但未完成写入——此时用ls -la查看文件大小是否为 0 或不完整，这类文件必须删除，否则注册后会导致 ORA-00334
真正棘手的情况是：在线日志被覆盖、归档目录清空、RMAN 备份又没包含最近归档——这时候唯一能做的，是接受 RPO（恢复点目标）回退到上一个可用归档时间点，并立刻重建 ADG。所谓“抢救”，本质是抢时间窗口；而窗口长度，取决于你日常是否保留足够冗余的归档保留策略和跨机房备份链。
