最近一两个月,一直有场景化运维、场景化大数据分析的声音围绕在耳畔,以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里,没有容灾环境,但幸亏有备份,不然……
作者介绍 杨志洪
【DBAplus社群】联合发起人,新炬网络首席布道师;
数据管理专家,拥有十余年电信、银行、保险等大型行业核心系统Oracle数据库运维支持经验,掌握ITIL运维体系,擅长端到端性能优化、复杂问题处理。现主要从事数据架构、高可用及容灾咨询服务;
Oracle ACE、OCM、《Oracle核心技术》译者。
本文来自云栖社区合作伙伴"DBAplus",原文发布时间:-05-21