Oracle perment表空间里的临时段

白鳝的洞穴 2020-12-09

2222

ORA-1652/ORA-1653是我们运维中常见的两个错误号。ORA-1653和ORA-1652的区别是，ORA-1653是无法在表空间中扩展普通的段，而ORA-1652是无法在表空间里扩展临时段。

很多朋友总结的是如果是ORA-1652,那是临时表空间的问题，ORA-1653是永久性表空间的问题。实际上这是有个误解。在永久性表空间里也是会遇到ORA-1652的。为什么会有这种情况呢？

上面是有个rebuild索引时候的报错，无法在一个Perment的表空间里扩展1024个字节的临时段。可能有些粗心的朋友看到这个报错就会说，临时表空间怎么又满了，不是刚扩充过吗？实际上仔细一点的朋友会去看tablespace后面的那个表空间名，通过dba_tablespace去确认这个表空间是临时表空间还是永久表空间。

实际上我们有很多操作都会在perment表空间中创建临时段，比如copy table/create table as select alter index rebuild move操作等。

在这种情况下，会在PERMENT表空间中产生一些类似xx.xxxx的临时对象。第一部分是数据文件的ID，后一段是临时段的ID。当这些操作完成的时候，这些临时段就会变成PERMENT的段。

甚至在有些时候，这些操作如果中途失败，那么这些临时段就会遗留在表空间中，不会马上被清除。pmon发现会话异常后，会通知smon在后台清理这些temporary segment,不过有时候smon会出现一些异常，无法及时清理这些对象。有可能这些对象会长期遗留下来。以前老白就遇到过有客户的表空间真正使用的量并不大，但是空闲比例很低，最后一查，发现里面有大量的temporary 段。遇到这种情况，我们可以使用event:drop_segments来手工清理这些临时段。

alter session set events 'immediate trace name DROP_SEGMENTS level TS#+1';

其中的level是表空间的ID+1,针对存在大量临时段的表空间，需要一个个的设置drop_segments事件来手工清理。

通过上面的分析，我们可以重新梳理一下ORA-1652错误的诊断路径：

oracle

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Oracle perment表空间里的临时段

评论