Continue the Duplicate after RMAN-06054: media recovery requesting unknown archived log

 Problem:

During the execution of Duplicate RMAN command to create a new 19c database from an RMAN backup, the duplicate processes terminated with RMAN-06054 before the completion of the duplicate process:

Analysis:

The backup I was restoring from was missing some critical archivelogs to bring all datafiles in a consistent state. Luckily, the datafile which was inconsistent belonged to goldengate tablespace which I don't need it in the new database.

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 68 needs more recovery to be consistent
ORA-01110: data file 68: '+DATA/SPP/DATAFILE/ggtbs.339.1098850765'

Solution:

1- Backup the current controlfile [In case things may go wrong, and you want to restore it back]

SQL> ALTER DATABASE BACKUP CONTROLFILE TO '/home/oracle/controlfile.bkp';

2- Generate the controlfile script with the RESETLOGS option:

-- Generate the controlfile script:

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS '/home/oracle/controlfile.trc' RESETLOGS;

-- Edit the controlfile trace script adding "SET" keyword: [If you will change the database name, make sure to modify the parameter db_name in the SPFILE to the same as well]

CREATE CONTROLFILE REUSE SET DATABASE "SPP" RESETLOGS
...

CHARACTER SET AL32UTF8
;
 

Delete the rest of lines after CHARACTER SET XXX ;

3- Shutdown the database and recreate the controlfile using the edited trace script:

SQL> shu abort
SQL> @/home/oracle/controlfile.trc

4- Set the inconsistent datafile in OFFLINE mode:

SQL> alter database datafile '+DATA/SPP/DATAFILE/ggtbs.339.1098850765' offline;

5- Open the database with RESETLOGS mode:

 SQL> ALTER DATABASE OPEN RESETLOGS;

6- Add TEMP FILES to the TEMPORARY TABLESPACE:

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE;

Note: Setting parameter "_allow_resetlogs_corruption"=TRUE scope=spfile; may be an option here if you cannot set the datafiles in OFFLINE mode for any reason, but first you need to consult Oracle support before doing so; as the database will not be in a consistent state and most probably you will hit ora-00600 errors frequently!