Database Reference
In-Depth Information
<frlsb>2256999</frlsb>
<frlt>826900946</frlt>
</file>
</tablespace>
...
<tablespace>
...
</tablespaces>
There are more entries for each tablespace in the PDB as well as all the database options, whether or not Data
Vault or Label Security are in use and important initialization parameters. The XML file name is a very important
piece of information for the remaining process as you will see next. Before you can plug a PDB into a CDB, the
following requirements have to be met in Oracle 12.1:
•
The source and destination CDB must have the same endianness (check field “byteorder”
in the above XML file). In other words, you cannot directly transport a PDB from a CDB on
Solaris SPARC into a PDB on Linux x86-64.
•
The PDB must have the same or compatible character set, and also the same national
character set. Do you see the value of standardization here?
•
The destination CDB must have the same options installed in the data dictionary as the source
CDB if the PDB makes use of them. You can view the options used by the PDB in the XML file
describing it in the tag <options>. The option is listed alongside its version. Use DBMS_PDB.
CHECK_PLUG_COMPATIBILITY() to check for compatibility of PDB and CDB options.
The API for plugging the exported PDB into a CDB gives you a great deal of freedom over the process. The basic
command is the now well-known “create pluggable database” statement used previously, with the extension of the
“using” clause. Depending on how you stored the unplugged PDB, and whether you want to clone the source or store
it in a different location you have many options.
•
To create the new user-PDB as a clone. The “as clone” clause to the “create pluggable
database” command instructs Oracle to generate new identifiers for the PDB to be plugged
in. Most importantly, it will ensure that the new PDB is different from the source PDB from an
Oracle point of view.
•
If you moved the unplugged PDB physically, or made it available via an NFS mount for
example, then the XML file does not represent the file location of the PDB to be plugged
in. Instead of editing the XML file manually, you should use the source_file_name_convert
option. It is exactly the same as the file_name_convert clause already explained earlier in
the chapter.
•
If you have already copied or moved the PDB's files to their final location, then you can
instruct Oracle not to copy them from the source location indicated in the XML file, which it
would be otherwise the default. Alternatively, you can specify the move keyword to move- and
not copy- the files to the new location.
•
In addition to specifying the source_file_name_convert parameter, you can also tell Oracle
where to move files to using the file_name_convert clause as already explained.
As you can see, the number of options available to detail what should happen with an unplugged PDB is quite
large. In addition to the ones mentioned here you can also specify the storage clause, which has already been discussed
in the section “Create a PDB from the seed database”. The options to use depend on your situation. If you are using
Oracle Managed Files, then you most likely do not need to consider the file_name_convert clause—the OMF naming
convention will take care of the destination location. Years of experience working with Oracle ASM have taught the
author that it is often best not trying to outsmart ASM in trying to micro-manage the file names and locations.
Search WWH ::
Custom Search