必须用UNTIL CANCEL而非时间/SCN/SEQUENCE，因丢失的是未归档的CURRENT/ACTIVE联机日志，Oracle无法定位缺失日志位置；UNTIL CANCEL允许手动终止恢复，应用完可用归档日志后输入CANCEL，再强制执行OPEN RESETLOGS并立即全库备份。
丢失联机重做日志（online redo log）时，recover database until cancel 是唯一可行的手动不完全恢复路径——因为缺失的不是归档日志，而是当前正在写入或刚切换但尚未归档的那组日志，数据库无法继续应用重做流，必须主动截断恢复点。
为什么必须用 UNTIL CANCEL 而不是时间或SCN
当 current 或 active 状态的联机日志文件被误删、磁盘损坏或权限丢失，v$log 中对应组的状态仍为 CURRENT 或 ACTIVE，但物理文件已不可读。此时：
-
UNTIL TIME和UNTIL SCN依赖归档日志连续性，而缺失的是“最后一段”未归档的变更，Oracle 无法定位该时间点/SCN 对应的日志位置； -
UNTIL SEQUENCE同样失效——序列号可能已推进，但对应日志内容根本不存在； -
UNTIL CANCEL是唯一允许 DBA 在日志应用过程中手动干预的机制：它让 Oracle 尽可能多地应用可用归档日志，直到遇到第一个无法读取的日志文件时暂停，并等待你输入CANCEL确认终止。
执行 RECOVER DATABASE UNTIL CANCEL 的关键步骤
该命令只能在 MOUNT 状态下运行，且要求所有数据文件已从备份中还原（不能只还原部分）。常见疏漏点：
- 先确认控制文件是当前的（不是旧备份）——若控制文件也损坏，需先用
RESTORE CONTROLFILE FROM ...恢复，再STARTUP MOUNT； - 确保归档日志路径正确且可读：
SHOW PARAMETER log_archive_dest_1，并检查LIST ARCHIVELOG ALL是否能列出完整序列； - 运行前必须关闭数据库并还原全部数据文件（哪怕只有 1 个损坏，也要全库 restore），否则会报
ORA-01113: file X needs media recovery； - 执行命令后，Oracle 会逐个尝试应用归档日志，一旦遇到缺失日志（如序列号 102 缺失，但 101 已应用完），会停在
Media recovery complete.前并提示Specify log: {<ret> = suggested | filename | AUTO | CANCEL}</ret>； - 此时直接输入
CANCEL（不能输错大小写或空格），回车确认终止。
ALTER DATABASE OPEN RESETLOGS 不是可选项，是强制要求
不完全恢复完成后，数据库处于一个“逻辑断点”状态：SCN 连续但日志序列中断。此时：
-
OPEN RESETLOGS必须执行，否则OPEN会报ORA-01589: must use RESETLOGS or NORESETLOGS option； -
NORESETLOGS绝对不可用——它仅适用于完全恢复且所有日志完整的情况； - 执行
RESETLOGS后，当前联机日志会被清空重建，日志序列号重置为 1，旧的归档日志链就此终结； - 务必在
RESETLOGS后立即做一次全库备份，否则后续任何恢复都只能回到这个新 incarnation，无法跨 resetlogs 边界。
真正容易被跳过的动作是：在输入 CANCEL 前，没确认 v$archived_log 中最后成功应用的归档日志序列号；以及 RESETLOGS 后没验证 v$log 中各组状态是否全为 INACTIVE 或 UNUSED——如果仍有 CURRENT 组指向已丢失路径，数据库虽能打开，但下次日志切换就会立刻宕机。
