有压力，要坚持
DBA未必是一个高薪的职业，但绝对是一个高压力的职业。
昨天晚上，数据仓库一个4节点的RAC+ASM系统，在进行新加节点操作的时候，发现新节点的ASM实例无法mount diskgroup，报ORA-15042错误。后来尝试将整个库重启，结果所有节点的ASM实例都出现同样的问题了。这个教训告诉我们，在遇到问题没有搞清楚具体原因之前，千万不要轻易重启数据库。
但是问题既然已经发生，自然要想办法修复。这是一个将近7T的生产系统，虽然目前只供内部使用，也不可能接受长时间的停机，所以重建diskgroup然后从备份恢复的方案只能是最坏情况下的打算。那么，当务之急，是要尽快查出问题所在，对症下药。
工欲善其事，必先利其器。这次问题的解决，得益于oracle的kfed工具。从dump出来的结果看到，报错的两个disk的头信息确实已经损坏，另外一点比较奇怪的就是，正常disk header中记录的disk number和path信息，和从v$asm_disk查出来的已经不一致了。这个现象可能由于两个disk的头信息损坏，导致AMS Instance读取相关信息的整个机制出现了混乱。
使用kfed工具查看ASM disk header信息
从v$asm_disk中可以看到disk的很多状态信息，但有时候这些信息可能还不够，而且在我们的一个案例中，在一次报ORA-15042错误后，v$asm_disk中的信息甚至都是错误的了。Oracle提供了一个kfed的工具提供更详细准确的信息。
这个工具默认是没有编译的，需要手工编译
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk ikfed
make -f ins_rdbms.mk ikfed
使用kfed dump出裸设备头信息，还是比较容易看懂对应的内容的
kfed read /dev/raw/raw41 text=raw41.out
