Oracle 11g - 临时表空间段未发布（Oracle 错误？）

Posted 2023-03-29

【中文标题】Oracle 11g - 临时表空间段未发布（Oracle 错误？）

【英文标题】：Oracle 11g - Temp Tablespace Segments don't get released (Oracle Bug?)

【发布时间】：2015-10-01 20:27:03

【问题描述】：

我正在使用Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production，我在 TOAD 12.6.0.53 中执行的以下查询存在问题 em>（不是典型的查询，只是为了演示）：

with rownums 
as (select distinct 
    rownum rn 
      from dual 
   connect by level <=1000000 
) 
select rn from rownums 
 union all
select rn from rownums;

--Edit: this Statement ist NOT showing the behaviour:
begin
    for cRow in (with rownums 
                as (select distinct 
                    rownum rn 
                      from dual 
                   connect by level <=1000000 
                ) 
                select rn from rownums 
                 union all
                select rn from rownums) 
    loop
        return;
    end loop;
end;

执行此查询后，我可以通过此查询检查临时表空间的使用情况：

SELECT S.sid, S.serial#, SUM (T.blocks) * TBS.block_size / 1024 / 1024 used_mb, T.tablespace
  FROM v$sort_usage T, v$session S, dba_tablespaces TBS
 WHERE T.session_addr = S.saddr
   AND T.tablespace = TBS.tablespace_name
   and s.sid = sys_context('userenv','sid')
 GROUP BY S.sid, S.serial#, TBS.block_size, T.tablespace;

结果是，每次执行上面的测试查询都需要大约 12MB 的 Temp 表空间，直到我断开会话后才会释放。 如果我经常这样做，它也会导致ORA-1652：无法扩展临时段。

我做错了什么？或者这可能是一个 oracle 错误？

【问题讨论】：

我在 11.2.0.3 中没有看到带有 PL/SQL 块的效果，而普通 SQL 的效果更小。您的临时表空间真的是临时的，还是使用永久段 - dba_tablespaces.contents 显示什么？ （如果您有访问权限，MOS 注释 1039341.6 可能是相关的，因为我可以看到 v$sortsegments.user_blocks 增长，同样仅使用纯 SQL）。

实际上，在 SQL*Plus 中，我也没有在纯 SQL 版本中看到它；但我在 SQL Developer 中看到了它——仅当结果集中有尚未获取和显示的行时——所以查询仍然处于活动状态。我猜蟾蜍正在做类似的事情？

感谢您的反馈，这是我关于 PL/SQL 块的错误，它没有显示行为。我检查了 dba_tablespaces.contents - 它是“TEMPORARY”而不是“PERMANENT”

我也可以从一个简单的 Java 程序中重现（SQL Developer 和 Toad 都通过 JDBC 运行）；将查询执行到结果集中会占用临时空间，除非我遍历整个结果集，否则它不会被释放。关闭结果集或准备好的语句不会释放临时段，它们仅在 while (rSet.next()) ... 循环完成后才被释放。我认为这看起来像一个错误，但我在 MOS 中看不到任何明显的匹配 - 18098207 可能是相关的，但很难说。看看这是否可以在其他版本中重现会很有趣。

在 10.2.0.5 中没有完全重现。段没有被 rSet.close() 释放，但第二次执行似乎重用了相同的段，并且它们被 pStmt.close() 释放。并且仍然通过完全循环结果集来释放。我没有任何其他版本可以方便地测试。可能值得提出有关此行为的服务请求。

【参考方案1】：

TEMP 表空间有一些有限的磁盘空间。当您运行查询时，它开始越来越多地使用 TEMP 空间，直到达到极限并给出错误 can't extend TEMP ，所以可能有两种解决方案

使用 EM 更好地增加 TEMP 空间

优化使用较少 TEMP 的查询