怎么理解AMDU数据抽取

这篇文章主要介绍“怎么理解AMDU数据抽取”，在日常操作中，相信很多人在怎么理解AMDU数据抽取问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么理解AMDU数据抽取”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

专注于为中小企业提供成都网站设计、做网站、成都外贸网站建设公司服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业珲春免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了1000多家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。

上半年遇到一起某客户对ASM磁盘组扩容，由于扩容期间操作不当导致磁盘组被dismount，日志如下：

通过日志可以看到由于磁盘头的元数据被破坏，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;

到此，关于“怎么理解AMDU数据抽取”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！