存储盘异常导致oracle数据库宕机的故障案例

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638    QQ号:47079569    邮箱:[email protected]

 

1 问题现象描述

2015年3月20日 接运维同事反馈南宁富士康工厂有异常,前台web界面输入账号密码无反应,这边试了下登录数据库发现数据库无监听,登录外协厂服务器检查发现数据库挂了。

2 问题根因说明

事前巡检同事发现南宁富士康系统存储有异常,有个盘处于即将失效状态,存储中只剩下一个热备盘,如果该盘失效后热备盘将会启用,期间将不允许坏第二块盘。根据事件的紧急层度决定把配件交由将会去南宁的同事帮忙带过去。备件送达南宁工厂但由于工厂流程问题未能及时更换。存储中另一块硬盘损坏,热备盘给启用,该天下午,即将失效的磁盘失效,导致数据库异常系统无法启动。定位到是存储一个硬盘异常导致数据库DATA文件缺失,无法启动数据库。

3 问题判断方法

1、定位到是存储一个硬盘异常导致数据库DATA文件缺失,无法启动数据库。

2、找南宁富士康同事把寄过去的存储备件插上,发现由于之前的备份盘已经给使用了,无备份盘,导致一块硬盘数据缺失,找公司负责存储的同事分析确认通过常规手段恢复不了了,只能把盘拔出来找数据恢复公司恢复了。

3、DBA检查发现由于磁盘损坏数据库无法启动,需要根据备份文件恢复,与DBA沟通,把损坏的磁盘从映射的主机组中去除,并把新到的存储备件插入开始划分LUN并格式化,

预计3个小时能格式化完。格式化完后DBA开始帮忙把新LUN添加到数据库文件组中,并开始根据备份文件还原数据库。

4、DBA检查控制文件发现参数异常没有备份成功,并且数据文件备份好像也有些问题,无法通过备份文件恢复,DBA帮忙协调资源看能否在磁盘损坏的情况下把数据库mount起来,至于丢失数据通过业务方案来补充。

5、DBA通知根据他们那边能协调到的资源无法在部分磁盘损坏的情况下启动数据库,需要项目组看看能否找oracle顾问能否解决。

6、项目组召开紧急会议决定,为了尽快恢复工厂的生产,在原来南宁富士康工厂的服务器上面新建instance,重新部署系统。

4 解决方案

阶段一:恢复产线生产

异常当天组织技术讨论发现无法快速的恢复异常的数据库,项目组决定给南宁富士康工厂新建数据库来使用。DBA开始帮忙新建DATA组并创建instance。新数据库部署完毕,开始导入数据文件,初始化sequence。数据库表结构导入完成,修改was数据源测试通过。开始开始跑数据库的脚本及新系统的部署。系统部署完成,内部及工厂产线开始验证。
内部及工厂产线开始验证完成,工厂开始根据业务方案进行返工处理。

阶段二:对故障库进行数据恢复

1、数据库存储中有一块硬盘损坏,通过raid机制无法对其数据进行恢复,需要找专业的磁盘恢复公司进行硬盘修复。通过公司采购流程采购了存储设备修复服务,将损坏硬盘恢复为能正常使用的硬盘,未对硬盘内部底层数据进行更改。

2、硬盘恢复好后插回原存储中,找DBA帮忙对数据库进行修复和启动。
经过努力,现在grid已经能够起来,几个disk group也已mount上去,但是在打开数据库的时候报ora 600 [2662]错误,这个是由于当前的scn远小于数据块的scn号:
尝试使用了alter session set events ‘10015 trace name adjust_scn level X’;方法来提升scn号,遇到如下问题:

由于出现了ora-00283和ora-16433,尝试重建了控制文件,再重新进行操作,在open的时候它会要求必须使用resetlogs或noresetlogs选项:

最后还是报了ora 600 [2662]错误,scn看上去也没有提升上去。

其实还有一种方式可以提升scn号,即把数据库反复的shutdown和open,但是这只适用于当前scn号与数据文件中的scn号相差不大的场景,这个案例中的当前scn号是4150989410,需要提升到的scn号是4151687346,相差69万多,而每次启停数据库仅能提升4,意味着要打开需要启停10几万次,因此人工方式是不现实的。

 

这个问题有点棘手,常规方法试了都不起作用,按理说这已经是恢复数据库的最后一步了,但不知道打开后还会不会有其他的问题,恢复出来的磁盘上的数据组织形式是否正确只有在打开后才能验证。

3、针对数据库无法启动异常,咨询了公司相关技术专家都无法处理,找oracle原厂顾问咨询他们也不支持这块业务,最后只能通过公司自行采购流程找到了数据库异常数据恢复的供应商进行处理。供应商技术人员通过技术手段打开了数据库,但是华为DBA在进行导出是发现无法对数据库进行操作,无法导出数据文件。

a.)rman备份到最后报了ORA-19566 exceeded limit of 0 corrupt block问题,有2个数据文件好像有问题,但是没截图。
b.) 想通过expdp导出,但是新建directory时报错

c.) expdp导出一晚上没反应,日志一直都是这样,数据库session见截图,早上以为是临时表空间满了,加大了也没用,帮忙看看

专家到现场进行处理。通过exp导出了大部分表。但是个别表通过oracle自带的exp无法进行导出,技术人员通过工具进行抽取来导出数据。最终所有表都顺利导出数据文件。

4、由于南宁富士康原库恢复出来的数据安装《终端TGMES系统数据归档管理规范V0100》恢复数据将不再导入到南宁富士康现在的生产库中。数据给搬迁还原到TGMES项目归档库中。

如果需要对2015年3月15日之前数据进行查询或者提取,需要提业务数据变更电子流,电子流走到项目组会安排人在后台数据库进行导出。

5 经验总结
1、 服务器或存储上面需要做好冗余,需要保障一定量的备份盘并做好RAID机制。
2、 硬件如果出现告警,需要第一时间升级并及时得到解决。
3、 对数据库备份文件需定期的检查参数并尝试进行还原,防止备份文件不可还原的情况。
4、 对数据库这样重要的应用需要有专人进行维护,现所有外协厂都完成的服务器后移至数据中心,数据库由公司专职DBA进行维护。


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *