ORA-10567故障处理

一：场景描述数据库版本：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日志告警如下：

1234567 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 UNDOTBS1ORA-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参数均设置为typicalSQL> 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表空间数据文件备份更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx？tid=12MySQL Administrator连接VMWare下Ubuntu中MySQL过程关于Oracle表碎片整理相关资讯 ORA-10567 本文评论查看全部评论（0）