« What's Mean "reliable message"? | Blog首页 | 《深度解析Oracle》之《循序渐进Oracle》 »
DBA警世录:使用ASM应当具备充分认识
作者：eygle |【转载时请以超链接形式标明文章出处和作者信息及本声明】链接：http://www.eygle.com/archives/2008/02/asm_notice.html
本周五，淘宝网的DBA们遇到了ASM的故障，产品环境的故障对于DBA的考验是巨大的(同日我的一个客户也经历了一次ASM故障)。
故障症状就是ASM磁盘的Header信息丢失，导致磁盘组无法加载相应磁盘。
通过kfed工具可以查看ASM磁盘头信息。
出问题的磁盘信息显示：
kfbh.endian: 83 ; 0x000: 0x53
kfbh.hard: 0 ; 0x001: 0x00
kfbh.type: 0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt: 0 ; 0x003: 0x00
kfbh.block.blk: 4294967293 ; 0x004: T=1 NUMB=0x7ffffffd
kfbh.block.obj: 65286 ; 0x008: TYPE=0x0 NUMB=0xff06
kfbh.check: 144 ; 0x00c: 0x00000090
kfbh.fcn.base: 136903976 ; 0x010: 0x0828fd28
kfbh.fcn.wrap: 4294953840 ; 0x014: 0xffffcb70
kfbh.spare1: 136905029 ; 0x018: 0x08290145
kfbh.spare2: 30000 ; 0x01c: 0x00007530
由于ASM是个封装的磁盘管理工具，我们很难窥探其内部原理，所以遇到问题时常常就会手足无措。
这就要求我们在使用ASM时要有充分的认识，ASM也可能出现严重的故障。不可对此掉以轻心
所以，做好数据库的备份是最基本的要求，除此之外，定期保存一下ASM Disk Header信息（通过kfed read来记录）以备不时之需也许是必要的。
有一点也许要引起注意：数据库总是会在你毫无准备的地方出现问题。仔细想想，你在哪些地方缺乏考虑?
此外我们需要谨记：当问题没有定位之前，不要贸然关闭运行中的节点。
-The End-
历史上的今天...
>> 2006-02-24文章:
>> 2005-02-24文章:
------
这篇 【DBA警世录:使用ASM应当具备充分认识】来自 www.eygle.com | CSDN技术网摘| del.icio.us|365Key
By eygle on 2008-02-24 10:53 | Comments (7) | Posted to Beginner | Edit |Pageviews:
留言 (7)
以前我们公司的DBA只是一个DBA，刚开始时对于存储的问题手足无处，而我们公司有单独的存储工程师，精通各种存储阵列和各种存储共享软件，这时候终于有用武之地了，两人配合干，后来那个存储工程师变成了很牛的DBA，所以当然asm的出现，DBA不止是一个一个DBA，还是是很牛的存储工程师。
Posted by: eshen at February 24, 2008 2:21 PM
问题的解决，才是最终最重要的结果
当然，其中有幸运的成分，也必须有扎实的基础与缜密的思路，以及团队合作精神
Posted by: piner at February 24, 2008 5:03 PM
处理过程可以参考
http://rdc.taobao.com/blog/dba/html/69_dba_under_pressure.html#comment-384
Posted by: piner at February 24, 2008 5:04 PM
对asm的问题现在谁都没有一套好的资料拿出来，对严重故障也没有类似隐含参数或event之类的极端解决办法，所以配好dataguard ,做好备份，才是最关键的，这次是顺利解决了，下次就不一定那么幸运了
Posted by: mustapha at February 24, 2008 5:37 PM
备份是有的，standby也有，但是是不对称的。
那么大的数据量，从备份恢复的工作量是巨大的。
Posted by: piner at February 24, 2008 5:46 PM
恩，解决问题是王道！
Posted by: eygle at February 25, 2008 11:11 AM
那么大的数据量做恢复确实很可怕,即使是random划的ASM,让ASM做rebalance也很可怕,ASM只做这个事情了,业务都无法运转.
Posted by: 赵宇 at April 3, 2008 11:52 AM
