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;

DBRECOVER Recovery Options

For Oracle incidents, start with the DBRECOVER for Oracle trial to verify table visibility, row previews, and export readiness on copied datafiles. For MySQL and InnoDB incidents, DBRECOVER for MySQL is free software and can inspect.ibd files, ibdata1, and database directories locally.

When the case is urgent, preserve the original files first, work from copies, and contact paid emergency support with the database version, platform, error messages, file list, and recovery objective.