Oracle11g ASM强大的新工具AMDU
在上次ASM故障恢复的案例中，强烈的感觉到ASM过于封装的特性，虽然极大的减轻了DBA的管理负担，但同时也使得灾难发生的时候处理的难度更高。
刚刚在著名的Pythian上看到一篇不错文章，提到Oracle11g的ASM提供了一个新的工具amdu，这个名字貌似就是ASM+DUL的简写，很好很强大。目前还没有实际使用过，看了看帮助，其功能真的非常厉害，对于磁盘头损坏之类的故障处理起来非常的方便，也可以直接从diskgroup里抽取出数据文件。有了这个东东，d.c.b.a开发基于ASM的AUL的想法基本可以放弃了，哈哈。有时间可以好好的研究下。
文章中还提到两个rac和asm方面非常值得一看的网站：
http://canali.web.cern.ch/canali/
http://blogs.oracle.com/AlejandroVargas/
有压力，要坚持
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的工具提供更详细准确的信息。
这个工具默认是没有编译的，需要手工编译
make -f ins_rdbms.mk ikfed
使用kfed dump出裸设备头信息，还是比较容易看懂对应的内容的
使用普通文件也能玩转ASM
ASM是Oracle10g一个非常吸引人的新特性。但是其需要多块磁盘才能配置，虽然可以使用vmware虚拟磁盘，但是毕竟要在虚拟环境中来配置，对于测试机器的硬件要求就比较高了。实际上，利用普通文件也能玩一把ASM。本文主要参考：How to use Files in place of Real Disk Devices for ASM - (Windows)
