一：场景描述数据库版本：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表空间数据文件备份
本文出自 “斩月” 博客，谢绝转载！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告
收藏
收藏
收藏
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
346
