我们的数据库系统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确实是改的,也修改了参数文件。但只有重新启动才算是真正的修改了。因为只有这样,才能重新读取参数文件到内存。
一.创建一个表空间: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确实是改的,也修改了参数文件。但只有重新启动才算是真正的修改了。因为只有这样,才能重新读取参数文件到内存。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25116248/viewspace-1061156/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/25116248/viewspace-1061156/