Oracle Cloud Infrastructure Documentation

About Pluggable Databases

This article provides details about pluggable databases and managing their various features, such as backup, restore, relocate, and clone.

The multitenant architecture enables an Oracle database to be a container database. A container database (CDB) contains one or more user-created, pluggable databases and application containers. A pluggable database (PDB) is a portable collection of schemas, schema objects, and nonschema objects that appears to an application as a separate database. At the physical level, each PDB has its own set of data files that store the data for the PDB. The CDB includes all the data files for the PDBs contained within it and a set of system data files that store metadata for the CDB itself.

Oracle 19c or later databases created in a DB system include an initial PDB that you can access from the Database details page in the Console. Using the Console or APIs, you can start, stop, clone, and delete the PDB. You can also create additional PDBs in the CDB. All PDB operations performed using the Console or APIs can be monitored using the work request generated by the operation. For more information, see Work Requests.

You can create and manage PDBs in the DB system using the OCI Console and APIs.

Note

Generally, the term 'database' refers to the container database (CDB).

Create

You can have more than one PDB in a CDB. PDBs must be created one at a time, and creating a new PDB has no effect on existing PDBs in the CDB.

To create a PDB using the Console, see Create a Pluggable Database.

Backup

You can take a backup of the PDB optionally during create, clone, or relocate operations when the CDB is configured with the auto-backup feature. The PDB backup destination will always be the same as CDB, and the backups cannot be accessed directly or created on demand. Oracle recommends immediately backing up the PDB after you create or clone it. This is because the PDB will not be recoverable until the next daily auto-backup completes successfully, leading to a possible data loss.

Restore

A PDB can be restored from a backup.

  • Out-of-place restore: You can restore a PDB by creating a CDB from the backup, then selecting a PDB or a subset of them you want to restore on the new database.
  • In-place restore: You can restore a PDB within the same CDB to its last known good state or to a specified time stamp.

You can perform an in-place restore when you want to move a PDB back to a specified state or time. Both the CDB and PDB must be up and running, and only one PDB can be restored at a time.

  • If you have multiple PDBs in your CDB and want to restore multiple of them to the same CDB, then you could restore each individual PDB, one PDB at a time, from the CDB backup.
  • When the CDB is down, you can restore the complete CDB, and all the PDBs in that CDB will also be restored.
  • You could either restore the database to the specified time stamp or to its last known good state.

To restore a PDB using the Console, see Restore a Pluggable Database.

Relocate

You can relocate a PDB from one CDB to another CDB within the same availability domain (AD) to the same or a later database version across compartments, DB systems, or VCNs. If two different VCNs are used, then both VCNs must be peered before relocating. During relocation, the PDB will be removed from the source CDB and moved to the destination CDB that is up and running. In a Data Guard association, a PDB relocated to the primary will be synchronized with the standby as well.

To relocate a PDB using the Console, see Relocate a Pluggable Database.

Clone

A clone is an independent and complete copy of the given database as it existed at the time of the cloning operation. You can create clones of your PDB within the same CDB or a different CDB and refresh the cloned PDB.

The following types of clones are supported:

  • Local clone: A copy of the PDB is created within the same CDB.
  • Remote clone: A copy of the PDB is created on a different CDB.

    You can perform a remote clone of a PDB from one CDB to another CDB within the same availability domain (AD) to the same or a later database version across compartments, DB systems, or VCNs. If two different VCNs are used, then both VCNs must be peered before cloning.

  • Refreshable clone: A copy of the PDB is created on a different CDB, and you will be able to refresh the cloned PDB.

    You can perform a refreshable clone of a PDB from one CDB to another CDB within the same availability domain (AD) to the same or a later database version across compartments, DB systems, or VCNs. If two different VCNs are used, then both VCNs must be peered before cloning.

To clone a PDB using the Console, see Clone a Pluggable Database.

Refreshable Clone

A refreshable clone enables you to keep your remote clone updated with the source PDB.

  • You can only refresh while the PDB is in mount mode.
  • The only open mode you can have is read-only, and refresh cannot be performed while it is in read-only mode.
  • A database link user credential is required for creating a refreshable clone.
  • Clone, relocate, and in-place restore operations are not supported in the refreshable clone. Relocate and in-place restore operations are not supported in the source, and the source can only be deleted after disconnecting or deleting the refreshable clone.
  • When cloning a PDB from 19c to 23ai, the cloned PDB is automatically upgraded to 23ai. For example, if you use refreshable clones to clone to 23ai and then convert it to regular PDB, all necessary upgrade steps are automatically handled, converting the refreshable clone into a fully upgraded 23ai PDB.
  • In a Data Guard association, a refreshable clone cannot be created on standby, but it can be created on the primary. However, the primary will not be synced to the standby.
  • A PDB in standby cannot be used as the source for a refreshable PDB.

To create a refreshable clone using the Console, see Clone a Pluggable Database.

To refresh a clone using the Console, see Refresh a Pluggable Database.

Convert Refreshable Clone to Regular PDB

You can convert a refreshable clone to a regular PDB by disconnecting the refreshable clone (destination PDB) from the source PDB at any time. If the refresh PDB is in a Data Guard association, when it is converted to a regular PDB, then the PDB will be synced to the standby as part of the conversion process.

To convert a PDB using the Console, see Convert a Refreshable Clone to a Regular Pluggable Database.

Open Modes

On the Console, you can see the open modes of a PDB, such as read-write, read-only, and mounted. If the PDB status is the same across all nodes, the system displays the same status for all PDBs. If the PDB statuses are different across the nodes, the system displays a message indicating on which nodes the PDBs are opened in read-write mode. You cannot change the open mode of a PDB through the API or Console. However, you can start or stop a PDB. Starting the PDB will start it in read-write mode. Stopping the PDB will close it, and it will remain in mount mode.

Limitations of PDB Management

  • New PDBs created with SQL are not immediately discovered and displayed in the Console. However, OCI performs sync operations regularly to discover manually created PDBs, and they should be visible in the Console and API-based tools within 6 hours of creation. Oracle recommends using the Console or API-based tools (including the OCI CLI, SDKs, and Terraform) to create PDBs.
  • PDB operations are supported only for databases using Oracle Database 19c and later.
  • PDBs are backed up at the CDB level, and each backup includes all the PDBs in the CDB. OCI does not support the creation of backups for individual PDBs.