数据库坏块触发ora-00600和ora-07445

时间：2017-09-29 10:59:19 阅读：204 评论：0 收藏：0 [点我收藏+]

上午10:03分收到资源同步库的宕机告警，登陆数据库核实数据库确实异常，第一反应手动重启库，但依旧失败。

回过头查看数据库告警日志，发现大量的600和7445报错

技术分享

查看trace文件，发现都是对同一个表T_PRODUCT_ADDR_6_8_TEMP_AREA的更新操作：

技术分享

在连续的报错后，数据库自身有个坏块recover的操作

技术分享

从在线日志恢复成功后，依然有类似的报错信息，最后数据库直接宕机

技术分享

【分析过程】

1.根据数据库报错信息中涉及的两个数据文件号信息，在数据库启动到mount状态，通过以下脚本查询对应的数据文件

2.用DBV工具查看是否存在逻辑坏块

技术分享

发现数据文件repgx11.dat确实存在坏块

3.查看主机日志，没有IO相关报错

4.登陆资源同步库所连存储EVA8100和EVA6400查看，也无异常报错信息

5.剩下的就是考虑如何恢复的问题：

从上面的报错信息可以看出是由于存在坏块，导致事务异常而无法回滚，通过设置event=‘10513 trace name context forever,level 2‘内部事件后，SMON不再recover dead transaction ，数据库能正常打开。至此数据库正常恢复。

6.虽然数据库正常打开，但坏块问题依然存在，通过告警日志的提示信息file 58 block 367365查找坏块所在的对象

技术分享

跟trace文件中提示的操作对象一致，通过重建该表，并rename互换解决该问题

互换后：

7.修改pfile，删除event时间，使用spfile重启数据库，正常，数据库无类似的异常报错

8.通过DBV校验问题文件

已恢复正常

【附属说明】

1.如果在重建表后，坏块依然存在，可以删除原来的表，再使用CREATE TABLE命令将原存在逻辑坏块的数据块覆盖，避免上述ORA-600问题再次发生。

create table LARGE_TABLE (t1 int) tablespace REP_GX;

alter table LARGE_TABLE allocate extent (datafile ‘/dsgdata/zydata/repgx17.dat‘ size 10M);

2.如果数据库处于归档模式，且有备份，可以通过RMAN来恢复

RMAN> blockrecover datafile 58 block 367365 from backupset;

原文地址：http://www.cnblogs.com/tonnytangy/p/7609893.html

踩

(0)

评论一句话评论（0）

分享档案

更多>

周排行