一道面试题:遇到大规模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里,没有容灾环境,但幸亏有备份,不然……

 

作者介绍  杨志洪

  • 【DBAplus社群】联合发起人,新炬网络首席布道师;
  • 数据管理专家,拥有十余年电信、银行、保险等大型行业核心系统Oracle数据库运维支持经验,掌握ITIL运维体系,擅长端到端性能优化、复杂问题处理。现主要从事数据架构、高可用及容灾咨询服务;
  • Oracle ACE、OCM、《Oracle核心技术》译者。


时间: 2024-10-26 01:14:50

一道面试题:遇到大规模Oracle坏块该怎么处理?的相关文章

ORACLE坏块(ORA-01578)处理方法

oracle ORACLE的坏块即ORA-01578错,同时还可能伴随ORA-01110错,这种错误对于初学者或是那些没有实践经验的dba来说无疑是很棘手的.我当初就深受其害,写下这篇文章则是希望对大家有所帮助. 一.出问题时的情景 1.  我的一个计费的入库的进程停掉,报的便是ORA-01578错,对应用相关的表tg_bill03做SQL>select from tg_cdr03 where rownum<10;这样是可以的,但做SQL>select count(*) from tg_

Oracle坏块问题处理 Oracle坏块修复 Oracle坏块怎么办

Oracle数据库出现坏块现象是指:在Oracle数据库的一个或多个数据块(一个数据块的容量在创建数据库时由db_block_size参数指定,缺省为8K)内出现内容混乱的现象.由于正常的数据块都有固定的合法内容格式,坏块的出现,导致数据库进程无法正常解析数据块的内容,进而使数据库进程报错乃至挂起,并级联导致整个数据库实例出现异常. 一.坏块分类 物理坏块:也可以称为介质坏块,指的是块格式本身是坏的,块内的数据没有任何意义. 逻辑坏块:指的是块内的数据在逻辑是存在问题.比如说索引块的索引值没有按

oracle坏块修复实例

最近几天发现库里有坏块了,环境是11gR2, linux平台的64位的库.以下是我的修复办法,基于dbms_repair做的在线修复,也可以基于备份rman来修复,archivelog,noarchive log可能修复的方式有所不同.-->首先从alert.log里面发现如下的错误. DDE: Problem Key 'ORA 1110' was flood controlled (0x1) (no incident) ORA-01110: data file 8: '/dbTS2/oracl

oracle中RMAN备份和检查逻辑坏块

1. RMAN备份时是默认检查物理坏块. 2. 如果要检查逻辑坏块,可以用如下语句: $ rman target / RMAN> backup check logical validate database; 注上述语句,只是检查,不会备份的. 3. 如果要在备份的同时,进行逻辑坏块检查,可以用: $ rman target / RMAN> backup check logical database; 4.如果发现坏逻辑如何处理,下面补充一篇教程. 利用RMAN检测数据库坏块的脚本 虽然我们也

如果处理Oracle数据库中的坏块问题

oracle|数据|数据库|问题 Oracle的数据块有固定的格式和结构,分三层: Cache layer.Transaction layer和Data layer.对数据块进行读写操作时,做一致性检查:–Block type–DBA–Scn –Header and tail 发现不一致,标记为坏块. 坏块有两种: 物理坏块和逻辑坏块. 坏块产生的影响:数据字典表.回滚段表.临时段和用户数据表和索引.应用报错:–Ora-1578 –Ora-600 and trace file in bdump

如何处理Oracle数据库中的坏块问题

oracle|数据|数据库|问题   本文主要介绍如何去处理在Oracle数据库中出现坏块的问题,对于坏块产生在不同的对象上,处理的方法会有所不同,本文将大致对这些方法做一些介绍.因为数据库运行时间长了,由于硬件设备的老化,出现坏块的几率会越来越大,因此,做为一个DBA,怎么去解决数据库出现的坏块问题就成了一个重要的议题了.   一:什么是数据库的坏块   首先我们来大概看一下数据库块的格式和结构 数据库的数据块有固定的格式和结构,分三层:cache layer,transaction laye

Oracle中通过RMAN修复坏块

通过dbv和rman blockrecover对Oracle数据库坏块进行修复. (1)rman备份时alert.log报如下错误: Fri Jul  2 12:41:36 2010 Hex dump of (file 12, block 2718618) in trace file /u01/app/oracle/admin/bi/udump/bi_ora_31213.trc Corrupt block relative dba: 0x03297b9a (file 12, block 2718

Oracle 9i数据坏块的处理实例

笔者在一台生产用测试库上SELECT一个表时出现ORA-01578,一个块损坏,以前学习过块损坏怎么处理,到还真没遇到过,今天总算让我遇到了,还是一台生产用测试库,就不用很紧张了. 数据库版本是9.2.0.4,Oracle9i的RMAN有一个blockrecover命令,可以在线修复坏块,以下就是使用RMAN修复坏块的过程. SQL> conn owi/owi Connected. SQL> select * from dpa_history; select * from dpa_histor

处理Oracle数据库中的坏块

一 什么是数据库的坏块 首先我们来大概看一下数据库块的格式和结构--数据库的数据块有固定的格式和结构,分三层 cache layer,transaction layer,data layer.在我们对数据块进行读取写入操作的时候,数据库会对要读写的数据块做一致性的检查,其中包括 数据块的类型.数据块的地址信息.数据块的SCN号以及数据块的头部和尾部.如果发现其中有不一致的信息,那数据库就会标记这个数据块为坏块了.数据库的坏块分为两种,逻辑坏块和物理坏块. 二 坏块对数据库产生的影响 如果数据库出