ORA-10567故障处理
一:场景描述数据库版本: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表空间数据文件备份
本文出自 “斩月” 博客,谢绝转载!
上一篇: PowerDesigner体验之旅