Recovery Continuity with Multitenant

 Recovery Continuity with Multitenant is something you need to understand as you migrate databases from one CDB to another

Above is from a presentation that I recently gave to my internal Oracle Team. This was such a big hit (and very eye opening) that I wanted to make sure I share the information on my Blog

The first thing to point out is that before we (Oracle) moved to the multitenant architecture, life was simple. Below is my slide showing how databases were moving around as they upgraded.  Regardless of whether it was an out-of-place upgrade, or migrating it to a different host, the DB name stays, and the backups stay contiguous.

But, like many things in life, new ideas came along that changed the way we do things.  Multitenant is one of those things.  Don't get me wrong, multitenant is a great feature giving DBAs a lot more flexibility.  Below are a couple of pictures that show all the wonderful things that multitenant can do.

Above are the 2 slides from my presentation.  These slides are often used to show the benefits of multitenant.  I did point out on the last slide encryption keys that are used to secure the database with TDE.

The use of Encryption keys is an important point to think about.  With Multitenant (if you think about how it works), the CDB has a different encryption key from the PDB.  If I create an encrypted backup of my CDB, it is encrypted with the CDB key. The backup (and actual datafiles) for my PDB are encrypted with the PDB key.

Below is the next slide I used.  All the information on multitenant talks about how easy it is to unplug/plug (which it is), but ensuring you maintain your recovery window is the hard part.

Database backup and recovery in a multitenant environment

Here are some things to keep in mind in a multitenant environment

• Pluggable database backup pieces are ALWAYS kept independent of the CDB and other PDBs.  Even with a filesperset=1000 channels=1 each PDB, and the CDB will be individual backupsets.

• Pluggable databases can be backed up independently of each other, and of the CDB. “backup pluggable database xxx.

• You can perform a point in time recovery of a pluggable database independent of other PDBS. This requires local undo. “recover pluggable database until”

• Recovering a pluggable database requires a backup of the CDB (for metadata), and backups of the archive logs.

• All redo transactions for all PDBs are intertwined into a single redo stream. This will not change in the near future. 

• Flashback can be set at the PDB level

• You can create restore points within a PDB

When backing up a Multitenant environment, the item to keep in mind is that the RMAN catalog information is stored at the CDB level.  Pluggable databases are part of the CDB, and registration is done at the CDB.

The next image shows what a recovery of the Pluggable database looks like. Keep in mind that the datafiles for the  pluggable database get restored using the pluggable database backup, but to defuzzy them, the archive logs get restored from the CDB.  Remember that in a multitenant environment the redo/archive logs are intertwined at the CDB level.

The next image shows what is typically done to perform a PDB upgrade with unplug/plug. The pluggable database is migrated from 12c to 19c.

Now that the database is migrated, let's look at what happens to the RMAN catalog after the migration to ensure that we have a backup of the pluggable database.

• 

You can see in the image above, that the pluggable database is now associated with the CDB that the pluggable database is plugged into.

Now to go back to the image at the beginning of this post, you can see what it takes to restore and recovery the database throughout it's lifecycle.

• Backups that were taken through previous CDBs (for example an archival backup) needs to be restored through the CDB is was backed up through.
• Backups that were taken in original CDB can only be restored back to the original CDB.
• Pre-plugin backups provide a gateway between plugging in and when the first backup is taken
• Backups to the new CDB will restored back to the new CDB.

Finally some parting thoughts on backups of pluggable databases when migrating.

• Perform a full backup if possible (ZDLRA makes this easy) with the PDB mounted prior to unplugging. This is the best possible restore point after migrating.

• Keep the RMAN catalog entries for the old CDB as long as there are valid backups pieces. This could be years for keep backups.

• NOTE – On the ZDLRA you can execute “Pause Database” this will remove all backups, but leave the RMAN catalog entries.

• Ensure you have the encryption keys for both CDBs and PDBs for the needed recovery window which may be years.

• Keep track of CDB backups, as a PDB might be migrated between multiple CDBs throughout it’s backup cycle.

• NEVER delete a CDB backup that has needed backups

• NEVER delete any TDE keys or wallets that support needed backups.