联系：手机/微信(+86 17813235971) QQ(107644445)
标题：不太常见的10.2.0.1的oracle redo损坏恢复
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
曾经恢复过大量10g的库,现在一年也恢复不了几个10g的了,而10.2.0.1的64位库更是少之又少了.近期有幸处理过一个这样的case,重温了当年的感觉
SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi PL/SQL Release 10.2.0.1.0 - Production CORE 10.2.0.1.0 Production TNS for 64-bit Windows: Version 10.2.0.1.0 - Production NLSRTL Version 10.2.0.1.0 - Production
由于系统断电导致该版本的erp系统的数据库无法启动,看alert日志由于redo损坏导致异常(ORA-00354 ORA-00353)
Thu Jun 04 10:27:40 2026 ALTER DATABASE RECOVER datafile 5 Thu Jun 04 10:27:40 2026 Media Recovery Start WARNING! Recovering data file 5 from a fuzzy backup. It might be an online backup taken without entering the begin backup command. parallel recovery started with 7 processes Thu Jun 04 10:27:40 2026 Recovery of Online Redo Log: Thread 1 Group 3 Seq 26215 Reading mem 0 Mem# 0 errs 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG Thu Jun 04 10:28:06 2026 Errors in file d:\oracle\product\10.2.0\admin\ORCL\udump\ORCL_ora_3856.trc: ORA-00354: 损坏重做日志块头部 ORA-00353: 日志损坏接近块 93816 更改 1049070732 时间 05/27/2025 18:00:16 ORA-00334: 归档日志: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG'
接手之后再次验证了该错误
这种错误基本上要不bbed/obet修改文件头,要不直接屏蔽一致性强制打开,我直接选择了强制拉库,先做不完全恢复
然后强制拉库报ORA-600 2662错误
直接使用_minimum_giga_scn修改scn,数据库open成功,并使用expdp成功导出数据,完成本次恢复工作
