SQLHC不诊断表空间性能瓶颈，其设计仅聚焦单条SQL的执行环境健康度，包括CBO统计信息、执行计划、对象元数据和优化器参数等，不采集或分析表空间状态、数据文件I/O、空间使用率等存储层指标。
SQLHC 本身不诊断表空间性能瓶颈
sqlhc sqlhc.sql 脚本的设计目标非常明确：只分析单条 sql 语句的执行环境健康度，包括 cbo 统计信息、执行计划、对象元数据、优化器参数等。它**不采集、不分析、也不报告任何与表空间（如 sys.auxiliary_tablespace、dba_tablespaces 状态、数据文件 i/o、空间使用率、段争用）相关的信息**。
如果你在运行 SQLHC 后发现报告里没有“表空间”“datafile”“autoextend”“free space”等内容，不是操作错了，而是工具本来就不覆盖这个维度。
- 常见错误现象：看到 SQL 执行慢，又查到
DBA_TABLESPACES中某个表空间USED_SPACE接近 100%，就以为 SQLHC 应该能定位到——它不会 - 真正影响 SQL 性能的表空间问题，通常表现为底层 I/O 延迟（如
db file sequential read等待事件飙升），而 SQLHC 不解析 AWR/ASH 的等待事件分布，也不关联V$FILESTAT - SQLHC 报告中可能出现的“间接线索”仅限于：某张表的统计信息陈旧 → 导致优化器误选全表扫描 → 进而放大表空间物理读压力；但这属于归因链的上游，不是表空间本身的诊断
表空间性能瓶颈该用什么查？
当怀疑表空间成为 SQL 性能瓶颈时，必须切换到系统级或存储层视角，用 Oracle 原生动态视图和 AWR 报告组合排查：
- 确认高 I/O 是否真实存在：
SELECT * FROM V$SYSTEM_EVENT WHERE EVENT LIKE 'db file%read' ORDER BY TIME_WAITED DESC—— 若db file sequential read或db file scattered read占比异常高，才值得继续深挖表空间 - 定位具体数据文件：
SELECT FILE#, PHYRDS, PHYWRTS, READTIM, WRITETIM FROM V$FILESTAT ORDER BY READTIM DESC—— 高READTIM的文件对应表空间需重点检查 - 检查空间是否耗尽或频繁扩展：
SELECT TABLESPACE_NAME, USED_PERCENT, STATUS FROM DBA_TABLESPACE_USAGE_METRICS WHERE USED_PERCENT > 85；同时看DBA_DATA_FILES中AUTOEXTENSIBLE和MAXBYTES是否受限 - 识别段级争用：
SELECT SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME FROM DBA_SEGMENTS WHERE TABLESPACE_NAME = 'YOUR_TS' AND BLOCKS > 100000 ORDER BY BLOCKS DESC—— 大段可能引发本地管理表空间中的位图争用（尤其在 ASSM 下）
SQLHC 和表空间问题的唯一交集场景
只有当某条 SQL 的执行计划中出现大量 TABLE ACCESS FULL，且该表恰好位于一个已满、自动扩展被禁用、或数据文件所在磁盘 I/O 饱和的表空间时，SQLHC 才会“被动反映”这个问题——但它只告诉你“这张表没统计信息”或“执行计划不合理”，绝不会说“你该扩容 USERS 表空间”或“检查 /u01/oradata/db/data02.dbf 的磁盘队列”。
- 典型误判：SQLHC 报告提示“Missing Indexes on column X”，你立刻建索引，结果 SQL 依然慢——因为底层表空间数据文件所在的 LUN 已经响应超时，索引也救不了物理 I/O 瓶颈
- 参数差异：SQLHC 的输入参数只有
SQL_ID和授权类型（T/D/N），它不接受表空间名、文件 ID、或 ASH 时间范围等参数 - 性能影响：强行让 SQLHC “覆盖”表空间逻辑，需要重写脚本并加入对
V$DATAFILE、DBA_HIST_IOSTAT_DETAIL等视图的查询，这会破坏其“无足迹”“秒级生成”的轻量特性，也违背 Oracle 官方定位
真正要做的动作顺序
遇到 SQL 慢，别先跑 SQLHC。先做三件事：
- 查
V$SESSION+V$SESSION_WAIT看当前会话卡在哪类等待上；如果是enq: TS - contention或write complete waits，直接跳过 SQLHC，去查表空间和临时段 - 跑 AWR 报告（
awrrpt.sql），聚焦 “I/O Profile” 和 “Tablespace IO Stats” 部分，确认瓶颈是否在存储层 - 只有当等待事件指向 SQL 本身（如
cursor: pin S wait on X、library cache lock）或执行计划明显异常时，再用 SQLHC 锁定那条 SQL 的环境问题
表空间问题藏在 I/O 子系统里，SQLHC 只在 SQL 编译器层面工作。两者不在同一抽象层级，硬凑一起只会掩盖真正瓶颈点。
