undo_tablesspace 持續增長的問題

显示全部楼层 · 2009-7-22 09:30:00

我相信大家碰到過undo_tablespace持續增長,即使是重啟服務器,也不能讓它下降的問題,除了加大undo_tablespace和切換新的undo_tablespace兩种方法外,還有沒有其它的方法
大家可以探討一下.....謝謝

千问 · 2009-7-22 09:30:00

up一下

千问 · 2009-7-22 09:30:00

目前多大，几个有关参数如何设置。
是否存在执行很长的sql语句。

千问 · 2009-7-22 09:30:00

為什么undo_tablesspace表空間會持續增長﹐先看看事務尋找undo空間的算法﹕
When a transaction needs more space in an undo segment, there is a fixed algorithm the determines when extents are reused.. The transaction will first attempt to reclaim expired extents from the current segment, then expired extents from another segment. The third method will be to autoextend the datafile(s), if this is set. Next, the unexpired extents from the current segment and other segments will be allocated, as long as the extents do not contain uncommitted transactions. Finally, an error will be raised if none of the methods are successful.

千问 · 2009-7-22 09:30:00

undo_management
stringAUTO
undo_retention
integer 7200
undo_suppress_errors
boolean FALSE
undo_tablespace
stringUNDOTBS
這是參數設置

千问 · 2009-7-22 09:30:00

目前是5g

千问 · 2009-7-22 09:30:00

优化前端应用

千问 · 2009-7-22 09:30:00

看情况，是一直出现这样的情况，还是偶尔出现的这样的情况
在有些大的事务出现后，undo有的时候是会因为bug，出现傻傻的往上涨
一般只要switch即可
如果是持续都是这样的话，最好检查你的应用，设置undo的数据文件为非自动扩展等等

千问 · 2009-7-22 09:30:00

是偶尔出现的这样的情况,
之前一般都維持在350M左右,即使是加大了,在某些時候都會自動縮小,這次真的很怪.....

千问 · 2009-7-22 09:30:00

select
s.SID,s.SERIAL#,s.USERNAME,r.STATUS,S.LOGON_TIME,N.name,seg.tablespace_name
from
v$session s,
v$process p,
v$transaction t,
v$rollstatr,
v$rollnamen,
dba_rollback_segs seg
where s.paddr = p.addr
and s.taddr = t.addr (+)
and t.xidusn = r.usn (+)
and r.usn = n.usn (+)
and n.name = seg.segment_name(+)
在很早以前我根據這條sql查過,結果發現是分布式事務失敗卻沒有rollback,後來就orakill xxx spid 就自動縮小,這次好像不是分佈式事務所造成的