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

wangfans

辛苦了

aimhigh

原帖由 mcseman 于 2008-2-26 01:48 发表


如果是ASM的ＤＧ的Ｈｅａｄｅｒ信息丢失，目前是否认定了是ＡＳＭ的Ｂｕｇ？本次问题的处理主要是依照Ｏｒａｃｌｅ内部文档处理的吧？Ｏｒａｃｌｅ工程师是否现场处理？还是远程支持？因为我们也用ＡＳＭ，并且问题比较多，我想知道这是不是一个Ｏｒａｃｌｅ的Ｂｕｇ？或者说是ＡＳＭ在Ｌｉｎｕｘ环境下不稳定？

是啊，问题是解决了，原因分析有没有。

zhangweicai74

也许很多事情都是这样，在你即将绝望放弃的时候，其实离最终的终点已经非常非常的接近，只要再坚持一下，但是这一下，又谈何容易呢。

blue_prince

原因还在追究中，我在不停在跟踪SR，单单这个SR就会弄得我火大，ORACLE处理得太慢了。NND，一堆杂事。

blue_prince

原帖由 mcseman 于 2008-2-26 01:48 发表


如果是ASM的ＤＧ的Ｈｅａｄｅｒ信息丢失，目前是否认定了是ＡＳＭ的Ｂｕｇ？本次问题的处理主要是依照Ｏｒａｃｌｅ内部文档处理的吧？Ｏｒａｃｌｅ工程师是否现场处理？还是远程支持？因为我们也用ＡＳＭ，并且问题比较多，我想知道这是不是一个Ｏｒａｃｌｅ的Ｂｕｇ？或者说是ＡＳＭ在Ｌｉｎｕｘ环境下不稳定？

ORACLE没有支持，只是通过一个朋友弄到一个内部文档我们自己解决的。原因还在追究中。

ghsyws193

DBA未必是一个高薪的职业，但绝对是一个高压力的职业。

zongyongchun

hack的感觉相当好啊！呵呵~~

做了一次DB的hack，对内部细节更清楚了。

想知道dd清空4k头部的依据。

跟踪此文，若是最终找出bug，一定要贴出来啊！

感谢分享经验！

mcseman

原帖由 blue_prince 于 2008-2-26 14:50 发表
原因还在追究中，我在不停在跟踪SR，单单这个SR就会弄得我火大，ORACLE处理得太慢了。NND，一堆杂事。

ＳＲ是极其繁琐的一个东西，而且比较复杂的情况在ＳＲ上又说不太清楚。呵呵！

mcseman

原帖由 blue_prince 于 2008-2-26 14:51 发表


ORACLE没有支持，只是通过一个朋友弄到一个内部文档我们自己解决的。原因还在追究中。

没有买Ｏｒａｃｌｅ的服务吗？我觉得ＡＳＭ的Ｂｕｇ的可能性比较大。如果仅仅坏了ＡＳＭ的ＤＧ的Ｈｅａｄｅｒ的话就会影响这么大，ＡＳＭ的ＤＧ　Ｈｅａｄｅｒ有没有冗余的配置呀？对于ＲＡＣ基本上所有单点都要考虑冗余的配置。。。。。。就像多路控制文件，Ｖｏｔｉｎｇ　Ｄｉｓｋ　Ｍｉｒｒｏｒ等等。。。

blue_prince

有ORACLE服务，我觉得ASM DISK HEADER的信息应该是互为冗余备份的，在另外一个内部文档中说清空头部就可以了。应该还能从其他盘读出信息。