Oracle恢复数据，你真的会吗？

先问个问题吧——你遇到过数据库突然打不开，alert log疯狂刷ORA-19815这种“归档空间爆掉”的错误吗？我遇到过……不止一次。但最头疼的还不是这个，而是归档文件本身被误删，然后数据库一下子变成了“硬伤”。今天就来聊聊oracle恢复数据这件事，不讲教科书式的理论，全是实战里摸爬滚打的经验。

www.sosit.com.cn

技王数据恢复

大概是上个月吧，一个做电商的朋友半夜打电话过来，说他们的Oracle 11g R2在跑了几个小时的批量导入后，突然所有会话都挂住了。重启实例直接起不来，报的是ORA-00354和ORA-00353，一看就知道是redo log损坏。他还在那边问“能不能用备份恢复啊？上个礼拜做了全库备份”。我心想：全备是上周的，这周的数据怎么办？而且redo损坏，光靠备份不一定能搞定。于是开始了我最熟悉的oracle恢复数据流程。

www.sosit.com.cn

第一步：判断故障类型，别急着动手

很多人一听到数据丢失，第一反应就是“赶紧跑脚本，用rman恢复”。但跑之前你得先想明白：到底丢的是什么？是数据文件掉了？redo log坏了？还是控制文件挂了？不同场景，恢复路径完全不一样。比如刚才那个客户，redo损坏，但数据文件还在，而且有归档日志——虽然归档也不全。这时候不能贸然用‘resetlogs’去重建redo，否则可能会让数据文件之间的SCN不一致，连resetlogs都救不回来。 www.sosit.com.cn

常见故障判断清单

• ORA-00312 / ORA-00313：在线日志成员损坏。先检查是否所有成员都坏了，如果只有一个成员损坏，删掉坏的那个，数据库通常能继续运行——但别高兴太早，得马上补一个成员。
• ORA-00257：归档空间满。这个最简单，清掉归档然后手工切换日志就行，但如果是磁盘本身故障，那就是的问题了。
• ORA-01157 / ORA-01110：数据文件离线或丢失。可能需要从备份恢复该数据文件，或者用‘alter database datafile offline drop’后重建，但要注意索引和主键。
• ORA-00600 [4194] / [4193]：redo日志和undo块不匹配，常见于redo损坏。这种情况下，很可能需要用到‘_allow_resetlogs_corruption’之类的隐含参数。

第二步：制定恢复策略，不要一根筋

还是说上面那个案例。归档日志虽然有，但缺了中间两个归档——因为几天前归档被DBA手动删掉了，没做好备份。这就比较尴尬了：用rman恢复只能恢复到丢失的归档之前，那这之后的数据怎么办？我当时的思路是：先尝试让数据库以不完全恢复的方式打开，然后通过日志挖掘或者第三方工具去补缺失的数据。但前提是数据文件不能有物理坏块。用rman的‘validate’检查了一下，还好数据文件都正常。于是决定做一次基于SCN的不完全恢复，打开数据库后用技王数据恢复的工具尝试扫描未被覆盖的redo记录——别急，我知道有人会问“技王不是做文件系统的吗？”其实他们也有数据库模块，专门处理碎片化的日志数据，这里需要灵活变通。 www.sosit.com.cn

核心操作步骤（不完全恢复 typical 流程）

注意：以下操作需要sys权限，建议在备库或测试环境先演练。

1. 启动到mount状态：startup mount;
2. 查询可用的归档和current redo：list backup; list archivelog all;（如果使用rman）
3. 如果不使用rman，直接用sqlplus：recover database until cancel; 然后手动应用归档到缺失的那个位置。
4. 当遇到ORA-01547或ORA-01194时，说明某些归档缺失，可以用recover database using backup controlfile until cancel; 尝试跳过丢失的归档（前提是数据库已经启用了‘undo tablespace offline’）。
5. alter database open resetlogs;——但一旦resetlogs，之前的所有归档恢复就都失效了，要确认真的没有其他办法了再执行。

那位客户运气不错，丢失的归档里记录的是少量更新操作，我们用技王数据恢复的日志分析工具从在线undo和尚未覆盖的归档文件中提取了SQL语句，然后手动重跑了一遍。虽然花了大概4个小时，但最终oracle恢复数据成功，数据完整度达到98%——丢失了几条测试记录，但核心业务没受影响。 技王数据恢复

第三步：应急处理的几个坑

干这行久了，发现很多DBA或者运维人员在紧急情况下会犯低级错误。比如： 技王数据恢复

• 直接删除已经坏掉的数据文件，想用‘offline drop’解决——但会导致那些对象无法访问，要是表空间里面有数据字典的话可能连数据库都打不开。
• 强行用‘_allow_resetlogs_corruption’参数打开数据库——虽然官方不建议，但有时候这是的选择。一旦打开，必须马上做全库导出再重建，否则后面隐患很大。
• 误以为有了rman备份就万事大吉——备份文件本身也可能损坏。我建议每周做一次‘restore validate’检查。

，归档日志的保留策略也很关键。很多公司设置保留1天，结果周末出故障时归档全没了。最好至少保留3天，并且做异地备份。 技王数据恢复

随机案例：一个意想不到的truncate恢复

有一次，某制造业客户误执行了truncate table（大表，有几十亿行）。他们备份是在执行前半小时做的，可以通过flashback database恢复。但问题是他们没开闪回日志！这时候还有没有救？我当时建议：如果数据库是归档模式，并且有完整的归档和current redo，可以通过redo挖掘出truncate之前的一条记录——不对，truncate是DDL，不会产生UNDO，通过常规方式恢复不了。，可以利用空间管理的一个小技巧：truncate操作实际上只是重置了高水位线，并没有立即覆盖数据块。在Oracle的存储结构里，只要这些数据块没有被其他会话复用，就可以通过第三方工具（比如技王数据恢复的数据库模块）直接扫描数据文件，找到未覆盖的旧行。幸好那个表是每天晚上做批量更新，truncate之后他们立即停了应用，数据全部被捞出来了。那次总共恢复了大概99.9%的数据，只丢失了truncate瞬间正在写入的少量记录。

总结：oracle恢复数据没有银弹

每一次恢复都是一个推理过程。你需要综合判断错误类型、备份情况、归档完整性、以及业务对数据丢失的容忍度。没有万能脚本，只有不断积累的经验。oracle恢复数据这件事，最关键的点在于：**在一切还来得及之前，做好预防**。每天检查alert日志，定期做恢复演练，别等出事了再抱佛脚。说一句——万一真遇到棘手的情况，别一个人死磕，可以找专业的团队帮忙，比如经常合作的技王数据恢复，他们有实验室级别的设备，能处理物理坏盘+逻辑损坏的复合故障。这篇文章主要还是聊思路，希望大家能自己掌握基本的方法论。

以上，就是一个老工程师的碎碎念。如果你也有oracle恢复数据的奇葩经历，欢迎交流。