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 小时数据。想查更久远的速率，得靠间接推算。
查最近 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_io
WHERE close_time > SYSDATE - 1
ORDER 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) "Avg_MB/s"
FROM V$RMAN_BACKUP_JOB_DETAILS
WHERE operation = 'BACKUP'
AND status = 'COMPLETED'
AND start_time > SYSDATE - 7
ORDER 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 的状态流转节奏，以及你是否清楚当前备份类型（全库 vs 归档 vs 表空间）对应的 I/O 模式。漏掉任一环，MB/s 就只是幻觉。
