表空间满了却不报错——Oracle的沉默陷阱

表空间满了却不报错——Oracle的沉默陷阱

故障现场

城镇居民医疗系统突然"卡住"了。

不是宕机，不是报错，就是写数据的时候卡在那里。前端界面转圈，后台日志没异常，数据库连接正常。用户打电话投诉：“结算办不了，病人等着出院。”

检查了网络、应用服务器、数据库连接池，一切正常。但就是写不进去数据。

排查过程

1. 应用层排查：检查Java应用日志，没有异常堆栈；连接池正常，没有死锁。
2. 数据库层排查：v$session显示会话在等待，等待事件是db file sequential read——看起来像正常的IO等待。
3. 系统层排查：服务器CPU、内存、IO都正常，没有瓶颈。

排查了两个小时，最后才想到检查表空间：

SELECT tablespace_name,
       ROUND(used_space/1024/1024, 2) used_mb,
       ROUND(tablespace_size/1024/1024, 2) total_mb,
       ROUND(used_percent, 2) used_pct
FROM dba_tablespace_usage_metrics
WHERE used_percent > 90;

结果：USERS表空间使用率100%。

问题根源

Oracle的表空间满了，但写操作不报错，只是卡住。

这不是bug，是Oracle的设计：当表空间的数据文件达到最大大小且无法扩展时，Oracle会让会话进入等待状态，而不是立即报错。

对于医疗结算系统，这意味着：

• 交易卡住，但系统不告警
• 监控系统看不到异常（CPU、内存、连接数都正常）
• 用户感知是"系统慢"，而不是"系统坏了"

解决方案

1. 紧急处理：清理历史数据，释放空间
2. 中期方案：给表空间增加数据文件
3. 长期方案：建立表空间监控告警，阈值设到85%

-- 增加数据文件（指定固定大小，不开启AUTOEXTEND）
ALTER TABLESPACE USERS 
ADD DATAFILE '/u01/oradata/prod/users02.dbf' 
SIZE 30G;

注意：AUTOEXTEND在生产环境一直是不推荐的做法。自动扩展听起来方便，但会导致磁盘空间不可控——某天磁盘满了，整个数据库挂掉，比表空间满更难恢复。正确的做法是：固定大小数据文件 + 监控告警 + 提前手动扩容。

经验教训

1. 监控不能只看"是否存活"

传统监控关注CPU、内存、连接数，但表空间满了这些指标都正常。需要监控：

• 表空间使用率（阈值85%）
• 数据文件是否已达上限
• 空间等待事件（enq: HW - contention等）

2. 沉默的故障最危险

报错的故障好处理，不报错的故障难发现。Oracle很多"静默失败"场景：

• 表空间满（写操作卡住）
• 归档目录满（数据库挂起）
• 密码过期（连接失败但不明确提示）

3. 政务系统的特殊性

医疗结算系统不能停：

• 病人等着出院，不能等
• 7×24小时服务，没有维护窗口
• 数据不能丢，事务必须完整

这种场景下，预防比救火重要。

技术细节

为什么Oracle不立即报错？

Oracle的存储管理是惰性的：

1. 插入数据时，先申请空间
2. 如果表空间不足，检查数据文件是否能扩展
3. 无法扩展时，会话进入等待状态
4. 等待其他会话释放空间（提交或回滚）
5. 超时后（默认无限期等待）才会报错

如何立即发现？

-- 监控空间等待
SELECT event, count(*) 
FROM v$session_wait 
WHERE event LIKE '%space%' 
GROUP BY event;
-- 监控已达上限的数据文件
SELECT tablespace_name, file_id, blocks, maxblocks
FROM dba_data_files
WHERE maxblocks IS NOT NULL 
AND blocks = maxblocks;

总结

表空间满了不报错，是Oracle的一个"特性"，不是bug。但在生产系统，特别是政务医疗系统，这种特性会变成致命陷阱。

关键点：

1. 监控表空间使用率，阈值设到85%
2. 固定大小数据文件，不用AUTOEXTEND，靠监控+手动扩容
3. 建立空间等待事件的监控告警
4. 定期清理历史数据，预留缓冲空间

系统不告诉你它病了，等你知道时，病人已经堵在结算窗口了。