Email: service@parnassusdata.com 7 x 24 online support!

    You are here

    • You are here:
    • Home > Blogs > PDSERVICE's blog > RMAN recover database fails RMAN-6025 - v$archived_log.next_change# is 281474976710655

RMAN recover database fails RMAN-6025 - v$archived_log.next_change# is 281474976710655

RMAN recover database fails RMAN-6025 - v$archived_log.next_change# is 281474976710655

SYMPTOMS
RMAN database recover failing with the following errors:
 
RMAN-06025: no backup of archived log for thread number with sequence number and starting SCN of string found to restore
Cause: An archived log restore restore could not proceed because no backup of the indicated archived log was found. It may be the case that a backup of this file exists but does not satisfy the criteria specified in the user's restore operands.
Action: None - this is an informational message. See message 6026 for further details.
 
 
 
 
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/17/2010 10:22:51
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 2668 lowscn 1079975830 found to restore
 
The archivelog being requested is very old compared to current log sequence.
Inspection of V$ARCHIVED_LOG shows:
 
CREATOR REGISTR  SEQ# FIRST_CHANGE# NEXT_CHANGE#        NAME
------- ------- -------------------- -------------------- -------------------- --------------------
RMAN     RMAN     2668     1079861514      281474976710655   /<path>/onlinelog/group_3.4508.718549667
To confirm if you have hit the same problem run this query against the controlfile :
 
SQL> select thread#, sequence#, creator, registrar, archived,
     to_char(first_change#), to_char(next_change#), name
     from v$archived_log
     where archived='NO';
 If you are using a catalog and the above query returns no rows then check the catalog:
 
 
SQL>select * from rc_database;
== note the dbinc_key of your target
 
SQL> select thread#, sequence#, creator, archived,
     to_char(first_change#), to_char(next_change#), name
     from rc_archived_log
     where archived='NO' and dbinc_key=<your dbinc_key>;
CAUSE
V$ARCHIVED_LOG or RC_ARCHIVED_LOG contains entries for online redo log files.
Online redo logs are temporarily cataloged by RMAN as 'archived logs' during
FULL media recovery; they are removed from the AL table when media
recovery completes successfully. One of the online redo logs will be 'current'
at the time so the SCN range for this log when cataloged will be low_SCN to 281474976710655 (FFFFFFFFFFFF(hex)).  When media recovery completes, these online entries in v$archived_log/rc_archived_log are deleted automatically by RMAN.  If media recovery fails and recovery is completed via SQLPlus, these entries in AL table are not removed.
 
During any subsequent recovery exercise, if the start SCN for recovery is
greater than the low_SCN of any of the cataloged online redo logs, the one with
an infinite next_SCN value will always be chosen as it will always fall within
the SCN range calculated for recovery - but this 'archived log' does not really exist so RMAN fails.
 
SOLUTION
There is no simple solution if a catalog database is not used 
 
Register the target in a catalog first and then proceed as shown below.
 
Take a backup of the recovery catalog BEFORE deleting the following rows:
 
SQL> select * from rc_database;
== Note the dbinc_key for your target database
 
SQL> delete from al
     where dbinc_key = <dbinc_key>
     and archived = 'N';
SQL> commit;