如何用Oracle 11g RMAN查看备份历史速率
在Oracle11g中,可通过V$BACKUP_ASYNC_IO的effective_bytes_per_second字段查看最近24小时异步备份速率(需换算为MB/s或GB/s);更久远历史速率需从V$RMAN_BACKUP_JOB_DETAILS的INPUT_BYTES和ELAPSED_SECONDS手动计算,但该平均值忽略并行、等待等因素。
RMAN备份速率查询是数据库管理员常遇到的问题。许多用户直接查阅官方文档,却发现相关视图种类繁多,但能直接获取速率的视图并不多。
实际上,V$BACKUP_ASYNC_IO 几乎是唯一一个能从视图中直接读出速率的途径。该视图仅记录异步I/O模式下的实际吞吐量,即 effective_bytes_per_second 字段,且默认只保留最近24小时的数据。如需查询更早的速率,则需要通过 V$RMAN_BACKUP_JOB_DETAILS 中的 INPUT_BYTES 和 ELAPSED_SECONDS 自行计算。

查询最近24小时的实时备份速率(含单位换算)
V$BACKUP_ASYNC_IO 表记录了每次备份I/O的起止时间、字节数和耗时。关键字段 effective_bytes_per_second 已由Oracle计算好有效速率,单位为字节/秒。如需换算为MB/s或GB/s,可自行除法运算。
常用查询如下(已转换为GB/s可读格式):
SELECT device_type "Device", TYPE, TO_CHAR(open_time, 'yyyy-mm-dd hh24:mi:ss') "Open", TO_CHAR(close_time, 'yyyy-mm-dd hh24:mi:ss') "Close", ROUND(elapsed_time / 60, 1) "Elapsed_min", ROUND(effective_bytes_per_second / 1024 / 1024, 2) "MB/s", ROUND(bytes / 1024 / 1024 / 1024, 2) "Size_GB"FROM v$backup_async_ioWHERE close_time > SYSDATE - 1ORDER BY close_time DESC;
使用该视图时需注意以下几点:
elapsed_time是真实耗时(秒),而非SYSDATE - open_time。后者可能包含等待或空闲时间,计算出的速率会失真。- 若
effective_bytes_per_second为NULL,表明该次I/O采用同步模式。例如小文件备份、归档日志备份未走异步路径,该视图无法提供速率。 TYPE字段常见值包括DATAFILE、ARCHIVELOG、CONTROLFILE。不同类型速率差异较大,混合计算平均值意义不大。
查询超过24小时的估算速率(使用 V$RMAN_BACKUP_JOB_DETAILS)
该视图虽未直接提供速率,但包含 INPUT_BYTES 和 ELAPSED_SECONDS。手动计算平均速率可实现估算:
SELECT start_time, completion_time, ROUND((input_bytes / 1024 / 1024 / 1024), 2) "Input_GB", elapsed_seconds "Elapsed_sec", ROUND((input_bytes / elapsed_seconds / 1024 / 1024), 2) "A vg_MB/s"FROM V$RMAN_BACKUP_JOB_DETAILSWHERE operation = 'BACKUP' AND status = 'COMPLETED' AND start_time > SYSDATE - 7ORDER BY start_time DESC;
需注意,此计算仅反映“总输入量 ÷ 总耗时”。它忽略了通道并行、I/O等待、压缩开销等因素,实际峰值速率通常高于此值2至5倍。此外,INPUT_BYTES 包含重复读取(如归档日志多次扫描)、控制文件快照等,不一定等于最终写入备份片的大小。若 elapsed_seconds 为0或极小(如1秒),说明备份任务被快速调度,但实际I/O在后台异步完成,此时计算出的MB/s会严重失真。
为什么 V$BACKUP_SYNC_IO 不适合查速率?
该视图仅记录同步I/O的等待事件,例如 direct path write。它不包含字节数,也没有完成时间戳,因此无法计算速率。其真正用途是排查卡顿:若 WAIT_TIME 较长或 WAIT_COUNT 较高,说明磁盘响应慢,与MB/s无关。
- 不要将其与
V$BACKUP_ASYNC_IO混用。两者底层机制不同,数据不可直接比较。 - 若观察到大量
SYNC类型的I/O,表明RMAN正以同步方式写入小对象,如控制文件副本。此类操作本身不应追求高吞吐。 - 启用
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET后,绝大多数数据文件备份走异步路径,V$BACKUP_ASYNC_IO才是主要数据来源。
速率不准的三个典型信号
查出的数值看似合理,但实际业务感知缓慢?警惕以下三个信号:
V$BACKUP_ASYNC_IO中,同一DEVICE_TYPE下多条记录的MB/s波动极大(例如从50到300)。这表示存储存在热点,或队列分配不均。问题不在于平均值,而在于I/O调度失衡。V$RMAN_STATUS中STATUS长期显示RUNNING WITH WARNINGS,同时V$SESSION_LONGOPS显示OPNAME为aggregate backup,但TIME_REMAINING不下降。这大概率是归档日志扫描卡住,属于逻辑阻塞,而非速率问题。- 备份命令使用了
AS COMPRESSED BACKUPSET,但V$RMAN_BACKUP_JOB_DETAILS的OUTPUT_BYTES远小于INPUT_BYTES。若基于INPUT_BYTES计算速率,会低估真实写入效率。
真正影响速率判断的,并非单个数字。需关注 V$BACKUP_ASYNC_IO 的分布形态、V$RMAN_STATUS 的状态流转节奏,以及当前备份类型(全库、归档还是表空间)对应的I/O模式。遗漏任何一环,MB/s便只是幻觉。
