作者：IT邦德
中国DBA联盟(ACDU)成员，10余年DBA工作经验，
Oracle、PostgreSQL ACE
CSDN博客专家及B站知名UP主，全网粉丝10万+
擅长主流Oracle、MySQL、PG、高斯及Greenplum备份恢复，
安装迁移，性能优化、故障应急处理
微信:jem_db
QQ交流群:587159446
公众号：IT邦德

前言

最近核心业务使用的一套Oracle数据库故障，由于自己的疏忽，导致恢复失败，彻底瘫痪了，分享经验给大家，引以为鉴

1.故障现象

ORACLE的RAC的2个数据库实例异常停止，查看日志以及试用 dbv 命令发现控制文件坏块，跟用户确认得知怀疑是近期服务器突发掉电导致，让人吐血的是多路复制的2个控制文件同时被破坏

再次用dbv 命令发现控制文件坏块程度及其严重，并且发现此套RAC，没有开归档、也没有做任何备份

2.恢复过程

2.1 重建控制文件

由于该数据库无备份，所以只能手工创建控制文件进行恢复，且数据库只能在 nomount 状态，无法生成控制文件，只能在 asm 里找到相关数据文件以及redo文件，手动生成的控制文件如下

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS NOARCHIVELOG
MAXLOGFILES 192
MAXLOGMEMBERS 3
MAXDATAFILES 1024
MAXINSTANCES 32
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '+data/rac/redo01.log' SIZE 50M,
GROUP 2 '+data/rac/redo02.log' SIZE 50M,
GROUP 3 '+data/rac/redo03.log' SIZE 50M,
GROUP 4 '+data/rac/redo04.log' SIZE 50M
-- STANDBY LOGFILE
DATAFILE
'+data/rac/system01.dbf',
'+data/rac/undotbs01.dbf',
'+data/rac/sysaux01.dbf',
'+data/rac/undotbs02.dbf',
'+data/rac/users01.dbf'
CHARACTER SET UTF8

2.2 恢复数据库

重建控制文件后，需要进行 recover database
由于数据库无归档，所以无法进行恢复。
使用隐含参数强制拉起数据库：
alter system set “_allow_resetlogs_corruption”=true scope=spfile;

2.3 开库

问题就出现在这一步
ALTER DATABASE OPEN ESETLOGS命令发出后
原始的在线日志被重构，导致数据库内部有不一致情况，这次是彻底的失败了
数据文件头部写的scn全乱了
正确的命令应该是ALTER DATABASE OPEN一致性开库

从恢复的过程alert日志报错也能明显确认到，相当于日志文件，数据文件，控制文件ckpt信息完全不相同了。非归档模式前推找不到基准线，再者恢复之前的在线日志也没有备份，彻底被重构了。

3.反思

经过这一次失败的故障失败，总结如下

1.故障发生后，保护原始环境非常重要，
做任何操作提前做好备份
2.备份恢复的作业流程需要反复确认，
最好有环境测试通过验证再实施
3.核心业务库必须开归档，做RMAN备份，
防止突发故障造成核心文件的损坏

4.后期处理

由于控制文件损坏重建后，没有备份和归档，无法进行恢复操作，导致数据库内部有不一致情况。如果想继续尝试，就只能尝试那种修改底层的非常规手段.

DUL是Data Unloader的缩写，Oracle内部恢复工具，为Oracle公司工程师 Bernard van Duijnen 开发，以标准C写成，在不同平台上会使用不同的binary文件，可以直接从Oracle的数据文件中读取数据，转换为DMP或文本格式输出，在特殊情况下可以用来进行数据恢复。这些特殊情况主要指，数据库没有有效备份、或者系统表空间损坏，或者在非归档模式下的不可逆数据损失等等，一旦普通手段失去作用，DUL就可以作为最后一招来最大限度的挽救用户数据。

5.总结

保护和恢复数据的能力对于确保业务连续性和减少潜在风险至关重要,作为DBA这是必须要精通的一门技术，吃一堑，长一智，此次故障恢复失败案例分享给大家，引以为鉴！