Oracle Database Cloud Service – Near Zero Downtime Migration to the Cloud

Introduction

Oracle Database Cloud Service is a great PaaS Service to provide the target platform for migrations of On Premise workloads to the Oracle Cloud. There are a number of migration tools available to support the majority of use cases, however sometimes the focus is on the continuity of service, especially when continuity of service and minimised downtime are main requirements. If that’s the case Golden Gate and Data Guard are great options. The Golden Gate approach is described here, however it isn’t necessarily always the best choice specifically if complex data types are in play – some data types are simply not supported. The Data Guard approach – focus of this article – is a high performance, simple to setup solution that provides an efficient way to migrate to the Cloud with near zero downtime.

image1

This approach is based on the fact that Oracle runs the same software that is manageable with the same skills – OnPremise and in the Cloud to allow the same architecture across the board. This means essentially the same software that is used on Premise is also deployed in the Oracle Data Cloud Service allowing great interoperability between the two.

 

 

Prerequisites

In order to achieve the minimal downtime during the migration the recommendation is that the On Premise (Source) database is running the Release and Patch level identical to what the Cloud Instance (Target) database will be running in the cloud. At the time of writing this article the following release are available: Oracle Database 11gR2, 12cR1 and 12cR2. The patch level should be matched at provisioning time of the Cloud Instance. It is supported to upgrade / patch the database during this migration – the details can be found in this support article: Mixed Oracle Version support with Data Guard Redo Transport Services (Doc ID 785347.1). Even heterogeneous migrations are possible for example between Windows and Linux – details here: Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration Doc ID 413484.1. However introduction of differences between source and target might reduce the actual switchover timings.

 

Migration Process

The setup for this process can be broken down into eight simple steps as shown in the diagram.

 image2

 

Step 1: Setup DBaaS as migration target instance to obtain IP and other configuration.

This step requires only a few steps to provision an initial target database in the Cloud. After logging in to the Cloud UI create the database with the required software edition. Select Database Type as Single Instance and a minimum of Enterprise Edition for Data Guard support, please note Active Dataguard requires at least Enterprise Edition – Extreme Performance Edition.

image3

 

 

Step 2: Delete Instance and prepare for Restore

Login to the VM holding the newly created database and proceed to drop the database – descirbed here. The database is dropped to make room for the on premise database that will be migrated to the Cloud.

Step 3: Configure Network and SSH between Cloud and OnPrem

In this step a security application and rule have to be created for the listener and the additional standby listener that is used by Data Guard for the communication. The communication should be limited to the specific source IP of the source database host.

image4

The security rule for the standby listener should be running on a different port as the main listener, which runs on 1521 by default. The screenshot shows how to configure port 2484 for the communication.

image5

You shoud additionally open ssh connectivity between the On Premise host and the Cloud VM with key based authentication as described here.

Step 4 : Download and configure Database Backup scripts

This steps requires to download and configure the Oracle Cloud Database Backup scripts from OTN here – this is straight forward and allows to backup the On Premise database straight to the Cloud  – detailed steps are here.

image6

Step 5: Backup up the database to the backup service

Execute the backup of the on premise database to the Oracle Cloud. The configuration is stored in the file  /opc/opcodbs.ora by default – you can change that location based on your requirements. Updating this file will allow you to backup the database to different target container.

image7

Step 6: Initiate DR Database – a new database is instantiated from the backup

Since the database is backed up in the cloud already this step is straight forward. Simply login to the Cloud VM and execute the restore while pointing to the same back container as On Premise.

image8

Step 7: Configure Data Guard / Active Data Guard

The configuration of Data Guard itself is covered in this white paper.

Additional tooling to simplify this process is being developed and it will be referenced here, once it becomes available.

Step 8: Switchover to Cloud DB and decommission On-Premise

This is the final step of the migration once the Data Guard has been established. This is the actual migration and should be tested thoroughly. The recommended tool to execute the Switchover is the Data Guard command-line interface (DGMGRL).

image9

Switchover Performance

An important part of the migration analysis is the review of the actual switchover time. This number gives a good idea of how close the migration time can be reduced to “Near-Zero”. The following graph shows examples of the different switchover times as analyzed in detail here.

Depending on the configuration and the active connections that have to be redirected into the cloud the timing varies significantly.

image10

In the diagram SNGL-MNT describes a single instance with a mounted standby as created in this article and delivers the best performance without active connections. Active Dataguard adds a few seconds. However if there are active connections to the database it will take additional time to switch those into the cloud and the application has to be capable of supporting the switchover. Adding Oracle Real Application Cluster (RAC) to the mix also increases the switchover time.

 

Further Reading

 

Disaster Recovery to the Cloud White Paper

http://www.oracle.com/technetwork/database/availability/dr-to-oracle-cloud-2615770.pdf

 

Client Failover Best Practices for Highly Available Oracle Databases

http://www.oracle.com/technetwork/database/availability/client-failover-2280805.pdf

Add Your Comment