ASM环境中有关磁盘的操作要慎重
这两天遇到一个ASM损坏的案例，环境是AIX，单机ASM，采用/dev/rhdiskn字符设备直接做为ASM Disk。损坏的diskgroup无法mount，alert中记录错误如下：
WARNING: cache failed to read fn=279 indblk=0 from disk(s): 6
ORA-15196: invalid ASM block header [kfc.c:7910] [endian_kfbh] [279] [2147483648] [6 != 0]
NOTE: a corrupted block was dumped to the trace file
System State dumped to trace file /u01/app/oracle/admin/+ASM/bdump/+asm_rbal_950452.trc
NOTE: cache initiating offline of disk 6 group 1
WARNING: offlining disk 6.4247132900 (DATA_0006) with mask 0x3
从报错中可以知道disk 6的某个block损坏了，kfbh.endian=6，本来应该等于0的。Trace file中可以找到损坏块的dump信息：
kfgbBind: binding kfgpn for group 1/0xA5A6EA25 (DATA)
kfgbRecoverCod: queued COD recovery for group 1/0xa5a6ea25 (DATA)
kfgbPeelWaitCIC: ignored, not rebalancing gn=1
kfgbRegister: registering group 2/0xA5F6EA26 (FLASH_RECOVERY_AREA)
kfgbBind: binding kfgpn for group 2/0xA5F6EA26 (FLASH_RECOVERY_AREA)
kfgbRecoverCod: queued COD recovery for group 2/0xa5f6ea26 (FLASH_RECOVERY_AREA)
kfgbPeelWaitCIC: ignored, not rebalancing gn=2
kfgbRebalanceCont: continuing-op COD for group 1/a5a6ea25lx (DATA)
kfgbRebalGrp: queued rebalance (power 1) for group 1/0xa5a6ea25 (DATA)
OSM metadata block dump:
kfbh.endian: 6 ; 0x000: 0x06
kfbh.hard: 162 ; 0x001: 0xa2
kfbh.type: 0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt: 0 ; 0x003: 0x00
kfbh.block.blk: 113817841 ; 0x004: T=0 NUMB=0x6c8b8f1
kfbh.block.obj: 581177085 ; 0x008: TYPE=0x2 NUMB=0x40efd
kfbh.check: 262 ; 0x00c: 0x00000106
kfbh.fcn.base: 2627010571 ; 0x010: 0x9c95000b
kfbh.fcn.wrap: 33554432 ; 0x014: 0x02000000
kfbh.spare1: 76002 ; 0x018: 0x000128e2
kfbh.spare2: 581177083 ; 0x01c: 0x22a40efb
这个比disk header损坏更严重，disk header中包含的信息有限，重建一下就可以恢复了。而具体的块损坏，则不可避免的导致数据丢失。后来发现导致块损坏的原因，居然是disk 6，对应的/dev/rhdisk8，被错误加入到一个vg当中了，这明显是一次误操作导致磁盘数据被覆盖了。在ASM环境中，对于磁盘操作，需要慎重，一个disk的损坏可能导致整个diskgroup无法使用，而且由于file分布在很多disk上，一个disk的损坏也会导致很多file失效，使得找回数据更加困难。
当然，这也可以说明另外一个问题，就是ASM还没有获得OS的足够支持。如果OS能够正确的识别ASM的Disk Header，就能够禁止该类型的操作，至少要给出提示，Oracle要推广ASM，还有很长的路要走。这也告诉我们，在DBA的日常操作中，要注重设计的简单性，文档的规范性和可操作性，并且操作要严格的安装手册执行。下命令前多检查，执行完后多监控，良好的习惯比任何高超的技巧都要来得有效。
ASM中的X$表
ASM看起来像个黑盒子，因为我们从文档中得到的信息有限。实际上ASM Instance和Database Instance没有什么区别，Oracle只是修改了代码使得其专注于存储管理而已。所以一些研究Database Instance的方法在ASM中照样有效，比如sql trace和10046事件等，这可以帮助我们认识到ASM内部的一些东西。
select count(*) from v$asm_file;
alter session set sql_trace=false;
找到对应的trace file，可以发现有如下语句：
blksiz_kffil,blkcnt_kffil,filsiz_kffil,filspc_kffil,sftype_kffil,
decode(redun_kffil,17,'UNPROT',18,'MIRROR',19,'HIGH',
35,'PARITY',36,'PARITY',37,'PARITY',38,'PARITY'),
decode(bitand(fdflg_kffil, 2), 2, 'FINE', 'COARSE'),
crdate_kffil,mddate_kffil,
decode(thinned_kffil, 0, 'U', 4294967295, 'N', 'Y')
from x$kffil
where incarn_kffil <> 0 and number_kffil > 255
ASM的隐含参数
ASM Instance从本质上来说，和数据库的实例是没有太大的区别的，基本的结构都差不多，只是专门用于管理存储而已。就像windows操作系统也有个专门的存储版本一样。
ASM Instance中也有一些隐含参数。当然，既然Oracle将它们隐藏了就是不希望我们去修改，所以在生产库中，千万不要尝试去修改这些隐含参数。我这里列出来纯属用于学习研究，擅自使用，后果自负^_^
from x$ksppi a, x$ksppcv b
where a.indx = b.indx
and ksppinm like '\_%asm%' escape '\'
order by a.ksppinm;
安装Oracle10g Clusterware遇到的一点问题
在vmware上安装一个双节点的Redhat Linux + Oracle10g RAC + ASM的测试环境，按照Oracle官方网站的安装指南，基本都很顺利，只是在clusterware的安装过程中碰到一点小问题。在执行root.sh脚本时，一直卡在Startup will be queued to init within 90 seconds.过不去，手动执行/etc/init.d/init.cssd start也是同样的问题，两个节点都是同样的情况。重装了三次后终于发现问题所在，就是在前面指定ocr和voting disk的location的时候，我填入的是soft link而不是raw设备的路径，改成类似/dev/raw/raw1的字符设备路径就ok了，本来想建个link比较易于识别的，郁闷。
