有压力，要坚持 --- ASM还魂记

yudingchu

好辛苦啊

kelsoncong

非常好的文章,最近PUB上关于DBA门槛越来越低的说法非常多,
个人觉得要是仅仅去做一个初级DBA还是比较容易的,
然后每向上提高一点还是需要花费大量的时间和工作的

bosonmaster

赞一个，确实非常复杂

zhaolinjnu

ORACLE对ASM封装的比较好，所以要解决此问题的整个过程真的很不容易.ASM作为ORACLE公司一款存储管理的产品，减轻了DBA存储管理的负担,这个方向是非常好的，但如果ASM有什么bug,想要在短时间内解决就会显得异常的困难。

zhaolinjnu

RAC系统属于多节点的系统,在这个节点上出现的存储上的问题(ASM)，因其是共享存储的数据库系统，很有可能在其它结点上都存在着相同的隐患,在经历了这件事后，对于这方面出问题，就不要再重启数据库了！尽可能的在线解决。这次事故提供了一次宝贵的经验。

[ 本帖最后由 zhaolinjnu 于 2008-2-24 11:20 编辑 ]

dg_mmc

原帖由 OoNiceDream 于 2008-2-24 08:11 发表
常常都是奋战在夜里的职业
遇到问题没有搞清楚具体原因之前，千万不要轻易重启数据库。得记住这句话

谢谢楼主

NinGoo

当时是以为这两个盘上存在reserve_lock锁导致新加的节点不能mount diskgroup，metalink上确实也有这种案例，才决定重启库的。没有想到出现了最坏的情况，是disk header本身损坏了，这个即使不将库宕下来，也没有更好的手段能够在线处理完成的，如果还是要用非常规手段修复disk header的话。不过在库还能正常运行的情况下，最好先不要重启库，而是要先搞清楚故障原因，这样宕机的时间能减少很多，压力也就相对小很多了。

mengzhaoliang

楼主辛苦了，很不容易啊。   

以后自己小心一点。

Ora-600

呵呵，由于asm这种封闭性，造成很多时候asm出了问题都很难解决或者很难在短时间内解决，这一点让很多用户不满，现在一些用户在了解这种情况后，宁愿还用以前的raw，哪怕复杂一些，起码成熟一些。
还有一个哥们的架构是，db用raw，归档用本地存储，flashback用asm。。。呵呵，这样的结构不知道有谁用过，够复杂的吧

magic007

越是自动化、封装很好的，出了问题，解决起来越麻烦。