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

该客户数据库在春节之前就出现故障,后面经过多人尝试恢复后,均为打开数据库;数据库在open时报如下错误:

该错误其实很场景,也恢复过太多这种情况了,这里不再过多描述。不过这里让我感觉很诧异的是该SQL的Query Duration 太大了。
根据经验,这种情况下可以直接推进SCN。可是当我们进行如下操作,发现不起作用:

alter session set events ‘10015 trace name adjust_scn level 13740’;

进一步通过10046 trace跟踪发现该sql访问了如下几个block:

通过分别dump上述block,我们发现file 1 block 122 有点小问题,如下:

通过脚本将该block copy到文件系统,bbed进行修改之后,再copy回asm diskgroup。
接着再次进行scn的推进,可以很顺利打开数据库。

这里需要注意的是,虽然打开了数据库,但是后面还有很多善后处理工作,比如我们dbv发现undo有坏块,那么就需要重建undo;同时检查alert log是否伴随其他的错误。

其次,对于强制open的数据库,我们建议通过mos脚本检查下数据字典是否存在异常;如果数据字典有明显异常,那么通常是需要通过逻辑导出来重建数据库的;否则一般不需要重建库。

对于是否需要重建库,我认为没有定论,安全起见是通常是建议重建数据库;或者数据库很小的时候也可以考虑重建;否则通过检查数据库告警,或者数据库运行一段时间没有其他异常,那么完全可以不重建数据库。

    分享到:
18180207355
加Q咨询