Migrate an Oracle database to an Azure virtual machine

Azure Virtual Machines

Azure ExpressRoute

Azure VPN Gateway

This article describes how to use Oracle Data Guard to migrate an on-premises Oracle Database to an Azure virtual machine (VM). This article assumes that you have a basic understanding of Oracle Database technologies, Azure compute, and Azure networking. This scenario builds on the scenario in Migrate Oracle database workloads to Azure.

Architecture

The following diagram shows an example of this scenario.

Download a Visio file of this architecture.

Scenario

Consider the following scenario details:

In your on-premises network, you have an existing Oracle Database instance, and you want to migrate a database from that instance to an Azure VM.
The database is 20 TB and runs on Oracle Enterprise Linux (x86). The database version is Oracle Database 19c, Enterprise Edition.
The database is Real Application Clusters (RAC)-enabled, which includes two nodes. For disaster recovery, you replicate the database via Oracle Data Guard to another datacenter that's geographically distant from the primary database location.
You conducted an assessment of your on-premises Oracle Database and application services and deployed a VM in Azure that has the required compute size and storage configuration.
You place the VM in the database subnet that's in the Oracle virtual network, which peers to the hub virtual network. The IP address range of the database subnet is 10.42.1.0/24.
In the hub virtual network, the traffic has to traverse a non-Microsoft network virtual appliance (NVA), such as FortiGate, Check Point, or Cisco. The NVA functions as a routing device, which helps ensure that connectivity between the VM and the on-premises Oracle Database implementation is fully routable. You configure the NVA to inspect all traffic that goes to and from on-premises. The IP address of the hub NVA is 10.0.0.5.
You configure hybrid connectivity in the hub virtual network via an Azure ExpressRoute connection to your on-premises network.
You need to migrate the on-premises database to the Azure VM with the minimum amount of downtime possible. You decide to use Oracle Data Guard and Oracle Recovery Manager (RMAN) for the migration.

Establish network connectivity

To use Oracle Data Guard for migration, you need to ensure that the source and target databases can communicate with each other.

Create an Azure route table and associate it with the database subnet.
Point the Azure route table to the IP address of the hub NVA to route to the on-premises environment.
Configure the hub NVA to route traffic between the on-premises environment and the database subnet.

Configure the route table

Use the following configuration to create an Azure route table, and associate it with the database subnet:

Address prefix: 192.168.0.0/16
Next hop type: Virtual appliance
Next hop IP address: 10.0.0.5
Name: <Route table name>

The following diagram shows an example of the updated network configuration.

Do the following steps to verify connectivity.

Sign in to the Azure VM. Verify that you can use the Secure Shell (SSH) protocol to establish a connection to the on-premises database server.
Sign in to the on-premises database server. Verify that you can use the SSH protocol to establish a connection to the Azure VM.

Do migration activities

Use RMAN to back up the database from the on-premises database server and restore it onto the target system. For more information, see Restore a database on a new host.

Depending on the database backup file size and network bandwidth, you might be able to copy the backup files directly to the Azure VM on a staging area set of disks that you specifically create for that purpose. If you can't use that method because of network bandwidth constraints, you can use Azure Data Box to copy the backup files to Azure. After the files are in Azure blob storage, you should copy them to the Azure VM staging area set of disks for the restore operation.
Configure Oracle Data Guard between the on-premises database server (primary replica) and the Azure VM database server (secondary replica). For more information, see Create a physical standby database.
After the Oracle Data Guard replication finishes and the databases sync, perform a switchover to the Azure VM. For more information, see Role transitions. Coordinate this step with the application team to ensure that they update application services to point to the new database.
Do the following application migration activities in parallel with the database migration to help ensure the least amount of downtime.
- Migrate application services in accordance with your plans and discussions.
- Update the application services to point to the new database, including the connection string, Transparent Network Substrate (TNS) entries, and other required configurations.
- Verify that the application services work as expected.

Do post-migration activities

Configure backup for the database on the Azure VM. For more information, see Backup strategies for Oracle Database on an Azure Linux VM.
Azure VMs don't support Oracle RAC, so consider using Oracle Data Guard for high availability and disaster recovery. For more information, see Business continuity and disaster recovery for Oracle on Azure VMs.
Run the on-premises database as a secondary Data Guard replica for a period of time to ensure that the migration is successful.
After you no longer need the on-premises database, decommission the database and the server. Review changes that you made to ports and the firewall to allow communication between the on-premises environment and the Azure VM. Convert any changes that you no longer need.

Conclusion

Do the preceding configuration changes to migrate your database from an on-premises environment to an Azure VM. The configuration changes help ensure that the source and target databases can communicate with each other and that you can do the migration with minimal downtime.

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Jan Faurskov | Cloud Solution Architect
Güher Kayali Sarikan | Cloud Solution Architect

To see non-public LinkedIn profiles, sign in to LinkedIn.

Next steps

Review the following articles to ensure that your implementation follows recommended practices:

Share via