rollback_segments='SYSTEM'
（2）用修改之后的pfile，重启DB
SQL> STARTUP MOUNT pfile='F:/initorcl.ora' ;
（3）删除原来的表空间，创建新的UNDO 表空间
SQL> drop tablespace undotbs;
SQL> create undo tablespace undotbs1 datafile '/u01/oradata/undotbs1.dbf' size 10M;
（4）关闭数据库，修改pfile参数，然后用新的pfile创建spfile，在正常启动数据库。
*.undo_tablespace='UNDOTBS1'
*.undo_management='AUTO'
#undo_management='MANUAL'
#rollback_segments='SYSTEM'
2.2. 方法二：跳过损坏的segment
在方法一里面，我们使用了system segment。 通过第一部分我们了解到，undo segment 有多个，我们可以通过alert log 来查看正在使用的是哪些segment，这些段有可能损坏了。 我们只需要把这些损坏的segment 跳过，先正常启动DB，在创建新的UNDO 表空间，在切换一下。
（1）修改pfile，添加参数：
*._corrupted_rollback_segments='_SYSSMU11$','_SYSSMU12$','_SYSSMU13$'
这些字段的值，我们通过alert log 查看。 也可以通过如下命令查看：
#strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u
（2）用修改之后的pfile启动DB
因为跳过了哪些损坏的segment，所以DB 可以正常启动。
（3）创建新的UNDO 表空间，并切换过来
SQL> create undo tablespace undotbs1 datafile '/u01/oradata/undotbs1.dbf' size 10M;
SQL> alter system set undo_tablespace=undotbs1;
SQL> drop tablespace undotbs;
（4）修改pfile，创建spfile，并正常启动
删除：
*._corrupted_rollback_segments='_SYSSMU11$','_SYSSMU12$','_SYSSMU13$'
以上就是UNDO 出现故障的2种处理方法。
三. Current online Redo 损毁的处理
其实在之前的不同故障处理的那篇blog里已经提到了这点。 但这种情况是一种特殊的情况。 所以还是单独拿出来说明一下。
current online log 损坏有两种恢复方法：
（1）如果有归档和备份，可以用不完全恢复。
SQL>startup mount;
SQL>recover database until cancel; 先选择auto，尽量恢复可以利用的归档日志，然后重新执行：
SQL>recover database until cancel; 这次输入cancel，完成不完全恢复,
用resetlogs打开数据：
SQL>alter database open resetlogs； 打开数据库
（2）强制恢复， 这种方法可能会导致数据不一致
sql>startup mount;
sql>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
sql>recover database until cancel;
sql>alter database open resetlogs;
这里主要看2点：
（1）使用了_allow_resetlogs_corruption 参数
（2）这种情况下，可能会报ORA-600[2662]（SCN有关）和 ORA-600[4000]（回滚段有关）的错误。
使用_allow_resetlogs_corruption参数，强制的打开数据库，可能会导致逻辑的坏块，从而影响数据字典。 所以，即使使用该参数正常打开后，也需要做的一个操作：逻辑导出数据。 重建实例，导入实例。 消除逻辑坏块的可能性。
如果使用_allow_resetlogs_corruption参数启动报了undo segment的错误而无法启动，处理方法参考第二节中undo 的处理情况。 只要DB 能正常open，就导出数据，重建实例，在导入。