ASM AMDU工具使用

转自：http://blog.itpub.net/29065182/viewspace-1157086

AMDU是ORACLE针对ASM开发的源数据转储工具，其全称为ASM Metadata Dump Utility(AMDU)

从oracle 11gR2版本,amdu工具可以直接使用,不需要单独下载 命令放在$ORACLE_HOME/bin
 
AMDU具体以下三个主要功能：
 
1. 将ASM DISK上的元数据转储到文件系统上以便分析
 2. 将ASM文件的内容抽取出来并写入到OS文件系统，Diskgroup是否mount均可
 3. 打印出块的元数据，以块中C语言结构或16进制的形式
 
这里我们将用到使用AMDU抽取ASM DISKGROUP中的数据文件； ASM作为近几年最流行的存储解决方案， 大家对他的优缺点都有所了解，其中的问题之一就是ASM是个黑盒。 一旦DISKGROUP无法MOUNT起来就意味着传统方法无法以磁盘为基础导出任何数据。
 
AMDU解决了这一问题， 这里我们仅讨论在ASM DISKGROUP 无法MOUNT的情况下的范畴，不讨论RDBMS数据文件在ASM下讹误的处理。
 
注意 AMDU虽然是11g才发布的工具，但是实际对10g的ASM 也有效。
 
当前你可能遇到的场景是， ORACLE DATABASE的SPFILE、CONTROLFILE、DATAFILE均存放在ASM DISKGROUP中，而由于一些ASM ORA-600错误导致无法MOUNT该DISKGROUP， 你需要的是使用AMDU将这些文件从ASM DISK中转储出来。
 
场景 1 丢失了 包括SPFILE、CONTROLFILE、DATAFILE
 
恢复步骤： 从备份中还原出SPFILE ，即便没有SPFILE的话PFILE也可以，总之你需要从参数文件中了解control_files的信息
 
SQL> show parameter control_files
 
NAME TYPE VALUE
 ———————————— ———– ——————————
 control_files string +DATA/prodb/controlfile/curren
 t.260.794687955, +FRA/prodb/co
 ntrolfile/current.256.79468795
 5
 
获得control_files 控制文件在ASM中的位置后事情就好办了，+DATA/prodb/controlfile/current.260.794687955 这里 260是这个控制文件在+DATA 这个DISKGROUP中的FILE NUMBER
 
此外我们还需要ASM DISK的DISCOVERY PATH信息，这完全可以从ASM的SPFILE中的asm_diskstring 参数获得
 
[oracle@mlab2 oracle.SupportTools]$ unzip amdu_X86-64.zip
 Archive: amdu_X86-64.zip
 inflating: libskgxp11.so
 inflating: amdu
 inflating: libnnz11.so
 inflating: libclntsh.so.11.1
 
[oracle@mlab2 oracle.SupportTools]$ export LD_LIBRARY_PATH=./
 
[oracle@mlab2 oracle.SupportTools]$ ./amdu -diskstring ‘/dev/asm*’ -extract data.260
 amdu_2009_10_10_20_19_17/
 AMDU-00204: Disk N0006 is in currently mounted diskgroup DATA
 AMDU-00201: Disk N0006: ‘/dev/asm-disk10′
 AMDU-00204: Disk N0003 is in currently mounted diskgroup DATA
 AMDU-00201: Disk N0003: ‘/dev/asm-disk5′
 AMDU-00204: Disk N0002 is in currently mounted diskgroup DATA
 AMDU-00201: Disk N0002: ‘/dev/asm-disk6′
 
[oracle@mlab2 oracle.SupportTools]$ cd amdu_2009_10_10_20_19_17/
 [oracle@mlab2 amdu_2009_10_10_20_19_17]$ ls
 DATA_260.f report.txt
 [oracle@mlab2 amdu_2009_10_10_20_19_17]$ ls -l
 total 9548
 -rw-r–r– 1 oracle oinstall 9748480 Oct 10 20:19 DATA_260.f
 -rw-r–r– 1 oracle oinstall 9441 Oct 10 20:19 report.txt
 
以上转储出来的DATA_260.f 就是控制文件，我们使用该控制文件startup mount RDBMS实例：
 
SQL> alter system set control_files=’/opt/oracle.SupportTools/amdu_2009_10_10_20_19_17/DATA_260.f’ scope=spfile;
 
System altered.
 
SQL> startup force mount;
 ORACLE instance started.
 
Total System Global Area 1870647296 bytes
 Fixed Size 2229424 bytes
 Variable Size 452987728 bytes
 Database Buffers 1409286144 bytes
 Redo Buffers 6144000 bytes
 Database mounted.
查看数据文件的位置，然后一一导出
1234567891011 
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
+DATA/db/datafile/system.256.804295135
+DATA/db/datafile/sysaux.257.804295137
+DATA/db/datafile/undotbs1.258.804295139
+DATA/db/datafile/users.259.804295141
$  amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.256     <<<<<<<<<<<<<<system
 $  amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.257     <<<<<<<<<<<<<<sysaux
 $  amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.258     <<<<<<<<<<<<<<undotbs1
 $  amdu -diskstring '/dev/oracleasm/disks/ASMDISK*' -extract data.259     <<<<<<<<<<<<<<users .="" 10.="" 重命名数据文件，并移动到同一个目录下，准备挂载数据文件
 12345678 
$ mv amdu_2013_07_03_18_12_56/DATA_257.f sysaux.257.804295137
$ mv amdu_2013_07_03_18_22_23/DATA_259.f users.259.804295141
$ mv amdu_2013_07_03_18_23_06/DATA_258.f undotbs1.258.804295139
$ ll
-rw-r--r-- 1 oracle dba 545267712 Jul  3 18:14 sysaux.257.804295137
-rw-r--r-- 1 oracle dba 702554112 Jul  3 18:11 system.256.804295135
-rw-r--r-- 1 oracle dba  99622912 Jul  3 18:23 undotbs1.258.804295139
-rw-r--r-- 1 oracle dba   5251072 Jul  3 18:22 users.259.804295141 
11. 挂载前需要修改pfile文件，下面是open数据库是control file如何识别不同路径的datafile， 我使用convert参数来解决（也可以是用set newname的方式）
db_file_name_convert='+DATA/db/datafile','/u01/amdu/amdu_datafile' 
添加完pfile，启动数据库，最终成功启动数据库
12345678910111213141516 
SQL> startup pfile='/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfilebk.ora';
[oracle@Single-DB ~]$ sqlplus / as sysdba
Connected to an idle instance.
SQL> startup pfile='/u01/app/oracle/product/11.2.0/dbhome_1/dbs/spfilebk.ora';
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size                  2220200 bytes
Variable Size             281022296 bytes
Database Buffers          780140544 bytes
Redo Buffers                5554176 bytes
Database mounted.
Database opened.
SQL>  select status, instance_name  from v$instance;
STATUS       INSTANCE_NAME
------------ ----------------
OPEN         db 
总结，备份很重要！！
由于是在我测试库上进行的实验，我没有破坏数据文件来完全模拟客户问题。
但是通过这个测试，我们可以确认的是，在ASM diskgroup无法挂载的情况下，我们是有办法将数据文件读出（即使是坏的），然后我们在针对具体的坏块尝试block恢复（估计没有备份，这个也没辙了）。
但是至少，数据文件摆在我们面前了，我们还有其他很多办法去尝试修复，再不行，也只是丢失部分数据，因为其中可能只是个别数据文件的个别block损坏。
总之，数据文件弄出来了，剩下的，继续研究吧。