查rman进度须过滤v$session_longops中opname like 'rman:%'且not like 'rman: aggregate%'、sofar>0、totalwork>0的行，按sid分文件观察块级进度，防伪行干扰与断连丢失。
直接看 V$SESSION_LONGOPS，但必须加过滤、盯块数、防断连——否则看到的全是假进度。
查 RMAN 进度为什么总看不到有效记录
不是没进度，是默认查法太宽泛。V$SESSION_LONGOPS 里混着大量伪行（比如 'RMAN: aggregate'），不加条件会淹没真实恢复线程。
- 必须加
WHERE OPNAME LIKE 'RMAN:%' AND OPNAME NOT LIKE 'RMAN: aggregate%' - 只看
SOFAR > 0 且TOTALWORK > 0的行，否则大概率卡在归档定位、控制文件读取失败或路径权限问题 -
SID对应实际干活的会话，不同数据文件可能跑在不同SID上，别只刷一个
为什么 SOFAR / TOTALWORK 看起来跳变不线性
这两个字段是块级计数（data block 数），不是字节也不是时间。跨文件恢复时，TOTALWORK 随文件大小剧烈变化，百分比自然抖动。
- 单个数据文件内：
ROUND(SOFAR/TOTALWORK*100, 1)可信 - 多个文件并行时：
SOFAR和TOTALWORK不可累加，每个SID只反映它当前处理的那个文件 - 如果某
SID长期SOFAR = 0，优先检查该通道对应的数据文件路径是否存在、ASM diskgroup 是否 online、Oracle 用户是否有读写权限
RESTORE VALIDATE 和 RESTORE PREVIEW 不能代替真恢复测速
这两个命令根本不走真实 I/O 路径，返回的“预计耗时”对实际恢复毫无参考价值。
-
RESTORE VALIDATE只校验备份集头和元数据，不读任何数据块内容 -
RESTORE PREVIEW仅解析 RMAN 目录，输出将用哪些备份集+归档日志，不打开任何物理文件 - 想测真实速度，唯一办法是开测试库做最小粒度恢复（比如单个非关键表空间），并持续观察
V$SESSION_LONGOPS中SOFAR的稳定增长速率
RMAN 客户端断开后进度记录就消失
这不是 bug，是 Oracle 的设计行为：会话退出，V$SESSION_LONGOPS 对应条目自动清理，哪怕后台恢复进程仍在跑。
- 要持续跟踪，必须保持 SQL*Plus 或 RMAN 客户端连接不中断
- 脚本轮询时，得确保会话存活；可用
ps -ef | grep rman辅助确认后台进程是否还在 - 已断开？只能靠
V$BACKUP_SYNC_IO/V$BACKUP_ASYNC_IO查 I/O 活跃度，或提前在恢复命令里加SET COMMAND ID TO 'xxx'，后续可通过COMMAND_ID关联其他视图
最常被忽略的是：即使 OPNAME 显示 RMAN: full datafile restore，也可能实际卡在等待归档日志应用阶段（即已进入 RECOVER 阶段），此时 SOFAR 停滞但 V$ARCHIVED_LOG 和 V$LOG_HISTORY 才是关键排查入口。
