Export an Oracle VDB or a vPDB to a physical ASM or exadata database
Overview
This article describes how to perform an export or an in-place conversion of a virtual database (VDB) or a virtual pluggable database (vPDB) into a physical database stored on Oracle Automatic Storage Management (ASM) disk groups. No intermediate storage is needed; the database files are moved directly from Delphix into the ASM diskgroup(s).
This procedure can be used to export an Oracle VDB, or a vPDB in a Linked CDB, to ASM disk group(s), including disk group(s) residing in an Oracle Exadata machine. The procedure follows Oracle's recommended best practice of using a single disk group for data files. A separate disk group can be specified for redo log files.
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 non-multitenant virtual Oracle database to ASM or CLI cookbook: export a multitenant virtual pluggable Oracle database to ASM articles.
Furthermore, it is also fully supported with TDE-enabled virtual databases provisioned through Delphix.
Prerequisites
Oracle Managed Files (OMF) must be enabled on the VDB or vPDB before export can be performed. OMF eliminates the need for the DBA to directly manage the operating system files that comprise an Oracle Database. As a result of this OMF requirement, it is expected that all database file names of the exported physical database would change.
The following conditions must be met prior to the export operation. Export will fail if any of these conditions are not met:
Sufficient storage space must be available in the target ASM diskgroup for datafiles and the target ASM diskgroup for online logs if specified. The validation of the target ASM diskgroup for online logs is only applicable in the case of VDBs and not vPDBs.
While exporting a vPDB, if a new PDB name is specified:
it must meet all the naming constraints as defined in the Oracle documentation.
it must be different from the existing PDBs in the target CDB.
While exporting a VDB, if a new database unique name is specified:
it must meet all the naming constraints as defined in the Oracle documentation.
it must be different from the database unique name of any other database on the same target host.
it must not be a RAC database.
No offline datafiles or tablespaces must exist in the VDB or vPDB.
The VDB or vPDB on which the export is initiated must be Open.
Export of a VDB in a RAC environment must be performed as the Oracle user, otherwise the export will fail. This is required because Delphix issues srvctl commands to configure the resulting physical database in RAC and these commands can only be run with Oracle user privileges.
No other job must be running on the virtual database or its associated environment.
When running export of a VDB or vPDB in a RAC environment, ensure that the states of all the cluster nodes are displayed as 'Enabled' in the Delphix management GUI. If one of the cluster nodes is disabled, the export operation will fail, although the physical copy has been completed and it is usable, however the VDB or vPDB will need to be force disabled manually.
The VDB or vPDB must have a provisionable snapshot, otherwise operation will fail with the following message:
Cannot find a point in the TimeFlow for the semantic location "LATEST_POINT".
If you want to export a vPDB in a vCDB, the vPDB must be migrated to a Linked CDB and then enabled, or alternatively, provision a child vPDB from this vPDB snapshot to a linked CDB and then perform the export.
Procedure
Delphix takes a new snapshot of the virtual database/pluggable database before starting export. Also, Delphix retains the timeflow and all its snapshots after the virtual source is exported. As such, after export, the virtual source can be easily migrated and rewinded to the previously created snapshots.
It is recommended that the export be performed on a newly provisioned VDB or vPDB, although it can still be performed on your existing VDB or vPDB. The reason is it simplifies the post export process to re-enable the existing VDB or vPDB.
Please refer to the appropriate CLI cookbook sections for the procedure to export a VDB or export a vPDB to a physical ASM or Exadata database.
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 should not be more than the number of datafiles.
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.
Performance tuning considerations for Oracle databases with bigfile tablespaces
As part of the export workflow, Delphix performs the data transfer using RMAN. By default, 8 RMAN channels are created to copy files from Delphix to ASM. The number of RMAN channels can be specified in the export CLI. Each RMAN channel takes up one datafile at a time and picks up another as soon as it is done copying one. For databases that contain hundreds or thousands of small data files, this is usually sufficient.
Consider a database which contains 100 data files of sizes 20-40GB each, and 1 large datafile of size 1TB or larger. In such a case, one of the RMAN channels will be doing all the work of transferring the 1TB datafile and the rest of the RMAN channels would be idling until the 1TB of data is copied. To speed up the data transfer for such databases, Delphix now provides a new rmanFileSectionSizeInGb API parameter that can be passed to the export CLI. When this parameter is specified, Delphix will pass the SECTION SIZE parameter to the RMAN BACKUP AS COPY command, and RMAN then creates several chunks of backup copies in which each chunk contains the blocks from one file section. This type of copy is called a multisection copy. The purpose of multisection copies is to enable RMAN channels to copy a single large file in parallel. Thus, when the rmanFileSectionSizeInGb parameter is specified in the export CLI, RMAN will divide the work among multiple channels, with each channel copying one file section in a file. For example, if rmanFileSectionSizeInGb is set to 64, then the large 1TB datafile transfer will be broken into 16 sections of 64GB each, and all 8 channels will then be utilized for copying the large datafile once the copy of the smaller files has completed. Copying a file in separate sections can thus improve the performance of copies of large data files which in turn could speed up the time taken by the V2ASM export job.
Considerations after successful export of a VDB or vPDB to ASM
After the export is successful, no Delphix operations are allowed on the VDB/vPDB except migrate or a fresh provision of a new child VDB or vPDB. However, there may be situations where you may need to re-enable the VDB or vPDB, please perform a migrate of the VDB/vPDB to a different host and/or CDB and then rewind the VDB/vPDB to it’s latest snapshot
After successfully performing export of a VDB to replace a linked physical database that is damaged and is unusable with new physical database having the same name, same unique name and same SID as the original damaged database, the new physical database can be linked back to Delphix engine using the following steps:
Delete or Migrate the VDB that was used to create a new physical database to a different environment.
Refresh the environment where the new physical database is created.
Detach the dSource from the original source database.
Force attach the dSource to the newly created physical database.
After successfully performing export of a vPDB with the new physical PDB name that is same as the vPDB name, the new physical PDB can be linked back to Delphix engine using the following steps:
Delete or migrate the vPDB to a different CDB.
Refresh the environment where the new physical PDB is created.
Detach the dSource PDB from the original source PDB.
Force attach the dSource to the newly created physical PDB.