Database migration from on-premises to Azure cloud
As a result of the Oracle decision to phase out single-instance databases, many organizations have converted single-instance Oracle databases to multitenant container databases. This enables the easy relocation of a subset of container databases called PDB to cloud with the maximum availability option, which minimize downtime during migration.
However, if you still have a single instance of a Oracle database, it can first be converted into a multitenant container database in place before attempting PDB relocation.
The following sections provide details for the migration of on-premises Oracle databases to Azure cloud in either scenarios.
Converting a single instance non-CDB to a PDB in a multitenant CDB
If you still have a single-instance Oracle database, it must be converted into a multitenant container database whether you wish to migrate it to the cloud or not, because Oracle will stop supporting single-instance databases some time soon.
The following procedures plug a single instance database into a container database as a pluggable database or PDB.
-
Build a shell container database on the same host as the single-instance database in a separate
ORACLE_HOME
. -
Shut down the single instance database and restart it in read-only mode.
-
Run the
DBMS_PDB.DESCRIBE
procedure to generate the database metadata.BEGIN DBMS_PDB.DESCRIBE( pdb_descr_file => '/home/oracle/ncdb.xml'); END; /
-
Shut down the single-instance database.
-
Start up the container database.
-
Run the
DBMS_PDB.CHECK_PLUG_COMPATIBILITY
function to determine whether the non-CDB is compatible with the CDB.SET SERVEROUTPUT ON DECLARE compatible CONSTANT VARCHAR2(3) := CASE DBMS_PDB.CHECK_PLUG_COMPATIBILITY( pdb_descr_file => '/disk1/oracle/ncdb.xml', pdb_name => 'NCDB') WHEN TRUE THEN 'YES' ELSE 'NO' END; BEGIN DBMS_OUTPUT.PUT_LINE(compatible); END; /
If the output is YES, then the non-CDB is compatible, and you can continue with the next step.
If the output is NO, then the non-CDB is not compatible, and you can check the
PDB_PLUG_IN_VIOLATIONS
view to see why it is not compatible. All violations must be corrected before you continue. For example, any version or patch mismatches should be resolved by running an upgrade or the opatch utility. After correcting the violations, runDBMS_PDB.CHECK_PLUG_COMPATIBILITY
again to ensure that the non-CDB is compatible with the CDB. -
Plug in the single instance non-CDB.
CREATE PLUGGABLE DATABASE ncdb USING '/home/oracle/ncdb.xml' COPY FILE_NAME_CONVERT = ('/disk1/oracle/dbs/', '/disk2/oracle/ncdb/') ;
If there is not sufficient space on the host, the NOCOPY
option can be used to create the PDB. In that case, a single-instance non-CDB is not useable after plug in as a PDB because the original data files has been used for the PDB. Make sure to create a backup before the conversion so that there is something to fall back on if anything goes wrong. -
Start with PDB upgrade after conversion if the version between the source single-instance non-CDB and the target CDB are different. For the same-version conversion, this step can be skipped.
sqlplus / as sysdba; alter session set container=ncdb alter pluggable database open upgrade; exit; dbupgrade -c ncdb -l /home/oracle
Review the upgrade log file in the
/home/oracle
directory. -
Open the pluggable database, check for pdb plug-in violations, and recompile the invalid objects.
alter pluggable database ncdb open; alter session set container=ncdb; select message from pdb_plug_in_violations where type like '%ERR%' and status <> 'RESOLVED'; $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -c 'ncdb' -e -b utlrp -d $ORACLE_HOME/rdbms/admin utlrp.sql
-
Execute
noncdb_to_pdb.sql
to update the data dictionary.sqlplus / as sysdba alter session set container=ncdb; @$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql;
Shut down and restart the container DB. The ncdb is taken out of restricted mode.
Migrate on-premises Oracle databases to Azure with PDB relocation
Oracle PDB relocation with the maximum-availability option employs PDB hot-clone technology, which allows source PDB availability while the PDB is copying over to the target. At switchover, user connections are redirected to the target PDB automatically. Thus, downtime is minimized independent of the size of the PDB. NetApp provides an Ansible-based toolkit that automates the migration procedure.
-
Create a CDB in the Azure public cloud on an Azure VM with the same version and patch level.
-
From the Ansible controller, clone a copy of the automation toolkit.
git clone https://github.com/NetApp-Automation/na_ora_aws_migration.git
-
Read the instruction in the README file.
-
Configure the Ansible host variable files for both the source and target Oracle servers and the DB server host's configuration file for name resolution.
-
Install the Ansible controller prerequisites on Ansible controller.
ansible-playbook -i hosts requirements.yml ansible-galaxy collection install -r collections/requirements.yml --force
-
Execute any pre-migration tasks against the on-premises server.
ansible-playbook -i hosts ora_pdb_relocate.yml -u admin -k -K -t ora_pdb_relo_onprem
The admin user is the management user on the on-premises Oracle server host with sudo privileges. The admin user is authenticated with a password. -
Execute Oracle PDB relocation from on-premises to the target Azure Oracle host.
ansible-playbook -i hosts ora_pdb_relocate.yml -u azureuser --private-key db1.pem -t ora_pdb_relo_primary
The Ansible controller can be located either on-premises or in the Azure cloud. The controller needs connectivity to the on-premises Oracle server host and the Azure Oracle VM host. The Oracle database port (such as 1521) is open between the on-premises Oracle server host and the Azure Oracle VM host.
Additional Oracle database migration options
Please see the Microsoft documentation for additional migration options: Oracle database migration decision process.