安装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比较易于识别的,郁闷。

Read more of this post

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/

Read more of this post

有压力,要坚持

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读取相关信息的整个机制出现了混乱。

Read more of this post

使用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

使用kfed dump出裸设备头信息,还是比较容易看懂对应的内容的

kfed read /dev/raw/raw41 text=raw41.out

Read more of this post

无觅相关文章插件,快速提升流量