Directly after my DOAG (German Oracle User Group) Conference presentation about “How Single-/Multitenant will change a DBA’s life” Martin Bach (Enkitec) approached me and told me about his experiences with the DROP PLUGGABLE DATABASE command and future recoverability.
Martin discovered that once you issued the DROP PLUGGABLE DATABASE command you can’t reuse a previously taken backup of this particular PDB anymore and recover the PDB into this existing CDB. I wasn’t aware of this and I’m glad that Martin told me about it.
See also my blog post from Jun 9, 2015:
This is the error message you’ll see when you try to recover a dropped pluggable database:
RMAN> restore pluggable database pdb2drop; Starting restore at 01-JUN-15 using channel ORA_DISK_1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 06/01/2015 10:10:40 RMAN-06813: could not translate pluggable database pdb2drop
Just a few weeks ago a colleague from German presales asked me if I know a more convenient way to restore a PDB once the magic command (DROP PLUGGABLE DATABASE) has been issued than recovering it into an auxiliary container database and unbplug/plug it. I haven’t.
But Nik (thanks!!!) told me that he pushed a MOS Note to being published explaining how to workaround this issue:
MOS Note: 2034953.1
How to Restore Dropped PDB in Multitenant
In brief this MOS Note describes how to:
- Create an auxiliary container database
- Recover the backup (yes, you will have to have a backup of your container database) including this particular PDB
- Unplug the PDB after recovery has been finished and plug it back into the original CDB
Now some will say: Hey, that’s simple and obvious. For me it wasn’t 😉 That’s why I write about it to remind myself of this workaround …
–Mike
Hey Mike,
it is even more clumsy.
You may want to check out our Twitter discussion about this from last year.
https://twitter.com/FranckPachot/status/671340731638923264
Regards
Stefan
Stefan,
as always thanks for the addition 😉
Cheers
Mike
Hi Mike
Seems that note 2034953.1 is no more available.
Does it mean that using an auxiliary container for recovering a pdb is no more relevant ?
Regards
Thanks – it is UNDER EDIT and currently not visible to the public. It got reviewed today but I’m not familiar with the publishing policies of support (and why it has been not visible for over a month now). Sorry for the inconvenience …
If you need it please open an SR and ask Support to either send you the content or explain it to you.
The note still exists …
Cheers
Mike
Hi mike,
There are patches built to overcome this situation.But I could not succeed so far using them on one of the TEST envs.Could you please check?
Thanks
satya
Satya,
do you mean the patch for bug19809171?
I see their availability on top of the July and the April BPs.
What is your result?
Cheers
Mike
I know that this blog entry is quite old but when one googles how to restore a dropped PDB it still comes up as one of the top links, together with the MOS Note you linked. I’m sure you know that with 19c we have a much more comfortable way to simply recover the PDB with rman, it work’s quite similar to how a recover table works. Oracle will create the auxiliary database itself, restore the PDB into the aux db, unplug the PDB and plug it into the ORACLE_SID=CDB with just one command:
rman target /
recover pluggable database until SCN|to_date”…..” ;
That’s it, a few minutes later your PDB is back online, resetlogs included.
I mention this because after reading this article and the MOS note I was ready to do it manually, luckily I found this command in the oracle docs. Maybe it’s time to update the blog to prevent other poor souls from too much work?
Thanks Raphael,
if you’d kindly share the blog link with me I’ll happily add it to the blog post.
Thanks,
Mike