ORA-1652 临时表空间满了导致新会话数据不能入库诊断案例(一)

2014-11-24 18:40:37 · 作者: · 浏览: 0

2.定位问题
报错现象:
Fri Aug 17 13:37:39 EAT 2012
ORA-1652: unable to extend temp segment by 128 in tablespace MDSTEMP 显示不能扩展临时段,说明临时表空间已经被使用满了,空间不够。
说明:从metalink上官方解释,没有更多的空闲区分给这个临时段了,可以给表空间添加数据文件的方式来解决此问题,表面上是这样,我们更加的深入了解,是什么原因导致的临时段没有空间了呢,我们都知道临时段是记录排序和数据迁移的,现在深层次问题不是空间不够,过一会再执行sql可能就不报错了。是sql语句不够优化。因为当sql在批量DML操作的时候,会突发性占用大量临时空间排序,就会报临时段不够用,新数据此时不能入库!过一会空间释放后又可以入库了,要想解决此问题就需要sql优化。
The below is from metalink:
Error: ORA-1652
Text: unable to extend temp segment by %s in tablespace %s
------- -----------------------------------------------------------------------
Cause: Failed to allocate an extent for temp segment in tablespace.
Action: Use ALTER TABLESPACE ADD DATAFILE statement to add one or more
files to the tablespace indicated or create the object in another
tablespace.
select * from gnwebbrw12081720; 此时是有数据的,说明空间已经释放了
colfile_name for a35
selectfile_name,file_id,bytes/1024/1024,status,autoextensible TABLESPACE_NAME from DBA_TEMP_FILES;
FILE_NAME FILE_ID BYTES/1024/1024 STATUS TAB
----------------------------------- ---------- --------------- --------- ---
/oradata/mdsoss/temp01.dbf 1 24671 AVAILABLE YES
/oradata/mdsoss/mdstmp.dbf 2 20000 AVAILABLE NO MDSTEMP 不是自动扩展,如果是就没有上述问题了,但我们不建议使用数据文件自动扩展功能,不容易监控。看 24G + 20G 空间是没有问题的,一般都是sql写的不够好导致不必要排序。

3.解决方案
(1)重启实例,7*24 重启实例 smon进程可以释放sort段,但我们的库是不能down的
(2)增加数据文件,我的空间很紧张,不可以
(3)配置合理sort_area大小 已经配置完毕了,现PGA 4G sort_area_size 208M
(4)sql optimization 最佳方案
(5)总结哪些操作会导致临时表空间暴涨呢
什么操作在使用temp
- 索引创建或重建.

- ORDER BY or GROUP BY
- DISTINCT 操作.
- UNION & INTERSECT & MINUS
- Sort-Merge joins.
- Analyze 操作
- 有些异常将会引起temp暴涨
当处理以上操作时候呢,dba需要加倍关注temp使用情况?我们现在来看看谁使用这些临时段。
(5)临时表空间使用情况
select tablespace_name,current_users,total_blocks,used_blocks,free_blocks from v$sort_segment;
TABLESPACE_NAME CURRENT_USERS TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS
------------------- ------------- ------------ ----------- -----------
TEMP 1 3157760 128 3157632
MDSTEMP 24 2559872 2337152 222720 已经使用了92%


(6)谁在使用这些sort段
select username,session_addr,sqladdr,sqlhash from v$sort_usage;
USERNAME SESSION_ADDR SQLADDR SQLHASH
------------------------------ ---------------- ---------------- ----------
MDSOSS C0000008483ECFB8 C0000008512150B8 3342809064
SABOCOUSR C00000084B405E50 C00000033F867510 141205382
MDSOSS C00000084740E988 C0000008508AB1C0 409467952
MDSOSS C0000008483DE390 C00000033B8914F0 2951877480
MDSOSS C00000084A404460 C0000003404007A0 2584373469
MDSOSS C0000008483F5088 C00000033FA63E18 2245874020
MDSOSS C0000008483FFC48 C00000084D5B5F98 3000467390
MDSOSS C0000008483F5088 C00000033FA63E18 2245874020
MDSOSS C000000852404A60 C00000084DD6F598 1491833069
MDSOSS C0000008483EBA40 C00000084DE28990 1530468420
MDSOSS C0000008483FD158 C00000084E13A648 3459409074
MDSOSS C000