主库启动报ORA-00313时，先查日志组状态：若INACTIVE/UNUSED，执行ALTER DATABASE CLEAR LOGFILE GROUP n；若ACTIVE/CURRENT，先ALTER SYSTEM CHECKPOINT再尝试CLEAR，仍失败则用CLEAR UNARCHIVED LOGFILE GROUP n（需立即全备）。
主库重做日志组丢失后，dg备库通常不会自动中断，但后续归档传输会失败、备库出现 ora-00313 或 ora-00308 错误，且无法应用新归档——这不是备库问题，而是主库日志缺失导致归档链断裂。恢复核心是：**先稳住主库，再重建归档供应能力，最后让备库追上**。
主库启动报 ORA-00313 时怎么应急打开？
主库启动到 MOUNT 状态成功，但 ALTER DATABASE OPEN 失败并报 ORA-00313（open failed for members of log group X），说明控制文件记录了该日志组路径，但文件已不存在。
- 先查日志组状态：
SELECT GROUP#, STATUS, TYPE, MEMBER FROM V$LOG JOIN V$LOGFILE USING(GROUP#); - 若状态为
INACTIVE或UNUSED，直接清除：ALTER DATABASE CLEAR LOGFILE GROUP 2; - 若状态为
ACTIVE或CURRENT，不能直接CLEAR，必须先做检查点：ALTER SYSTEM CHECKPOINT;，再尝试CLEAR；若仍失败，需用CLEAR UNARCHIVED LOGFILE GROUP 2（注意：这会丢失未归档事务，且之后必须立即全备） - 清除成功后，
ALTER DATABASE OPEN即可完成
清除日志组后归档不再生成？
CLEAR 操作本身不破坏归档功能，但若清除的是当前组或刚切换过的组，LGWR 可能卡在写入环节，导致后续归档停滞。
- 确认归档模式开启：
ARCHIVE LOG LIST输出应含Database log mode: Archive Mode - 强制归档切换一次：
ALTER SYSTEM ARCHIVE LOG CURRENT;，观察是否生成新归档文件 - 检查
log_archive_dest_1路径是否有写权限，ls -ld和touch测试 - 若仍无归档，查
V$ARCHIVE_DEST_STATUS中STATUS是否为VALID，ERROR列是否非空
备库报 FAL[client]: Failed to request gap sequence 怎么办？
这是主库归档断供后最典型的症状：备库发现归档序列号有缺口（gap），但向主库请求补传失败——因为主库已无法提供缺失的归档（对应日志组已被清除或丢失）。
- 先在备库确认缺口：
SELECT * FROM V$ARCHIVE_GAP;，得到LOW_SEQUENCE#和HIGH_SEQUENCE# - 不要依赖
FAL_SERVER自动拉取：主库已无对应归档，设了也无效 - 正确做法是人工补缺：从主库
DB_RECOVERY_FILE_DEST或归档目录中找是否存在这些序列号的归档（哪怕部分存在），手动拷贝到备库log_archive_dest_1对应路径 - 若完全缺失（例如被
CLEAR UNARCHIVED后未备份），则必须放弃这部分事务，执行备库“闪回 + 重新同步”或主库DUPLICATE新建备库——没有捷径
为什么不能只清日志组就完事？
清除日志组只是让主库能启动，但没解决根本问题：归档链断裂后，DG 的一致性保障机制已经失效。即使主库恢复归档生成，备库也无法自动跳过缺失段继续应用。
-
CLEAR操作不记录到控制文件的归档历史中，V$ARCHIVED_LOG不会新增记录 - 备库的
MRP进程严格按序列号顺序应用，缺一个就卡死 - 如果缺失的是近期归档（比如最近1小时内），且主库仍有可用备份，最优解是：主库做增量备份 + 备库
RECOVER DATABASE USING BACKUP CONTROLFILE手动恢复到最新一致点 - 最易被忽略的一点：清除操作后，必须立刻执行
RMAN BACKUP DATABASE PLUS ARCHIVELOG，否则下次故障将彻底失去恢复依据
