在我的案例中，由于回滚段的损坏对象和损坏程度我已经都摸清除了，因此，没有设置 event = 10015 或者10046等等，而是尝试恢复。
恢复的过程主要是：
从温柔型的到坚决型的，逐步试验：
1, 找到有问题的对象，备份并尝试重建，如果失败继续下一步骤
2, 重启数据库（clear shutdown and startup），如果问题不能被系统自行化解，那么继续下一步骤
3, 使用 event="10015 trace name context forever, level 10" 找到损坏回滚段的和对象等等的一些信息
4, 使用 _smu_debug_mode=4并使用manual的方式管理UNDO,即将回滚段设置为手工的debug模式，可以在启动数据库后尝试删除那个回滚段试试看
5, 上述都不行（根据我的经验，通常有一半的生产环境使用前3步都不行，不过也要视损害的具体情况而定了）
那么就是用 _offline_rollback_segments = ('List of rollback segments') ，启动数据库，然后删除那么损坏的回滚段，并重建那个undo空间。
这么做通常可以解决大部分问题，并且不需要重建数据库。
注意，在少数情况下仍然会出现使用这个参数导致不一致情况，需要重建数据库，主要是和数据库启动时后的一些状态有关。
6, 上述都不行，就使用_corrupted_rollback_segments ，当然大多数情况下还需要加上“_allow_resetlogs_corruption”
即，既不要当前的undo空间，也不要当前的redo（他们都被标记为损坏）。
但是这样以来，数据库是需要重建的，否则使用中也是会经常会出现不可预期的错误。
看看这些参数的定义：
lunar@TSMISC02> select KSPPDESC from X$KSPPI where ksppinm='_corrupted_rollback_segments';
KSPPDESC
----------------------------------------------------------------
corrupted undo segment list
Elapsed: 00:00:00.03
lunar@TSMISC02> select KSPPDESC from X$KSPPI where ksppinm='_allow_resetlogs_corruption';
KSPPDESC
----------------------------------------------------------------
allow resetlogs even if it will cause corruption
Elapsed: 00:00:00.11
SQL> select KSPPDESC from X$KSPPI where ksppinm='_smu_debug_mode';
KSPPDESC
----------------------------------------------------------------
<debug-flag> - set debug event for testing SMU operations
SQL> select KSPPDESC from X$KSPPI where ksppinm='_offline_rollback_segments';
KSPPDESC
----------------------------------------------------------------
offline undo segment list
SQL>