一次TB级ERP(ASM RAC)库的恢复案例

前不见某客户的ERP 库出现故障(Linux x64,10204 rac ams环境). 大概问题是由于一些列操作之后导致磁盘组无法mount,
只能进行数据恢复,针对该case,我们前后投入了8个人力,进行了3天3夜终于成功抢救该数据库。

首先是客户在rac其中一个节点add disk时,发现在另外节点未添加成功,后面又反复折腾add,甚至dd 盘头进行了add。
最为致命的一个动作是强制add disk,其实在该步骤之前这几个disk已经add过一次,且完成了reblance,但是drop disk
却并未成功,最后客户尝试强制添加,如下:

首先利用kfed 读取相关的disk,发现asm的相关元数据基本上都不存在了,因为前面的add disk force其实相当于是吧
diskgroup 重建了一次,其中最为关键的file directory元数据没了。这是非常麻烦的一件事。

在恢复的过程中,我们甚至尝试了Oracle DUL,发现file directory完全丢失的情况下,dul根本无法正常工作。当然,

我们利用老熊的ODU成功的恢复了该库。ODU目前有这样的一个强悍功能,可以进行scan asm disk,然后将所有数据文件

的AU分配信息扫描出并记录到一个文件asm_fileext_meta.odu 中,然后可以自动的将AU进行拼接,也就形成了一个完整

的数据文件,大致的语法如下:

备注:
1.   第一次使用抽取文件的方式进行了恢复,由于数据字典损坏严重,导致数据库open后问题不断(其中还修复了
大量的block,因为部分block是空的,空块是因为部分disk完成了reblance,部分没有,导致抽取的数据字典不完整),
因此我们又重新抽取了一次数据,并重建库导入,前后花费了大量的人力,当然这也是我第一次利用ODU
恢复ERP库,并完美的解决问题。 这里必须赞一个!

 

某客户的一套5TB Oracle RAC 数据库恢复案例

某客户的核心数据库存储问题导致数据库重启后无法正常启动,根据客户反馈最开始在启动数据库时
报错控制文件IO错误,如下:

上述的问题本质上都跟控制文件有关系,替换掉损坏的控制文件就行。当替换掉控制文件之后,在open数据库时发现报如下错误:

该错误本质上是因为redo的问题,即有redo log损坏。通过在RMAN进行recover,发现报如下类似错误:

上述过程大致是客户之前的处理过程。我在18点左右介入之后,进行了相关的操作。我最开始尝试在利用RMAN 进行恢复,发现报错:

从上面的错误来看,初步可以判断redo04a.log文件已经损坏,而且是block 1788672的问题。为了验证该block是否损坏,我通过类似如下的dump 命令进行dump,发现报错:

由此判断,该block损坏无疑。 由于客户的需求是尽可能快的将数据库拉起来,因此对应redo损坏的情况之下。
通常只能进程不完全恢复并强制打开,这里我使用了如下的参数:

在open resetlogs之前,我已经将redo备份,resetlogs打开时,发现数据库报错如下:

从日志来看,大致判断可能是_SYSSMU25$ 回滚段的问题,因此尝试先通过如下隐含参数屏蔽回滚段:

屏蔽回滚段之后,尝试打开数据库,发现错误依旧,通过10046 trace跟踪,发现递归SQL在如下的block上执行失败:

通过dump file 1 block 91,发现该block上第2个ITL确认存在一个活跃事务。原本计划直接bbed提交该事务,但是当我编译好bbed之后,查看发现该block为一个cluster block.

对于cluster block的事务修改,相对复杂一些,我的博客有文章描述,大家可以参考,这里不多说。考虑到生产库使用bbed有一定的风险,我并没有使用bbed。

接着使用undo_management参数启动数据库,然后强制open数据库,发现错误变成如下:

从错误来看,我们就可以知道,这应该是SCN的问题。如果要手工推进SCN,那么level应该待遇3297*4才行,由于这里的238091117/1024/1024/1024小于1,因此推进scn时,level=3297*4+2 就差不多了。 这里我再次进行了10046 trace,发现了如下信息:

bscn: 0xce1.e379b05 将该scn进行转换,我们可以发现:0xce1 为3297,e379b05为238525189. 与上述报错信息一致。同时我发现这里使用了第2号回滚段,如下:

因此,尝试继续使用隐含参数屏蔽这第2号回滚段,并尝试打开数据库,但是错误依旧。看来还是需要调整SCN才行,如下:

首先我尝试了在会话级别设置:

发现alter database open失败,尝试使用*._minimum_giga_scn参数,但是在启动的时候,提示说该参数不支持。从此判断,该环境可能是安装了比较新的PSU,Oracle将该参数废弃掉了,这么说前面的10015 event根本就没起作用。 无奈只能通过oradebug手工修改SCN来启动数据库了,如下:

修改SCN之后,顺利打开了数据库,但是数据库很快就crash掉,如下是日志信息:

从上述日志信息来看,主要出现了如下几个错误:

ORA-00600 [6006],ORA-00600 [4137],ORA-00600 [kdsgrp1]

对于前面2个错误,很明显是Oracle SMON进程在进行利用回滚段进行事务rollback时失败导致,如下:
ORACLE Instance xxxx2 (pid = 22) – Error 600 encountered while recovering transaction (44, 26) on object 47098.
ORACLE Instance xxxx2 (pid = 22) – Error 600 encountered while recovering transaction (48, 25).

因此,不难看出,数据库中还有部分的回滚段存在活跃事务。

对于ORA-00600 [kdsgrp1]错误,通常是出现在Index上,即Index数据和表的数据不一致,一般来说可以通过重建解决。

其次,对于后面的ORA-08102: index key not found, obj# 239, file 1, block 1674 (2) 错误,主要是job调用出现,因此
我们可以暂时屏蔽job的调度。

对于ORA-08102错误,我的博客几年前也写过相关的文章,本质上也是Index block中的相关键值不存在导致。

与其如此,最后我感觉将数据库的所有回滚段都屏蔽掉,并重建数据库undo 表空间,如下是获取回滚段的命令:

strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u

经过整理,发现该库存在大约2600个回滚段,我了个去,先不管这么多,重启实例后,重建undo表空间:

最后重启数据库实例,让客户将关键核心的配置表导出,先进行业务恢复,如果需要数据,直接从库中抽取。
这里要补充一点,该库约为5TB多一点,虽然有备份,但是恢复时间太长,如果有个dataguard是多么的重要啊!