16_15_50]$ ls
DATA_260.f report.txt
AMDU抽取生成数据文件的格式为“磁盘组+数据文件号”，并且加后缀名为点f,如这里生成的文件就是DATA_260.f，这就是抽取的控制文件，我们可以通过mv对这些文件进行移动并重命名，移动为/u01/app/oracle/controlfile01.ctl如下
[oracle@rac01~]$mv /home/oracle/amdu_2015_07_23_16_15_50/DATA_260.f/u01/app/oracle/controlfile01.ctl
接下来我们对系统自带的pfile文件（一般在/u01/app/oracle/admin/orcl/pfile文件夹中）进行编写，修改里面的控制文件的路径，如下
control_files=("+DATA/orcl/controlfile/current.261.883666805","+DATA/orcl/controlfile/current.260.883666805")
cluster_database=true
修改为：
control_files=("/u01/app/oracle/controlfile01.ctl")
cluster_database=false
启动到mount状态
SQL>startup mount pfile='/u01/app/oracle/admin/orcl/pfile/init.ora'
ORACLEinstance started.
TotalSystem Global Area 772472832 bytes
FixedSize 2257232 bytes
VariableSize 566234800 bytes
DatabaseBuffers 201326592 bytes
RedoBuffers 2654208 bytes
Databasemounted.
SQL>
后面我们就可以用类似的方法，通过amdu把其他剩余的所有数据文件、REDO日志文件等抽取出来，然后将控制文件中的路径作调整（可以通过重建控制文件的方式），就是一个简单的冷备恢复，把数据库脱离ASM重新启动起来，由于篇幅限制这里就不再演示了。
6.总结
ASM作为ORACLE推崇的数据存储方式，在性能、安全、管理上都提供了极大的方便，但是由于其高密闭的封装，导致一旦出现问题，DBA对其往往束手无策。今天我们分别介绍了几个日常大家不怎么接触的数据库自带的ASM维护小工具，可以从内部深探ASM的架构，为我们在极端情况下进行一些拯救性的操作提供了方法，请有兴趣的同事能够尝试学习研究，能够有效的掌握这些工具的使用。