Oracle 11g RMAN查看备份历史速率方法

如何查询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都只是数字上的幻觉。