遇到大规模Oracle坏块应该如何处理？

《遇到大规模Oracle坏块应该如何处理？》要点：
本文介绍了遇到大规模Oracle坏块应该如何处理？，希望对您有用。如果有疑问，可以联系我们。

最近一两个月,一直有场景化运维、场景化大数据分析的声音围绕在耳畔,以Gdevops全球敏捷运维峰会杭州站上新炬网络执行副总裁程永新的“一切没有场景驱动的运维平台建设都是假大空!”最为振聋发聩.我们一直在谈技术,谈原理,谈内核,总以为“懂了”这些的人,就势必能广阔天地大有所为.

技术固然重要,但偏离了业务/应用场景的技术,无法呈现业务价值的技术就非常不重要.

技术也应该是场景驱动的,对于运维技术人员来说,离开场景学习的所谓高深技术,只是浪费时间.所以新同事进入一个新团队后,能使技术更好发挥作用的环境、流程的考核会占据了另外的三分之二.

今天来谈谈Oracle坏块问题.坏块问题,相信做过两三年Oracle维护、支持的DBA都会遇到过,即使从来没遇到过的,看过Oracle 官方文档的甚至是会度娘或者谷哥的,应该也知道基本的处理手段.

这是我内部分享的一个简单思维导图,如果有遗漏,欢迎在后面评论补充.

面试的时候通常是这么问的：你了解Oracle坏块么?坏块为什么会产生?描述一下你处理过的坏块案例细节?如果你负责的好几个数据库都突然发生了坏块,你会怎么做?

通常,前面几个问题的回答都不会太差.但是最后一个问题的回答,鲜有能出众的.原因在于面太窄,思维太窄.如果这个时候你还要一个个库的去看alert日志,那么显然就走错了方向.

现实情况就是,我们的数据库可能是五六十套,或者上百套,你一套套库的去看这些日志里的报错的块,再根据块找到对象,确定是表还是索引,再去用坏块的修复手段去修复…….那么,所有人都会被你害了.

我们经历过,花了两天的时间,都没修复完一个库中几万个坏块的情况,在其他大牛还在哼哧哼哧做恢复的时候,我向领导提议启用了新的方案,在大老板没有完全失去耐性的情况下恢复了业务.

真正正确的做法是,如果确定坏块数量为数众多,赶紧停业务,切灾备,后面再补数据.灾备是干什么吃的,养库千日,用库一时,就在这个时候了!

非常可惜的是,大多数来面试的DBA会非常纠结于用block recover,还是用dbms_repair,还是用BBED,还是……

那么,什么时候往上申报,要切灾备?

且不谈许多公司的灾备形同虚设,关键时候不敢切的事情.就算这些灾备都是实实在在可用的,恐怕也不是说切立即就能切的,切灾备涉及到应用、网络、主机、存储等多方面的调整.

那么多久应该切呢?一般的企业从故障处理开始,预估2小时之内不能让业务恢复正常运行的,应该申报切灾备.当然,如果是金融行业,特别是证券基金行业,1分钟之内故障还没恢复,就要知会证监会,半个小时没有恢复就会受到同行业通报,所以要切就应该在这个时间之内申报.

问题又回到了原点.你得先有规划,作为企业的重要系统,你得先建设灾备环境,而且是有效的灾备,并且应该事先有一个灾备切换预案.

作为DBA来说,动作敏捷的检查数据库的情况,并及时汇报非常重要.其实这里,又想说自动运维平台了.通过简单的按钮点点,就能快速知道告警日志里的坏块涉及什么对象,是不是就好很多呢?

继续往回看,面试的问题是什么?是多个数据库同时发现大量坏块.

作为一个经验丰富的运维管理人员,第一反应应该是,为什么会同时发生呢?显然是由于外因导致的.因此做好容灾切换,业务恢复使用的第一时间,应该去看看这些数据库共同的基础是不是同样的存储、同样的存储管理软件、卷管理软件.

依我的经验,大部分多个库同时出现坏块,都坏在存储管理软件身上.

有一次是Storage Foundation做卷复制的时候出现了软件bug,IBM、Oracle、symentec等众多厂家在“问题作战室”里整整呆了一个月,各家公司二线、三线出具各种证据自己没问题,最后最后才找到蛛丝马迹,揪出来.

还有一次稍微容易些,存储软件状态恢复后坏块没有恢复,一个个系统通过fsck命令来进行的修复.你说,这是什么类型的坏块呢?

作为有经验的DBA,要解决问题,但不要急着去敲命令,站在更高点的位置来看待问题,可能会事半功倍.

很不幸的前两天,某个朋友公司核心数据库“莫名奇妙”地遇到中止了.原因不方便说,但是据说等故障恢复完之后,朋友已经抽了好几包烟了.

我们先来看看,是由于LGWR终止了数据库(注：做了一些脱敏处理).

但是,重启数据库却发现数据库启动不了,发现众多数据文件发生了坏块,数据库根本不能open：

同时伴随着类似的内部错误：

怎么破?通过当天的数据库备份结合归档进行恢复,远远比去修复坏块要快.

解决问题时,一定是用最优先能处理好业务的技术,而不是最有技术含量的技术.

这个case里,没有容灾环境,但幸亏有备份,不然……

 

文/杨志洪

原文出处——DBApius社群微信公众号

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4518.html