DBA警世录:使用ASM应当具备充分认识

本周五，淘宝网的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-