数据恢复:AMDU数据抽取恢复

今天我们通过一则真实的案例来认识oracle 自带工具AMDU,无需将磁盘组mount即可实现数据分析,轻松进行数据恢复

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

灾难描述

这则案例是由于存储误操作引起的:

1.用户进行存储维护和磁盘添加操作

2.维护后发现CRS无法启动

3.检查发现OCR盘损坏,ASM磁盘组受损

4.经用户反复确认,故障原因是因为误操作磁盘导致的ASM磁盘受损

5.为减少意外,客户请求在不更改配置等的情况下安全抽取数据

6.数据库为3节点RAC系统

灾难再一次由于疏忽而降临。

技术回放

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

AMDU工具

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

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

通过amdu –h可以查看详细的帮助说明,缺省的调用amdu,会自动生成一个以时间命名的目录,该目录下生成的报告文件会记录磁盘组的相关信息:

[oracle@enmou1 ~]$ amdu amdu_2015_03_29_10_28_41/ [oracle@enmou1 ~]$ cd amdu_2015_03_29_10_28_41/ [oracle@enmou1 amdu_2015_03_29_10_28_41]$ls report.txt

该报告的主要内容如下:

[oracle@enmou1 amdu_2015_03_29_10_28_41]$more report.txt -*-amdu-*- *********************** AMDUSettings **************** ORACLE_HOME = /u01/app/db/11.2.0 System name: Linux Node name: enmou1 Release: 2.6.18-128.el5 Version: #1 SMP Wed Dec 17 11:41:38 EST 2008 Machine: x86_64 amdu run: 29-MAR-11 10:28:41 Endianess: 1 ---------------------Operations --------------- ********************** DISCOVERY*****************

定义特定的参数可以获得ASM磁盘组内部的区间分配等详细信息。以下命令指定转储CRSDG的磁盘组信息,除了报告文件外,还生成了map和img信息文件:

[oracle@enmou1 ~]$ amdu -diskstring '/dev/oracleasm/disks/VOL*'-dump 'CRSDG' amdu_2015_03_29_10_36_03/ [oracle@enmou1 ~]$ cd amdu_2015_03_29_10_36_03/ [oracle@enmou1 amdu_2015_03_29_10_36_03]$ls CRSDG_0001.img CRSDG.map report.txt

这里MAP文件的信息如下,其内容描述了ASM元数据在磁盘组中的位置,最后部分就是指针信息:

而IMG文件则是元数据块的镜像转储,为2进制文件,这些文件在ASM出现故障时,可以用于收集信息,分析故障。

AMDU的一个重要参数是extract,该参数可以用于从ASM磁盘组中抽取数据文件,以下是AMDU的帮助信息摘录:

这个选项可以用于直接从ASM磁盘组中抽取数据文件。

文件分析

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

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

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

su - oracle mkidr –p /u01/d02 cd /u01/d02 amdu -extract DG_REDO.270

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

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

AMDU文件恢复

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

amdu -extract DG_DATA.282 amdu -extract DG_DATA.278 amdu -extract DG_DATA.281 amdu -extract DG_DATA.280 amdu -extract DG_DATA.279 amdu -extract DG_DATA.277 amdu -extract DG_DATA.276 amdu -extract DG_DATA.284 amdu -extract DG_DATA.283 amdu -extract DG_REDO.274 amdu -extract DG_REDO.273 amdu -extract DG_REDO.276 amdu -extract DG_REDO.275 amdu -extract DG_REDO.272 amdu -extract DG_REDO.271

运行以上脚本,就可以将相应的数据文件和日志文件从磁盘组中提取出来,然后将这些文件整合到一个统一的目录中。

通过配置好的参数文件和抽取的控制文件,可以将数据库启动到 mount 状态,具体过程如下:

export ORACLE_SID=d02 startup nomount pfile='/u01/d02/ora.pfile' alter database mount;

接下来编写类似如下的文件重命名脚本,将文件指向统一的存储目录:

在这个案例中,由于文件和日志完好,数据库随后就可以被成功打开。

对于特定的文件,通过以下测试可以验证amdu的恢复过程和文件完好性:

+DG_DATA/proda02/datafile/users.271.768047753'

通过amdu提取文件:

[oracle@oracle]$ amdu -diskstring'/dev/oracleasm/disks/DISK*' -extract 'DG_DATA.271' amdu_2015_02_22_02_02_09/

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

SQL> ALTER DATABASE RENAME FILE'+DG_DATA/proda02/datafile/users.271.768047753' to'/u01/amdu_2015_02_22_02_02_09/DG_DATA_271.f'; Database altered. SQL> alter database open; Database altered. SQL> select name from v$datafile wherename like 'DG%'; NAME -------------------------------------------------------------------------------- /u01/amdu_2015_02_22_02_02_09/DG_DATA_271.f

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

案例警示

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

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

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

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

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

由于底层存储对于数据库的核心作用,我们必须在进行维护时反复确认维护计划,并且通过多部门来统一协调、共同确认,避免流程割裂导致的误操作行为。

常规的存储维护在企业中被定义为系统或存储部门的责任,但是运行于其上的数据库是数据存储的核心使用者,在存储维护的过程中,一定需要数据部门的介入和确认。对于Oracle数据库来说,由于前期的存储划分可能非常零散,包括OCR、VOTING、REDO、DATA等都可能存在独立的存储分区,所以如果不进行严格管理,在后期维护中就可能对其中的部分存储卷产生误操作,导致破坏。

当然,关于备份的重要性,如何强调都不为过,始终保有有效的备份才能够在出现问题时有备无患。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-09-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Jerry的SAP技术分享

SAP Netweaver和Hybris的数据库层

在SAP基于Netweaver的ABAP应用里,应用开发人员用Open SQL访问数据库, 这些Open SQL会被Database interface(数据库...

4563
来自专栏企鹅号快讯

一枚女程序员眼中的mysql,值得收藏

某群聊天内容 什么是数据库? ‍‍数据库(Database)是按照数据结构来组织、存储和管理数据的仓库, 每个数据库都有一个或多个不同的API用于创建,访问,管...

4068
来自专栏Spark学习技巧

HBase学习—高表与宽表的选择

转自:https://yq.aliyun.com/articles/213705?utm_content=m_31236 hbase中的宽表是指很多列较少行,...

2615
来自专栏我的博客

Mysql数据库文件夹复制出错,你遇到过吗?

今天我的一个同学在家做了一个作品,建立了mysql数据库,来学校的时候从家里的wamp文件夹里面拷贝了data下的mysql数据库文件夹,结果到学校不能使用了。...

3056
来自专栏架构师之路

InnoDB并发如此高,原因竟然在这?

《InnoDB行锁,如何锁住一条不存在的记录?》埋了一个坑,没想到评论反响剧烈,大家都希望深挖下去。原计划写写InnoDB的锁结束这个case,既然呼声这么高,...

1263
来自专栏文渊之博

SQL Server中的锁的简单学习

简介     在SQL Server中,每一个查询都会找到最短路径实现自己的目标。如果数据库只接受一个连接一次只执行一个查询。那么查询当然是要多快好省的完成工作...

2475
来自专栏性能与架构

Mysql 压力测试工具 mysqlslap

mysqlslap 是 Mysql 自带的压力测试工具,可以模拟出大量客户端同时操作数据库的情况,通过结果信息来了解数据库的性能状况 mysqlslap 的一个...

5935
来自专栏杨建荣的学习笔记

MySQL 8.0初体验

从决定安装MySQL 8.0到开始行动,也就不到一个小时的时间,一个小时的时间能干些啥呢,来简单体验下8.0,官网上能看到这个丰富的表情包。

1354
来自专栏Netkiller

数据库进程间通信解决方案之MQ

摘要 你是否想过当数据库中的数据发生变化的时候出发某种操作?但因数据无法与其他进程通信(传递信号)让你放弃,而改用每隔一段时间查询一次数据变化的方法?下面的插件...

3244
来自专栏网络研发技术

如何防订单重复提交策略方法

#### [原文链接:https://www.cnblogs.com/jett010/articles/9056567.html](https://www.cn...

3030

扫码关注云+社区