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

Posted by PDSERVICE on Mar 08, 2020 In

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

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;

You are here

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