tablespace i/o stats数据源自采样差值，需严格对齐快照时间；不提供readtim，须下钻dba_hist_filestatxs并乘10换算avg_read_ms；sysaux/system异常多为awr自产负载；rac环境下该视图全局聚合，不可信，须分实例分析。
看Tablespace I/O Stats前先确认快照时间对齐
AWR报告里的Tablespace I/O Stats章节看似直接，但数据来自DBA_HIST_TABLESPACE_STAT，它本质是采样瞬时值做差，不是精确累加。如果两份报告快照ID不一致、或跨时段对比没对齐起止时间，PHYSICAL_READS数值会失真——比如某表空间在快照开始前刚被大量刷脏，开头采样值就偏高，导致后续计算出的“每秒读”虚高。务必用DBA_HIST_SNAPSHOT核对BEGIN_INTERVAL_TIME和END_INTERVAL_TIME是否严格匹配，尤其排查RAC环境时，不同实例快照可能有秒级偏差。
别信PHYSICAL_READS总数，重点算AVG_READ_MS
表空间级统计不提供readtim字段，所以Tablespace I/O Stats里只显示读写次数和块数，无法直接算延迟。这是最大陷阱：你看到USERS表空间PHYSICAL_READS高达200万次，但不知道这200万次是分散在60分钟里均匀发生，还是集中在某3分钟内爆发。真正反映I/O质量的是单次响应时间。必须下钻到文件级：DBA_HIST_FILESTATXS里READTIM单位是百分之一秒（centisecond），要换算成毫秒得乘10，再除以PHYRDS。漏掉乘10，avg_read_ms会小一个数量级，误判为“正常”。示例SQL中必须带NULLIF(f.phyrds, 0)，否则除零报错中断查询。
当SYSAUX或SYSTEM表空间I/O异常升高，先查AWR自身开销
这两个系统表空间物理读突增，90%以上不是业务SQL导致，而是AWR快照收集、ADDM分析、甚至DBMS_STATS自动任务在后台密集写入。检查DBA_HIST_WR_CONTROL确认SNAP_INTERVAL是否被无意调短（如从60分钟改成15分钟），或RETENTION设得过大导致历史数据堆积。用以下SQL快速定位源头：
SELECT sql_id, sql_text FROM dba_hist_sqlstat s JOIN dba_hist_sqltext t USING (sql_id) WHERE parsing_schema_name = 'SYS' AND sql_text LIKE '%SYSAUX%' AND snap_id IN (&snap_id) ORDER BY elapsed_time_delta DESC FETCH FIRST 5 ROWS ONLY;
若发现大量INSERT INTO WRH$_SEGMENT_STATISTICS或UPDATE WRH$_SYSMETRIC_HISTORY，基本锁定是AWR自产负载。
RAC环境下Tablespace I/O Stats完全不可信
该章节是全局聚合视图，不区分实例。一个典型反例：UNDOTBS1表空间在实例1上I/O占比85%，实例2仅15%，但合并报告里显示“UNDOTBS1 reads: 1.2M”，掩盖了实例1实际承受了近100万次读的压力。这种失衡会导致你误判为undo段设计不合理，而真实问题是实例1承担了绝大多数事务，实例2空闲——根因可能是服务名未正确负载均衡，或应用连接串硬编码了实例名。必须改用@?/rdbms/admin/awrrpti.sql生成per-instance报告，单独看每个实例的Tablespace I/O Stats，再比对GV$INSTANCE的STARTUP_TIME确认是否所有节点都在线且稳定运行。
