暂无图片
暂无图片
10
暂无图片
暂无图片
2
暂无图片

temp表空间不足处理思路

3895

ORA-1652: unable to extend temp segment by 128 in tablespace TEMP 
相信这种报错大部分dba都处理过。引起临时表空间增长的原因很多,如order by/group by,数据导入导出,索引维护。

查询思路

temp暴增后,首先应该确认占用temp的详细情况:
从11g开始,ash视图新增TEMP_SPACE_ALLOCATED列,能看到不同时间段的增长情况。

select to_char(sample_time,'yyyymmdd hh24:mi:ss'),session_id,session_serial#,sql_id,max(TEMP_SPACE_ALLOCATED/1024/1024)
from v$active_session_history where con_id=3
and to_char(sample_time,'yyyymmdd hh24')='20200204 16'
group by to_char(sample_time,'yyyymmdd hh24:mi:ss'),session_id,session_serial#,sql_id order by 5;

TO_CHAR(SAMPLE_TI SESSION_ID SESSION_SERIAL# SQL_ID
----------------- ---------- --------------- -------------
MAX(TEMP_SPACE_ALLOCATED/1024/1024)
-----------------------------------

20200204 16:02:08         72           37321 g1dw2r1d4g2am
                                  0

20200204 16:02:06         72           37321 g1dw2r1d4g2am
                                  0

测试环境资源有限,最后一列就是占用的临时表空间大小,可以看到不同时间段temp占用情况。实际生产中,可以看到几分钟内,某条sql_id占用急速上升。
查看sql_id内容:
select * from table(dbms_xplan.display_cursor('&sqlid'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
SQL_ID  g1dw2r1d4g2am, child number 0
-------------------------------------
select id,count(*) from t1 group by id

Plan hash value: 136660032

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |       |  5740 (100)|          |
|   1 |  HASH GROUP BY     |      |    13M|   171M|  5740   (9)| 00:00:01 |

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
|   2 |   TABLE ACCESS FULL| T1   |    13M|   171M|  5318   (2)| 00:00:01 |
---------------------------------------------------------------------------

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)


18 rows selected.

执行计划中可以看到1300w行的group by
select SID,SERIAL#,USERNAME,MACHINE,PROGRAM from v$session where sid=72;
  SID    SERIAL# USERNAME        MACHINE         PROGRAM
----- ---------- --------------- --------------- -------------------------
   72      37321 SYS             localhost.local sqlplus@localhost.localdo
                                 domain          main (TNS V1-V3)

复制

以上信息可以确认,sys用户本地连接(session:’72,37321’),执行1300W行数据的group by语句。

处理思路

增加临时表空间和kill session 可以作为应急处理,解决问题可以考虑以下:
1 、设置合理的pga
2 、禁止业务高峰期执行未上线的sql
3 、优化sort sql

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论

and1
暂无图片
4年前
评论
暂无图片 0
茂材这个处理思路和当初飞哥分享的很类似啊。
4年前
暂无图片 点赞
1
茂材
暂无图片
4年前
回复
暂无图片 0
有可能,我在去年整理时和飞哥讨论过
4年前
暂无图片 点赞
回复