|
凌晨1点半，朦胧中电话铃狂响，某Exadata严重故障……. 离上一篇文章（5小时数据蒸发||24小时服务降级，Salesforce的遭遇只是个案？）不远，我们又遇到了一次又一次数据救援工作。跟Salesforce巧合的是，大家都是运行在Exadata上，不幸的是Salesforce丢失了4个小时数据（后续没看到新闻稿，是否又追回了部分）业务停顿，那我今天遇到的要麻烦更多。 近期Exadata故障比较多，比较重要的是硬件生命周期所致，X2从2010年9月开始发布上线，到现在已经将近6年，就算传统“高端”小型机也到该下线的时候了。提醒使用Exadata的朋友们做好备份，否则，你可能也要经历一场难忘的救援经历。 问题发生得很不可思议，又很理所当然，细节就不说了。总之比较糟糕：存放数据文件的diskgroup不能加载（mount），celldisk状态是unknown，部分asm disk的header是invalid的，就连它自动备份的块也是invalid的，有磁盘物理损坏，物理损坏的磁盘没有的mirror也失效了。接近10TB的数据，想想也头疼吧。 再说具体数据抢救工作之前，还是提醒下使用ASM/Exadata的朋友们，至少搭建个Data Guard吧，刚好建荣也做了这方面的分享，赶紧去读读。 鉴于问题非常棘手，综合各方信息，我们做了如下的方案： 将数据库文件抽取出来 尝试open 如失败再DUL
要将数据库文件（控制文件、数据文件、日志文件）从没有加载的磁盘组中抽取出来，需要借助于AMDU。 AMDU: ORACLE针对ASM开发的源数据转储工具，其全称为ASM Metadata Dump Utility 抽取的具体步骤： 从alert日志中找到启动参数（包括控制文件），编辑成新的参数文件/tmp/pfile 从pfile中找到控制文件的位置，并用amdu抽取 用抽取出来的控制文件，将数据库mount起来 从mount库把所有数据文件找出来，可能有2种格式 OMF格式（数据文件带Oracle自动生成的数字） 自定义格式（手贱的），处理起来麻烦一些 日志文件同上处理
抽取数据文件 第一步：抽控制文件 先从alert日志找到控制文件位置： control_files string +DATA/exdb/controlfile/curren t.266.278946847955, 11g开始amdu不需要编译可以直接使用。到/data文件系统，开始操作 amdu -diskstring '/o/*/ *' -extract data.266 在当前目录下会生成一个DATA_266.f的文件和一个report.txt文件，DATA_266.f就是控制文件了。 第二步：找数据文件和日志文件 如果你有备份的pfile最好，如果没有，就从alert日志里去找启动的时候的初始化参数，实在没有，手工编辑一个也行，包含sga_max_size,db_name,control_file这几个参数。 然后把数据库启动到mount状态，查找数据文件和日志文件： select name from v$datafile; select member from v$logfile; 运气好，都是这样的（OMF格式）： +DATA/exdb/datafile/system.256.278946847955 +DATA/exdb/datafile/sysaux.257.278946847955 +DATA/exdb/datafile/undotbs1.258.39804295139 +DATA/exdb/datafile/users.259.48049295141 运气不好，可能是有这样的（自定义格式）： +DATA/exdb/datafile/users_2013084.dbf +DATA/exdb/datafile/tbs_jifen_cx_0123.dbf 对于OMF格式的，仿照抽取控制文件，一个个抽： amdu -diskstring '/o/*/ *' -extract data.256 对于自定义格式的，要从amdu -extract DATA.6 -diskstring 'o/*/DATA' ，生成DATA_6.f 文件
for (( i=1; i<15; i++ )) do kfed read DATA_6.f blknum=$i |egrep 'name|fnum'>>aa.out done 再依照OMF格式抽取方式抽取出所有数据文件。 值得一说的是，我们遭遇了一个3T的bigfile，extract消耗了将近24小时= =。--NFS挂过去的文件系统速度特别慢= = 最后对所有的文件用dbv做一次校验，有没有物理坏块。 尝试Open数据库 当到了这一步的时候，其实就跟寻常的数据库恢复类似了。 我们同样在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的方法很多网友也有分享过，度娘或者谷哥都可以。这里需要重点提示后续有需要的小伙伴的是，搞了两下没起来也别灰心。 这次单就推进SCN这块，我们也折腾了好长时间，甚至一度两度打算放弃准备DUL了。 先看看oradebug poke的描述： 
那首先是找到SCN的内存地址： 
等号后面的值，就是当前显示的SCN了，不过，由于是mount状态，所以显示为0. 将当前的SCN（从v$datafile_header#查）随手加上100万，转为十六进制，推一把看看： 
再次查看就能看到SCN的值了： 
然后“alter database open uprade", 不断重复尝试....... 此外还用了bbed修改块，还去删除数据字典记录....... 终于，数据库总算open了，数据回来了。 关于更详细的细节，欢迎关注后续DBA+技术沙龙主题。 DUL和AMDU 万幸的是，没有走到最后一步，没有用DUL来抽数据，不然，以这龟速，少说也是一个星期的事情。 DUL和AMDU都是救命的稻草，我们有能力使用，不代表我们一定要去用。而且我们从不在这个时候跟客户谈收费，作为服务商我们坚持救急如救火！而这些救命工具就如同山洞里的核武器，我们希望每个客户都能做好前期规划、维护、备份和容灾，让它们静静地躺着，作为一种威慑手段就好了。 关于exadata的维护 再好的东西，你不关心它，总会出问题的，Exadata也不例外。 摘抄《Exadata专家工具箱》里的几个工具，仅供参考： sundiag 
ExaWatcher 
Diskinfo IBCardino Iostat Netstat Ps Top Vmstat
Exachk 
CheckHWnFWProfile 
这些命令两周做一次检查还是必要的。 关于数据库运维管理工具 问题发生在别人身上的时候，我们听起来不可思议，觉得别人是不是傻啊，还是懒啊，其实不是，有的时候真是太忙太忙，忙不过来，这时候需要一套工具来帮助大家。 是的，说的就是你。还记得我们昨天的聊天么，你说，他们是不是傻啊，不做监控么，平时不去看么？我说，你要是管理几千个数据库，而你又没有合适的管理工具，一个边缘系统发生这种情况，是在所难免的。 那么什么样的数据库运维管理工具是合适的呢？ 数据库多维度监控 日常运维场景化 数据库实时性能分析 应用性能追溯
这几个方面互为补充，逐渐让运维变得信手拈来。 1、数据库是一个非常专业的细分领域，传统的ITOM工具集成的监控功能往往太粗放，所以需要专业的数据库多维度监控，各项监控指标数据需要实时采集并存放，根据趋势进行告警。 就拿本案例来说，如果有对Exadata服务存活的监控，问题至少在故障发生前一星期就能得到预警，并及时处理。 2、日常运维场景化 太多的数据库意味着任何一个点的维护，都需要大量的时间消耗，因此需要集成、封装一些运维场景。比如： 有了这些功能，你是不是可以省下好多时间钻研新技术，为企业核心技能的更新换代贡献自己的能量，而不需要整天想着逃离苦海了呢。 3、数据库实时性能分析 此功能意义很大，看下面两个场景： 如果有一个工具，能帮你实时记录数据库的这些信息，而且不用查询数据库，而是直接读取SGA，那这一些问题都能够分分钟解决，是不是很爽？ 4、应用性能追溯 有些问题，明显是应用的问题，可是如果你不明确告诉他，是哪个应用模块，哪个用户干的，你几乎就说不清楚是应用的问题。 如果运维管理工具不仅仅能够帮你发现是哪个SQL语句导致，说出program，而且能告诉你是从哪个路径爬过来的，是由哪个jar包发起，那是不是一切就显而易见了呢。让背锅的日子见鬼去吧。 那么，存在这样的数据库运维管理工具么？ 答案是yes。 作者介绍 杨志洪 精选专题（点击蓝色标题可阅读全文）
|
点
点