# 🗃️ Oracle 19C V$RECOVERY_PROGRESS 动态性能视图详解
1. 视图概述与核心作用
V$RECOVERY_PROGRESS 是 Oracle 数据库中用于实时监控和跟踪恢复操作进度的关键动态性能视图。它提供了数据库恢复过程中各个阶段的详细状态信息,包括实例恢复、介质恢复和数据库闪回等操作的执行进度。
2. 主要用途与应用场景
V$RECOVERY_PROGRESS 视图在以下场景中特别重要:
- 实例恢复监控:当数据库异常关闭后重新启动时,监控SMON进程进行的实例恢复进度
- 介质恢复跟踪:在执行基于归档日志的恢复操作时,实时跟踪恢复进度
- 闪回数据库操作:监控闪回数据库操作的执行进度
- 长时间恢复操作:对于大型数据库的恢复操作,提供进度估算和完成时间预测
- 故障诊断:当恢复操作出现问题时,帮助诊断恢复停滞或缓慢的原因
3. 字段详解
以下是 V$RECOVERY_PROGRESS 视图的核心字段说明:
| 字段名称 | 类型 | 描述 |
|---|---|---|
| RECOVERY_ID | NUMBER | 恢复操作的唯一标识符 |
| TYPE | VARCHAR2(64) | 恢复操作类型(INSTANCE_CRASH, MEDIA, FLASHBACK等) |
| ITEM | VARCHAR2(64) | 恢复项标识(如数据文件号或线程号) |
| STATUS | VARCHAR2(32) | 恢复状态(IN PROGRESS, COMPLETED, FAILED) |
| START_TIME | DATE | 恢复操作开始时间 |
| END_TIME | DATE | 恢复操作结束时间(如果已完成) |
| WORK_ESTIMATED | NUMBER | 估计的总工作量单位 |
| WORK_COMPLETED | NUMBER | 已完成的工作量单位 |
| UNITS | VARCHAR2(64) | 工作量单位(BYTES, BLOCKS, FILES等) |
| PARAMETER1 | VARCHAR2(256) | 附加参数1(依赖具体的恢复类型) |
| PARAMETER2 | VARCHAR2(256) | 附加参数2(依赖具体的恢复类型) |
| PARAMETER3 | VARCHAR2(256) | 附加参数3(依赖具体的恢复类型) |
| MESSAGE | VARCHAR2(512) | 恢复操作的详细消息或描述 |
4. 相关视图与基表
4.1 相关动态性能视图
| 视图名称 | 描述 |
|---|---|
V$SESSION_LONGOPS | 显示长时间运行的操作,包括恢复操作 |
V$RECOVERY_STATUS | 显示恢复操作的整体状态信息 |
V$INSTANCE_RECOVERY | 显示实例恢复的调整参数和统计信息 |
V$DATABASE | 显示数据库信息,包括恢复状态 |
V$DATAFILE | 显示数据文件信息,包括恢复状态 |
V$LOG | 显示重做日志信息,用于恢复操作 |
4.2 基表信息
V$RECOVERY_PROGRESS 视图基于内存中的内部数据结构:
- 数据来源:SGA中的恢复管理数据结构
- 底层结构:
X$表(如X$KRCVRPROG) - 中间视图:
V_$RECOVERY_PROGRESS→GV_$RECOVERY_PROGRESS - 临时性:视图内容仅在恢复操作期间存在,恢复完成后数据被清除
5. 底层原理与内部机制
5.1 恢复进程架构
Oracle恢复操作涉及多个后台进程的协同工作:
5.2 进度跟踪机制
Oracle使用基于工作量单位的进度跟踪系统:
- 工作量估算:在恢复开始时,基于需要处理的重做记录数量估算总工作量
- 进度更新:随着恢复的进行,定期更新已完成的工作量
- 状态管理:维护恢复操作的状态机和阶段转换
5.3 恢复类型详解
5.3.1 实例恢复(INSTANCE_CRASH)
- 触发条件:数据库异常关闭后重新启动
- 执行进程:SMON后台进程
- 处理内容:前滚已提交事务,回滚未提交事务
5.3.2 介质恢复(MEDIA)
- 触发条件:数据文件损坏或丢失后的恢复
- 执行方式:用户发起或RMAN自动执行
- 处理内容:应用归档日志和重做日志
5.3.3 闪回恢复(FLASHBACK)
- 触发条件:使用FLASHBACK DATABASE命令
- 执行方式:用户发起,使用闪回日志
- 处理内容:逆向应用闪回日志到指定时间点
6. 常用查询 SQL 示例
6.1 监控当前恢复操作进度
SELECT recovery_id, type, item, status,
start_time,
ROUND((work_completed / NULLIF(work_estimated, 0)) * 100, 2) AS progress_pct,
work_completed, work_estimated, units,
message
FROM v$recovery_progress
WHERE status = 'IN PROGRESS'
ORDER BY start_time;
6.2 查看恢复操作历史
SELECT type, item, status,
start_time, end_time,
ROUND((end_time - start_time) * 1440, 2) AS duration_minutes,
work_completed, work_estimated,
CASE WHEN work_estimated > 0
THEN ROUND((work_completed / work_estimated) * 100, 2)
ELSE NULL
END AS completion_pct,
message
FROM v$recovery_progress
WHERE status = 'COMPLETED'
AND start_time > SYSDATE - 7
ORDER BY start_time DESC;
6.3 估算恢复完成时间
SELECT type, item,
start_time,
work_completed, work_estimated,
ROUND((work_completed / NULLIF(work_estimated, 0)) * 100, 2) AS progress_pct,
CASE WHEN work_estimated > 0 AND work_completed > 0
THEN start_time + ((SYSDATE - start_time) * work_estimated / work_completed)
ELSE NULL
END AS estimated_end_time,
message
FROM v$recovery_progress
WHERE status = 'IN PROGRESS';
6.4 按恢复类型分组统计
SELECT type,
COUNT(*) AS operation_count,
SUM(CASE WHEN status = 'COMPLETED' THEN 1 ELSE 0 END) AS completed,
SUM(CASE WHEN status = 'IN PROGRESS' THEN 1 ELSE 0 END) AS in_progress,
SUM(CASE WHEN status = 'FAILED' THEN 1 ELSE 0 END) AS failed,
ROUND(AVG(work_estimated)) AS avg_work_estimated,
ROUND(AVG(work_completed)) AS avg_work_completed
FROM v$recovery_progress
WHERE start_time > SYSDATE - 30
GROUP BY type
ORDER BY operation_count DESC;
6.5 详细恢复进度监控
SELECT rp.recovery_id, rp.type, rp.item, rp.status,
rp.start_time,
TO_CHAR(rp.start_time, 'YYYY-MM-DD HH24:MI:SS') AS start_time_str,
ROUND((rp.work_completed / NULLIF(rp.work_estimated, 0)) * 100, 2) AS progress_pct,
rp.work_completed, rp.work_estimated, rp.units,
ls.sid, ls.serial#, ls.username, ls.program,
rp.message
FROM v$recovery_progress rp
LEFT JOIN v$session ls ON (rp.parameter1 = TO_CHAR(ls.sid) AND rp.parameter2 = TO_CHAR(ls.serial#))
WHERE rp.status = 'IN PROGRESS'
ORDER BY rp.start_time;
7. 重要知识点与注意事项
7.1 关键概念
-
工作量单位:恢复进度使用不同的单位进行度量
BYTES:基于字节数量的恢复BLOCKS:基于数据块数量的恢复FILES:基于文件数量的恢复RECORDS:基于重做记录数量的恢复
-
进度估算精度:
WORK_ESTIMATED是预估值,实际工作量可能因多种因素而变化 -
恢复阶段:复杂恢复操作可能包含多个阶段,每个阶段在视图中可能有单独的记录
7.2 最佳实践
-
监控策略:建立恢复操作的监控和告警机制
-- 检查长时间运行的恢复操作 SELECT * FROM v$recovery_progress WHERE status = 'IN PROGRESS' AND start_time < SYSDATE - INTERVAL '1' HOUR AND (work_completed / NULLIF(work_estimated, 0)) < 0.1; -
性能基线:记录历史恢复操作的性能数据,建立基准
-- 创建恢复性能历史表 CREATE TABLE recovery_performance_history AS SELECT type, item, work_estimated, work_completed, (end_time - start_time) * 1440 AS duration_minutes, start_time, end_time FROM v$recovery_progress WHERE status = 'COMPLETED' AND work_estimated > 0; -
容量规划:基于恢复性能数据规划系统资源
-- 分析恢复吞吐量 SELECT type, ROUND(AVG(work_completed / NULLIF((end_time - start_time) * 1440, 0)), 2) AS work_per_minute, ROUND(AVG((end_time - start_time) * 1440), 2) AS avg_duration_minutes, COUNT(*) AS sample_count FROM v$recovery_progress WHERE status = 'COMPLETED' AND work_estimated > 0 GROUP BY type;
7.3 故障排查
-
恢复停滞诊断:当恢复操作长时间没有进展时
-- 检查恢复操作状态 SELECT rp.*, s.event, s.wait_time, s.seconds_in_wait FROM v$recovery_progress rp JOIN v$session s ON (rp.parameter1 = TO_CHAR(s.sid) AND rp.parameter2 = TO_CHAR(s.serial#)) WHERE rp.status = 'IN PROGRESS' AND rp.start_time < SYSDATE - INTERVAL '30' MINUTE; -
资源争用分析:检查恢复操作是否遇到资源瓶颈
-- 关联恢复操作和会话等待事件 SELECT rp.type, rp.item, s.event, s.wait_class, COUNT(*) AS wait_count, SUM(s.seconds_in_wait) AS total_wait_seconds FROM v$recovery_progress rp JOIN v$session s ON (rp.parameter1 = TO_CHAR(s.sid) AND rp.parameter2 = TO_CHAR(s.serial#)) WHERE rp.status = 'IN PROGRESS' GROUP BY rp.type, rp.item, s.event, s.wait_class ORDER BY total_wait_seconds DESC; -
I/O性能监控:恢复操作通常对I/O有较高要求
-- 监控恢复相关的I/O活动 SELECT rp.type, rp.item, SUM(d.phyblkrd) AS blocks_read, SUM(d.phyblkwrt) AS blocks_written, SUM(d.phyblkrd + d.phyblkwrt) AS total_io FROM v$recovery_progress rp JOIN v$session s ON (rp.parameter1 = TO_CHAR(s.sid) AND rp.parameter2 = TO_CHAR(s.serial#)) JOIN v$sess_io d ON (s.sid = d.sid) WHERE rp.status = 'IN PROGRESS' GROUP BY rp.type, rp.item;
通过深入理解 V$RECOVERY_PROGRESS 视图,DBA 可以有效地监控和管理数据库恢复操作,确保恢复过程顺利进行,并在出现问题时能够快速诊断和解决。
欢迎关注我的公众号《IT小Chen》
1395

被折叠的 条评论
为什么被折叠?



