今年新型冠状肺炎爆发,好多企业持续停工,我们也是放假在家,由于小区、道路被社区工作人员封闭,出不来,于是机房缺少运维,等复工后发现了一台有十四块硬盘做的是raid5的IBM DS5020磁盘阵列,其中3块硬盘故障亮灯掉线。
这台ds5020磁盘阵列通过fc光纤通道卡连接一台IBMX3850服务器,经硬盘数据恢复后提取出oracle的dbf文件及控制文件。
重新将磁盘阵列挂到服务器上,oracle无法启动,报控制文件损坏,先后试过冷备份启动及控制文件替换或者重建的方式先后宣告失败。于是使用PRM 灾难恢复工具对oracle的DBF文件进行了成功恢复。
一、使用冷备份方式(失败的尝试):
1.安装oracle 数据库并创建一个要恢复的数据库相同一的实例
2,以sysdba身份登录:对控制文件进行备份;sqlplus /nolog
3.conn /as sysdba;登录
4.备份控件文件到udmp目录的trace文件 alter database backup controlfile to trace;
5.找到oracle的安装目录:..\oracle\product\10.2.0\db_1\admin\实例名\udump文件夹下,找到最近的trace文件。
6.shutdown immediate停止数据库实例;
7.备份..\oracle\product\10.2.0\oradata\orcl,接着将该实例文件夹删除,把恢复的DBF直接替换原来orcl
8.以sysdba进入并执行startup nomount。把数据库启动到nomount状态。
9.trace文件中拷贝CREATE CONTROLFILE部分语句来重建控制文件:
最后启动数据库报ORA-01578 数据库system表空间坏块。可能是控制文件不匹配原因 宣告失败。
二、使用oracle紧急救援工具
我选择prm-dul紧急救灾工具(社区版),这可能是数据库恢复的最后一根稻草。由于prm-dul使用的java语音编写,所以需要安装JDK。从网上下载prm-dul,无需安装解压后执行prm.bat。
2.打开系统后选择菜单栏中的文件—恢复向导
3.根据自身条件,选择模式。我选择是的默认的字典模式。
4.选择字符编码及偏移量,由于是磁盘阵列亮灯掉线,不存在数据损坏的情况,所以偏移量为0
5.选择dbf文件,选择加载,要把所有的文件都选择上,不能只选择需要恢复的表。
6.系统自动默认加载DBF文件,等待
7.加载完成选择需要恢复的用户下面的表
8.由于我下载的是社区版,社区版如果直接导入oracle 有一万行的限制,如果是企业版就要付费,所以没有采用付费方式的企业版,我使用的是抽取数据表另存为的方式,这样就不受版本的限制了
9.点击抽取另存为,对相关的数据表进行保存。一个数据表输出是文件和。ctl两个文件形式。
10.ctl后缀文件用记事本打开后是建表的表结构语句。
11.不带后缀的文件形式用及时本打开是就是我们保存在数据库里面的数据
12.剩下工作就是重新安装oracle数据库,配置监听端口,然后通过这些ctl文件对数据库进行重新新建数据表,最后把文件里面的表格数据全部倒入到新建的数据库中,形成新的数据库。恢复完成。
总结:
1.信息化建设不能只重视建设,轻运维。
2.要定期对数据进行备份并且导出。
3.合适的情况下购置存储备份设备。
4.在数据量不大的情况下,缺少运维技术时候不要选用oracle,因为控制文件和日志文件不能有一丝不一致,易加载失败。就像这次磁盘阵列掉线,服务器环境并无改变,磁盘阵列恢复后依然无法加载,最后不得以进行数据恢复。