Pluggable Database Relocation: A How-to Guide

Pluggable Database Relocation allows you to move a Pluggable Database (PDB) from one Container Database (CDB) to another with minimal downtime, without upgrading the PDB. This method is efficient and minimizes disruption, making it ideal for planned maintenance and load balancing, and High Availability.

In this post, we will guide you through the process to make the change with minimal downtime and effects on your databases. Apps Associates is a trusted Oracle implementation partner with more than twenty years of experience in enterprise technology management.

Here’s a brief summary of the process:

1. Prerequisites: Ensure both the source and target CDBs are compatible and meet the necessary requirements.
2. Preparation Steps: Prepare the source PDB for relocation by checking its status and ensuring it is ready for the move.
3. Phase 1 – Relocation: Execute the initial relocation commands. During this phase, the source PDB remains accessible to users and applications.
4. Phase 2 – Finalization: Complete the relocation with a short downtime (typically less than 10 minutes) to finalize the move.
5. Post-Relocation Steps: Verify the PDB in the target CDB and perform any necessary post-relocation tasks.

Now, let’s review this process in more detail.

Pre-requisites

To ensure an optimal relocation, check that you have these prerequisites in place.

1. The source and destination CDBs must be Oracle Database 12cR2 or later. It is highly recommended that they are Oracle Database 19c or later.
2. The source and destination CDB platforms must be the same endian type.
3. The source CDB must be in ARCHIVELOG mode.
4. Ensure the Oracle Homes for both the source and destination CDBs have matching versions and patch inventories. This ensures that no additional steps are required after opening the PDB at the destination.
5. Ensure the source and destination CDBs have the same Oracle Options (e.g., Oracle Spatial, Oracle Label Security, Oracle JVM, etc.) installed and the same versions of the options.
6. Both the source and destination CDBs must be using Local Undo; each PDB has its own set of undo tablespaces.
7. Use the STANDBYS=NONE clause to defer the recovery of the PDB in destination standby databases when the destination CDB is part of a Data Guard environment. It is currently not possible to automatically maintain standby databases during PDB relocation operations; deferring recovery allows redo to apply at any standby databases to continue.  To enable recovery, you will need to restart redo apply when synchronizing a standby with the relocated PDB’s data files. Use the instructions in Making Use Deferred PDB Recovery and the STANDBYS=NONE Feature with Oracle Multitenant Document 1916648.1 to enable recovery of the PDB after relocation has completed.

Required Patches

In order to successfully complete this relocation process, you must ensure you have these patches in place:

• Patch 26001677 – Implements REFRESH MODE for PDB relocate, included 19.8 and later required for environments with Transparent Data Encryption (TDE).
• Patch 29175638 – Adds support for INCLUDING the SHARED KEY clause to avoid ORA-46659 errors.
• Patch 32220709 – Ensures shared PDB master keys display in v$encryption_keys, included in 19.14 and later.

Highly recommended

Though not required, we highly recommend having this patch installed as well:

• Patch 28374604 – Deletes partial redo logs created during refresh operations, available 19.1 and later -*** This is available for 12 and 18C only, does not exist for 19c env.

Work with an Oracle Expert

Apps Associates has more than twenty years of experience in Oracle technology. We’re a certified partner with deep expertise in both databases and applications, and offer a variety of services to fit your unique needs. Looking for a partner to help with database relocation? Start the conversation with Apps today.