amdu oracle,分析oracle自带工具AMDU数据抽取恢复

今天我们通过一则真实的案例来认识oracle自带工具AMDU，无需将磁盘组mount即可实现数据分析，轻松进行数据恢复.其中手机数据误删恢复给了创业者很大的精神支持，未来会有更多的创业者为这个行业贡献自己的力量。

某日，我们收到了一则香港用户ASM破坏案例，请求数据恢复。灾难描述

这则案例是由于存储误操作引起的：1.用户进行存储维护和磁盘添加操作2.维护后发现CRS无法启动3.检查发现OCR盘损坏，ASM磁盘组受损4.经用户反复确认，故障原因是因为误操作磁盘导致的ASM磁盘受损5.为减少意外，客户请求在不更改配置等的情况下安全抽取数据6.数据库为3节点RAC系统灾难再一次由于疏忽而降临。技术回放

对于这个案例，我们有多种手段可以进行恢复，只要ASM磁盘组完好，就可以很容易的从中提取数据，本案例我们使用了AMDU工具进行恢复。

AMDU工具

在Oracle10g中，ASM磁盘组的信息需要在Mount之后才能通过内部视图查询，如果磁盘组因为故障无法正常加载，那么信息将不可用，这为诊断带来了诸多不便。

从Oracle11g开始，Oracle提供了一个工具AMDU用于协助诊断，通过这个工具可以在磁盘组加载之前将ASM的元数据抽取出来，用于数据库诊断，这个工具可以向后兼容，引入到10g中。

通过amdu&ndashh可以查看详细的帮助说明，缺省的调用amdu，会自动生成一个以时间命名的目录，该目录下生成的报告文件会记录磁盘组的相关信息：[oracle@enmou1~]$amdu

amdu_2015_03_29_10_28_41

[oracle@enmou1~]$cdamdu_2015_03_29_10_28_41

[oracle@enmou1amdu_2015_03_29_10_28_41]$ls

report.txt

该报告的主要内容如下：[oracle@enmou1amdu_2015_03_29_10_28_41]$morereport.txt

*amdu*

***********************AMDUSettings****************

ORACLE_HOMEu01appdb11.2.0

SystemnameLinux

Nodenameenmou1

Release2.6.18128.el5

Version#1SMPWedDec17114138EST2008

Machinex86_64

amdurun29MAR11102841

Endianess1

Operations

**********************DISCOVERY*****************

定义特定的参数可以获得ASM磁盘组内部的区间分配等详细信息。以下命令指定转储CRSDG的磁盘组信息，除了报告文件外，还生成了map和img信息文件：[oracle@enmou1~]$amdudiskstring'devoracleasmdisksVOL*'dump'CRSDG'

amdu_2015_03_29_10_36_03

[oracle@enmou1~]$cdamdu_2015_03_29_10_36_03

[oracle@enmou1amdu_2015_03_29_10_36_03]$ls

CRSDG_0001.imgCRSDG.mapreport.txt

这里MAP文件的信息如下，其内容描述了ASM元数据在磁盘组中的位置，最后部分就是指针信息：而IMG文件则是元数据块的镜像转储，为2进制文件，这些文件在ASM出现故障时，可以用于收集信息，分析故障。AMDU的一个重要参数是extract，该参数可以用于从ASM磁盘组中抽取数据文件，以下是AMDU的帮助信息摘录：这个选项可以用于直接从ASM磁盘组中抽取数据文件。

文件分析由于磁盘组不能Mount，控制文件也无法访问，我们需要首先分析数据库的文件分布情况，进而通过文件的ASM存储序号来进行文件抽取。

通过告警日志，可以找到数据库的控制文件信息，如下所示，控制文件的ASM文件号是270：

随后可以通过amdu提取控制文件：

suoracle

mkidr&ndashpu01d02

cdu01d02

amduextractDG_REDO.270

取得控制文件之后，可以通过控制文件内容获得数据库的数据文件、日志文件分布情况，以下是从控制文件中获得的信息输出：

有了文件分布信息，接下来的恢复就大大简化了。

AMDU文件恢复获得了文件的分布信息之后，就可以使用amdu工具进行文件提取工作。根据如上的数据文件和日志文件信息,抽取对应的日志文件和数据文件,创建如下脚本：amduextractDG_DATA.282

amduextractDG_DATA.278

amduextractDG_DATA.281

amduextractDG_DATA.280

amduextractDG_DATA.279

amduextractDG_DATA.277

amduextractDG_DATA.276

amduextractDG_DATA.284

amduextractDG_DATA.283

amduextractDG_REDO.274

amduextractDG_REDO.273

amduextractDG_REDO.276

amduextractDG_REDO.275

amduextractDG_REDO.272

amduextractDG_REDO.271

运行以上脚本，就可以将相应的数据文件和日志文件从磁盘组中提取出来，然后将这些文件整合到一个统一的目录中。通过配置好的参数文件和抽取的控制文件,可以将数据库启动到mount状态,具体过程如下exportORACLE_SIDd02

startupnomountpfile'u01d02ora.pfile'

alterdatabasemount

接下来编写类似如下的文件重命名脚本，将文件指向统一的存储目录在这个案例中，由于文件和日志完好，数据库随后就可以被成功打开。对于特定的文件，通过以下测试可以验证amdu的恢复过程和文件完好性：+DG_DATAproda02datafileusers.271.768047753'

通过amdu提取文件：

[oracle@oracle]$amdudiskstring'devoracleasmdisksDISK*'extract'DG_DATA.271'amdu_2015_02_22_02_02_09

通过更名来重定向数据文件：

SQL&gtALTERDATABASERENAMEFILE'+DG_DATAproda02datafileusers.271.768047753'to'u01amdu_2015_02_22_02_02_09DG_DATA_271.f'Databasealtered.SQL&gtalterdatabaseopenDatabasealtered.SQL&gtselectnamefromv$datafilewherenamelike'DG%'NAMEu01amdu_2015_02_22_02_02_09DG_DATA_271.f

这个案例的幸运之处在于磁盘组未发生更为严重的损坏，数据文件和日志文件都是完好的，而Oracle的AMDU工具在这种情况下为我们提供了便利的恢复手段。案例警示

这类案例我们已经遭遇了很多，在这里我们再次郑重的提示以下内容：

1.存储的使用分配应当自始至终建立和维护详细的档案

鉴于众多惨痛的数据灾难，结合标准化流程要求，我们建议用户对于数据库的存储规划、分配，建立详细的档案记录，在进行后续的维护操作时，需要严格通过文档进行对比确认，必须严格杜绝低级的误操作行为。

标准化和文档维护不仅仅是流程和管理的需要，也是为技术人员屏蔽错误，保障数据安全的基本要求。我们不能够把文档当做过场或可有可无的摆设，必须将其上升到数据安全的保障层面。

2.涉及到存储的调整，必须多部门协同反复确认