在实施容灾项目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微信公众号二维码](/wp-content/uploads/res/images/spriteimg/ttweixin.jpg)
TechTarget
官方微博
![TechTarget中国官方微博二维码](/wp-content/uploads/res/images/spriteimg/ttweibo.jpg)
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格式。
作者
相关推荐
-
甲骨文自治数据库亮相 带来云计算新希望
早前甲骨文还不在云计算公司之列,而现在该公司正在迅速弥补其失去的时间。甲骨文的云计算核心是甲骨文自治数据库(O […]
-
2017年12月数据库流行度排行榜 定格岁末排名瞬间
数据库知识网站DB-engines最近更新的2017年12月份数据库流行度排名情况是否能提供更多的看点呢?TechTarget数据库网站将与您分享12月份的榜单排名情况,让我们拭目以待。
-
2017年11月数据库流行度排行榜 半数以上数据库积分减少
数据库知识网站DB-engines更新了2016年11月份的数据库流行度排行榜。TechTarget数据库网站将与您一同关注11月份的榜单排名情况。
-
DBA必须掌握的数据库恢复管理技术
如果没有备份副本,数据库管理员就无法还原数据库,所以DBA在恢复之前倾向于考虑备份是合乎逻辑的。 但是,对我来说,这种逻辑一直是错误的。