X

Maximum Availability Architecture – Oracle’s industry-leading set of database high availability capabilities

Using Oracle GoldenGate for an Efficient & Flexible Oracle Cloud Migration

Nick Wagner
Product Manager

In this blog, we’ll focus on why Oracle GoldenGate (OGG) is the perfect product to use to migrate your production databases to Oracle’s cloud platforms; including Oracle Cloud Infrastructure, DBaaS, SaaS, and the Exadata Cloud Server and Cloud at Customer solutions. Using OGG to migrate to the cloud has many benefits: 

  1. Downtime can be eliminated in most cases, or as least drastically reduced. GoldenGate can be used to load the cloud database while the production database is still online.  
  2. Once the Oracle Cloud database is in use, GoldenGate can be used to replicate back to the on-premise environment, providing the ability to fail back to it should anything unforeseen occur with the new environment. 
  3. In addition to being able to migrate Oracle databases, Oracle GoldenGate supports many different databases, and can migrate from SQL Server, Sybase, Informix, MySQL, HP Nonstop, and many flavors of DB2 to the Oracle Cloud.  

Many companies are looking to move production databases to the Oracle Cloud, and there are many reasons why one would like to do this. Oracle GoldenGate can address two concerns that are constantly brought up when moving systems into any new cloud provider. First, the amount of downtime that it would take to move the data into the cloud, and second, how to failback to the on-premise environment should anything go wrong.  

Using Oracle GoldenGate to reduce the downtime of migrations has been something customers have done thousands of times over the past decade. The key to the technology is the logical replication, and the ability of OGG to allow the target database in the cloud to be built, while normal activity continues on the production database. When the database in the cloud is ready for use, OGG can replicate from that new environment, back to the old one in case you need to fail-back for any reason.  

Figure 1 – Migration to Oracle Cloud

Oracle GoldenGate can do more than just migrate Oracle databases into the cloud (figure 1), it can also replicate between dissimilar environments, and even different databases.  Whether the source database is Oracle, SQL Server, DB2 or many other relational databases, GoldenGate can capture transaction log changes of that database to obtain details on the changes that are being performed. Then the database in the Oracle cloud is built in the background while Oracle GoldenGate is capturing the ongoing changes from the production database.  So, if it takes 3 minutes or 3 days to move the database, it does not impact the production environment.  

Figure 1 (above), is a high level diagram that shows how OGG would migrate the data to the Oracle Cloud.  In the source datacenter, the Oracle GoldenGate Capture process would pull data from the transactions logs of the source database. As transactions are committed they would be written to disk.  These transactions are then sent into the Oracle cloud using AES256 bit encryption, or over HTTPS, TLS/SSL, or via VPN.  As the transactions are received in the cloud, the Oracle Goldengate Delivery process will apply them to the database, and this all occurs in real time with minimal latency.  If the source database is non-Oracle, or if there are datatype conversions or character set conversions required, the Delivery process will handle this.  If even more complex changes are needed, Oracle GoldenGate can be instructed do the transformation as it applies into the target database.  For such transformations you can use dozens of built in transformation routines or even PL/SQL to manipulate the data.  

Throughout the migration, you can stop the apply process at any time and begin testing on the new cloud server. The Oracle database has many features allowing you to test the new environment, including Oracle Flashback, Oracle Real Application Testing, and others. Once testing has been completed on the new cloud server, and GoldenGate has finished applying the changes and is caught up, then you can freely switch the users from the old production server into the new environment in the cloud. 

     

Figure 2 – Fail Back Configuration

Once testing has been completed on the new cloud server, and GoldenGate has finished applying the changes and is caught up, then you can freely switch the users from the old production server into the new environment in the cloud. To enable fail back capabilities (figure 2) simply configure GoldenGate to replicate from the new cloud server, back to the old database, just in case something unforeseen does go wrong, you can quickly switch back to the old platform.  You can learn more about using GoldenGate here.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.