我们的数据库系统CPU性能很好，但由于磁盘阵列是09年的，所以I/O 读写这块比较差一些，领导说能否把undo表空间挪到另外一个盘上，把读写分散在不同的盘上，增加效率，于是，我就开始执行：
    一.创建一个表空间：untotbs2.  
         SQL>CREATE UNDO TABLESPACE "UNDOTBS1" DATAFILE
           2    'E:\ORADATA\APTS\UNDOTBS01_new.DBF' SIZE 30644633600
           3     AUTOEXTEND ON NEXT 5242880 MAXSIZE 32767M
           4     BLOCKSIZE 8192
           5     EXTENT MANAGEMENT LOCAL AUTOALLOCATE
     注意：这种大型的ddl操作建议在远程桌面上直接操作，不要使用pl/sql developer，容易挂死。   
   
    二.把数据库undo_tablespace修改为undotbs2.
           SQL> alter system set undo_tablespace='UNDOTBS2' scope=both;

    这里注意一下，我们现在把undotbs2设置成undo表空间之后，它的状态在dba_rollback_segs里就是online了
            SQL>select tablespace_name,segment_name,status from dba_rollback_segs
   查看这个会表示出有几个回退段，他们的状态是什么，有online,有offline的，在生产库中，不会马上undotbs1就变成offline,会有一些事online，这很正常，因为有些用户没有提交，这时我们还可以查看一个动态性能视图 :v$rollstat:
       
        SQL>select usn,status from v$rollstat;
           0    online
          10    PENGING OFFLINE
          11    ONLINE
          12    ONLINE
     ..............................................................
这里只会显示ONLINE和PENDING OFFLINE，也就是在线和正在离线的状态。我们必须等待所有的回退段都ONLINE，我们才能进行下一步，删除老的回退表空间。

三.删除老的undo表空间:   
           SQL> drop tablespace undotbs1 including contents and datafiles;   ##删除表空间极其数据文件。
注意：这里会显示执行成功，但在alert日志里，
    会显示：
ORA-01265: 无法删除 DATA D:\APP\ADMINISTRATOR\UNDO_DATAFILE_APTS\UNDOTBS02.DBF
ORA-27056: 无法删除文件
OSD-04024: 无法删除文件。
O/S-Error: (OS 32) 另一个程序正在使用此文件，进程无法访问。
Completed: drop tablespace undotbs2 including contents and datafiles
    
       我们在操作系统手工删除也会出问题，不能手工删除。但我之前在linux操作时就没有这个问题，估计是操作系统的原因。有人说删除undo必须重启数据库，有人说不用。
看来在win下的数据库修改undo表空间，必须重启数据库才能真正的生效。但我们在系统里查看undo表空间：
     SQL>show parameter undo
会正确的显示出undo是修改过的，说明什么呢，说明undo确实是改的，也修改了参数文件。但只有重新启动才算是真正的修改了。因为只有这样，才能重新读取参数文件到内存。