ADDM报告中“Tablespace I/O Hotspot”表明某表空间下多个数据文件I/O延迟显著偏高，源于ASH采样发现db file sequential/scattered read等待时间远超阈值，且集中于同一表空间，需检查大对象分布及热冷分区混用情况。
ADDM报告里出现“Tablespace I/O Hotspot”说明什么
这不是警告磁盘坏了，而是addm通过ash采样发现某几个数据文件的db file sequential read或db file scattered read等待时间远超其他文件，且集中在同一表空间下。它不直接说“该表空间要拆”，但会把“affected area”标为storage configuration，并提示“i/o latency on datafiles in tablespace users exceeds threshold”。此时别只盯着sql，先查这个表空间里有哪些大对象、是否混了热分区和冷分区。
怎么从ADDM建议反推表空间是否该分拆
重点看ADDM每个FINDING下的Impact值和关联对象：
- 如果Impact > 2.0分钟，且
Related Objects列出多个不同业务模块的表（比如orders、logs_2025_q3、config_cache），说明I/O争用是跨应用的——大概率共用了USERS或APP_DATA这类通用表空间 - 如果FINDING里提到“high buffer busy waits on segment header”或“segment is in same tablespace as other high-DML objects”，基本可断定多个高并发表/分区挤在同一个表空间，物理上无法隔离
- 执行
SELECT tablespace_name, COUNT(*) FROM dba_segments WHERE blocks > 10000 GROUP BY tablespace_name ORDER BY 2 DESC;，若某个表空间段数远超其他（比如>200），又没做分区表空间绑定，就是典型隐患点
建新表空间时哪些参数必须差异化设置
不能只复制CREATE TABLESPACE ...语句然后改个名。关键差异点在物理路径、扩展策略和缓存属性：
-
AUTOEXTEND：高频写入分区（如最近季度）设NEXT 100M；归档分区设AUTOEXTEND OFF，避免误增长填满磁盘 -
FLASH_CACHE：SSD存储的表空间加FLASH_CACHE DEFAULT；SAS/NL-SAS存储的禁用，否则反而增加闪存管理开销 - 数据文件路径必须落在不同挂载点（如
/u01/oradatavs/u02/oradata），仅靠ASM条带化不足以解决单盘IO饱和问题 - 建完后立刻执行
ALTER TABLESPACE ts_2026_q2 READ WRITE;，别依赖默认状态——ADDM对READ ONLY表空间的I/O分析会降权
分区表绑定表空间最容易漏掉的一步
很多人建完独立表空间，ALTER TABLE ADD PARTITION时写了TABLESPACE ts_2026_q2，却忘了原表的DEFAULT TABLESPACE仍是USERS。结果后续没显式指定表空间的新分区，或者MOVE PARTITION操作没带TABLESPACE子句，数据又悄悄回流到默认表空间。
必须做两件事：
- 检查建表语句中每个
PARTITION子句是否都含TABLESPACE，一个都不能省——dba_tab_partitions里tablespace_name字段为空就说明有问题 - 执行
ALTER USER your_app_user DEFAULT TABLESPACE users_temporary;（设成临时表空间），彻底阻断新对象意外落入USERS
ADDM不会提醒你默认表空间还在生效，它只告诉你I/O热点在哪。真正的优化动作，永远发生在报告生成之前。
