我最近将 oracle 从版本更新11.2.0.1
到11.2.0.4
,我的冗余系统不再能够从故障转移中恢复。
我在主节点和备用节点上都使用脚本来恢复到可以将它们再次安装为冗余系统的状态。
执行故障转移后,可以在所有状态下一遍又一遍地运行重置脚本。唯一的变化是升级到11.2.0.4.
它就像一个魅力11.2.0.1
我正在使用 Data Guard Broker 来维护冗余。
设置过程很复杂,在这里很难解释,所以我只是想问问是否有人遇到过同样的错误,并且可能有解决方案如何从这种情况中恢复。
至少,这是失败的输出:(备份步骤在重复操作之前执行)
2014-11-14 17:08:55 : Recovery Manager: Release 11.2.0.4.0 - Production on Fri Nov 14 17:08:48 2014
2014-11-14 17:08:55 : Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
2014-11-14 17:08:55 : connected to target database: REF15 (DBID=276671931)
2014-11-14 17:08:55 : RMAN> CONNECT AUXILIARY *
2014-11-14 17:08:55 : 2> RUN {
2014-11-14 17:08:55 : 3> SET UNTIL sequence = 159 thread = 1;
2014-11-14 17:08:55 : 4> ALLOCATE AUXILIARY CHANNEL CH1 TYPE DISK;
2014-11-14 17:08:55 : 5> DUPLICATE TARGET DATABASE FOR STANDBY NOFILENAMECHECK DORECOVER;
2014-11-14 17:08:56 : 6> RELEASE CHANNEL CH1;
2014-11-14 17:08:56 : 7> }
2014-11-14 17:08:56 : 8> exit;
2014-11-14 17:08:56 : connected to auxiliary database: REF15 (not mounted)
2014-11-14 17:08:56 : executing command: SET until clause
2014-11-14 17:08:56 : using target database control file instead of recovery catalog
2014-11-14 17:08:56 : allocated channel: CH1
2014-11-14 17:08:56 : channel CH1: SID=25 device type=DISK
2014-11-14 17:08:56 : Starting Duplicate Db at 14-NOV-14
2014-11-14 17:08:56 : released channel: CH1
2014-11-14 17:08:56 : RMAN-00571: ===========================================================
2014-11-14 17:08:56 : RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
2014-11-14 17:08:56 : RMAN-00571: ===========================================================
2014-11-14 17:08:56 : RMAN-03002: failure of Duplicate Db command at 11/14/2014 17:08:51
2014-11-14 17:08:56 : RMAN-05501: aborting duplication of target database
2014-11-14 17:08:56 : RMAN-20206: log sequence not found in the repository
2014-11-14 17:08:56 : Recovery Manager complete.
更新:从以下查询中获取日志序列号(在本例中为:159):
从 v$archived_log 中选择 max(sequence#);
谢谢(最初发布于 std Stack Exchange)
该消息表明在当前版本中不存在具有此序列的归档日志。
故障转移开始新的化身,日志序列再次从 1 开始。假设您的数据库现在的序列号为 10,而故障转移前的日志序列号为 159。此时 V$ARCHIVED_LOG 仍包含有关先前化身的条目,因此上述查询将返回 159,因为它不考虑新化身的开始(重置日志)。
对于此类查询,请始终检查 resetlogs_change# 或 resetlogs_time,例如:
修复此问题并再次尝试复制。或者只是跳过 UNTIL 子句,让日志传送处理归档日志。