通过日志可以看到由于磁盘头的元数据被破坏，ASM检测发现PST表不满足冗余要求后磁盘组被dismount。对于这种类似由于ASM磁盘元数据被破坏导致磁盘组无法mount，且元数据无法修复，需要找回ASM磁盘组中丢失的ASM文件时可以使用Oracle提供的AMDU工具进行抽取。
AMDU 介绍
AMDU是ASM Metadata Dump Utility的缩写，即asm元数据导出工具，它可以从asm磁盘中将元数据信息以及磁盘中的文件直接抽取出来，并且该工具不依赖asm磁盘组的状态，可以在asm实例关闭以及asm磁盘组dismount状态下正常使用。当磁盘组因为某些故障无法mount后，需要恢复数据就可以使用amdu工具对asm磁盘组中的数据文件进行抢修抽取，但需要注意的是，amdu只能将文件从asm磁盘中抽取出来，如果文件本身已经损坏，amdu是无法进行修复，抽取出来的文件将依然是损坏的，像这种情况，如果需要将损坏的数据文件中的数据找回，可以使用dul类工具直接读取抽取出来的数据文件找回数据。
回归主题
回到本次的故障处理，磁盘组已经无法mount，且难以修复，只能用AMDU将数据文件从asm磁盘中直接抽取，因为控制文件和参数文件以及日志文件所在的磁盘组均正常，整个恢复相对比较简单，如果控制文件所在的磁盘组也无法mount，我们可以从数据库alert文件中找到数据库控制文件的位置，这通常是第一步：
控制文件恢复：
control_files="+REDODG/xxxpd/controlfile/current.269.957297789"
然后通过amdu将控制文件抽取出来：
amdu -diskstring '/dev/xxx/*' -extract REDODG.269 -noreport -nodir
上面命令相关参数的含义：
· diskstring: 使用磁盘的全路径或者是ASM_DISKSTRING参数值
· extract: 磁盘组名.ASM文件序号
· output:提取的输出文件（当前目录下）
· noreport:不输出amdu的执行过程
· nodir:不创建dump目录
数据库启动到mount状态：
因为alert日志文件中输出的启动信息会包含实例参数信息，通过对输出的参数信息重新编辑一个参数文件，通过参数文件以及控制文件我们就可以将数据库启动到mount状态。
SQL> startup nomount pfile='/orabackup/tmp/init.ora'
ORACLE instance started.
Total System Global Area 3.2068E+10 bytes
Fixed Size 2269072 bytes
Variable Size 4362076272 bytes
Database Buffers 2.7649E+10 bytes
Redo Buffers 55242752 bytes
SQL> alter database mount;
Database altered.
SQL>
获取数据文件名称：
此时由于数据库已启动到mount状态，通过v$datafile视图既可获取数据文件名称。
select name from v$datafile;
+DATADG/xxx/datafile/system.347.957297809
+DATADG/xxx/datafile/sysaux.368.957297823
+DATADG/xxx/datafile/undotbs1.316.957297837
+DATADG/xxx/datafile/xxx_large.335.957297873
...
将ASM磁盘组中数据文件抽取到本地文件系统：
如果数据文件采用OMF命名格式直接使用amdu命令进行抽取即可，命令与抽取控制文件相同，但当数据文件命名采用+DATADG/xxx/tbs01.dbf方式，需要先抽取元数据，在元数据中通过数据文件的alias找到对应的fnum在依照OMF格式文件的抽取方式进行抽取，更详细的介绍请参考《asm翻译系列》。
客户在创建数据文件时均是采用OMF文件管理方式，直接编辑如下数据文件抽取命令：
amdu -diskstring '/dev/xxx/*' -extract datadg.347 -noreport -nodir
amdu -diskstring '/dev/xxx/*' -extract datadg.368 -noreport -nodir
amdu -diskstring '/dev/xxx/*' -extract datadg.316 -noreport -nodir
amdu -diskstring '/dev/xxx/*' -extract datadg.335 -noreport -nodir
抽取完成后的文件格式默认为DATADG_347.f这样的命令规则，由于抽取到本地后数据文件名称已经发生变化，在数据库mount状态下将控制文件中记录的数据文件名称进行重命名，让数据库识别抽取到本地的数据文件。
重命名数据文件:
alter database rename file '+DATADG/xxx/datafile/system.347.957297809' to '/orabackup/xxx/DATADG_347.f';
alter database rename file '+DATADG/xxx/datafile/sysaux.368.957297823' to '/orabackup/xxx/DATADG_368.f';
alter database rename file '+DATADG/xxxdatafile/undotbs1.316.957297837' to '/orabackup/xxx/DATADG_316.f';
...
将数据库OPEN：
由于日志文件所在的磁盘组没有出现dismount问题，日志文件完好，并可以正常访问，这种情况下直接open数据库即可。
SQL> alter database open;
Database altered.
SQL>
数据库被正常打开，但此时数据文件，都存储在本地文件系统中，还需将数据文件移动至asm磁盘组中，由于客户环境已无可用的asm磁盘组，对上面问题磁盘组进程删除重新创建后使用rman copy方式将本地文件系统中的文件重新移动至asm磁盘组中：
select 'backup as copy datafile ' || file_id || ' format ' || '+DATADG;' from dba_data_files;
select 'switch datafile ' || file_id || ' to copy;' from dba_data_files;
