主库ORA-00313报错需先查V$LOG确认日志组状态：INACTIVE/UNUSED则CLEAR LOGFILE；ACTIVE/CURRENT需先CHECKPOINT再CLEAR或CLEAR UNARCHIVED，之后立即全备并验证归档生成。
主库联机日志损坏后，备库不会立即报错，但归档传输会静默中断，MRP0进程卡在WAIT_FOR_LOG或APPLYING_LOG却不推进——这不是备库配置问题，而是主库已无法生成/提供连续归档。
主库启动报 ORA-00313 时怎么快速稳住局面
主库ALTER DATABASE OPEN失败并报ORA-00313，说明控制文件里记录的日志组路径已不存在。必须先查状态再操作，不能直接CLEAR：
- 执行
SELECT GROUP#, STATUS, ARCHIVED FROM V$LOG;确认损坏组的状态 - 若为
INACTIVE或UNUSED：直接ALTER DATABASE CLEAR LOGFILE GROUP n; - 若为
ACTIVE或CURRENT：先ALTER SYSTEM CHECKPOINT;，再尝试CLEAR；仍失败则用CLEAR UNARCHIVED LOGFILE GROUP n;（注意：这会丢失未归档事务，之后必须立刻全备） - 清除成功后，
ALTER DATABASE OPEN即可恢复主库服务
清除日志组后归档不生成？检查这三处
CLEAR本身不关归档开关，但LGWR可能卡住，导致后续归档停滞。重点排查：
- 确认归档模式开启：
ARCHIVE LOG LIST输出中必须含Database log mode: Archive Mode - 手动触发一次归档：
ALTER SYSTEM ARCHIVE LOG CURRENT;，然后ls -l看log_archive_dest_1目录是否有新文件生成 - 检查
V$ARCHIVE_DEST_STATUS中STATUS是否为VALID，ERROR列是否非空；常见错误如ORA-09285（权限不足）或ORA-16038（日志重用）
备库MRP0不动、V$ARCHIVE_GAP为空，但数据不同步
这说明归档已收全，但应用层卡住了。别只盯着GAP视图：
- 查
v$managed_standby：确认PROCESS = 'MRP0'且STATUS = 'APPLYING_LOG'；若为WAIT_FOR_LOG，说明归档供应断了 - 查
v$dataguard_stats：看apply lag和transport lag是否持续增长 - 查备库
alert.log：搜ORA-01111（UNNAMED文件）、ORA-01193（数据文件不一致）、corruption；特别注意主库新增PDB或数据文件后，备库standby_file_management设为MANUAL却没同步创建文件的情况
主库已丢失归档，备库出现缺口怎么办
如果V$ARCHIVE_GAP返回LOW_SEQUENCE#和HIGH_SEQUENCE#，且主库对应归档确实没了（比如被CLEAR UNARCHIVED后又没备份），就不能等FAL自动拉取：
- 不要设
FAL_SERVER——主库已无对应归档，设了也白设 - 优先从主库
DB_RECOVERY_FILE_DEST或归档目录手工找缺失序列号的归档，拷到备库log_archive_dest_1路径下 - 若完全缺失，
RESTORE DATABASE FROM SERVICE是19c最稳妥的选择：在备库RMAN中执行RESTORE DATABASE FROM SERVICE 'primary_db_service';，它会通过网络从主库实时拉取所需数据文件，绕过归档缺口
真正麻烦的不是日志损坏本身，而是清除操作后没验证归档是否恢复生成——很多DBA以为OPEN成功就万事大吉，结果备库在几小时后才暴露出应用停滞，此时缺口已扩大，补救成本陡增。
