今天以前某客户联系我，说有个库无法启动，花了几分钟远程看了一下，alert log信息如下：
Sun Mar 16 20:27:49 2014Media Recovery Startparallel recovery started with 7 processes
Sun Mar 16 20:27:49 2014Recovery of Online Redo Log: Thread 1 Group 3 Seq 7363 Reading mem 0 Mem# 0 errs 0: /oracle/data/orclzjs/redo03.log
Sun Mar 16 20:28:01 2014Errors in file /opt/app/oracle/admin/orclzjs/udump/orclzjs_ora_21469.trc:ORA-00333: 重做日志读取块 67221 计数 6144 出错ORA-00312: 联机日志 3 线程 1: ‘/oracle/data/orclzjs/redo03.log‘ORA-27072: 文件 I/O 错误Linux-x86_64 Error: 2: No such file or directoryAdditional information: 4Additional information: 67221Additional information: 669184Sun Mar 16 20:28:08 2014Errors in file /opt/app/oracle/admin/orclzjs/udump/orclzjs_ora_21469.trc:ORA-00333: 重做日志读取块 65173 计数 8192 出错ORA-00312: 联机日志 3 线程 1: ‘/oracle/data/orclzjs/redo03.log‘ORA-27091: 无法将 I/O 排队ORA-27072: 文件 I/O 错误Linux-x86_64 Error: 2: No such file or directoryAdditional information: 4Additional information: 67221Additional information: 669184Sun Mar 16 20:28:19 2014Media Recovery failed with error 333ORA-283 signalled during: ALTER DATABASE RECOVER database ...Sun Mar 16 20:30:16 2014ALTER DATABASE RECOVER database until cancel
Sun Mar 16 20:30:16 2014这是很典型的Oracle currnet redo logfile损坏的案例。 询问发现该库是强制关的，重启主机后发现数据库无法正常启动了。
对于非归档的数据库，在停库之前，我们建议先进行alter system checkpoint,多切几次redo，然后kill 掉相关进程后再去shutdown。 哪怕是shutdown abort，这样风险都要小的多，至少强制open数据库不会存在数据丢失。
当然，客户这里肯定是必然丢失数据的了。 通过隐含参数很容易的打开数据库。
备注： 其实我们可以尝试去修复redo的，如果alert log中提到的2个redo log block损坏不严重的话。