Skip to main content
NetApp Solutions

Database migration from on-premises to Azure cloud

Contributors acao8888 banum-netapp

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.

  1. Build a shell container database on the same host as the single-instance database in a separate ORACLE_HOME.

  2. Shut down the single instance database and restart it in read-only mode.

  3. Run the DBMS_PDB.DESCRIBE procedure to generate the database metadata.

        pdb_descr_file => '/home/oracle/ncdb.xml');
  4. Shut down the single-instance database.

  5. Start up the container database.

  6. Run the DBMS_PDB.CHECK_PLUG_COMPATIBILITY function to determine whether the non-CDB is compatible with the CDB.

      compatible CONSTANT VARCHAR2(3) :=
               pdb_descr_file => '/disk1/oracle/ncdb.xml',
               pdb_name       => 'NCDB')
        ELSE 'NO'

    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, run DBMS_PDB.CHECK_PLUG_COMPATIBILITY again to ensure that the non-CDB is compatible with the CDB.

  7. Plug in the single instance non-CDB.

    CREATE PLUGGABLE DATABASE ncdb USING '/home/oracle/ncdb.xml'
      FILE_NAME_CONVERT = ('/disk1/oracle/dbs/', '/disk2/oracle/ncdb/')
    Note 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.
  8. 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;
    dbupgrade -c ncdb -l /home/oracle

    Review the upgrade log file in the /home/oracle directory.

  9. 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/ -n 1 -c 'ncdb' -e -b utlrp -d $ORACLE_HOME/rdbms/admin utlrp.sql
  10. Execute noncdb_to_pdb.sql to update the data dictionary.

    sqlplus / as sysdba
    alter session set container=ncdb;

    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.

  1. Create a CDB in the Azure public cloud on an Azure VM with the same version and patch level.

  2. From the Ansible controller, clone a copy of the automation toolkit.

    git clone
  3. Read the instruction in the README file.

  4. 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.

  5. Install the Ansible controller prerequisites on Ansible controller.

    ansible-playbook -i hosts requirements.yml
    ansible-galaxy collection install -r collections/requirements.yml --force
  6. 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
    Note 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.
  7. 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
    Note 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.