V$SESSION_LONGOPS中OPNAME='media recovery'不可靠，仅反映日志应用阶段进度，无法预测总耗时；需结合V$RECOVERY_PROGRESS和V$ARCHIVED_LOG验证，并用recover database test测真实速率。
看 V$SESSION_LONGOPS 里的 OPNAME = 'media recovery' 是否可靠
它只反映当前正在执行的恢复操作进度，不是全库恢复总耗时预测。oracle 在应用归档/备库日志时才会触发该条目，如果恢复卡在“等待下一个归档”或“重建控制文件”阶段，v$session_longops 根本不更新，甚至可能查不到记录。
常见错误现象：SELECT * FROM V$SESSION_LONGOPS WHERE OPNAME LIKE '%media%'; 返回空，不代表没在恢复——只是 Oracle 还没进入“应用日志”这个可计量阶段。
- 必须搭配
V$RECOVERY_PROGRESS和V$ARCHIVED_LOG查已应用日志量 -
TIME_REMAINING字段常为 0 或负数，不能直接信 - 该视图每 5 秒刷新一次，实时性有限，短于 10 秒的操作压根不会出现
用 recover database test 测真实介质恢复速率
真正影响时间的是“日志应用速度”，不是备份集大小。测试必须绕过 RMAN 备份还原阶段，直奔恢复瓶颈：从归档日志里读、解压、重做（redo apply）。
实操建议：
- 先用
recover database test（非recover database），它跳过实际写盘，只跑日志解析和内存重做，耗时≈纯 CPU + 日志解析开销 - 再用
recover database noredo+ 手动ALTER DATABASE RECOVER MANAGED STANDBY DATABASE模拟带 I/O 的场景 - 对比两次耗时：若差值大，说明磁盘吞吐或日志 IO 是瓶颈；若接近，说明是 CPU 或重做日志结构复杂度（如大量小事务）拖慢
注意：test 恢复不校验数据块一致性，也不写入数据文件，但会读取所有归档并模拟应用逻辑——这才是测速率的关键。
set db_recovery_file_dest_size 不够导致恢复中途失败
恢复过程临时生成大量重做中间状态（比如 block cleanout、undo segment 回滚），全存在 DB_RECOVERY_FILE_DEST。哪怕你只恢复 10GB 数据，实际可能需要 3–5 倍空间。
容易踩的坑：
-
V$RECOVERY_FILE_DEST显示SPACE_LIMIT是硬上限，但SPACE_USED不包含恢复中动态分配的临时区 - 恢复报错
ORA-19809: limit exceeded for recovery files时，ALTER SYSTEM SET db_recovery_file_dest_size=xxG SCOPE=BOTH;无效——必须先shutdown abort再重启才能生效 - 更稳妥的做法：恢复前用
ALTER SYSTEM SET db_recovery_file_dest='/tmp/fast_recovery_area' SCOPE=SPFILE;指向大容量本地盘，避免共享存储争抢
不同归档格式对恢复速度的影响远超预期
压缩归档（COMPRESSED ARCHIVELOG）不是省空间就完事——解压消耗 CPU，且 Oracle 必须等整个归档文件下载+解压完才开始应用，无法流式处理。
实测差异：
- 未压缩归档：平均 80–120 MB/s 应用速率（SSD + 16 核）
- 压缩归档（ZLIB）：降到 30–50 MB/s，CPU 使用率持续 >90%
- 如果归档在 NFS 上，压缩归档还会放大网络延迟影响，
WAIT_EVENT = 'archivelog file read'时间暴涨
结论很直接：除非磁盘严重不足，否则别对归档启用压缩。恢复时间成本通常远高于存储节省。
恢复前务必确认：SELECT COMPRESSION FROM V$ARCHIVED_LOG WHERE FIRST_TIME > SYSDATE-1;，别只看备份脚本里写了 COMPRESS FOR ARCHIVELOG 就以为没问题。
