amdu 挽救6T数据全过程

这是一个借助amdu工具从失败的asm 实例抽出6T数据的样例，但也有60G数据丢失,
无论技术工具，还是思考问题的方式，还是坚持不协努力的精神，对我有着很大的启发。
同时也是一个远程解决数据库问题的案例

2012 年9月17日 周一 天气不错 ，刚上班，还没有看完新闻，东南亚印尼一现场同事
报告 主业务系统 三个RAC 点开部异常，
crs_stat  一看asm  实例起不来了

 

 
这是印尼 一运营商OSS 系统 7X24

OS:suse10
 
DBMS:Oracle11.1.0.7
 
主机:IBMx3850

存储: 华赛3600 ,托三个柜

数据库尺寸:6T
 
检查asm.log
 
kfdp_queryBg(): 5
NOTE: cache opening disk 0 of grp 2: DG_ORA_0000 path:/dev/raw/raw3
NOTE: F1X0 found on disk 0 fcn 0.0
NOTE: cache opening disk 1 of grp 2: DG_ORA_0001 path:/dev/raw/raw4
NOTE: cache opening disk 2 of grp 2: DG_ORA_0002 path:/dev/raw/raw5
NOTE: cache opening disk 3 of grp 2: DG_ORA_0003 path:/dev/raw/raw6
NOTE: cache opening disk 4 of grp 2: DG_ORA_0004 path:/dev/raw/raw7
NOTE: cache opening disk 5 of grp 2: DG_ORA_0005 path:/dev/raw/raw8
NOTE: cache opening disk 6 of grp 2: DG_ORA_0006 path:/dev/raw/raw9
NOTE: cache mounting (first) group 2/0xBD785B38 (DG_ORA)
* allocate domain 2, invalid = TRUE
kjbdomatt send to node 0
kjbdomatt send to node 2
NOTE: attached to recovery domain 2
NOTE: starting recovery of thread=1 ckpt=348.1542 group=2
NOTE: starting recovery of thread=2 ckpt=189.5027 group=2
NOTE: starting recovery of thread=3 ckpt=182.5380 group=2
Errors in file /opt/oracle/db/diag/asm/+asm/+ASM2/trace/+ASM2_ora_13235.trc  (incident=4155):
ORA-00600: internal error code, arguments: [kfcema02], [0], [165057275], [], [], [], [], [], [], [], [], []
Incident details in: /opt/oracle/db/diag/asm/+asm/+ASM2/incident/incdir_4155/+ASM2_ora_13235_i4155.trc
Abort recovery for domain 2
NOTE: crash recovery signalled OER-600
ERROR: ORA-600 signalled during mount of diskgroup DG_ORA
ORA-00600: internal error code, arguments: [kfcema02], [0], [165057275], [], [], [], [], [], [], [], [], []
ERROR: ALTER DISKGROUP ALL MOUNT
NOTE: cache dismounting group 2/0xBD785B38 (DG_ORA)
NOTE: lgwr not being msg'd to dismount
Trace dumping is performing id=[cdmp_20120917220439]
kjbdomdet send to node 0
detach from dom 2, sending detach message to node 0
kjbdomdet send to node 2
detach from dom 2, sending detach message to node 2
freeing rdom 2
NOTE: detached from domain 2
NOTE: cache dismounted group 2/0xBD785B38 (DG_ORA)
NOTE: cache ending mount (fail) of group DG_ORA number=2 incarn=0xbd785b38
kfdp_dismount(): 6
kfdp_dismountBg(): 6
NOTE: De-assigning number (2,0) from disk (/dev/raw/raw3)
NOTE: De-assigning number (2,1) from disk (/dev/raw/raw4)
NOTE: De-assigning number (2,2) from disk (/dev/raw/raw5)
NOTE: De-assigning number (2,3) from disk (/dev/raw/raw6)
NOTE: De-assigning number (2,4) from disk (/dev/raw/raw7)
NOTE: De-assigning number (2,5) from disk (/dev/raw/raw8)
NOTE: De-assigning number (2,6) from disk (/dev/raw/raw9)
ERROR: diskgroup DG_ORA was not mounted
NOTE: cache dismounting group 1/0x0A485B37 (ASMREDO1)
kjbdomdet send to node 0
detach from dom 1, sending detach message to node 0
kjbdomdet send to node 2
detach from dom 1, sending detach message to node 2
NOTE: detached from domain 1
NOTE: cache dismounted group 1/0x0A485B37 (ASMREDO1)
kfdp_dismount(): 7
kfdp_dismountBg(): 7
NOTE: De-assigning number (1,0) from disk (/dev/raw/raw10)
ERROR: diskgroup ASMREDO1 was not mounted

 
从日志来看，感觉与存储相关，进入磁阵管理平台查看
 
其中第三个柜的磁盘全部warning 状态。又联系现场同事，收集各种存储日志，
发给华赛存储工程师,经确定，当时系统上线第三个柜的联线出错了，只有一个控制器有效的。
今天这个可以工作的控制器出现异常。在工程师的指导下，重新正确联线。

排除了硬件问题，
 
开始启动数据库，完了。ASM实例还是没有起来。

 
经过一系列的尝试 ASM 实例还是不能mount
 
ASM 实例里有两个DISKGROUP
一个小的DISKGROUP REDODG 存放的是redo controlfile spfile 文件,这个diskgroup可以mount
通过asmcmd 里可以看到相关的文件,也可以cp出

DGORA diskgroup 存放的是所有的数据文件 ，这个diskgroup不能mount ,
里面的数据文件也不能看到，里面有 6T数据左右。

 

尝试通过amdu 把数制抽取出来,oracle11G里已经自带了这个小工具
 echo $LD_LIBRARY_PATH

在这个目录下

amdu 的命令例子
 
amdu -diskstring '/dev/raw/raw*' -extract 'DG_ORA.259'

DG_ORA.259 导出的这个文件对应哪个数据文件呢
对应的信息可以从
v$asm_alias 里查看
select name, file_number from  v$asm_alias
filenumber 与name 是一一对应的

但当是v$asm_alias因为diskgroup 里已民经不能查到相关信息
比较幸运的是有一份awr报告，可以有些数据文件是采用template 创建
比如  +DG_ORA/mos5200/datafile/undotbs1.261.795360547 对应的就是 DG_ORA.261

 
通过推算确定多数的文件号与数据文件的对应
 
有一些实不能确定
 
可能通过dump 确认其文件号

 alter system dump datafile '/extracted file' block 0;
 
通过其生成的trace 文件可以确认所有的数据文件,比较遗憾的是有两个32G的数据文件无论如何也没有找到

6T 的数据存在哪呢， 前线同事同事多方筹措借到一个6T的盘阵
 
重新构建库， spifle redo control 等

完成之后可mount .重命名数据文件
 
alter database  rename file '+DG_ORA/mos5200/datafile/system.259.776792687'  to '/bak6/DG_ORA/DG_ORA_259.f';
.
.
.
alter database rename file '+DG_ORA/mos5200/datafile/pm4h_db70.dbf' to '/bak7/DG_T/DG_ORA_583.f';

 
.SQL> startup
ORACLE 例程已经启动。
Total System Global Area 293601280 bytes
Fixed Size 1248624 bytes
Variable Size 121635472 bytes
Database Buffers 167772160 bytes
Redo Buffers 2945024 bytes
数据库装载完毕。
ORA-01122: 数据库文件 1 验证失败
ORA-01110: 数据文件 1:
'F:\ORACLE\PRODUCT\10.2.0\DB_1\ORADATA\ORCLDW\SYSTEM01.DBF'
ORA-01207: 文件比控制文件更新 - 旧的控制文件
4.SQL> alter database backup controlfile to trace as 'e:\controlfile';
数据库已更改。
5.SQL> shutdown immediate    如果数据库是打开状态，则关闭
ORA-01109: 数据库未打开
已经卸载数据库
6.SQL> startup nomount;
ORACLE 例程已经启动。
Total System Global Area 105979576 bytes
Fixed Size 454328 bytes
Variable Size 79691776 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes

7.Editplus之类的编辑器打开在第4步生成的e:\controlfile'文件；
其实在这个文件中的已经告诉你咋样恢复你的数据库了，找到STARTUP NOMOUNT字样(有好几处)，
然后下面可以看到类似语句，这个文件有好几个类似的生成控制文件语句，主要针对不同的环境执行不同的语句，
象我的数据库没有做任何备份，也不是在归档模式，就执行这句(删除其中的注释行，
删除不需要的数据文件,中间不要有任何空行; 碰到错误执行
SQL> shutdown abort ;
SQL> startup nomount; )
SQL>

CREATE CONTROLFILE REUSE DATABASE "ZFXFZB" RESETLOGS  NOARCHIVELOG
    MAXLOGFILES 50
    MAXLOGMEMBERS 5
    MAXDATAFILES 100
    MAXINSTANCES 1
    MAXLOGHISTORY 680
LOGFILE
  ....................................
 
..........................................
 
.............................................
CHARACTER SET ZHS16GBK
;
 
执行上面这段语句，这个语句重建控制文件,然后你可以看着e:\controlfile'文件完成下面的恢复工作了，
SQL>RECOVER DATABASE    （恢复指定表空间、数据文件或整个数据库） ; 即使出现错误也可以正常使用。
SQL>ALTER DATABASE OPEN resetlogs;     
SQL>ALTER DATABASE OPEN;     打开数据库 ;

-------------The end--------------
 

 

amdu 来自metalink

 AMDU - ASM Metadata Dump Utility
 
AMDU is an utility to extract all the available metadata from one or more ASM disks and/or generate formatted printouts of individual blocks.The utility does not require that any diskgroup to be mounted.
 
Oracle Support may ask you to provide AMDU output, especially when facing internal errors related to the ASM metadata