To get the same result as unplugging and plugging a PDB from a remote source CDB into another CDB, you can take advantage of the Oracle Database 12.2 feature such as near-zero downtime PDB relocating.

In Oracle Database 12.1, unplugging and plugging a PDB requires several steps such as unplugging the PDB from the source CDB, copying the database files to a new location, creating the new PDB by plugging the source PDB at the target CDB, and finally dropping the PDB from the source CDB.

A single DDL statement can relocate a PDB, using the “pull” mode, connected to the CDB where the PDB will be relocated to pull it from the CDB where the PDB exists, managing draining existing connections and migrating new connections without requiring any changes to the application.

There are two relocation methods: • Normal availability mode

• −  When the newly created PDB is opened in read-write mode for the first time, the source PDB is automatically closed and dropped, and the relocation operation is completed with the relocated PDB being fully available. This is the “normal availability” default mode.

• −  This method can be used to relocate application PDBs too.

• Maximum availability mode

  • −  The maximum availability mode reduces application impact by handling the migration of connections, preserving the source CDB in mount state to guarantee connection forwarding of the listener to the remote listener where the PDB is relocated. In this case, you cannot create a PDB with the same name as the source PDB because it will conflict with the listener forwarding. It is expected that connect strings are updated at a time that is convenient for the application. After this is done and all the clients connect to the new host without forwarding, the DBA can drop the source PDB.

  • −  If AVAILABILITY MAX is specified during the CREATE PLUGGABLE DATABASE RELOCATE command, additional handling is performed to ensure smooth migration of workload and persistent connection forwarding from the source to the target. The PDB is always first opened in read-only mode. This makes the PDB available as a target for new connections before the source PDB is closed. During this operation, listener information of the target CDB is automatically sent to the source and a special forwarding registration is performed with the source PDB’s current listener. New connections to the existing listener are automatically forwarded to connect to the new target. This forwarding persists even after the relocation operation has been completed, and effectively allows for no changes to connect strings.

  • −  It is still recommended that connect strings are updated eventually at a time that is convenient for the application, but availability is not dependent on when this action is performed.

    PDB relocation requires enabling the local UNDO mode and ARCHIVELOG mode in both CDBs.

  

We hope the content could useful for your Oracle DBA Tasks!

Cloning Oracle Database 12.1 PDBs to get a test PDB required the source PDB to be in read- only mode, which was nearly unacceptable on a production PDB. The new Oracle Database 12.2 technique copies a remote source PDB into a CDB while the remote source PDB is still up and fully functional.

Hot remote cloning requires both CDBs to switch from shared UNDO mode to local UNDO mode, which means that each PDB uses its own local UNDO tablespace.

Refreshable Copy

In addition, hot cloning allows incremental refreshing in that the cloned copy of the production database can be refreshed at regular intervals. Incremental refreshing means refreshing an existing clone from a source PDB at a point in time that is more recent than the original clone creation to provide fresh data. A refreshable copy PDB can be opened only in read-only mode.

Propagating changes from the source PDB can be performed in two ways:

• Manually (on demand)

• Automatically at predefined time intervals

  If the source PDB is not accessible at the moment the refresh copy needs to be updated, archive logs are read from the directory specified by the REMOTE_RECOVERY_FILE_DEST parameter to refresh the cloned PDB.

Let’s see in the Figure, how to do it

In step 2, when running preupgrade.jar in a CDB, make sure that all the PDBs are opened. The fixup scripts and log files are generated in the pre-upgrade directory of the source database, in $ORACLE_BASE/cfgtoollogs/SID/preupgrade.

You can define a list of PDBs to upgrade either by using an inclusion list with the -c parameter or an exclusion list with the -C parameter. The output of the progressing operation is displayed by default on TERMINAL. The output can be a FILE or a directory (DIR). Finally the type of the output is either TEXT by default or XML.

In step 4, use the catcon.pl script to execute the pre-upgrade SQL scripts in the CDB root and in specified PDBs in the correct order. It generates log files that you can view to confirm that the SQL script or SQL statement did not generate unexpected errors. It also starts multiple processes and assigns new scripts to them as they finish running scripts previously assigned to them.

In step 5, remove desupported initialization parameters, adjust deprecated initialization parameters, and add new ones. Make sure that all path names in the parameter file are fully specified.

To upgrade a subset of PDBs within a CDB, you can specify either an inclusion list with the – c parameter or an exclusion list with the -C parameter. Use the -l parameter to specify the directory to use for the spool log files.

In step 9, use the catcon.pl script to execute the postupgrade_fixups.sql and utlrp.sql scripts.

Note: A prioritized list is used in any upgrade from 11.2.0.3.0, 11.2.0.4.0, 12.1.0.1.0, or 12.1.0.2.0 to 12.2. Default priorities are set to containers, with the CDB root being always upgraded first. The DBA can alter the priority so that PDBs are upgraded according to the configured priority order.

This article is brought by Yunhe Enmo (Beijing) Technology Co.,LTD En.enmotech.com

Follow our Company in Linkedin: https://www.linkedin.com/company/1856106/

Subscribe to our Blog and enjoy our Weekly Cloud article..!

In Oracle Database 12.1, when a PDB is unplugged, all the data files associated with the PDB along with the PDB manifest must be copied or moved individually over to the remote server where it will be plugged into another CDB.

With Oracle Database 12.2, you can choose to create a single PDB archive file, a compressed file with the .pdb extension, which contains the PDB manifest and all the data files when unplugging a PDB. When plugging in a PDB, the presence of a .pdb file is interpreted and the PDB is plugged into the CDB. You can choose to run the PDB plug-in compatibility test directly on the PDB archive without extracting the PDB manifest file from the archive.

This feature provides ease of managing the unplugging and plugging of PDBs across CDBs.