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.
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.
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.
The setup for this process can be broken down into eight simple steps as shown in the diagram.
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.
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.
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.
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.
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.
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.
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).
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.
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.
Disaster Recovery to the Cloud White Paper
Client Failover Best Practices for Highly Available Oracle Databases