Oracle GoldenGate数据初始化ORA-00600解决方法

日期： 2011-03-16 作者：人在旅途 来源：TechTarget中国

在实施容灾项目Goldengate数据初始化时遇到一个问题，首先交代一下环境： 　　源端： 　　Redhat 5.1+Oracle10.2.0.4 RAC 　　存储方式：ASM 　　目标端： 　　Redhat 5.4+Oracle10.2.0.4 　　存储方式：文件系统 　　在用rman进行数据文件从ASM转换到FS时报错： alter database rename file ‘+ODSGRP1/dcods/onlinelog/group_1.271.729900793’ to ‘/odsdb/o……

我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。

我原创，你原创，我们的内容世界才会更加精彩！

【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论，本站保留删除与本文无关和不雅评论的权力。

在实施容灾项目Goldengate数据初始化时遇到一个问题，首先交代一下环境：

　　源端：

　　Redhat 5.1+Oracle10.2.0.4 RAC

　　存储方式：ASM

　　目标端：

　　Redhat 5.4+Oracle10.2.0.4

　　存储方式：文件系统

　　在用rman进行数据文件从ASM转换到FS时报错：

alter database rename file '+ODSGRP1/dcods/onlinelog/group_1.271.729900793' to '/odsdb/oradata/dcods/log01.dbf';
alter database rename file '+ODSGRP1/dcods/onlinelog/group_2.272.729900793' to '/odsdb/oradata/dcods/log02.dbf';
alter database rename file '+ODSGRP1/dcods/onlinelog/group_5.273.729900795' to '/odsdb/oradata/dcods/log03.dbf';
alter database rename file '+ODSGRP1/dcods/onlinelog/group_7.274.729900797' to '/odsdb/oradata/dcods/log04.dbf';
alter database rename file '+ODSGRP1/dcods/onlinelog/group_9.275.729900799' to '/odsdb/oradata/dcods/log05.dbf';
alter database rename file '+ODSGRP1/dcods/onlinelog/group_10.276.729900799' to '/odsdb/oradata/dcods/log06.dbf';
alter database rename file '+ODSGRP1/dcods/onlinelog/group_3.283.729901743' to '/odsdb/oradata/dcods/log07.dbf';
alter database rename file '+ODSGRP1/dcods/onlinelog/group_4.284.729901745' to '/odsdb/oradata/dcods/log08.dbf';
alter database rename file '+ODSGRP1/dcods/onlinelog/group_6.285.729901745' to '/odsdb/oradata/dcods/log09.dbf';
alter database rename file '+ODSGRP1/dcods/onlinelog/group_8.286.729901747' to '/odsdb/oradata/dcods/log10.dbf';
alter database rename file '+ODSGRP1/dcods/onlinelog/log11.ora' to '/odsdb/oradata/dcods/log11.dbf';
alter database rename file '+ODSGRP1/dcods/onlinelog/log12.ora' to '/odsdb/oradata/dcods/log12.dbf';
-----------------------------------tempfile
alter database rename file '+ODSGRP1/dcods/tempfile/temp.280.729900873' to '/odsdb/oradata/dcods/temp.dbf';
alter database rename file '+ODSGRP1/dcods/tempfile/odstmp.dbf' to '/odsdb/oradata/dcods/odstemp.dbf';
alter database rename file '+ODSGRP1/dcods/tempfile/dsstmp.dbf' to '/odsdb/oradata/dcods/dsstemp.dbf';

sql statement: ALTER DATABASE RENAME FILE '+ODSGRP1/dcods/onlinelog/group_1.271.729900793' TO '/odsdb/oradata/dcods/log01.dbf'
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of sql command on default channel at 03/06/2009 10:48:55
RMAN-20000: abnormal termination of job step
RMAN-11003: failure during parse/execution of SQL statement: ALTER DATABASE RENAME FILE '+ODSGRP1/dcods/onlinelog/group_1.271.729900793' TO '/odsdb/oradata/dcods/log01.dbf'
RMAN-11001: Oracle Error: 
ORA-00600: internal error code, arguments: [kgeade_is_0], [], [], [], [], [], [], []

　　经过查询metalink发现：

　　ORA-00600 [KGEADE_IS_0] When Renaming A File From ASM TO FS

　　Doc ID: 742289.

　　1 )The solution is to apply patch 7207932, if available for your platform. I requested a port to 32bit Linux from

　　support, which has been released today after only 3 days of waiting.

　　One workaround to the problem when opening the database resetlogs is to create the controlfile, do a "fake" point in time

　　recovery and to open the database resetlogs. The trick is to rename all the references to ASM.

　　- SQL> alter database backup controlfile to trace;

　　- edit the file in user_dump_dest, make sure your references to ASM are modified; you needto use the#2

　　NORESETLOGS case

　　- shutdown immediate

　　- startup nomount

　　- create controlfile ...

　　- recover database until cancel using backup controlfile

　　- cancel

　　- alter database open resetlogs

　　- add temp filesThis reliably worked for me today even though Oracle support said that there was no workaround except

　　for the application of the patch.

　　It's bug 7207932, fixed in 11g. And a patch for this bug is available, a workaround would be a manual recreation of the controlfile.

　　解决方法：

　　在容灾端打补丁7207932

　　$ cd $ORACLE_HOME/OPatch

　　$ opatch -help

　　Invoking OPatch 10.2.0.4.2

　　在终端窗口中，执行cd命令移动到7207932子目录中，执行以下命令：

　　$ $ORACLE_HOME/OPatch/opatch apply

　　对inventory列表，确认安装操作：

　　$ $ORACLE_HOME/OPatch/opatch lsinventory

　　执行卸载命令时，也必须使7207932子目录成为当前目录。其中，Rollback命令需要两个参数：-id给出

　　个别补丁号;-ph 给出个别补丁解压缩后的路径。

　　$ $ORACLE_HOME/OPatch/opatch rollback -id 7207932-ph /…/7207932

　　随后再对inventory列表，则会看到这一个别补丁已经被移去。

　　* 使用opatch显示已安装的版本信息

　　不需要启动数据库，执行加选项的对inventory的列表命令，可以得到已安装的软件的各个组件的详细版

　　本信息。

　　$ $ORACLE_HOME/OPatch/opatch lsinventory -detail

　　在安装时，首先下载压缩文件p7207932_10204_Linux-x86-64.zip，解压缩到与其它个别补丁相同的目录下。检

　　查其发行说明时，发现要求opatch版本比现已安装版本要高，下载安装指定版本opatch.进入子目录5225797

　　(这是此安全补丁的补丁号)，执行apply命令。

　　$ $ORACLE_HOME/OPatch/opatch apply

　　打开此次安装生成的日志文件，其中没有错误信息出现。执行inventory列表命令确认安装：

　　$ $ORACLE_HOME/opatch lsinventory

　　再次执行rename命令，执行成功，ASM成功转换成FS格式。

作者

人在旅途
人在旅途

相关推荐