1

I've recently updated oracle from version 11.2.0.1 to 11.2.0.4 and my redundant system is no longer able to recover from failover.

I'm using scripts both on primary and standby node to get back to a state where it is possible to install them as a redundant system again.

It is possible to run the reset script over and over again in all states exept after a failover is performed. The only change is the upgrade to 11.2.0.4. it worked like a charm in 11.2.0.1

I am using Data Guard Broker to maintan the redundancy.

The setup procedure is complicated and is hard to explain here, so I am just asking if someone have faced the same error, and might have a solution how to recover from such situation.

At least, this is the output where it fails: (Backup step is performed prior to duplicate action)

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.

Update: Log sequence number (in this case: 159) is fetched from the following query:

    select max(sequence#) from v$archived_log;

Thanks (originally posted in std Stack Exchange)

1

The message indicates that no archivelog exists with this sequence in the current incarnation.

Failover starts a new incarnation, and log sequences start from 1 again. Let's say your database is at sequence 10 now, and the log sequence was 159 before the failover. V$ARCHIVED_LOG at this point still contains entries about previous incarnation, so the above query will return 159 because it doesn't consider the start of a new incarnation (resetlogs).

For these kind of queries always check resetlogs_change# or resetlogs_time, e.g:

select max(sequence#) from v$archived_log join v$database using (resetlogs_change#);

Fix this and try duplicating again. Or just skip the UNTIL clause and let log shipping take care of the archivelogs.

| improve this answer | |
  • Thanks. It solved my issue. I extended my query to include the Join, and now it selects a better sequence number! – Magnus Dec 2 '14 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.