Re: rman duplicate with no target connection fails with RMAN-06024: no backup or copy of the control file found to restore after resetlogs

  • From: Leng <lkaing@xxxxxxxxx>
  • To: ilsuonogiallo@xxxxxxxxx
  • Date: Wed, 18 Dec 2019 03:43:44 +1100

Hi Andrea,

The fact that you said ‘ DUPLICATE fails as long as I am not connected to the 
target database‘ leads me to think that you need to ‘set dbid’ for a targetless 
duplicate. Or did I miss that somewhere in your output?

Secondly try a restore preview vs targetless duplicate with the same scn. The 
duplicate script generates an scn from your time. 

Run {
Set until scn x;
Restore controlfile preview;
}

Finally turn ‘debug on’ to see what it’s doing behind the scene for a target vs 
targetless duplicate.

Cheers,
Leng

On 16 Dec 2019, at 7:56 pm, Andrea Monti <ilsuonogiallo@xxxxxxxxx> wrote:


Hi,
I double-checked following documents:


Bug 14215868 : BACKUP DATABASE PLUS ARCHIVELOG WITH AUTOBACKUP IS NOT 
SUFFICIENT TO DUPLICATE
RMAN duplicate errors with RMAN-6026 RMAN-6024 no backup of controlfile (Doc 
ID 1348071.1)
Bug 14054568 - RMAN DUPLICATE fails with RMAN-6054 (Doc ID 14054568.8)
Perform Backup Based RMAN DUPLICATE Without Connecting To Target Database For 
Both Disk & Tape Backups (Doc ID 1375864.1)
RMAN 11GR2 : DUPLICATE Without Target And Recovery Catalog Connection (Doc ID 
874352.1)

but none apply. The problem comes up only when duplicating from backups a db 
with several incarnations without connecting to target. The same strategy 
works fine if I connect to the target (source) database or if the target 
(source) database only has 1 incarnation
Regards,
Andrea


Il giorno ven 13 dic 2019 alle ore 22:56 sallianz11 . <sallianz11@xxxxxxxxx> 
ha scritto:
Andrea, 

you might be hitting the issue reported in the below ML Note if your ctl 
file backup is newer than the arch backups.

===

RMAN duplicate errors with RMAN-6026 RMAN-6024 no backup of controlfile (Doc 
ID 1348071.1)

CAUSE

RMAN will be using the SCN of the highest backed up archived redolog and 
will try to find a backup of the controlfile before that.  This is not 
succeeding for the backup of the controlfile as the backup of the
controlfile is newer than the last archivebackup, so cannot be used.

SOLUTION

You can resolve this by making another archivelog backup of the target 
database.

RMAN> backup archivelog all;

and than restart the duplicate afterwards, then the database duplicated 
successfully.

 

Another option (if backups are on disk) would be to use targetless duplicate 
with 'backup_location' option and NO until clause specified with the rman 
duplicate command.


On Fri, Dec 13, 2019 at 3:31 PM Andrea Monti <ilsuonogiallo@xxxxxxxxx> 
wrote:
Hi Tim,
That would be nice but some circumstances we are forced to use backup - 
based duplication (may be because we have to restore to a quite old point 
in time, or because we must restore to different network,or because we want 
to apply the same strategy to some 11.2 DBs... ), thus we cannot always 
rely on PFBs hot clones

Regards, 
Andrea



Il ven 13 dic 2019, 17:47 Tim Hall <tim@xxxxxxxxxxxxxxx> ha scritto:
Sorry to answer a question with a question, but why would you use an RMAN 
duplicate if you were working with Multitenant?

We use lone-PDB for everything we can, or 3 PDBs on 19c. :) On those where 
we have PDBs I never run an RMAN duplicate. I try to act like the CDB 
doesn't exist. :) All clones are done using PDB clones. I see for the 
banner you are on 12.2, so you can do hot clones, which are awesome. I've 
just never felt the need to clone the CDB since I switched. It also means 
renames are easy. :)

https://oracle-base.com/articles/12c/multitenant-hot-clone-remote-pdb-or-non-cdb-12cr2
 

Cheers

Tim...

Other related posts: