如何查询RMAN备份速率？这是DBA工作中常见的需求。很多人在查找官方文档时发现，虽然存在多个视图，但能直接读取速率信息的视图并不多。
实际上，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格式：
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记录的是真实的I/O耗时（秒），而非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），既不包含字节数，也不记录完成时间戳，因此无法计算速率。它的真正用途是排查I/O卡顿问题：如果 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都只是数字上的幻觉。
