oracle+缩小undo,缩小回滚表空间(undotbs1)注意的问题

近期数据库的undotbs总是出现利用率过高。

在分析具体哪些大事务造成了大量UNDO之前，必须先解决利用率问题。

于是进行UNDOTBS的切换。

首先创建新的表空间

create undo tablespace undotbs2 datafile

'/path/to/file/undoxxx.dbf' size 8192m autoextend off;

扩展这个空间

alter tablespace undotbs2 add datafile

‘/path/to/file/udnoxxx.dbf' size 8192m reuse;

切换undotbs

alter system set undo_tablespace='undotbs2' scope=both;

(注：此步骤，经实验，即使不带“scope=both，系统也会在执行时候默认带上的，具体可以到alert.log里查看实际执行语句)

切换后，可以通过观察alert.log，查看切换情况：

若有如下语句：

Undo Tablespace 1 moved to Pending Switch-Out state.

说明旧的空间里数据还在用，这个时候，即使执行drop tablespace命令，也会报错，currently in

use.

直到看到如下语句：

Undo Tablespace 1 successfully switched out.

则切换完成，旧的空间已经可以正常drop了。

(注：经实验观察，UNDO空间切换完成后，旧空间也许仍旧会有大量数据存在，但这些数据已经无意义，不影响drop，这也从侧面说明，在retention值未到之前，或空间仍有盈余时，oracle并不会主动去清理无用的undo数据，这和undo表空间占有率高或许有关联。)

另，有一些SQL语句，可以用来查询UNDO空间切换情况：

select segment_name,owner,tablespace_name,status from

dba_rollback_segs

where tablespace_name='OLDUNDOTBS' and status =

'ONLINE';

可以查看是否仍有在旧空间上online的回滚段。

等待空间切换完成，即可drop旧的空间了

drop tablespace undotbs1 including contents and datafiles

cascade constraints;

至此，UNDO空间切换完成。

至于为什么会有短时大量UNDO数据出现，则还要从事务里去分析了。