v$session_longops可查rman恢复实时进度，需过滤opname like 'rman:%'且排除'aggregate'，关注各sid对应数据文件的sofar/totalwork块级计数，断连后记录消失，应保持会话连接或提前设置command id。
查 V$SESSION_LONGOPS 看实时进度
RMAN 恢复过程中，只要没卡死或挂起，就会在 V$SESSION_LONGOPS 里留下可查的进度记录。关键不是“有没有”，而是“怎么筛出真正有用的那几行”。
- 必须加过滤条件：
OPNAME LIKE 'RMAN:%'且排除'RMAN: aggregate%'，否则会混入汇总伪行 -
SID对应实际执行恢复的会话，不同数据文件可能跑在不同 SID 上，别只盯一个 -
SOFAR / TOTALWORK是块级计数，不是字节或时间，所以百分比跳变可能不线性（尤其跨文件时） - 如果
TOTALWORK = 0或长期不动，大概率是卡在归档日志定位、控制文件读取失败，或权限/路径问题
RESTORE VALIDATE 和 RESTORE PREVIEW 不等于真恢复
这两个命令常被误当作“轻量版恢复”来预估耗时，但它们根本不走真实 I/O 路径，也不触发实际的数据块读写，所以返回的进度或估算值对真实恢复毫无参考价值。
-
RESTORE VALIDATE只校验备份集头和元数据完整性，不读数据块内容 -
RESTORE PREVIEW仅解析 RMAN 目录，输出将用哪些备份集+归档日志，不打开任何文件 - 想测真实恢复速度，唯一办法是开测试库做一次最小粒度恢复（比如单个非关键表空间），并监控
V$SESSION_LONGOPS的实际SOFAR增长速率
并行通道多 ≠ 进度显示更全
用多个 ALLOCATE CHANNEL 启动并行恢复后，V$SESSION_LONGOPS 里会出现多个 RMAN: full datafile restore 行，但每行只反映对应通道正在处理的那个数据文件——不会合并成一个总进度条。
- 各通道的
TOTALWORK是各自数据文件的块总数，彼此独立，不能相加 - 如果某通道长时间
SOFAR == 0，优先检查该通道分配的数据文件路径是否存在、权限是否正确、ASM diskgroup 是否 online - 不要依赖
OPNAME字面意思：即使显示RMAN: full datafile restore，也可能卡在等待归档日志应用阶段（此时实际在跑RECOVER阶段）
恢复中途断开后，V$SESSION_LONGOPS 记录会消失
RMAN 会话退出或客户端断连后，对应的所有 V$SESSION_LONGOPS 条目会被 Oracle 自动清理，哪怕后台进程还在继续工作。这不是 bug，是设计行为。
- 要持续跟踪，必须保持 SQL*Plus 或 RMAN 客户端连接不中断；用脚本轮询时，得确保会话存活
- 如果已断开，只能通过
V$BACKUP_SYNC_IO或V$BACKUP_ASYNC_IO查 I/O 活跃度，或直接ps -ef | grep rman看进程是否存在 - 最可靠的补救方式是提前在恢复命令里加上
SET COMMAND ID TO 'restore_20260721'，这样即使断开，也能用V$SESSION的CLIENT_INFO字段反查历史会话
V$SESSION_LONGOPS 中每个 SID 的 SOFAR 是否稳定增长；一旦停住，优先排查归档日志路径、控制文件一致性、以及那个特定数据文件的物理可访问性——而不是刷新页面等百分比跳动。
