当前位置:Gxlcms > mysql > ORA-10567故障处理

ORA-10567故障处理

时间:2021-07-01 10:21:17 帮助过:35人阅读

一:场景描述数据库版本:11.2.0.164bitactivedataguard操作系统版本:centos5.864bit早上数据库例行检查,发现undo表空间数据文件太大,查询了最大的block后,

一:场景描述

数据库版本:11.2.0.1 64bit active dataguard

操作系统版本:centos 5.8 64bit

早上数据库例行检查,发现undo表空间数据文件太大,查询了最大的block后,发现实际只使用到几百兆。于是想当然alter database datafile 'xxxx' resize 3G;万事ok!在这之前,香港虚拟主机,遇到这种情况,香港空间,也都是这样处理,均未出现过问题!个人不太喜欢新建undo表空间然后改默认undo表空间的做法。


二:问题出现

没过多久,网站空间,手机收到监控报警信息,从库从read only with apply状态直接变成read only状态,mrp进程死掉了!alert日志告警如下:

Errors in file /u01/app/oracle/diag/rdbms/db2/xxxx/trace/xxxx_mrp0_7844.trc: ORA-00600: internal error code, arguments: [3020], [3], [10232], [12593144], [], [], [], [], [], [], [], [] ORA-10567: Redo is inconsistent with data block (file# 3, block# 10232, file offset is 83820544 bytes) ORA-10564: tablespace UNDOTBS1 ORA-01110: data file 3: '/u01/app/oracle/oradata/xxxx/undotbs01.dbf' ORA-10560: block type 'KTU SMU HEADER BLOCK' MRP0: Background Media Recovery process shutdown (xxxx)


三:问题分析

主从库的db_lost_write_protect参数均设置为typical

SQL> show parameter protec;


NAME TYPE VALUE

------------------------------------ ----------- ----------

db_lost_write_protect string typical


猜想因为undo表空间数据文件的收缩操作导致从库的undo数据文件丢失写,不知道这算不算oracle bug!


四:问题处理

1:关闭从库数据库实例

2: 主库上让undo表空间进入热备份状态

alter tablespace undotbs01 begin backup;

3:利用操作scp命令复制数据文件至从库指定位置,原有文件重命名下

4:启动从库数据库实例到read only状态,开启mrp进程,发现alert日志无报错信息

5:主库关闭undo表空间热备份状态

alter tablespace undotbs01 end backup;

6:删除从库原有的undo表空间数据文件备份


本文出自 “斩月” 博客,谢绝转载!

人气教程排行