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

当使用 RMAN 尝试将数据库复制到特定的日志序列时，如果提供的序列号未在 V$LOG_HISTORY 或 RC_LOG_HISTORY 中记录，RMAN 会错误地选择最新的归档日志序列号。此行为会导致数据库被复制到不正确的 SCN，解决方法是在 11.2.0.2 版本中修复了这一问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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.