Raid信息丢失数据恢复及oracle数据库恢复验证方案

简介:

早些时候,有个客户14块盘的磁盘阵列出现故障,需要恢复的数据是oracle数据库,客户在寻求数据恢复技术支持,要求我提供详细的数据恢复方案,以下是提供给客户的详细数据恢复解决方案,本方案包含Raid数据恢复和oracle数据库的恢复验证。

一、对磁盘阵列的恢复方案

   磁盘阵列常见故障表现为
A、阵列信息丢失,导致磁盘阵列在操作系统环境中查看不到;
B、阵列中多个硬盘掉线,导致阵列瘫痪;
C、人为的重新配置raid信息或Rebuild或者初始化等;

    D、阵列中某块盘掉线一段时间后,又重新上线参与盘阵工作,导致整个阵列数据部分数据正常,另一部分数据不正常。

Raid数据恢复步骤是

1、 第一步是做镜像:对每个硬盘做个镜像文件,存储到另外的空间上,对原始数据盘只读一次。如果盘阵的硬盘数量很多,单个硬盘容量很大的话,则需要很大的存储空间来存放这些镜像文件。这一步需要搭建的硬件环境是:准备一个空间足够大的可用的磁盘阵列,用来存放故障阵列的所有硬盘的镜像文件。硬盘镜像文件就是把整个硬盘通过硬件或者软件环境复制出跟硬盘完全一样的文件,在以后的恢复过程中,只用这个镜像文件去分析和重组数据,这样就保证整个恢复过程安全性,原始硬盘数据不会有二次损坏。

2、 第二步是分析底层数据:因为每个硬盘已经有了镜像文件,对镜像文件的分析等同于对原始数据的分析。在这一步分析中,我们可以确定出组成盘阵的硬盘数量,硬盘在磁盘阵列中的顺序,RAID配置中的块大小,数据走向等。如果有数据不新鲜的硬盘,我们也可以分析出来,在以后的重组中去掉这块盘就可以了。底层数据分析在WINDOWS系列的文件系统相对容易,但是在UNIX系列的文件系统难度就加大,目前我们在LINUX、AIX、SOLARIS、HP-UX、SCO UNIX、FREEBSD等都有成功的案例。

3、 第三步是重组数据:通过第二步地分析,得出一系列磁盘阵列参数—-硬盘数量、硬盘顺序、块大小、数据走向等,然后用D-Recovery For RAID软件对所有硬盘进行数据重新组合,写到另外的空间中。在这个过程中,我们需要准备的硬件环境是:准备一个空间足够大的可用的磁盘阵列,用于把重新组合出来的数据存放在这个空间上。

4、 第四步是恢复最终数据:数据重新组合出来以后,我们这一步要做的工作是把客户最终想要的数据恢复出来。如果是WINDOWS文件系统,这一步很容易完成;如果是UNIX文件系统,我们就要把组合出来的数据盘阵挂接到相应的UNIX环境下,然后在这个环境中找出客户想要的数据,把数据导到另外可用的空间上,以备客户验证数据。当然,也可以用D-Recovery For RAID软件直接把数据导出,存放到新的存储上。

5、 第五步是验证数据的正确性:客户数据在第四步已经COPY出来了,有些数据是直接看不出是否正确的,就像ORACLE数据库一样,恢复出来的是好多个文件,单个文件是没办法验证的。这就需要搭建一个ORACLE环境,把恢复出来的数据还原到ORACLE环境中,才能验证其正确性。其它数据库文件也是需要在相应的环境中验证的。

     磁盘阵列最典型的故障恢复:

阵列信息完好,磁盘分区也能访问正常,但是数据就是打不开或者部分数据正常,部分数据不正常。特别是对oracle数据库来说,必须全部的库文件正常,数据库才正常。

举个案例说明:有个客户给我们拿来3块盘做数据恢复,客户的对故障现象是这样描述的:这3块盘是配成raid5,服务器在一个月前1号盘亮黄灯,当时没有在意,后来在前天机房停电,服务器也关闭了,当服务器再起来的时候,启动一切正常,1号盘也正常,不亮黄灯。但是系统起来以后,发现oracle数据库启动不正常。别的文件在一个月前放到服务器上的大都正常,就是这个月的文件大都不正常。

经过我们的分析,发现1号盘原来亮黄灯以后就不参与到RAID5里头工作了,2号盘和3号盘在缺1号盘的情况下继续工作一个多月。从底层数据分析知道,1号盘数据不新鲜,当机器重启以后,RAID卡没有报错,1号盘又参与RAID5数据组合,这样不新鲜的数据盘参与数据组合,自然导致部分可用部分不可用。我们缺1号盘,用D-Recovery For RAID从2号盘和3号盘重组出客户的数据,验证ORACLE数据库也全部通过。

         如果是由于磁盘阵列故障导致的数据库不正常,整个恢复过程所花费的时间根据磁盘阵列的硬盘数量和硬盘大小来决定,一般不会超过一个星期。

 

 

二、对ORACLE数据库的恢复方案

ORALCE数据库相关文件恢复完成以后,我们还没办法直接判断恢复出来的数据库内容是否正确,需要把ORACLE数据库实例还原到ORACLE环境下才能验证。这就需要搭建好ORACLE环境,然后把恢复出来的ORACLE数据库实例在该环境下启动数据库,如果启动正常,那么数据恢复就顺利完成,如果数据库启动异常,则根据报错信息进行下一步分析。

ORALCE出错原因非常多,可以根据ORACLE错误代码来进行分析和解决。

  比如错误代码为:ORA-01650:unable to extend rollback segment NAME by NUM intablespace NAME

  产生原因:上述ORACLE错误为回滚段表空间不足引起的,这也是ORACLE数据管理员最常见的ORACLE错误信息。当用户在做一个非常庞大的数据操作导致现有回滚段的不足,使可分配用的回滚段表空间已满,无法再进行分配,就会出现上述的错误。

解决方式:使用“ALTER TABLESPACE tablespace_name ADD DATAFILE filename SIZE size_of_file”命令向指定的数据增加表空间,根据具体的情况可以增加一个或多个表空间。

 

 

 

声明:作者达思数据恢复技术专家覃廷良,本文首发http://www.bnuol.com,在donews.com,51cto,techweb,新浪,百度等数据恢复技术博客上转发.欢迎转发,转发请保留作者及出处。

相关文章
|
9月前
|
Oracle 关系型数据库 Linux
【赵渝强老师】Oracle数据库配置助手:DBCA
Oracle数据库配置助手(DBCA)是用于创建和配置Oracle数据库的工具,支持图形界面和静默执行模式。本文介绍了使用DBCA在Linux环境下创建数据库的完整步骤,包括选择数据库操作类型、配置存储与网络选项、设置管理密码等,并提供了界面截图与视频讲解,帮助用户快速掌握数据库创建流程。
759 93
|
8月前
|
Oracle 关系型数据库 Linux
【赵渝强老师】使用NetManager创建Oracle数据库的监听器
Oracle NetManager是数据库网络配置工具,用于创建监听器、配置服务命名与网络连接,支持多数据库共享监听,确保客户端与服务器通信顺畅。
411 0
|
9月前
|
SQL Oracle 关系型数据库
Oracle数据库创建表空间和索引的SQL语法示例
以上SQL语法提供了一种标准方式去组织Oracle数据库内部结构,并且通过合理使用可以显著改善查询速度及整体性能。需要注意,在实际应用过程当中应该根据具体业务需求、系统资源状况以及预期目标去合理规划并调整参数设置以达到最佳效果。
606 8
|
11月前
|
Oracle 关系型数据库 数据库
数据库数据恢复—服务器异常断电导致Oracle数据库报错的数据恢复案例
Oracle数据库故障: 某公司一台服务器上部署Oracle数据库。服务器意外断电导致数据库报错,报错内容为“system01.dbf需要更多的恢复来保持一致性”。该Oracle数据库没有备份,仅有一些断断续续的归档日志。 Oracle数据库恢复流程: 1、检测数据库故障情况; 2、尝试挂起并修复数据库; 3、解析数据库文件; 4、导出并验证恢复的数据库文件。
|
9月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
545 158
|
9月前
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。
|
9月前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS费用价格:MySQL、SQL Server、PostgreSQL和MariaDB引擎收费标准
阿里云RDS数据库支持MySQL、SQL Server、PostgreSQL、MariaDB,多种引擎优惠上线!MySQL倚天版88元/年,SQL Server 2核4G仅299元/年,PostgreSQL 227元/年起。高可用、可弹性伸缩,安全稳定。详情见官网活动页。
1442 152
|
9月前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎,提供高性价比、稳定安全的云数据库服务,适用于多种行业与业务场景。
1056 156
|
9月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(中)
使用MYSQL Report分析数据库性能
594 156
|
9月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(上)
最终建议:当前系统是完美的读密集型负载模型,优化重点应放在减少行读取量和提高数据定位效率。通过索引优化、分区策略和内存缓存,预期可降低30%的CPU负载,同时保持100%的缓冲池命中率。建议每百万次查询后刷新统计信息以持续优化
703 161

推荐镜像

更多