ORA-10567故障处理



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

一：场景描述

数据库版本：11.2.0.1 bit active dataguard

操作系统版本：centos 5.8 bit

早上数据库例行检查，发现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-105: 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表空间数据文件备份

本文出自 “斩月” 博客，谢绝转载！