V$BACKUP_ASYNC_IO是唯一能直接查RMAN备份历史速率的视图,它记录异步I/O下的effective_bytes_per_second(字节/秒),但仅保留最近24小时数据;更久远的速率需用V$RMAN_BACKUP_JOB_DETAILS中INPUT_BYTES与ELAPSED_SECONDS间接推算。
v$backup_async_io 是唯一能直接查出 rman 备份历史速率的视图,但它只记录异步 i/o 模式下的实际吞吐(effective_bytes_per_second),且默认只保留最近 24 小时数据。想查更久远的速率,得靠间接推算。
V$BACKUP_ASYNC_IO 记录每次备份 I/O 的起止时间、字节数和耗时,effective_bytes_per_second 字段就是 Oracle 算好的“有效速率”,单位是字节/秒。
常用查询(带 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,不同类型的速率差异很大,不能混在一起看平均值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) "Avg_MB/s"FROM V$RMAN_BACKUP_JOB_DETAILSWHERE operation = 'BACKUP' AND status = 'COMPLETED' AND start_time > SYSDATE - 7ORDER BY start_time DESC;
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 的状态流转节奏,以及你是否清楚当前备份类型(全库 vs 归档 vs 表空间)对应的 I/O 模式。漏掉任一环,MB/s 就只是幻觉。