The multitenant option introduced in Oracle Database 12c allows a single container database (CDB) to host multiple separate pluggable databases (PDB). This article covers the options for migrating a non-CDB/PDB database to a PDB.
The 12.1.0.2 patchset introduced the ability to create a PDB as a clone of a remote non-CDB.
The DBMS_PDB package allows you to generate an XML metadata file from a non-CDB 12c database, effectively allowing it to be describe it the way you do when unplugging a PDB database. This allows the non-CDB to be plugged in as a PDB into an existing CDB.
Typically, any feature used in the PDB must be present in the root container of the destination CDB prior to the migration. The following example assumes this to be the case.
Cleanly shutdown the non-CDB and start it in read-only mode.
export ORACLE_SID=db12c
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
STARTUP OPEN READ ONLY;
Describe the non-DBC using the DBMS_PDB.DESCRIBE procedure. This procedure creates an XML file in the same way that the unplug operation does for a PDB.
BEGIN
DBMS_PDB.DESCRIBE(
pdb_descr_file => '/tmp/db12c.xml');
END;
/
Shutdown the non-CDB database.
export ORACLE_SID=db12c
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
Connect to an existing CDB and create a new PDB using the file describing the non-CDB database. Remember to configure the FILE_NAME_CONVERT parameter to convert the existing files to the new location.
export ORACLE_SID=cdb1
sqlplus / as sysdba
CREATE PLUGGABLE DATABASE pdb6 USING '/tmp/db12c.xml'
COPY
FILE_NAME_CONVERT = ('/u01/app/oracle/oradata/db12c/', '/u01/app/oracle/oradata/cdb1/pdb6/');
Switch to the PDB container and run the "$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql" script to clean up the new PDB, removing any items that should not be present in a PDB.
ALTER SESSION SET CONTAINER=pdb6;
@$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
Startup the PDB and check the open mode.
ALTER SESSION SET CONTAINER=pdb6;
ALTER PLUGGABLE DATABASE OPEN;
SELECT name, open_mode FROM v$pdbs;
NAME OPEN_MODE
------------ ----------
PDB6 READ WRITE
1 row selected.
SQL>
The non-CDB has now been converted to a PDB. You should backup the PDB before you start to use it.
A simple option is to export the data from the non-CDB and import it into a newly created PDB directly. Provided the import is connecting using a service pointing to the relevant PDB, this is no different to any other data transfer using data pump.
If the non-CDB is version 11.2.0.3 onward, you can consider using Transport Database, as described here. If the non-CDB is pre-11.2.0.3, then you can still consider using transportable tablespaces.
Another alternative is to use a replication product like Golden Gate to replicate the data from the non-container database to a pluggable database.
If your instances are not at the same patch level, you will get PDB violations visible in the PDB_PLUG_IN_VIOLATIONS view. If the destination is at a higher patch level than the source, simply run the datapatch utility on the destination instance in the normal way. It will determine what work needs to be done.
cd $ORACLE_HOME/OPatch
./datapatch -verbose
If the destination is at a lower patch level than the source, you will need to run a datapatch -rollback operation.
◈ Clone a Remote Non-CDB
The 12.1.0.2 patchset introduced the ability to create a PDB as a clone of a remote non-CDB.
◈ Using DBMS_PDB
The DBMS_PDB package allows you to generate an XML metadata file from a non-CDB 12c database, effectively allowing it to be describe it the way you do when unplugging a PDB database. This allows the non-CDB to be plugged in as a PDB into an existing CDB.
Typically, any feature used in the PDB must be present in the root container of the destination CDB prior to the migration. The following example assumes this to be the case.
Cleanly shutdown the non-CDB and start it in read-only mode.
export ORACLE_SID=db12c
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
STARTUP OPEN READ ONLY;
Describe the non-DBC using the DBMS_PDB.DESCRIBE procedure. This procedure creates an XML file in the same way that the unplug operation does for a PDB.
BEGIN
DBMS_PDB.DESCRIBE(
pdb_descr_file => '/tmp/db12c.xml');
END;
/
Shutdown the non-CDB database.
export ORACLE_SID=db12c
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
Connect to an existing CDB and create a new PDB using the file describing the non-CDB database. Remember to configure the FILE_NAME_CONVERT parameter to convert the existing files to the new location.
export ORACLE_SID=cdb1
sqlplus / as sysdba
CREATE PLUGGABLE DATABASE pdb6 USING '/tmp/db12c.xml'
COPY
FILE_NAME_CONVERT = ('/u01/app/oracle/oradata/db12c/', '/u01/app/oracle/oradata/cdb1/pdb6/');
Switch to the PDB container and run the "$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql" script to clean up the new PDB, removing any items that should not be present in a PDB.
ALTER SESSION SET CONTAINER=pdb6;
@$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
Startup the PDB and check the open mode.
ALTER SESSION SET CONTAINER=pdb6;
ALTER PLUGGABLE DATABASE OPEN;
SELECT name, open_mode FROM v$pdbs;
NAME OPEN_MODE
------------ ----------
PDB6 READ WRITE
1 row selected.
SQL>
The non-CDB has now been converted to a PDB. You should backup the PDB before you start to use it.
◈ Using Data Pump (expdb, impdp)
A simple option is to export the data from the non-CDB and import it into a newly created PDB directly. Provided the import is connecting using a service pointing to the relevant PDB, this is no different to any other data transfer using data pump.
If the non-CDB is version 11.2.0.3 onward, you can consider using Transport Database, as described here. If the non-CDB is pre-11.2.0.3, then you can still consider using transportable tablespaces.
◈ Using Replication
Another alternative is to use a replication product like Golden Gate to replicate the data from the non-container database to a pluggable database.
◈ Patching Considerations
If your instances are not at the same patch level, you will get PDB violations visible in the PDB_PLUG_IN_VIOLATIONS view. If the destination is at a higher patch level than the source, simply run the datapatch utility on the destination instance in the normal way. It will determine what work needs to be done.
cd $ORACLE_HOME/OPatch
./datapatch -verbose
If the destination is at a lower patch level than the source, you will need to run a datapatch -rollback operation.
0 comments:
Post a Comment