如何用SQL脚本在执行INSERT前后自动检查表空间的剩余量？

dba_free_space 查询结果不准，因 Oracle 按 extent 分配空间、LMT bitmap 延迟可见、未提交事务不更新该视图，且忽略最大连续空闲块大小；应结合 dba_extents 和 dba_segments 校验，并用 PL/SQL 实现查-判-插-再查闭环。

INSERT 前后查 dba_free_space 为什么经常不准？

直接在 INSERT 前后执行 SELECT SUM(bytes) FROM dba_free_space 得到的“剩余空间”往往和实际可用值不一致，因为 Oracle 的段（segment）扩展不是按字节实时分配，而是按 extent 分配，且存在本地管理表空间（LMT）中 bitmap tracking 的延迟可见性。更关键的是：事务未提交时，新分配的 extent 不会立即反映在 dba_free_space 中，但已占用的空间却可能被其他会话抢占。

• 必须用 dba_segments + dba_extents 双校验，而非只看 dba_free_space
• 查询需加 AS OF TIMESTAMP 或在同事务内完成，否则快照不一致
• 如果表空间是 AUTOALLOCATE 模式，首次 extent 大小可能是 64KB，后续可能跳到 1MB —— 不能假设均匀增长

用 PL/SQL 匿名块封装检查逻辑，避免手动重复

纯 SQL 脚本无法跨语句共享变量，也无法做条件跳过插入；必须用 PL/SQL 实现“查→判→插→再查”闭环。核心是把空间阈值、表名、插入语句都参数化，避免硬编码。

DECLARE  v_free_bytes_before NUMBER;  v_free_bytes_after  NUMBER;  v_used_percent      NUMBER;  v_threshold_pct     CONSTANT NUMBER := 85; -- 警戒水位BEGIN  SELECT ROUND((a.bytes - b.bytes) / a.bytes * 100, 2)    INTO v_used_percent    FROM (SELECT SUM(bytes) bytes FROM dba_data_files WHERE tablespace_name = 'USERS') a,         (SELECT NVL(SUM(bytes), 0) bytes FROM dba_free_space WHERE tablespace_name = 'USERS') b;<p>IF v_used_percent > v_threshold_pct THENRAISE_APPLICATION_ERROR(-20001, 'Tablespace USERS usage ' || v_used_percent || '% exceeds ' || v_threshold_pct || '%');END IF;</p><p>SELECT NVL(SUM(bytes), 0) INTO v_free_bytes_before FROM dba_free_space WHERE tablespace_name = 'USERS';</p><p>INSERT INTO t1 VALUES (1, 'test'); -- 替换为你的真实 INSERT</p><p>SELECT NVL(SUM(bytes), 0) INTO v_free_bytes_after FROM dba_free_space WHERE tablespace_name = 'USERS';</p><p>DBMS_OUTPUT.PUT_LINE('Before: ' || v_free_bytes_before || ' bytes, After: ' || v_free_bytes_after || ' bytes');END;/

• dba_data_files 和 dba_free_space 必须同属一个表空间名，大小写敏感（尤其在非默认大写模式下）
• 如果 INSERT 触发了 segment 扩展（如首次插入），v_free_bytes_after 可能比 v_free_bytes_before 小得多，甚至为 0 —— 这说明已无连续 extent 可用，即使 SUM(bytes) 看似还有余量
• 务必在同一个会话中执行，否则 DBMS_OUTPUT 不会显示，且事务隔离会导致二次查询看到不同快照

替代方案：监控 dba_tablespace_usage_metrics 更稳定

Oracle 10g+ 提供动态性能视图 dba_tablespace_usage_metrics，它基于 AWR 快照聚合，刷新频率可控（默认每小时），数值比实时查询 dba_free_space 更平滑、更适合预警。但它不能用于 INSERT 前后的毫秒级判断，而是作为辅助验证。

• 该视图中 used_space 单位是 blocks，不是 bytes，需乘以 block_size（查 dba_tablespaces）才可比对
• 字段 tablespace_size 是最大允许大小（含 autoextend），而 used_space 是已分配段的总块数，不含 free space —— 所以它反映的是“已用”，不是“剩余”
• 若你的表空间设置了 AUTOEXTEND ON，这个视图的 tablespace_size 会动态增长，但 dba_free_space 不会立刻体现新文件空间，容易误判

真正要防的不是“没空间”，而是“没连续 extent”

最常被忽略的一点：即使 dba_free_space 显示还有 500MB 剩余，但如果最大连续块（MAX(bytes)）只有 64KB，而你要插入的数据触发了一个需要 1MB extent 的操作（比如 LOB 列或并行 DML），就会报 ORA-01652: unable to extend temp segment 或类似错误。

• 务必加查：SELECT MAX(bytes) FROM dba_free_space WHERE tablespace_name = 'USERS'
• 结合段类型判断：普通表插入一般用 INITIAL extent，但索引重建、CTAS、全局临时表等场景可能申请更大 extent
• 如果业务允许，提前用 ALTER TABLESPACE ... COALESCE 合并相邻空闲区（仅限字典管理表空间）；LMT 下只能依赖自动 bitmap 管理，此时更应关注 dba_extents 中相邻 extent 的物理连续性

实际部署时，别只盯着总数，连续性才是卡住 INSERT 的最后一根稻草。