如何通过SQL脚本在INSERT前后自动检查表空间剩余量？

很多人在 INSERT 前后直接去查 dba_free_space，想拿到剩余空间，结果发现数字经常对不上。这是为什么？其实原因有好几个：Oracle 的段扩展是按 extent 整块分配的，本地管理表空间（LMT）中的 bitmap 跟踪还有延迟可见性，事务没提交时新分配的 extent 不会立刻反映到视图里，更关键的是——dba_free_space 根本不告诉你最大连续空闲块有多大。所以直接拿它当“可用空间”来用，很容易误判。

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

直接从 dba_free_space 取出来的剩余空间，和真实可用量之间往往隔着几道弯。原因主要有三点：

• Oracle 不会按字节实时分配，而是按 extent 为单位发放，所以 dba_free_space 看到的剩余未必是你能立即用的。
• LMT 表的 bitmap 更新有延迟，同一时刻不同会话看到的空闲块可能不一致。
• 最要命的是：事务没提交前，新占用的 extent 不会扣减 dba_free_space，但其他会话可能已经抢走了那些看起来“空闲”的空间。

因此，靠谱的做法是带上 dba_segments 和 dba_extents 一起来校验，只看 dba_free_space 等于只看冰山一角。如果使用 AS OF TIMESTAMP 或者把查询放在同一个事务里，能避免快照不一致的问题。另外别忘了表空间如果是 AUTOALLOCATE 模式，第一个 extent 可能只有 64KB，下一个直接跳到 1MB——千万别假设增长是均匀的。

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

纯 SQL 脚本没法跨语句共享变量，也没法根据条件决定是否跳过插入。所以得用 PL/SQL 做一个“查→判→插→再查”的闭环，把空间阈值、表名、INSERT 语句全部参数化，不再硬编码。下面这个例子以表空间 USERS 为例，警戒线设在 85%，你可以直接替换成自己的表空间和 INSERT：

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;

  IF v_used_percent > v_threshold_pct THEN
    RAISE_APPLICATION_ERROR(-20001, 'Tablespace USERS usage ' || v_used_percent || '% exceeds ' || v_threshold_pct || '%');
  END IF;

  SELECT NVL(SUM(bytes), 0) INTO v_free_bytes_before FROM dba_free_space WHERE tablespace_name = 'USERS';

  INSERT INTO t1 VALUES (1, 'test'); -- 替换为你的真实 INSERT

  SELECT NVL(SUM(bytes), 0) INTO v_free_bytes_after FROM dba_free_space WHERE tablespace_name = 'USERS';

  DBMS_OUTPUT.PUT_LINE('Before: ' || v_free_bytes_before || ' bytes, After: ' || v_free_bytes_after || ' bytes');
END;
/

• 注意 dba_data_files 和 dba_free_space 查询的表空间名字要完全一致，Oracle 对大小写敏感，非默认大写模式下容易踩坑。
• 如果 INSERT 触发了 segment 扩展（比如第一次插入），插入后的 v_free_bytes_after 可能会比之前小很多，甚至变成 0——这说明已经没有连续空闲块可用了，哪怕 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。所以一定要额外查一下 SELECT MAX(bytes) FROM dba_free_space WHERE tablespace_name = 'USERS'，同时结合段类型来判断：普通表插入一般用 INITIAL extent，但索引重建、CTAS、全局临时表等场景可能申请更大的 extent。如果业务允许，可以提前用 ALTER TABLESPACE ... COALESCE 合并相邻空闲区（仅字典管理表空间有效）；LMT 下只能依赖自动 bitmap 管理，这时更要关注 dba_extents 中相邻 extent 的物理连续性。

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