【力荐】Exadata火线救援:10TB级数据修复经典案例详解!
《【力荐】Exadata火线救援:10TB级数据修复经典案例详解!》要点: 凌晨1点半,朦胧中电话铃狂响,某Exadata严重故障……. 离上一篇文章(5小时数据蒸发||24小时服务降级,Salesforce的遭遇只是个案?)不远,我们又遇到了一次又一次数据救援工作.跟Salesforce巧合的是,大家都是运行在Exadata上,不幸的是Salesforce丢失了4个小时数据(后续没看到新闻稿,是否又追回了部分)业务停顿,那我今天遇到的要麻烦更多. 近期Exadata故障比较多,比较重要的是硬件生命周期所致,X2从2010年9月开始发布上线,到现在已经将近6年,就算传统“高端”小型机也到该下线的时候了.提醒使用Exadata的朋友们做好备份,否则,你可能也要经历一场难忘的救援经历.问题发生得很不可思议,又很理所当然,细节就不说了.总之比较糟糕: 存放数据文件的diskgroup不能加载(mount),celldisk状态是unknown,部分asmdisk的header是invalid的,就连它自动备份的块也是invalid的,有磁盘物理损坏,物理损坏的磁盘没有的mirror也失效了.接近10TB的数据,想想也头疼吧.再说具体数据抢救工作之前,还是提醒下使用ASM/Exadata的朋友们,至少搭建个DataGuard吧,刚好建荣也做了这方面的分享,赶紧去读读. 鉴于问题非常棘手,综合各方信息,我们做了如下的方案:
要将数据库文件(控制文件、数据文件、日志文件)从没有加载的磁盘组中抽取出来,需要借助于AMDU. 抽取的具体步骤:
第一步:抽控制文件先从alert日志找到控制文件位置: 11g开始amdu不需要编译可以直接使用.到/data文件系统,开始操作 在当前目录下会生成一个DATA_266.f的文件和一个report.txt文件,DATA_266.f就是控制文件了. 第二步:找数据文件和日志文件如果你有备份的pfile最好,如果没有,就从alert日志里去找启动的时候的初始化参数,实在没有,手工编辑一个也行,包含sga_max_size,db_name,control_file这几个参数. 然后把数据库启动到mount状态,查找数据文件和日志文件: 运气好,都是这样的(OMF格式): 运气不好,可能是有这样的(自定义格式): 对于OMF格式的,仿照抽取控制文件,一个个抽: 对于自定义格式的,要从<diskgroup>.6去抽取元数据,然后找到其对应的number
for (( i=1; i<15; i++ )) 再依照OMF格式抽取方式抽取出所有数据文件. 值得一说的是,我们遭遇了一个3T的bigfile,extract消耗了将近24小时= =.–NFS挂过去的文件系统速度特别慢= = 最后对所有的文件用dbv做一次校验,有没有物理坏块. 当到了这一步的时候,其实就跟寻常的数据库恢复类似了. 我们同样在open的时候遇到了ORA-1555、ORA-704错误. 记录下我们用到的参数和事件. event: 隐含参数: 这里比较讨厌的是rollback segments不容易确定,因为你是mounted状态的数据库,连v$rollname都查询不了. 有两个办法来解决: 办法一,用strings去system文件里抓. 办法二,用DUL/AUL/ODU/GDUL等类似工具.相对来说这种方法得到的准确一些 把得出的SYS_UNDO.dmp导入普通用户,去除status为1和2的回滚段(还原段)后放入到上述空着的2个参数. open的时候可能还会报ORA-1555,需要推进SCN,以upgrade模式open. 推进SCN的方法很多网友也有分享过,度娘或者谷哥都可以.这里需要重点提示后续有需要的小伙伴的是,搞了两下没起来也别灰心. 先看看oradebug poke的描述: 那首先是找到SCN的内存地址: 等号后面的值,就是当前显示的SCN了,不过,由于是mount状态,所以显示为0. 将当前的SCN(从v$datafile_header#查)随手加上100万,转为十六进制,推一把看看: 再次查看就能看到SCN的值了: 然后“alter database open uprade”,不断重复尝试……. 此外还用了bbed修改块,还去删除数据字典记录……. 终于,数据库总算open了,数据回来了. 关于更详细的细节,欢迎关注后续DBA+技术沙龙主题. 万幸的是,没有走到最后一步,没有用DUL来抽数据,不然,以这龟速,少说也是一个星期的事情. DUL和AMDU都是救命的稻草,我们有能力使用,不代表我们一定要去用.而且我们从不在这个时候跟客户谈收费,作为服务商我们坚持救急如救火!而这些救命工具就如同山洞里的核武器,我们希望每个客户都能做好前期规划、维护、备份和容灾,让它们静静地躺着,作为一种威慑手段就好了. 再好的东西,你不关心它,总会出问题的,Exadata也不例外. 摘抄《Exadata专家工具箱》里的几个工具,仅供参考: sundiag ExaWatcher
Exachk CheckHWnFWProfile 这些命令两周做一次检查还是必要的. 问题发生在别人身上的时候,我们听起来不可思议,觉得别人是不是傻啊,还是懒啊,其实不是,有的时候真是太忙太忙,忙不过来,这时候需要一套工具来帮助大家. 是的,说的就是你.还记得我们昨天的聊天么,你说,他们是不是傻啊,不做监控么,平时不去看么?我说,你要是管理几千个数据库,而你又没有合适的管理工具,一个边缘系统发生这种情况,是在所难免的. 那么什么样的数据库运维管理工具是合适的呢?
这几个方面互为补充,逐渐让运维变得信手拈来. 就拿本案例来说,如果有对Exadata服务存活的监控,问题至少在故障发生前一星期就能得到预警,并及时处理. 2、日常运维场景化
有了这些功能,你是不是可以省下好多时间钻研新技术,为企业核心技能的更新换代贡献自己的能量,而不需要整天想着逃离苦海了呢. 3、数据库实时性能分析
如果有一个工具,能帮你实时记录数据库的这些信息,而且不用查询数据库,而是直接读取SGA,那这一些问题都能够分分钟解决,是不是很爽? 4、应用性能追溯 如果运维管理工具不仅仅能够帮你发现是哪个SQL语句导致,说出program,而且能告诉你是从哪个路径爬过来的,是由哪个jar包发起,那是不是一切就显而易见了呢.让背锅的日子见鬼去吧. 那么,存在这样的数据库运维管理工具么? 答案是yes. 作者介绍? 杨志洪
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |