_OFFLINE_ROLLBACK_SEGMENTS 和 _CORRUPTED_ROLLBACK_SEGMENTS的这两个参数可以强制打开数据库，但是open后，最好导出，重建库，然后再导入。对这两个参数不是很了解，直到看到了maclean的帖子，下面是帖子地址
_CORRUPTED_ROLLBACK_SEGMENTS隐藏参数
http://www.askmaclean.com/archives/_corrupted_rollback_segments.html
_OFFLINE_ROLLBACK_SEGMENTS隐藏参数
http://www.askmaclean.com/archives/_offline_rollback_segments.html
我把内容放一份在下面
_CORRUPTED_ROLLBACK_SEGMENTS(corrupted undo segment list)隐藏参数所独有的功能:
在实例启动startup并open database的阶段_CORRUPTED_ROLLBACK_SEGMENTS所列出的undo segments(撤销段/回滚段)将不会被访问读取
所有指向这些被_CORRUPTED_ROLLBACK_SEGMENTS列出的undo segments的事务都被认为已经提交了commit，和这个undo segments已经被drop时类似
这将导致严重的逻辑讹误
如果数据字典上有活跃事务那么将更糟糕，数据字典逻辑讹误会造成数据库管理问题
如果bootstrap自举核心对象有活跃事务，那么将无法忽略错误ORA-00704: bootstrap process failure错误，导致无法强制打开数据库(见拙作Oracle数据恢复:解决ORA-00600:[4000] ORA-00704: bootstrap process failure错误一例)
衷心地建议用_CORRUPTED_ROLLBACK_SEGMENTS这个参数打开数据库后导出数据并重建数据库，这个参数使用的后遗症可能很顽固
Oracle公司内部有叫做TXChecker的工具可以检查问题事务
_OFFLINE_ROLLBACK_SEGMENTS(offline undo segment list)隐藏参数(hidden parameter)的独有作用：
在实例startup启动并open database的阶段仍将读取_OFFLINE_ROLLBACK_SEGMENTS所列出的Undo segments(撤销段/回滚段)，若访问这些undo segments出现了问题则将在alert.log和其他TRACE中体现出来，但不影响实际的startup进程
若查询数据块发现活跃的事务，并ITL指向对应的undo segments则：
若读取undo segments的transaction table事务表发现事务已提交则做数据块的清除
若读取发现事务仍活动未commit，则生成一个CR块拷贝
若读取该undo segments存在问题(可能是corrupted讹误，可能是missed丢失)则产生一个错误并写出到alert.log，查询将异常终止
若DML更新相关的数据块会导致服务进程为了恢复活跃事务而进入死循环消耗大量CPU，解决方法是通过可以进行的查询工作重建相关表
_offline_rollback_segments 和 _corrupted_rollback_segments 均会造成的实例行为变化：
- 以上2个参数所列出的Undo Segments(撤销段/回滚段)将不会被在线使用online
- 在UNDO$数据字典基表中将体现为OFFLINE的记录
- 在实例instance的生命周期中将不会再给新的事务分配使用
- 参数所列出的Undo Segments列表上的活跃事务active transaction将即不被回滚亦不被标记为dead以便SMON去回滚(了解你所不知道的SMON功能(五):Recover Dead transaction)