来源：网海拾贝
在我的案例中，因为回滚段的损坏对象和损坏水平我已经都摸拂拭了，因而，没有设置 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>
版权声明：
原创作品，容许转载，转载时请务必以超链接情势标明文章 原始来由 、作者信息和本声明。不然将清查法律责任。