11 · 空间类故障排查：表空间满 / 临时表空间爆 / 归档满挂库

空间故障的特点是可预测但总没人预测------它从来不是突然发生的，是监控缺位的必然结果。四类场景症状相似（业务报错/库挂起），但急救动作完全不同。本篇给每类一套"监控 SQL + 急救命令"。

一、全景：四类空间故障的分诊

场景	典型报错	直接后果	急救动作
数据表空间满	ORA-01653/01654（表/索引扩展失败）	DML 报错	加数据文件/扩容
临时表空间满	ORA-01652（temp 扩展失败）	排序/查询报错	加 tempfile
归档区满	ORA-00257（archiver error）	整个库挂起，DML 全停	RMAN 清归档
ASM 磁盘组满	alert 报无法扩展	文件创建失败	加盘/清空间

严重性排序：ORA-00257 > ORA-01652 > ORA-01653。归档满会让数据库"罢工"，是唯一的全局性故障。

二、场景一：数据表空间满（ORA-01653）

2.1 诊断

sql 复制代码

-- 表空间使用率（含 autoextend 上限）
SELECT d.tablespace_name,
 ROUND(SUM(NVL(a.bytes,0))/1024/1024) used_mb,
 ROUND(SUM(DECODE(a.autoextensible,'YES',a.maxbytes,a.bytes))/1024/1024) max_mb,
 ROUND(SUM(DECODE(a.autoextensible,'YES',a.maxbytes,a.bytes)-NVL(f.bytes,0))/1024/1024) free_mb
FROM dba_data_files a
JOIN dba_tablespaces d ON a.tablespace_name=d.tablespace_name
LEFT JOIN (SELECT tablespace_name, SUM(bytes) bytes FROM dba_free_space GROUP BY tablespace_name) f
 ON a.tablespace_name=f.tablespace_name
GROUP BY d.tablespace_name;

-- 是谁在吃空间：找段级大头
SELECT owner, segment_name, segment_type, ROUND(bytes/1024/1024) mb
FROM dba_segments
WHERE tablespace_name='USERS'
ORDER BY bytes DESC FETCH FIRST 10 ROWS ONLY;

2.2 处理

sql 复制代码

-- 立即止血：加数据文件
ALTER TABLESPACE USERS ADD DATAFILE '/u01/oradata/orcl/users02.dbf' SIZE 30G AUTOEXTEND ON NEXT 1G MAXSIZE UNLIMITED;

-- 根治：大头是谁？
-- 业务数据增长 → 容量规划、分区/归档历史数据
-- 索引膨胀 → REBUILD 降高水位
-- LOB 段 → 检查是否有"删了但段不缩"的 LOB（securefile 需 RETENTION 策略）

也可以用 shell 脚本实现表空间自动扩容（阈值触发 ALTER TABLESPACE ... ADD DATAFILE），适合没法立刻扩盘的过渡期------但要配总量上限，防止把存储吃穿。

三、场景二：临时表空间爆满（ORA-01652）

3.1 现象与原理

排序、哈希连接、全局临时表数据都消耗 temp。典型触发：新上的报表 SQL 带巨型 ORDER BY / DISTINCT，或并发批量任务叠加。

text 复制代码

ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

3.2 诊断

sql 复制代码

-- temp 总量视角
SELECT tablespace_name,
 SUM(bytes_used)/1024/1024 used_mb,
 SUM(bytes_free)/1024/1024 free_mb
FROM v$temp_space_header
GROUP BY tablespace_name;

-- 谁在吃：按会话/SQL 追责
SELECT username, sql_id, session_addr, SUM(blocks)*8/1024 mb
FROM v$tempseg_usage
GROUP BY username, sql_id, session_addr
ORDER BY SUM(blocks) DESC;

3.3 处理

sql 复制代码

-- 止血：加 tempfile
ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/oradata/orcl/temp02.dbf' SIZE 30G;

-- 19c+：可组临时表空间组，多库共享大 temp
ALTER TABLESPACE TEMP GROUP temp_grp;

⚠️ 常见踩坑 ：tempfile 开 AUTOEXTEND 时，小文件表空间单文件上限 32 GB------涨到顶照样 ORA-01652。要么一开始就大文件表空间（bigfile），要么预留多 tempfile。

根治：拿到 v$tempseg_usage 里的 SQL_ID，回 10-慢SQL分析路径优化（往往一条笛卡尔积/巨型排序被修好后，temp 需求断崖式下降）。

四、场景三：归档区满（ORA-00257）------最紧急

4.1 现象

text 复制代码

ORA-00257: archiver error. Connect internal only, until freed.

归档模式（ARCHIVELOG）下，归档目的地（通常是快速恢复区 FRA）写满时，ARCH 进程卡住 → LGWR 等归档 → 所有 commit 挂起 → 全库 DML 停摆。这是"业务全停"级别故障。

4.2 诊断

sql 复制代码

-- FRA 使用情况
SELECT name, ROUND(space_limit/1024/1024) limit_mb,
 ROUND(space_used/1024/1024) used_mb,
 ROUND(space_reclaimable/1024/1024) reclaimable_mb,
 round(space_used/space_limit*100,1) pct
FROM v$recovery_file_dest;

-- 明细：FRA 里都是什么
SELECT file_type, ROUND(percent_space_used,1) pct
FROM v$flash_recovery_area_usage ORDER BY percent_space_used DESC;

4.3 急救（务必走 RMAN，不要 rm！）

sql 复制代码

-- ① 确认备份策略允许删：已备份到带库/异地
RMAN> CROSSCHECK ARCHIVELOG ALL;
RMAN> DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;

-- ② 更常用的：删已备份过的归档（保留最近 1 天）
RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-1';

-- ③ 空间还不够：应急扩大 FRA 上限
SQL> ALTER SYSTEM SET db_recovery_file_dest_size=500G;

⚠️ 为什么不能 rm 归档文件 ：控制文件记录着归档目录。直接 rm 会导致 RMAN 元数据与磁盘不一致，后续备份报错；且已 rm 的文件若未被 RMAN 登记删除，FRA 统计不释放，库里照样认为满。永远 RMAN CROSSCHECK + DELETE。

4.4 根治

定时（如每日）RMAN 备份后自动 DELETE ARCHIVELOG ... BACKED UP 1 TIMES TO DEVICE TYPE DISK；
监控 v$recovery_file_dest 使用率，> 80% 告警。

五、场景四：ASM 磁盘组满

sql 复制代码

-- grid 用户 sqlplus / as sysasm
SELECT name, state, type,
 ROUND(total_mb/1024) total_gb, ROUND(free_mb/1024) free_gb,
 ROUND(free_mb/total_mb*100,1) free_pct
FROM v$asm_diskgroup;

-- 在线加盘（12c+ Flex ASM 同理）
ALTER DISKGROUP DATA ADD DISK '/dev/asm-disk5' FAILGROUP fg_a;
-- rebalance 进度
SELECT * FROM v$asm_operation; -- 看 EST_MINUTES

真实案例：RAC 磁盘组满无法扩容时，可在线处理（先降冗余度临时腾挪/清理冗余数据再插盘）；另一个案例是"磁盘空间又满了，竟是监控工具在作祟"------空间问题先找"谁在涨"，再谈扩容。

六、空间监控清单（把事故消灭在发生前）

对象	视图	告警阈值建议
数据表空间	dba_data_files + dba_free_space	> 85% 警告，> 95% 严重
临时表空间	v$temp_space_header	> 80% 警告
FRA	v$recovery_file_dest	> 80% 警告
ASM 磁盘组	v$asm_diskgroup	free < 15% 警告
OS 文件系统	df -h（含 diag 目录！见 02-告警日志与ADRCI-第一现场）	> 85% 警告
段增长 TOP	dba_segments 快照对比	周环比异常告警

七、小结

四类空间故障先分诊：01653 表空间、01652 temp、00257 归档（最紧急）、ASM 满；
归档清理只走 RMAN（CROSSCHECK + DELETE），rm 是事故放大器；
tempfile 注意 32 GB 上限，大排序需求要么 bigfile 要么多文件；
空间事故的根治永远是容量监控 + 增长归因，而不是无限扩容。

篇末：12-ORA-01555与误删数据恢复 ------ 系列收官：时间窗口最短的一类故障。