【IT168 技术文档】
摘要:在使用Oracle9i/Oracle10g的自动Undo管理表空间(AUM)特性时,经常会因为各种原因而导致Undo表空间过度扩展。本文通过一则案例诊断,介绍如何收缩过度扩展的Undo表空间,释放占用空间。
环境:
OS: Red Hat Enterprise Linux AS release 4 (Nahant)
DB: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
某日,一台Oracle10gR2数据库报出如下错误:
ORA-1653: unable to extend table SYSMAN.MGMT_SYSTEM_ERROR_LOG by 8 in tablespace SYSAUX
ORA-1653: unable to extend table SYSMAN.MGMT_SYSTEM_ERROR_LOG by 8 in tablespace SYSAUX
ORA-1653: unable to extend table SYSMAN.MGMT_SYSTEM_ERROR_LOG by 8 in tablespace SYSAUX
ORA-1653: unable to extend table SYSMAN.MGMT_SYSTEM_ERROR_LOG by 8 in tablespace SYSAUX
ORA-1653: unable to extend table SYSMAN.MGMT_SYSTEM_ERROR_LOG by 8 in tablespace SYSAUX
数据库无法正常使用。
登陆检查,发现是SYSAUX表空间空间用尽,不能扩展,尝试手工扩展SYSAUX表空间:
alter database datafile '+ORADG/danaly/datafile/sysaux.266.600173881' resize 800m Tue Nov 29 23:31:38 2005 ORA-1237 signalled during: alter database datafile '+ORADG/danaly/datafile/sysaux.266.600173881' resize 800m...
出现ORA-1237错误,提示空间不足。这时候我们认识到是磁盘空间可能被用完了.
是谁“偷偷的”用了那么多空间呢(本来有几十个G的Free磁盘空间的)?
通过如下脚本检查数据库表空间占用空间情况:
SQL> select tablespace_name,sum(bytes)/1024/1024/1024 GB2 from dba_data_files group by tablespace_name 3 union all 4 select tablespace_name,sum(bytes)/1024/1024/1024 GB 5 from dba_temp_files group by tablespace_name order by GB; TABLESPACE_NAME GB ------------------------------ ---------- USERS .004882813 UNDOTBS2 .09765625 SYSTEM .478515625 SYSAUX .634765625 WAPCM_TS_VISIT_DETAIL .9765625 HY_DS_DEFAULT 1 MINT_TS_DEFAULT 1 MMS_TS_DATA2 1.375 MMS_IDX_SJH 2 MMS_TS_DEFAULT 2 IVRCN_TS_DATA 2 TABLESPACE_NAME GB ------------------------------ ---------- MMS_TS_DATA1 2 CM_TS_DEFAULT 5 TEMP 20.5498047 UNDOTBS1 27.1582031 15 rows selected.
不幸的发现,UNDO表空间已经扩展至27G,而TEMP表空间也扩展至20G,这2个表空间加起来占用了47G的磁盘空间,导致了空间不足。
显然曾经有大事务占用了大量的UNDO表空间和Temp表空间,Oracle的AUM(Auto Undo Management)从出生以来就经常出现只扩展,不收缩(shrink)的情况(通常我们可以设置足够的UNDO表空间大小,然后取消其自动扩展属性)。