数据库坏块触发ora-00600和ora-07445
上午10:03分收到资源同步库的宕机告警,登陆数据库核实数据库确实异常,第一反应手动重启库,但依旧失败。
回过头查看数据库告警日志,发现大量的600和7445报错
![](https://images2017.cnblogs.com/blog/1236303/201709/1236303-20170929102749747-265811588.png)
查看trace文件,发现都是对同一个表T_PRODUCT_ADDR_6_8_TEMP_AREA的更新操作:
在连续的报错后,数据库自身有个坏块recover的操作
从在线日志恢复成功后,依然有类似的报错信息,最后数据库直接宕机
【分析过程】
1.根据数据库报错信息中涉及的两个数据文件号信息,在数据库启动到mount状态,通过以下脚本查询对应的数据文件
![](https://images2017.cnblogs.com/blog/1236303/201709/1236303-20170929102933340-596814231.png)
2.用DBV工具查看是否存在逻辑坏块
发现数据文件repgx11.dat确实存在坏块
3.查看主机日志,没有IO相关报错
![](https://images2017.cnblogs.com/blog/1236303/201709/1236303-20170929103024153-1323888834.png)
4.登陆资源同步库所连存储EVA8100和EVA6400查看,也无异常报错信息
5.剩下的就是考虑如何恢复的问题:
从上面的报错信息可以看出是由于存在坏块,导致事务异常而无法回滚,通过设置event='10513 trace name context forever,level 2'内部事件后,SMON不再recover dead transaction ,数据库能正常打开。至此数据库正常恢复。
![](https://images2017.cnblogs.com/blog/1236303/201709/1236303-20170929103045731-1741771373.png)
6.虽然数据库正常打开,但坏块问题依然存在,通过告警日志的提示信息file 58 block 367365查找坏块所在的对象
跟trace文件中提示的操作对象一致,通过重建该表,并rename互换解决该问题
互换后:
![](https://images2017.cnblogs.com/blog/1236303/201709/1236303-20170929103123372-1666009181.png)
7.修改pfile,删除event时间,使用spfile重启数据库,正常,数据库无类似的异常报错
8.通过DBV校验问题文件
![](https://images2017.cnblogs.com/blog/1236303/201709/1236303-20170929103148919-628694789.png)
已恢复正常
【附属说明】
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;