在Oracle 10g数据库的应用中,出现了UNDO表空间过大导致磁盘空间不足而崩溃的现象(ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1')。对此问题进行分析后,总结了出现该问题的原因主要有以下两点:
1. 有较大的事务量让Oracle Undo自动扩展,产生过度占用磁盘空间的情况;
2. 有较大事务没有收缩或者没有提交所导制;
说明:本问题在Oracle系统管理中属于比较正常的一现象,日常维护多注意对磁盘空间的监控。
UNDO表空间介绍
UNDO表空间用于存放UNDO数据,当执行DML操作(INSERT,UPDATE和DELETE)时,oracle会将这些操作的旧数据写入到UNDO段,在oracle9i之前,管理UNDO数据时使用(Rollback Segment)完成的.从oracle9i开始,管理UNDO数据不仅可以使用回滚段,还可以使用UNDO表空间.因为规划和管理回滚段比较复杂,所有oracle database 10g已经完全丢弃用回滚段.并且使用UNDO表空间来管理UNDO数据。
UNDO数据也称为回滚(ROLLBACK)数据,它用于确保数据的一致性.当执行DML操作时,事务操作前的数据被称为UNDO记录.UNDO段用于保存事务所修改数据的旧值,其中存储着被修改数据块的位置以及修改前数据。
Oracle 10g 有自动Automatic Undo Retention Tuning 这个特性。设置的 undo_retention 参数只是一个指导值,缺省值900秒,,Oracle 会自动调整 Undo (会跨过 undo_retention 设定的时间) 来保证不会出现 Ora-1555 错误.。通过查询V$UNDOSTAT(该视图记录4天以内的UNDO表空间使用情况,超过4天可以查询DBA_HIST_UNDOSTAT视图)的tuned_undoretention (该字段在10G版本才有,9I是没有的)字段可以得到Oracle 根据事务量(如果是文件不可扩展,则会考虑剩余空间)采样后的自动计算出最佳的 retenton 时间。
ORACLE推荐我们将undo 表空间中的datafile 设定MAXSIZE ,不要让它一直自动扩展,如果ORACLE获得了自动扩展的能力,那么旧的undo不会被覆盖,到后来undo表空间会越来越大,越来越大,直到将磁盘空间耗尽。
1)查询retention值
show parameter undo_retention
| undo_retention = 900 是指事务结束后undo 将保存900秒后释放,事务没结束根本不能被覆盖 |
| undo tablespace 除了能控制这个 undo_retention 参数外其他的都是不可控制的 |
查询自动计算出最佳的retenton 时间
select tuned_undoretention, maxquerylen, maxqueryid from v$undostat;
2)更改retention值
ALTER SYSTEM SET undo_retention=10800 SCOPE=BOTH;
这样对于一个事务量分布不均匀的数据库来说,,就会引发潜在的问题--在批处理的时候可能 Undo 会用光, 而且这个状态将一直持续, 不会释放。
如何取消10g的auto UNDO Retention Tuning,有如下三种方法:
(1)10.2.0.2/10.2.0.3有相应的patch,这个bug在10.2.0.4中已经修复,建议找时间停机打patch.
(2)设置隐含参数_smu_debug_mode=33554432,将tuned_undoretention取值算法修正为max(maxquerylen secs + 300,undo_retention ),不建议使用
SQL> Alter system set "_smu_debug_mode" = 33554432;
(3)设置隐含参数_undo_autotune=false,关闭自动undo retention调整特性,不建议使用
SQL> Alter system set "_undo_autotune" = false;from metalink 420525.1: Automatic Tuning of Undo_retention Causes Space Problems.
(4)GUARANTEE : 保证undo_retention参数所设定的时间有效,这个是10g的新功能。
SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;
SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;
(测试无变化,enable auto tuning of undo_retention = true )
在没有guarantee的保证下,ORACLE并不能保证能够将undo信息存储900秒,如果undo表空间不足,那么ORACLE将忽略undo_retention的设置,直接覆盖掉以前的undo,这个时候有可能会产生ORA-01555错误。如果undo表空间空间足够,那么undo将会保存很长一段时间,直到undo表空间达到maxsize,这个时候才会覆盖undo信息,而且ORACLE会从最古老的undo信息开始覆盖。在有guarantee的保证下,ORACLE将会保证undo信息能够保存到undo_retention设定的值之后才被覆盖,如果这个时候同时执行了很多事物,将undo表空间耗完了,那么那个事物会失败,会报ORA-30036 (空间不足)错误,所以使用guarantee一定要慎用,如果非要使用guarantee,那么尽量将undo 表空间设大 一点。
解决步骤:
1. 启动SQLPLUS,并用sys登陆到数据库。
#su - oracle
$>sqlplus / as sysdba
2. 查找数据库的UNDO表空间名,确定当前例程正在使用的UNDO表空间:
Show parameter undo_tablespace。
3. 确认UNDO表空间;
SQL> select name from v$tablespace;
NAME
------------------------------
UNDOTBS1
4. 检查数据库UNDO表空间占用空间情况以及数据文件存放位置;
SQL>select file_name,bytes/1024/1024 from dba_data_files where tablespace_name like 'UNDOTBS%';
5. 查看回滚段的使用情况,哪个用户正在使用回滚段的资源,如果有用户最好更换时间(特别是生产环境)。
SQL> select s.username, u.name from v$transaction t,v$rollstat r, v$rollname u,v$session s
where s.taddr=t.addr and t.xidusn=r.usn and r.usn=u.usn order by s.username;
6. 检查UNDO Segment状态;
SQL> select usn,xacts,rssize/1024/1024/1024,hwmsize/1024/1024/1024,shrinks
from v$rollstat order by rssize;USN XACTS RSSIZE/1024/1024/1024 HWMSIZE/1024/1024/1024 SHRINKS
1 0 0 0.000358582 0.000358582 0
2 14 0 0.796791077 0.796791077 735
3 44 1 0.00920867919921875 3.99295806884766 996
这还原表空间中还存在3个回滚的对象。
7. 创建新的UNDO表空间,并设置自动扩展参数;
SQL> create undo tablespace undotbs2 datafile '/opt/oracle/oradata/ge01/UNDOTBS2.dbf' size 100m reuse autoextend on next 50m maxsize 5000m;Tablespace created.
8. 切换UNDO表空间为新的UNDO表空间 , 动态更改spfile配置文件;
SQL> alter system set undo_tablespace=undotbs2 scope=both;
System altered.
9.验证当前数据库的 UNDO表空间
SQL> show parameter undoNAME TYPE VALUE
------------------------------------ ----------- --------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS2
9. 等待原UNDO表空间所有UNDO SEGMENT OFFLINE;
select usn,xacts,status,rssize/1024/1024,hwmsize/1024/1024, shrinks from v$rollstat order by rssize;
select t.segment_name,t.tablespace_name,t.segment_id,t.status from dba_rollback_segs t;
SEGMENT_NAME TABLESPACE_NAME SEGMENT_ID STATUS
1 SYSTEM SYSTEM 0 ONLINE
2 _SYSSMU1$ UNDOTBS1 1 OFFLINE
3 _SYSSMU2$ UNDOTBS1 2 OFFLINE
4 _SYSSMU47$ UNDOTBS1 47 OFFLINE上面对应的UNDOTBS1还原表空间所对应的回滚段均为OFFLINE
10.到$ORACLE_HOME/dbs/init$ORACLE_SID.ora如下内容是否发生变更:
#cat $ORACLE_HOME/dbs/initddptest.ora
……
*.undo_management=’AUTO’
*.undo_retention=10800
*.undo_tablespace=’UNDOTBS2’
……如果没有发生变更请执行如下语句:
SQL> create pfile from spfile;
File created.
11. 删除原有的UNDO表空间;
SQL> drop tablespace undotbs1 including contents;
最后需要在重启数据库或者重启计算机后到存储数据文件的路径下删除数据文件(为什么要手动删除呢:以上步骤只是删除了ORACLE中undo表空间的逻辑关系,即删除了数据文件在数据字典中的关联,不会自动删除项关联的数据文件)。
drop tablespace undotbs1 including contents and datafiles;
Tablespace dropped.
关于Oracle 10g UNDO表空间过大导致磁盘空间不足的解决方法就介绍到这里了,希望本次的介绍能够对您有所收获!
source:http://blog.163.com/cyh_1987/blog/static/39469292011109101731374/
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/7583803/viewspace-719746/ ,如需转载,请注明出处,否则将追究法律责任。