最近一两个月，一直有场景化运维、场景化大数据分析的声音围绕在耳畔，以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里，没有容灾环境，但幸亏有备份，不然……