love wife & love life —Roger 的Oracle技术博客

Phone:18180207355 提供专业Oracle数据恢复、性能优化、迁移升级、紧急救援等服务

Recover Case: 一个24TB的rac(asm)恢复案例

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客

本文链接地址: Recover Case: 一个24TB的rac(asm)恢复案例

前几天某客户的一个核心数据库,大约24TB的rac,asm diskgroup无法mount。经过分析发现是某个disk的一个block坏掉了。其中通过kfed read读取发现确实有问题:

我们通过手工构造了一个block,然后进行merge修复之后,我尝试mount diskgroup,发现还是报错,如下:

不难看出,这个错误比较熟悉了。从上述日志来看,第49号disk的第0号AU的第18号block还是有问题,通过kfed读取发现确实也是坏块。跟前面第2号block 一样。这里如法炮制,仍然构造一样的block,然后merge之后,成功将diskgroup mount了。

将diskgroup mount之后,我检查数据库,发现crs自动将数据库拉起来了,并且已经open了。然而后续进一步检查发现asm的arb进程仍然在报错:

虽然已经不影响数据库的正常运行,然而由于arb进程的异常,导致reblance操作实际上没有进行完成,客户新加的磁盘基本上没有被使用,导致diskgroup的磁盘使用不均衡。

这个错误看上去很复杂,实际上很简单。根据后面的序号,我们可以判断,本质来讲是因为我们前面手工构造的2个block其实并不完整,这是allocate table,需要将后面的kfdate数据都构造完毕,才能让arb进程正常工作下午。

不过熊爷已经在修改odu代码了,准备odu来搞定这个遗留问题。看来ODU以后将具备修复ASM元数据的功能了。很强悍!

    分享到:
18180207355
加Q咨询