Oracle SYSTEM/UNDO表空间损坏是比较棘手的故障，通常会导致数据库异常宕机进而无法打开数据库。数据库的打开故障处理起来相对比较麻烦，读者可以参考本书第5章进一步了解该类故障的处理过程。如果数据库没有备份，通常需要设置官方不推荐的隐含参数或者使用bbed工具修复损坏的数据块来强制打开数据库，所以此类故障处理起来存在着风险性和不可预知性。当碰到此类故障时，笔者的处理思路如下（假设数据库没有备份）：
（1）检查数据库的警告日志，初步确定数据库打不开的原因。如果是RAC，则检查所有节点的警告日志。
（2）物理备份整个数据库。如果备份到本地，其备份速度最终取决于数据库大小和存储I/O能力。如果通过网络备份到异地，则还取决于网络带宽。
（3）用dbv工具校验SYSTEM/UNDO表空间，确定数据块的损坏范围和严重程度。
（4）关闭监听。其目的是数据库成功打开之后，外部应用不会立刻连接至数据库。
（5）进行故障处理。具体的处理思路请参考第5章。
（6）如果是UNDO表空间有坏块，可以设置隐含参数_offline_rollback_segments屏蔽坏块所在的回滚段来打开数据库。如果熟悉数据块格式，则可以用bbed工具修复损坏的数据块。
提示：如果空间不够或者备份时间过长，则备份SYSTEM、UNDO和SYSAUX表空间下的数据文件、控制文件、所有在线日志文件。非常规手段修复数据库所带来的副作用很难被DBA全部预见到，为防止事态进一步恶化，所以在问题处理之前必须全部备份上述文件。对于不可逆转的修复，DBA一定要小心，备份为上！