adr中表空间不足诊断需四步：查ora-01653/ora-1652告警trace；用adrci按时间窗过滤incident并分析log.xml；排查temp与os /tmp满耦合；核查用户配额为0导致的静默失败。
直接查ADR中与表空间不足强相关的告警和trace
ORA-01653、ORA-1652这类错误一定会写入ADR（Automatic Diagnostic Repository），但不是所有日志都进alert.log——尤其RAC节点挂起时，部分会落在trace或incident子目录。别只盯着alert_ORCL.log，先定位ADR base路径：SELECT value FROM v$diag_info WHERE name = 'Diag Base';，然后进对应路径下的rdbms/<sid>/<sid>/trace/</sid></sid>找最近的ora_<pid>.trc</pid>，用grep -i "unable to extend\|ORA-01653\|ORA-1652" *.trc快速筛出线索。
用ADRCI过滤“表空间+挂起”组合事件
ADRCI比手动翻文件高效得多，关键是用条件过滤而非全量扫描：
- 进入ADRCI后执行
SHOW HOMES确认当前实例home； - 运行
SET HOME <home_path></home_path>（如rdbms/orcl/ORCL）； - 执行
IPS CREATE PACKAGE INCIDENT TIME "2026-08-25 14:00:00" TO "2026-08-25 15:30:00"限定时间窗； - 再用
IPS GENERATE PACKAGE导出压缩包，解压后重点看incpkg/里含ORA-01653或ORA-1652的incident目录，里面log.xml会记录触发该错误的SQL、会话ID及堆栈； - 若发现多个incident都指向同一表空间（如
TS_DATA），且时间点与节点假死一致，基本可锁定根源。
结合ADR诊断临时表空间与OS /tmp冲突
RAC节点挂起常是数据库TEMP不足 + OS /tmp满双重触发，ADR里不会直接报No space left on device，但会留下间接证据：
- 在
trace中搜hsperfdata_或OraInstall，若出现write failed或open(/tmp/...)失败，说明OS层已卡； - 检查
incident下是否有ASM相关错误（如ORA-15075或ORA-01114），这类错误常伴随/tmp满导致ASM扫描失败； - 对比
v$diag_alert_ext中message_text含TEMP和/tmp的日志时间戳——若两者误差在秒级内，就是典型耦合故障。
别忽略ADR里被忽略的配额类静默失败
用户配额为0（max_bytes = 0）导致ORA-01653时，ADR中通常只有单条ORA-01653，无上下文堆栈，极易误判为磁盘满。这时要交叉验证：
- 从ADR中提取报错会话的
session_id（在incident的log.xml里找SESSION_ID字段）； - 用该ID查
v$session拿到username和tablespace； - 立即执行
SELECT max_bytes FROM dba_ts_quotas WHERE username = '&user' AND tablespace_name = '&ts';——若返回0，问题就在这儿，和磁盘、自动扩展全无关。
配额问题在ADR里不报错细节，只留结果，必须人工补查，这是最常被跳过的环节。
