根本原因是全局临时表的生命周期与存储过程调用边界不一致：ON COMMIT PRESERVE ROWS 表残留数据未清导致下一次调用读到旧数据，ON COMMIT DELETE ROWS 表因中间 COMMIT 提前清空数据；ORA-14452 错误源于会话异常终止后 TO 锁未释放，需查 v$lock/v$session 并 KILL SESSION 强制清理。
为什么存储过程里用全局临时表会出一致性问题
根本原因不是数据“错乱”，而是生命周期和事务边界没对齐。比如用 on commit preserve rows 的表，在存储过程中反复 insert 却不 truncate，下一次调用时会读到上一会话残留的数据；又或者在 on commit delete rows 表里执行了中间 commit，结果刚算一半的数据就没了。
ORA-14452 锁未释放的典型表现与清理方法
这个错误本质是会话异常终止后，临时表上的 TO 锁没被释放，导致后续 DROP 或重建失败。常见于应用连接池未正确关闭、存储过程崩溃退出、或客户端断连但会话未自动清理。
- 先查谁占着锁：
SELECT sid, serial#, status, sql_id FROM v$session WHERE sid IN (SELECT session_id FROM v$lock WHERE type = 'TO'); - 确认无业务影响后，用
ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;强制清理 - 别等它自动超时——有些会话能挂好几天
建表语句写在存储过程里？这是最危险的惯性操作
每次调用都 EXECUTE IMMEDIATE 'CREATE GLOBAL TEMPORARY TABLE ...' 看似灵活，实则埋雷：并发执行时可能撞上 ORA-00955: name is already used；DDL 还会隐式提交，破坏你原本的事务控制。
- 生产环境必须预建表——由 DBA 在部署阶段一次性执行
CREATE GLOBAL TEMPORARY TABLE - 存储过程只做
INSERT/SELECT/DELETE（仅限PRESERVE ROWS场景） - 真要动态建表，必须加唯一前缀+时间戳，例如
t_tmp_$$SID$$_20260625，并捕获ORA-00955忽略建表失败
数据残留比性能慢更致命
很多人盯着执行速度，却忽略了一个事实：全局临时表的数据隔离只按会话或事务生效，不按存储过程调用边界生效。一次没清干净，下次调用就可能拿错数据——这种 bug 往往只在高并发或长时间运行后才暴露。
- 用
ON COMMIT DELETE ROWS时，确保整个逻辑在一个事务内完成，中间不要COMMIT - 用
ON COMMIT PRESERVE ROWS时，入口处加DELETE FROM t_temp;或TRUNCATE TABLE t_temp;（后者更快，且不记日志） - 别依赖“会话结束自动清理”——连接池会让会话复用，数据可能跨天存活
