应查DBA_HIST_IOSTAT_DETAIL视图定位表空间级IO分布，通过JOIN DBA_DATA_FILES或DBA_TEMP_FILES关联表空间名，区分DATA FILE/TEMP FILE类型，按SMALL_READ_MEGABYTES等字段汇总吞吐量，并严格限定SNAP_ID范围。
查 DBA_HIST_IOSTAT_DETAIL 视图定位表空间级IO分布
AWR本身不直接在标准HTML报告里展示「每个表空间的读写吞吐量（MB/s）」，必须手动查历史IO统计视图。核心是DBA_HIST_IOSTAT_DETAIL，它按文件类型（FILETYPE_NAME）和文件ID（FILENO）记录每小时快照的IO量，而表空间名需通过DBA_DATA_FILES或DBA_TEMP_FILES反向关联。
常见错误是直接查v$iostat_file——那是实时内存数据，无法回溯；或者误用DBA_HIST_IOSTAT_FILE（该视图按文件路径聚合，不含表空间字段，且字段命名易混淆）。
-
SMALL_READ_REQS/SMALL_WRITE_REQS是IOPS，不是吞吐量；真正对应「读写MB」的是SMALL_READ_MEGABYTES和SMALL_WRITE_MEGABYTES - 注意
FILETYPE_NAME值：'DATA FILE' 对应永久表空间，'TEMP FILE' 对应临时表空间，'LOG FILE' 不属于表空间范畴，别混入计算 - 查询时务必加时间范围过滤（
SNAP_ID BETWEEN ...），否则默认返回全部历史，性能极差
用SQL把文件IO汇总到表空间维度
需要两层JOIN：先用DBA_HIST_IOSTAT_DETAIL拿到各文件的IO量，再用DBA_DATA_FILES或DBA_TEMP_FILES映射到TABLESPACE_NAME。临时表空间要单独处理，因为它的文件在DBA_TEMP_FILES里，且FILE_NO可能与数据文件重叠。
示例语句（只查数据文件）：
SELECT d.tablespace_name,
SUM(i.small_read_megabytes) rd_mb,
SUM(i.small_write_megabytes) wr_mb,
COUNT(*) snap_count
FROM dba_hist_iostat_detail i
JOIN dba_data_files d ON i.fileno = d.file_id
WHERE i.filetype_name = 'DATA FILE'
AND i.snap_id BETWEEN 12345 AND 12346
GROUP BY d.tablespace_name
ORDER BY rd_mb + wr_mb DESC;
- 如果发现某表空间
rd_mb极高但buffer hit%也高（>99%），大概率是逻辑读密集型操作（如大索引扫描），未必真压IO子系统 -
temp表空间的SMALL_READ_MEGABYTES突然飙升，通常对应大量排序/Hash Join溢出到磁盘，不是表空间配置问题，而是SQL执行计划异常 - 不要用
SUM()直接除以秒数算“平均MB/s”——AWR快照间隔不固定（可能被手动调整过），应先用dba_hist_snapshot算出实际秒数再加权
对比 IO Stats 报告节与自定义查询结果的差异
标准AWR报告里的「IO Stats」章节只显示实例级汇总（如Physical read total IO requests），以及按function（如DBWR、LGWR）拆分的IO，**不出现表空间名**。有人试图从「Tablespace IO Stats」小节找数据，但该节只列Av Reads/s和Av Rd(ms)，且仅限当前快照起止间有IO活动的表空间，缺失静默表空间，也不含写入量。
- 当
DBA_HIST_IOSTAT_DETAIL查出USERS表空间IO占比70%，但「Tablespace IO Stats」里没它——说明该表空间IO集中在快照边界附近，未被采样捕获，需缩小时间窗口重查 - 「IO Stats」中
Read IO (MB)数值应≈所有数据文件SMALL_READ_MEGABYTES之和，若偏差>5%，检查是否遗漏ASM磁盘组或bigfile表空间（其FILE_ID可能超出DBA_DATA_FILES关联范围） - RAC环境下，
DBA_HIST_IOSTAT_DETAIL默认只返回本实例数据，跨实例汇总需加INSTANCE_NUMBER条件并确认全局临时表空间归属
识别吞吐量异常的真实瓶颈点
单纯看「某表空间读了200MB/s」没意义——得结合硬件能力判断是否过载。比如SAN存储标称单LUN吞吐上限为150MB/s，而SYSAUX表空间持续跑220MB/s，那IO等待必然上升；但若只是UNDOTBS1偶尔冲到180MB/s（且log file sync等待未涨），大概率是批量事务提交导致，属正常脉冲。
- 优先核对
Top 5 Timed Events：若db file sequential read或direct path read排前三，且对应表空间正是高读取者，才需深入 - 检查
Physical read total bytes（实例级）与各表空间rd_mb总和是否匹配，不匹配说明有control file或redo log读被忽略（它们不归属任何表空间） - 虚拟化环境（如VMware）下，
cell physical IO interconnect bytes可能远高于表空间级读取量——这是存储网络层开销，不能归因于Oracle表空间设计
create_snapshot在任务前后手动打点，再查DBA_HIST_IOSTAT_DETAIL，否则看到的只是假象。 
