Recent News about Pluggable Databases – Oracle Multitenant

Three recent lessons about PDBs in the Oracle Single/Multitenant space you should be aware of.

And thanks to my teammates and the Multitenant PMs for bringing this into our radar.

Unplug/plug – don’t forget to DROP your PDB

I’ve had to add a single line to my previous blog post about the upgrade solution Unplug/Plug/Upgrade for PDBs:
https://mikedietrichde.com/2014/08/05/upgrade-pdbs-one-at-a-time-unplugplug/

You’ll have to DROP your PDB after you have unplugged it as otherwise the information will stay in the CDB’s dictionary where you have unplugged it from (a) forever and (b) during an subsequent upgrade of the entire source CDB. But the latter will cause trouble as catcon.pl, the PERL script to execute sql code in all the containers, will try to open the PDB you have unplugged a while ago as the information about it is still kept. To me this looks like an undesired behavior but there’s discussion going on internally about it.

 	alter pluggable database PDB1 close;
 	alter pluggable database PDB1 unplug into '/stage/pdb1.xml';
 	drop pluggable database PDB1 keep datafiles;

If you don’t issue the command marked in yellow you’ll get yourself in trouble the sooner or later unless this CDB will be deleted afterwards anyways as it was just meant to hold this single PDB.

Unplug/plug – take care on your backup

If you’d use the above procedure for Unplug/Plug/Upgrade (or even just Unplug/Plug without upgrade from one CDB into another) be aware that you will need to take a backup of your PDB right after the upgrade has been finished. This is something which is pretty clear and obvious but it doesn’t jump into your face when you don’t think about it – and it’s not mentioned in the docs as far as I know.

The previous backup is useless as you won’t be able to use a backup of PDB1 taken on CDB1 to recover PDB1 into CDB2. Therefore a backup taken directly after the upgrade or plug in has to be scheduled immediately – it’s a must and needs to be considered into your maintenance plans.

Every PDB must have its own TEMP tablespace

This one is fairly new to me [thanks Hector!].
MOS Note: 2004595.1 (PDB to Use Global CDB (ROOT) Temporary Tablespace Functionality is Missing

Basically this means that you’ll be unable to drop the local temporary tablespace of a PDB and instead use the global temporary tablespace (the one in CDB$ROOT). This is documented as a functionality which is described in the docs but does not exist right now. It is logged under Bug17554022. No major issue but I’ve a intense discussion with Johannes Ahrends a while back at the DOAG conference about it – so others saw this issue as well.

–Mike