Oracle Database 220.127.116.11 delivers several noteworthy enhancements to the Oracle Multitenant Option of the Oracle Database. We will begin to take a look at these enhancements in our blog posts.
In Oracle Database version 18.104.22.168, there is a new and powerful feature which is quite useful. Remote cloning of pluggable databases is now fully functional in this version. This uses database links between the container databases.
The capability of Remote cloning results in considerable data mobility benefits when using the Multitenant option. PDBs can now be relocated on desire if using a hybrid cloud model (for e.g. take the scenario where your production databases are set up on-premise, and your development and test databases are set up in the public cloud).
The remote cloning capability includes snapshot cloning. Snapshot cloning is supported on any dNFS file system. Note that the “CLONEDB” database initialization parameter must be set to true for snapshot cloning to work on a dNFS system. If CLONEDB is set to false, then snapshot cloning will only work when the file system supports storage snapshots, as in the case of Oracle Automatic Storage Management Cluster File System (Oracle ACFS – now called Oracle CloudFS) and also Direct NFS Client storage (for e.g. Sun ZFS Storage Appliance, NetApp, EMC).
A non-CDB can also be cloned across the database link, but snapshot cloning is not possible in this case.
The command used is the “create pluggable database <pdb name>” with the create pdb clone construct. This construct would look like “from <source pdb / noncdb>@dblink” with or without the “snapshot copy” clause. For example, in the container database CDB1, issue the following command to clone from the SALES PDB in the remote CDB2:
create pluggable database SALESTEST from SALES@CDB2;
There is also a NO DATA clause that can be used when cloning PDBs (but not non-CDBs). This is also an enhancement in 22.214.171.124 and allows you to make a metadata-only clone. The clone is created with the same data model as the source, but no data. This would be useful in quickly creating development environments with the same schema as the production PDB but without the production data.
One restriction of using dNFS and CLONEDB is that the source PDB must be read-only. This means you cannot take snapshots directly from a production database for development and testing, but from a copy of the production database that has been masked fully for its confidential data content, which is the correct thing to do. Note that as long as the clones exist, it is necessary for the source PDB to remain open in the read-only mode.
If the database uses ASM, then snapshot cloning is supported in this case only on Exadata and not on ASM without Exadata at this point of time.
The full syntax of the cloning is explained in the documentation here, along with other restrictions.
"One restriction... is that the source PDB must be read-only."
Make that one HUGE restriction for most 24/7 shops. Our main interest in PDB's is to simplify the cloning process from production to dev/test. With this limitation, that simply is not possible as most production db's only go down about twice a year (for PSU upgrades). For now, we will have to mostly ignore PDB's and continue with the RMAN restore cloning process, which is unfortunate.
I guess it still works for cloudy purposes - which I assume was Oracle's main goal.
Well Bryan, as I mentioned, the recommended way to to create a test master PDB with the confidential data masked before copying it to development or test. Once the test master PDB has been created, it can be kept read only and used for cloning. You wouldnt want to make straight copies of production for used in development and test if production contains confidential data - most production databases do contain this kind of data.