Exporting a PDB from a snapshot or a timeflow-point to a physical filesystem
Overview
This article describes how to perform an export from a snapshot or a timeflow-point belonging to a pluggable database to create a physical database stored on a physical filesystem. No intermediate storage is needed; a temporary virtual pluggable database is provisioned, and the database files are moved directly from Delphix onto the physical filesystem.
This procedure can be used to export snapshots of a PDB dSource or a vPDB to a pluggable database in a linked CDB. The physical database is created on the filesystem.
This procedure can be performed using the CLI only and applies to all Oracle RDBMS Versions supported by Delphix. For CLI commands, refer to the CLI cookbook: export a snapshot or a Timeflow point of a multitenant pluggable Oracle database to ASM or Physical Filesystem article.
Furthermore, it is also fully supported with TDE-enabled databases.
Prerequisites
Sufficient storage space must be available on the filesystem for datafiles, tempfiles.
While exporting from a PDB snapshot, the new PDB name:
must meet all the naming constraints as defined in the Oracle documentation.
must be different from the existing PDBs in the target CDB.
Offline tablespaces can exist; however, offline datafiles must not exist in an online tablespace.
When running export of a multitenant snapshot in a RAC environment, ensure that the states of all the cluster nodes are displayed as
Enabled
in the Delphix management GUI.
Procedure
Delphix provisions a temporary virtual pluggable database, from the provided snapshot or timeflow point, which would be converted in-place to a physical database.
Delphix takes a new snapshot of the temporary virtual pluggable database before starting export.
The virtual pluggable database is converted in-place to a physical database on filesystem. The temporary virtual source is then deleted.
Refer to CLI cookbook: export a multitenant virtual pluggable Oracle database to ASM or Physical Filesystem for the procedure.
Performance considerations before running the export
When deciding the number of RMAN channels to use, there are tradeoffs between speed and resource consumption on the host.
The number of RMAN channels must not be more than the number of data files.
Similar to selecting the number of RMAN channels to perform backup, if impact to other databases is not a concern, then setting the number of channels should be increased to the point of diminished returns. Otherwise, it is a compromise between what the system can handle and how fast we want the export to finish.
By default, it is set to 8, but this value might be too large for some environments and should be adjusted down appropriately.