RMAN DUPLICATE SELECTS WRONG SCN IF SET UNTIL SEQUENCE, WORKS FINE IF SET UNTIL SCN [ID 1076816.1]

RMAN DUPLICATE SELECTS WRONG SCN IF SET UNTIL SEQUENCE, WORKS FINE IF SET UNTIL SCN [ID 1076816.1]
		Modified 03-MAY-2010     Type PROBLEM     Status MODERATED

In this Document
  Symptoms
  Changes
  Cause
  Solution
  References

---

 

 

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.

 

 

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.2.0.1 - Release: 10.2 to 11.2
Information in this document applies to any platform.
Oracle Database: RMAN

Symptoms

Assume the current log sequence is 400 in production database, and the requirement is to DUPLICATE "upto" sequence 6, which is available in older backups not known to controlfile or recovery catalog. Hence we 'catalog' the backup pieces 'upto' sequence 6. Needless to say,  we provide SET UNTIL SEQUENCE 7 in DUPLICATE script :

run {
SET UNTIL SEQUENCE 7 ;
DUPLICATE TARGET DATABASE TO.......
}

While finding the corresponding SCN (FIRST_CHANGE# of 7), it fails because Sequence 7 is not cataloged as it is not required for recovery (upto sequence 6).

Moreover, when it fails to find the SCN (i.e. FIRST_CHANGE#) of sequence 7, instead of aborting the DUPLICATE further, it does a kind of 'exception handling' and finds the SCN of maximum archivelog sequence available, which is wrong in the sense because the purpose is to DUPLICATE upto sequence 6.

Here's the extract of rman debug trace:

DBGSQL: EXEC SQL AT RCVCAT begin dbms_rcvman . setUntilLog ( :untilseq , :untilthread ) ; :untscn := dbms_rcvman . getUntilScn ; end ; [10:53:42.231]
DBGSQL: sqlcode=-20206 [10:53:42.234]
>
DBGSQL: EXEC SQL AT TARGET select decode(LOG_MODE,'ARCHIVELOG',1,0) into :b1 from V$DATABASE [10:53:42.235]
DBGSQL: sqlcode=0 [10:53:42.237]
DBGSQL: :b1 = 1

DBGSQL: EXEC SQL AT TARGET select min(maxnc) ,min(maxnc) into :b1,:b2 from (select max(a.NEXT_CHANGE#) maxnc from v$archived_log a ,v$thread t ,v$database d where ((((a.THREAD#=t.THREAD# and a.ARCHIVED='YES') and t.ENABLED<>'DISABLED') and a.resetlogs_change#=d.resetlogs_change#) and a.resetlogs_time=d.resetlogs_time) group by a.THREAD#) [10:53:42.240]
DBGSQL: sqlcode=0 [10:53:42.259]
DBGSQL: :b1 = 20800590 <<=================================== wrong SCN calculated
DBGSQL: :b2 = "20800590"
DBGMISC: Until SCN was set by krmkgscn to be=20800590 [10:53:42.261]

Changes

The old backups have been cataloged in RMAN.

Cause

This is due to Bug 8554110 .

RMAN looks for the corresponding SCN of archivelog in V$LOG_HISTORY (or RC_LOG_HISTORY in case recovery catalog is used). The problem is that V$LOG_HISTORY does not have an entry for the archivelog sequence. While doing SET UNTIL SEQUENCE  <n>, If RMAN is not able to find sequence <n-1> in V$LOG_HISTORY or RC_LOG_HISTORY, it selects the maximum SCN number (NEXT_CHANGE#) of latest archivelog in v$archived_log for the current incarnation.

This 'failover' kind of behavior is identified as bug in Bug 8554110 . The fix is to fail the RMAN DUPLICATE with following error:

RMAN-20206: log sequence not found in the repository

Solution

+ Bug 8554110 is fixed in 11.2.0.2 patchset.

Workaround
=========

Make sure the archive log sequence is known to rman in
V$LOG_HISTORY or RC_LOG_HISTORY (in case recovery catalog is used) before doing duplicate, or use until scn directly.

References

NOTE:1075885.1 - NO TARGET DUPLICATE TO LOG SEQUENCE AFTER LAST ARCHIVELOG FAILS WITH RMAN-20208

Related Products Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition Keywords V$LOG_HISTORY; V$ARCHIVED_LOG; DBMS_RCVMAN; SCN; RECOVERY CATALOG Errors RMAN-20206