Re: point in time restore of PDB fails with RMAN-06023

  • From: Mladen Gogala <gogala.mladen@xxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Sat, 23 May 2020 17:33:16 -0400

Rman is chock full of PDB related bugs. This seems to be one of them. Please open SR with Oracle and keep us informed.

Regards

On 5/23/20 4:44 PM, anthony Sanchez wrote:

Hello Folks,

Oracle 18.8 - Exadata Cloud@Customer

I am trying to do a point in time restore and recovery of a PDB.

The PDB was created on 4/26.
I have all backups up until that point and incarnation did not change.
I am trying to restore to 4/29.
Between 4/29 and now many data files have been added to the PDB.

At restore time, RMAN is trying to restore files that did not exist on 4/29, resulting in RMAN-06023.

What are my options here?  I don't want to restore and mount an older version of the controlfile, impacting all of my PDBs, and i would prefer not to have to duplicate the entire CDB to be able to do my restore of a single PDB.   It seems to me that this should be a supported (and common) scenario from an RMAN and PDB perspective, but maybe I'm just not understanding something here.  I'm a pretty big fan of multi tenant, but this seems like a major limitation.



Version 18.8.0.0.0
[oracle@cc01201vm02 ~]$ rman target /
Recovery Manager: Release 18.0.0.0.0 - Production on Wed May 13 16:45:34 2020
Version 18.8.0.0.0
Copyright (c) 1982, 2018, Oracle and/or its affiliates. All rights reserved.
connected to target database: UTILCDB2 (DBID=235128710)
RMAN> run {
SET UNTIL TIME "TO_DATE('29-APR-2020 11:00:00','DD-MON-YYYY HH24:MI:SS')";
restore pluggable database osfutestha;
recover pluggable database osfutestha;
}2> 3> 4> 5>
executing command: SET until clause
Starting restore at 13-MAY-20
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=225 instance=UTILCDB21 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=1176 instance=UTILCDB21 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 05/13/2020 16:46:13
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 569 found to restore
RMAN-06023: no backup or copy of datafile 568 found to restore
RMAN-06023: no backup or copy of datafile 567 found to restore
RMAN-06023: no backup or copy of datafile 565 found to restore
RMAN-06023: no backup or copy of datafile 563 found to restore
RMAN-06023: no backup or copy of datafile 560 found to restore
RMAN-06023: no backup or copy of datafile 557 found to restore
RMAN-06023: no backup or copy of datafile 555 found to restore
RMAN-06023: no backup or copy of datafile 553 found to restore
RMAN-06023: no backup or copy of datafile 551 found to restore
RMAN-06023: no backup or copy of datafile 549 found to restore
RMAN-06023: no backup or copy of datafile 546 found to restore
RMAN-06023: no backup or copy of datafile 540 found to restore
RMAN-06023: no backup or copy of datafile 536 found to restore
RMAN-06023: no backup or copy of datafile 534 found to restore
RMAN-06023: no backup or copy of datafile 527 found to restore
RMAN-06023: no backup or copy of datafile 525 found to restore
RMAN-06023: no backup or copy of datafile 523 found to restore
RMAN-06023: no backup or copy of datafile 521 found to restore
RMAN-06023: no backup or copy of datafile 514 found to restore
RMAN-06023: no backup or copy of datafile 513 found to restore
RMAN-06023: no backup or copy of datafile 510 found to restore
RMAN-06023: no backup or copy of datafile 509 found to restore
RMAN-06023: no backup or copy of datafile 508 found to restore
RMAN-06023: no backup or copy of datafile 506 found to restore
RMAN-06023: no backup or copy of datafile 505 found to restore
        


per my open SR and some debug traces.

The point in time set:
SET UNTIL TIME "TO_DATE('29-APR-2020 11:00:00','DD-MON-YYYY HH24:MI:SS')";

Translated to:
DBGRCV: Until time: TO_DATE('29-APR-2020 11:00:00','DD-MON-YYYY HH24:MI:SS'), toscn: 0 (krmkicat)

DBGSQL: TARGET> select TO_DATE('29-APR-2020 11:00:00','DD-MON-YYYY HH24:MI:SS') from sys.dual
DBGSQL: sqlcode = 0
DBGSQL: D :mydate = "29-APR-2020 110000"

DBGSQL: TARGET> begin dbms_rcvman.setAllIncarnations(TRUE); end;
DBGSQL: sqlcode = 0
DBGRCVMAN: allIncarnations is set to TRUE

DBGSQL: TARGET> declare tmpscn number; begin dbms_rcvman.setUntilTime(:date); tmpscn := dbms_rcvman.getUntilScn; if (:toscn > 0) then dbms_rcvman.setUntilScn(tmpscn + 1); end if; :untscn := tmpscn; end;
DBGSQL: sqlcode = 0
DBGSQL: B :toscn = NULL
DBGSQL: B :untscn = 11944075292177
DBGSQL: B :date = "29-APR-2020 110000"
DBGRCVMAN: ENTERING setUntilTime
DBGRCVMAN: EXITING setUntilTime untilSCN=11944075292177
DBGANY: Current untilscn: 11944075292177 [13:32:08.678] (krmkicat)
DBGRCV: EXITED krmkicat

There are a few datafiles that are in the restore list that were created after the point in time/SCN.

DBGRCVMAN: dfNumber=575 creationSCN=11945330321543 pluginSCN=0 foreignDbid= pluggedRonly=0
DBGRCVMAN: dfNumber=575 creationSCN=11945330321543 pluginSCN=0 foreignDbid= pluggedRonly=0
DBGRCVMAN: dfNumber=576 creationSCN=11945330393270 pluginSCN=0 foreignDbid= pluggedRonly=0
DBGRCVMAN: dfNumber=576 creationSCN=11945330393270 pluginSCN=0 foreignDbid= pluggedRonly=0
DBGRCVMAN: dfNumber=577 creationSCN=11945381134908 pluginSCN=0 foreignDbid= pluggedRonly=0
DBGRCVMAN: dfNumber=577 creationSCN=11945381134908 pluginSCN=0 foreignDbid= pluggedRonly=0
DBGRCVMAN: dfNumber=578 creationSCN=11945381134935 pluginSCN=0 foreignDbid= pluggedRonly=0
DBGRCVMAN: dfNumber=578 creationSCN=11945381134935 pluginSCN=0 foreignDbid= pluggedRonly=0

That means there is not a recoverable copy of the database using the controlfile used to the point in time. You will have to restore a controlfile from before these datafiles so they are not part of the controlfile when the restore is done and recovery actions calculated by RMAN.

Thanks,
Anthony Sanchez

--
Mladen Gogala
Database Consultant
Tel: (347) 321-1217

Other related posts: