love wife & love life —Roger的Oracle&MySQL技术博客

Phone:18180207355 提供专业Oracle&MySQL数据恢复、性能优化、迁移升级、紧急救援等服务

15 TB 3节点RAC 的恢复记录

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger的Oracle&MySQL技术博客

本文链接地址: 15 TB 3节点RAC 的恢复记录

某客户的业务系统(15TB,3节点RAC) 由于abort关闭之后,导致数据库无法正常open. 在Open时报错如下:

但看上面的错误,或许有人以为这是回档有问题,或者以为是AIX操作系统有问题。 其实不然,why ?

我想问一下,实例恢复需要archivelog吗?

因此我们可以确认,数据库无法正常open的原因是ora-00600 [4097]错误在作祟。 关于这个错误,不想描述的太多。

网上也有很多文章,教你通过屏蔽回滚段来强制拉库。

但是这里,我想知道是,为什么会抛出这个错误。

我们来看Metalink 文档关于该错误的一个标准解释:

根据文档解释,产生该错误的原因是oracle在open时会去读取回滚段头中的事务表信息,以此来判断是否已经提交.
当发现某个事务(XID)的warp#比当前数据库的最大值都还要大时,将出现该错误。 下面我们来看下trace文件:

oracle internal错误如下:
ORA-00600: internal error code, arguments: [4097], [3909], [23], [121212]

从trace 内容下面的信息,可以判断出oracle在open的时候,是在对事务XID 0x0f45.017.0001d97c
进行操作时无法正常进行,进而抛出ora-00600 内部错误。

关于XID的结构如下:
XID= 0x0f45.017.0001d97c

0f45: 表示回滚段编号,转换为10进制后为3909
017:表示slot编号,转换为10进制后为23
0001d97c:表示wrap#号,转换为10进制后为121212

而从trace下面的内容可以看出,该事务操作的数据块是(5/2545616),即datafile 5,block 254516.

同时,在对数据库open之前,进行10046 trace跟踪时,从跟踪内容也可以确认,数据库在open时在
访问数据块file 5 block 2545616时出现异常,进而导致数据库无法打开,如下:

到这里,我们可以确认问题出在回滚段上。按理说这里应该存在活动事务,然而我并没有发现:

所以,只能说该数据库在被强制关闭时oracle并没有来得及去更新warp#,最终出现了这个情况。 当然解决方案比较简单,屏蔽掉回滚段即可。话说客户这里,我strings一下发现有超过10000个回滚段,哈哈~~~。 还好,顺利打开数据库,且从我们的分析来看,没有数据丢失.

3 Responses to “15 TB 3节点RAC 的恢复记录”

  1. liusx Says:

    是否需要重建UNDO表空间?

  2. oracledba Says:

    这里其实不需要,open之后,把问题回滚段drop即可。
    安全起见可以重建undo!

  3. 15 TB 3节点rac 恢复记录 - 数据库教程 - 开发者第2326342个问答 Says:

    […] 详见原本博客链接地址:15 TB 3节点RAC 的恢复记录 本条目发布于 2013 年 10 月 25 日。属于 数据库教程 分类。作者是 admin。 0 次浏览 document.getElementById("bdshell_js").src = "http://bdimg.share.baidu.com/static/js/shell_v2.js?cdnversion=" + Math.ceil(new Date()/3600000) […]

Leave a Reply

You must be logged in to post a comment.