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 THEN
RAISE_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><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/ai/1894" title="Postme"><img
src="https://img.php.cn/upload/ai_manual/000/000/000/175680421960982.png" alt="Postme" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/ai/1894" title="Postme" class="overflowclass">Postme</a>
<p class="overflowclass">一款面向外贸和跨境营销场景的AI写作工具，可辅助生成产品推广、营销沟通和海外市场所需的商业文案内容。</p>
</div>
<a rel="nofollow" href="/ai/1894" title="Postme" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><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;
/</p>
-
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' - 结合段类型判断：普通表插入一般用
INITIALextent，但索引重建、CTAS、全局临时表等场景可能申请更大 extent - 如果业务允许，提前用
ALTER TABLESPACE ... COALESCE合并相邻空闲区（仅限字典管理表空间）；LMT 下只能依赖自动 bitmap 管理，此时更应关注dba_extents中相邻 extent 的物理连续性
