RMAN-06054 While performing Duplicate

SYMPTOMS

RMAN duplicate fails with error

RMAN-06054 media recovery requesting unknown archived log for thread 1 with sequence XXXX and starting SCN of XXXXXX
RMAN-06054: media recovery requesting unknown archived log for thread string with sequence string and starting SCN of string Cause: Media recovery is requesting a log whose existence is not recorded in the recovery catalog or target database control file. Action: If a copy of the log is available, then add it to the recovery catalog and/or control file via a CATALOG command and then retry the RECOVER command. If not, then a point-in-time recovery up to the missing log is the only alternative and database can be opened using ALTER DATABASE OPEN RESETLOGS command.

CHANGES

CAUSE

Duplicate process takes the SCN (for until scn) from most recent backup control file checkpoint_change# and if the SCN of the control file

In the backup was higher than the SCN of the most recent archived log in backup, then RMAN recovery will be looking for archives to recover

The database as per UNTIL SCN condition and it fails.

Until 11.2.0.3, It was using Highest SCN of Archive log from the backup

Bug 21868720 - RMAN-06054 ON BACKUP BASED DUPLICATE"

SOLUTION

* Ensure the controlfile checkpoint SCN is less than last archivelog SCN in the backup.

* While taking backup for duplicate purpose, disable CONTROLFILE AUTOBACKUP and perform complete database backup, this will make sure controlfile is backed up in the middle of the backup.

Option 1

=======

Apply patch 21868720

Option 2

======

Workaround: Connect to catalog while doing duplicate.

Option 3

======

While doing backup, if we disable controlfile autobackup, the controlfile backup will not be taken after the archivelog backup. Thus the archivelog SCN will be higher than the controlfile SCN.

1. Turn off controlfile autobackup

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP OFF;

2. Perform database/archivelog backup

Run

{

Allocate channel a1 device type disk format '/<path>/<datafilename>/%U';

Allocate channel a2 device type disk format '/<path>/<datafilename>/%U';

Allocate channel a3 device type disk format '/<path>/<datafilename>/%U';

Allocate channel a4 device type disk format '/<path>/<datafilename>/%U';

Allocate channel a5 device type disk format '/<path>/<datafilename>/%U';

Allocate channel a6 device type disk format '/<path>/<datafilename>/%U';

Backup as compressed backupset database plus archivelog;

}

3. With the above backup, perform the duplicate.

Option 4

======

1. While performing duplicate, use a SET UNTIL clause. I.e., "SET UNTIL SCN" or "SET UNTIL SEQUENCE" explicitly. For example:

Rman auxiliary /

Run

{

Set until SCN 1234455;

Allocate auxiliary channel a1 device type disk;

Allocate auxiliary channel a2 device type disk;

Allocate auxiliary channel a3 device type disk;

Allocate auxiliary channel a4 device type disk;

DUPLICATE DATABASE TO dev1 BACKUP LOCATION '/<path>/<datafilename>/';

}

Option 5

=======

If we don't want to re-execute the duplicate command, complete the process manually using information in the following note:

Manual Completion of a Failed RMAN Duplicate (Note 360962.1)

NOTE: It may be required for you to manually make more archivelog files available to satisfy the until SCN condition.

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.