今天以前某客户联系我,说有个库无法启动,花了几分钟远程看了一下,alert log信息如下:

​​Sun Mar 16 20:27:49 2014​​




​​Media Recovery Start​​





​​parallel recovery started with 7 processes​​




​​Sun Mar 16 20:27:49 2014​​




​​Recovery 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 2014​​




​​Errors 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 directory​​




​​Additional information: 4​​




​​Additional information: 67221​​




​​Additional information: 669184​​




​​Sun Mar 16 20:28:08 2014​​




​​Errors 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 directory​​




​​Additional information: 4​​




​​Additional information: 67221​​




​​Additional information: 669184​​




​​Sun Mar 16 20:28:19 2014​​




​​Media Recovery failed with error 333​​




​​ORA-283 signalled during: ALTER DATABASE RECOVER database ...​​




​​Sun Mar 16 20:30:16 2014​​




​​ALTER 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损坏不严重的话。