安装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比较易于识别的，郁闷。
有压力，要坚持
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读取相关信息的整个机制出现了混乱。
