Pluggable Databases - Expert Consolidation in Oracle Database 12c - page 246

Once the PDB has been closed, you can reopen it in read-only mode:
SQL> alter pluggable database pdb1 open read only;
Pluggable database altered.
The cloning process in its most basic form requires no arguments when OMF is in use, especially not an admin
user clause. Consider the following example on a system using Oracle Managed Files:
SQL> create pluggable database pdb5 from pdb1;
Pluggable database created.
On a regular file system without OMF the command requires the file name conversion parameter. This means
that all files belonging to a PDB are always contained under a single directory or mount point. You cannot avoid the
file name conversion, and bundle up all the PDBs under a single directory, such as /u01/oradata/pdbs/pdbs . From a
deployment perspective you should therefore create mount points for different storage tiers, with sub-directories for
each PDB.
The below does not make use of this schema, but rather has a generic mount point “pdbs”, under which all the
PDBs are created. The user-PDB “fspdb1” has already been created and is now in read-only mode waiting to be cloned:
SQL> create pluggable database fspdb2 from fspdb1
2 file_name_convert = ('/u01/oradata/pdbs/fspdb1','/u01/oradata/pdbs/fspdb2')
3 /
Pluggable database created.
When cloning a PDB you cannot assign a default tablespace in the same command, and you cannot modify or
set the roles for the PDB administrator the same way you would as shown in the previous section. You can however
make use of the storage clause, and limit the temp and permanent storage used by the PDB. Changes to the physical
structure of the PDB need to be completed after the PDB has been created and opened.
Once the PDB is created it needs to be backed up.
Cloning from a remote PDB
Cloning a user-PDB from a remote source requires a very similar syntax as cloning from a local source. In essence,
all that is required is a database link between the destination and source. The operation itself is a pull from remote
via the database link. There is similar advice to be given concerning the operation compared to RMAN's ability to
duplicate an active database: don't overload your network! If you can, you should use tagged VLANs for this kind of
operation, or maybe not clone at all.
In the example that follows you find two Container Databases: CDB1 and CDB2. CDB1 currently has a PDB called
swingbench1 which needs to be cloned as swingbench2 under CDB2. Before spending time on the clone operation
you need to ensure that the CDBs use the same character set. In Oracle 12.1 a clone operation from a remote database
requires identical character sets, as does the plug operation as you will see shortly. Additionally, you need to ensure
that the database options between the source and destination CDB are identical.
As with any clone operation, the source has to be opened read-only. Again, make sure that all the stakeholders
of the application are aware of that operation so that applications can be shut down cleanly prior to the event. Before
shutting down the source, create a database link to the CDB$ROOT of your source, then enter the known command
“create pluggable database clone Name from sourceName@dblink.
And you cloned a PDB over the network which opens interesting possibilities.