如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:[email protected]
适用于:
Oracle Database – Enterprise Edition – 版本11.2.0.3及以上 症状 在恢复期间复制活跃数据库,生成以下错误: 更改 数据库被升级11.2.0.3。
原因 在复制活跃数据库期间,在数据文件被复制后,RMAN在创建一个内存脚本来编目(catalog)从源复制到辅助站点的所有归档日志文件,然后编目在由FRA(Fast Recovery Area)指定的磁盘组下的所有文件,然后切换所有数据文件。内存脚本Memory script的示例是: { 现在,如果磁盘组被用于大量数据库,且有不同名称,相同DBID的数据库在生成归档日志文件,那么RMAN编目可以有不同化身(incarnation)的归档日志文件。在归档日志文件被编目时,在辅助数据库的控制文件的化身可以改变,这保证数据库恢复可以完成,并完全复制活跃数据库。 在之前的版本中,RMAN仅试图编目在恢复区下的所有文件(“catalog clone recovery area”),但在11.2.0.3版本中,命令改为编目归档日志文件在辅助数据库中被配置的位置下的所有文件(“Catalog clone start with “+DISKGROUP”)。 这个问题:“为什么在同一个磁盘组中有相同DBID但不同数据库名的归档日志文件?”答案是:因为有一个数据库的现有活跃。即之前的尝试失败。之前运行的数据库被再次被克隆。解决方案 你有以下选择: 选择1: 要手动完成复制,步骤是: * 更改控制文件中的incarnation 。 详情参见: Manual Completion of a Failed RMAN Backup based Duplicate (Note 360962.1) 注 : 注意对重做日志文件指定不同位置的控制文件的重建,因为源数据库的重做日志文件可能会损坏。
选择2: 如果未设置log_archive_dest_1,更改FRA的位置,其指定一个没有相同BDID的数据库的磁盘组。 * db_recovery_file_dest的值必须是一个文件系统或仅为ASM 磁盘组名称。不要在磁盘组中指定目录。这么做会导致错误且数据库被mount。 选择3:如果指定了 log_archive_dest_1,确保在该位置没有相同DBID的数据库的文件。在这里,FRA能被设为一个其他数据库存在的磁盘组。 例如: * 在辅助数据库的参数文件中: *.db_recovery_file_dest=’+RECOC4′ 当RMAN 复制数据库时,内存脚本会显示要编目的归档日志文件。例如: Memory Script的内容: 选择 4: 更改与源数据库有相同dbid的数据库的dbid。NID 工具可用于更改数据库的DBID。 注: 在NID工具执行之前,对数据库(数据文件和归档日志文件)进行完整备份是很重要的。确保在备份后归档日志文件被删除,因为NID工具不更改现有归档日志文件的dbid。 |
Leave a Reply