好的，我们将对 Oracle 19C 数据库中用于高级性能诊断的核心视图——V$BACKUP_SYNC_IO——进行极其详细的解析。这个视图是理解和管理 RMAN 备份性能的钥匙。
1. 视图概述与核心作用
V$BACKUP_SYNC_IO 动态性能视图的作用是提供关于 RMAN 备份和恢复操作中发生的每一次同步 I/O 的详细统计信息和性能指标。
同步 I/O（Synchronous I/O） 是指进程发起一个 I/O 请求后，会阻塞并等待该 I/O 操作彻底完成，才能继续执行下一步操作。
核心作用可以概括为：
- 微观性能诊断：不再是查看整个备份集的总时间，而是深入到每一个独立的 I/O 调用，精确到毫秒级的速度、等待时间和效率。
- 瓶颈定位：准确判断性能瓶颈是出现在读取端（从数据文件/归档日志读取）、写入端（向备份片写入），还是由系统 I/O 子系统本身（如磁盘慢、网络延迟高）引起的。
- 问题排查：识别低效的 I/O 操作，例如大量的短时 I/O（
SHORT_WAITS）或异常长的等待（LONG_WAITS），这可能表明配置不当（如缓冲区大小不合理）。 - 优化验证：验证对
DB_FILE_DIRECT_IO_COUNT、BACKUP_TAPE_IO_SLAVES等参数调整后的实际效果。
2. 使用场景
-
备份/恢复速度缓慢调查：
当 RMAN 作业耗时异常时，查询此视图可以计算出精确的平均读取和写入速率（MB/s），直接判断是源存储、目标存储还是网络成为瓶颈。 -
优化 RMAN 配置：
通过分析SHORT_WAITS与LONG_WAITS的比例以及平均 I/O 大小，可以决定是否需要调整DB_FILE_DIRECT_IO_COUNT参数以增大每次 I/O 操作的数据量，减少系统调用次数。 -
识别资源争用：
查看EFFECTIVE_BYTES_PER_SECOND并与理论带宽对比，可以判断备份操作是否正在与其它应用激烈争用 I/O 资源。 -
诊断特定备份片问题：
如果某个备份片创建时间特别长，可以通过HANDLE字段过滤出该备份片的所有 I/O 操作，进行单独分析。
3. 字段详细含义
此视图字段众多，以下是对关键字段的详细解释：
| 字段名 | 数据类型 | 含义说明 |
|---|---|---|
| SID | NUMBER | 执行该 I/O 操作的服务器进程的标识符。可用于与 V$SESSION 和 V$PROCESS 关联。 |
| SEQ | NUMBER | 同一个会话 (SID) 中 I/O 操作的序列号，用于区分同一会话内的多次 I/O。 |
| TYPE | VARCHAR2(13) | I/O 操作的类型： • AGGREGATE : 汇总行（通常是所有操作的合计）• INPUT : 读取操作（从数据文件、归档日志等源读取）• OUTPUT : 写入操作（向备份片或镜像拷贝写入） |
| STATUS | VARCHAR2(8) | I/O 操作的状态： • IN PROGRESS : 正在进行中• FINISHED : 已完成• MERGE COMPLETE : (用于增量备份合并) |
| FILETYPE | VARCHAR2(9) | 正在备份的文件类型： • DATAFILE• ARCHIVELOG• SPFILE• CONTROLFILE |
| FILENO / BLOCKNO | NUMBER | 对于 DATAFILE 类型，这是文件号和起始块号。 |
| BUFFER_SIZE | NUMBER | 用于此 I/O 操作的缓冲区大小（字节）。 |
| BUFFERS | NUMBER | 涉及到的缓冲区数量。 |
| IO_COUNT | NUMBER | 物理 I/O 请求的次数。 |
| READY | NUMBER | I/O 请求已准备就绪的次数（异步 I/O 概念，在此视图中意义不大）。 |
| SHORT_WAITS | NUMBER | 进程为完成 I/O 而经历的短等待事件的次数。 |
| LONG_WAITS | NUMBER | 进程为完成 I/O 而经历的长等待事件的次数。 |
| BYTES | NUMBER | 此 I/O 操作传输的总字节数。 |
| OPEN_TIME / CLOSE_TIME | DATE | I/O 操作开始和结束的时间。 |
| ELAPSED_TIME | NUMBER | I/O 操作从开始到结束的总耗时（百分之一秒）。 |
| EFFECTIVE_BYTES_PER_SECOND | NUMBER | 有效的吞吐率（字节/秒）。这是衡量 I/O 效率的最关键指标。 |
| DISCRETE_BYTES_PER_SECOND | NUMBER | 离散吞吐率，通常接近于物理设备的速度。 |
| IO_CUR_RATE | NUMBER | 当前 I/O 速率（字节/秒）。 |
| MAXIO_CUR_RATE | NUMBER | 最大当前 I/O 速率（字节/秒）。 |
| DEVICE_TYPE | VARCHAR2(17) | I/O 设备类型 (DISK, SBT_TAPE)。 |
| HANDLE | VARCHAR2(513) | 对于 OUTPUT 类型，这是备份片的文件名；对于 INPUT 类型，这是源数据文件的路径。 |
| MEDIA | VARCHAR2(80) | 介质名称（主要用于磁带）。 |
4. 相关视图与基表
-
姊妹视图：
V$BACKUP_ASYNC_IO：这是V$BACKUP_SYNC_IO的异步版本。绝大多数情况下，RMAN 会优先使用异步 I/O 以获得最佳性能。只有当异步 I/O 不可用或被禁用时，才会使用同步 I/O。两个视图的结构几乎完全相同，是性能分析时必须同时关注的对象。V$BACKUP_SET,V$BACKUP_PIECE,V$BACKUP_DATAFILE：这些视图提供备份的元数据信息，可以通过SID或HANDLE与V$BACKUP_SYNC_IO关联，从而将性能数据与具体的备份对象联系起来。
-
**底层基表（X表）∗∗：‘V表）**： `V表）∗∗：‘VBACKUP_SYNC_IO
的数据来源于 SGA 中专门用于跟踪 RMAN I/O 操作的**内存数据结构**。其底层关联的 **X$表**（如可能存在的XKCCBI‘或类似结构）是∗∗不公开∗∗的。这些表实时记录每个通道进程发起的I/O请求和完成状态。∗∗重要警告∗∗：严禁直接查询XKCCBI` 或类似结构）是**不公开**的。这些表实时记录每个通道进程发起的 I/O 请求和完成状态。 **重要警告**：严禁直接查询 XKCCBI‘或类似结构）是∗∗不公开∗∗的。这些表实时记录每个通道进程发起的I/O请求和完成状态。∗∗重要警告∗∗：严禁直接查询X 表。
5. 相关底层详细原理
-
同步 I/O 流程：
- 发起请求：RMAN 通道进程准备好一个缓冲区（Buffer），然后发起一个
read()或write()系统调用。 - 进程阻塞：进程立即被操作系统置入睡眠（Sleep）状态，等待内核完成底层的 I/O 操作。
- I/O 完成：磁盘控制器或网络将数据读取到内存或发送完毕后，内核唤醒睡眠的进程。
- 进程继续：进程从系统调用中返回，继续执行下一个操作（如处理数据或准备下一个缓冲区）。
- 发起请求：RMAN 通道进程准备好一个缓冲区（Buffer），然后发起一个
-
数据收集：
Oracle 内核在 RMAN 进程发起和完成每一个同步 I/O 请求时，都会在 SGA 的固定区域填充一个统计记录。这些记录包括时间戳、传输字节数、等待时间等。V$BACKUP_SYNC_IO视图就是这些内存记录的对外窗口。 -
性能指标计算：
视图中的许多字段（如EFFECTIVE_BYTES_PER_SECOND）并非直接存储，而是由 Oracle 在查询时根据基础数据（BYTES/ (ELAPSED_TIME/100)）动态计算出来的。
6. 相关知识点介绍
-
同步 vs. 异步 I/O：
- 同步 I/O：简单，但性能差，因为进程需要等待。是备份性能不佳的常见原因。
- 异步 I/O (AIO)：进程发起 I/O 请求后立即返回，继续做其它工作（如处理已读入的数据），待 I/O 完成后由操作系统通知它。能极大提升吞吐量，是 Oracle 的默认和推荐模式。
-
如何启用异步 I/O：
- 对于磁盘：通常由
FILESYSTEMIO_OPTIONS参数控制（设置为SETALL或ASYNCH）。 - 对于磁带：通常由
BACKUP_TAPE_IO_SLAVES参数控制（设置为TRUE）。 - 如果平台不支持 AIO，或上述参数未正确设置，RMAN 会自动降级使用同步 I/O。
- 对于磁盘：通常由
-
直接 I/O (Direct I/O)：
RMAN 始终使用直接 I/O，绕过操作系统缓冲区缓存，以避免污染缓存并保证性能的一致性。DB_FILE_DIRECT_IO_COUNT参数影响 RMAN 每次 I/O 操作的大小。
7. 常用查询 SQL
1. 查看当前正在进行的同步 I/O 操作（实时监控）：
SELECT sid, type, filetype, filename, buffers, buffer_size,
bytes, elapsed_time, effective_bytes_per_second
FROM v$backup_sync_io
WHERE status = 'IN PROGRESS';
2. 分析已完成备份操作的 I/O 效率（性能诊断）：
-- 按操作类型(INPUT/OUTPUT)汇总，这是最关键的诊断查询
SELECT type,
SUM(bytes) total_bytes,
SUM(elapsed_time) total_hundredths_sec,
ROUND(SUM(bytes) / (SUM(elapsed_time)/100) / 1024/1024, 2) avg_throughput_mb_sec,
SUM(short_waits) short_waits,
SUM(long_waits) long_waits,
ROUND(SUM(bytes) / SUM(io_count), 2) avg_io_size
FROM v$backup_sync_io
WHERE status = 'FINISHED'
GROUP BY type;
3. 查找效率低下的备份片（针对性优化）：
-- 对于OUTPUT操作，低吞吐率可能意味着目标存储是瓶颈
SELECT handle, device_type,
ROUND(bytes/1024/1024,2) size_mb,
elapsed_time/100 elapsed_sec,
ROUND((bytes/(elapsed_time/100))/1024/1024,2) throughput_mb_sec
FROM v$backup_sync_io
WHERE type = 'OUTPUT'
AND status = 'FINISHED'
ORDER BY throughput_mb_sec ASC; -- 找出速率最慢的写入操作
4. 检查平均 I/O 大小，以调整参数：
-- 如果平均I/O大小远小于 DB_FILE_DIRECT_IO_COUNT，说明有很多小I/O，可能需调整
SELECT type,
ROUND(AVG(io_count), 2) avg_io_count,
ROUND(AVG(bytes), 2) avg_bytes_per_io,
ROUND(MAX(bytes), 2) max_bytes_per_io
FROM v$backup_sync_io
WHERE status = 'FINISHED'
GROUP BY type;
5. 综合查询：关联备份集和信息，进行根因分析
SELECT bs.tag, io.type, io.filetype,
ROUND(io.bytes/1024/1024,2) io_mb,
io.elapsed_time/100 io_sec,
ROUND((io.bytes/(io.elapsed_time/100))/1024/1024,2) io_mb_sec,
io.handle
FROM v$backup_sync_io io
JOIN v$backup_piece bp ON (io.handle = bp.handle)
JOIN v$backup_set bs ON (bp.set_stamp = bs.set_stamp AND bp.set_count = bs.set_count)
WHERE io.status = 'FINISHED'
AND bs.completion_time > SYSDATE - 1 -- 查看最近一天内的备份
ORDER BY io_mb_sec ASC;
通过深入理解 V$BACKUP_SYNC_IO 视图，您可以将 RMAN 性能 troubleshooting 从猜测提升到基于数据的精确分析，从而有效地解决备份和恢复过程中的性能瓶颈。
欢迎关注我的公众号《IT小Chen》
扫一扫
49
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
