AWS experience with Oracle is a decade in the making with more than 10+ years of Oracle App experience (JD Edwards, E-Business Suite, Peoplesoft), 1000+ Oracle EBS instances running on AWS today, and 100k+ Oracle Applications running on AWS.
Organizations running Oracle E-Business Suite workloads are looking for different ways to migrate to AWS but are hesitant when it comes to the technology needed to complete this migration with minimal downtime and real-time replication.
This is where we usually start our discovery phase with clients, and the primary focus would be questioning about the expected RPO and RTO for this migration. In brief, Recovery Time Objective (RTO) is basically the amount of time a specific workload requires to restore its processes in the event of a disaster whereas Recovery Point Objective (RPO) focuses on the maximum acceptable amount of data that an organization can lose after a recovery in the event of a disaster and the organization can tolerate.
This blog will target a potential migration that requires 12 hours of RTO and 6 hours of RPO. Planning for this migration is sometimes tricky and expect a thorough analysis of the current running Oracle EBS environment to generate a well-defined solution. For that reason, I write down some questions that should be taken into consideration during your assessment phase:
- How many Applications and Databases will be part of this migration?
- What current tools are used to back up your Oracle EBS Workloads?
- Are you running your current production databases underlying Oracle E-Business Suite on Oracle Real Application Clusters (Oracle RAC)?
- What operating system and Oracle version are currently in use for the Application and Database servers? (You can collect this using application discovery tools such as AWS Application Discovery Service and Cloudamize)
- Do you have any plans to upgrade Oracle EBS or the DBMS in the near future?
- What is your current backup frequency for the running Oracle EBS workloads?
- Would you prefer to BYOL for the running operating systems or have it supplied by AWS?
- What is the current total data storage?
- Do you require Database Encryption at rest?
- Do you have any 3rd party integrations with the running Oracle EBS application?
- Do you have a running Oracle Enterprise support plan?
Replicating Oracle EBS to AWS can be achieved in different methods and tools such as:
- Data Guard
- Physical Standby
- RMAN
- Transportable Tablespaces
- DataPump
- AWS Snowball
In this scenario, we will assume that the client is utilizing RMAN to automate the backup and restore process, and their Oracle License does not support Oracle Data Guard. However, if you would like to achieve minimum downtime by using Oracle Data Guard, the migration sequence will look as follows:
- Replicate the database from On-prem to AWS using Data Guard
- Establish the replication from On-prem to AWS using Data Guard/Standby
- Replicate the Oracle Application files from On-prem to AWS using tools such as rsync or Amazon Application Migration Service (Amazon MGN)
- Recover the standby node
So, let's get started with the steps required to migrate your Oracle E-Business Suite to Amazon EC2 using RMAN backup-based duplication which is an Oracle native tool recommended by AWS to migrate Oracle EBS applications.
- Run pre-clone on the source database and application nodes
- Tar and Compress the database backup with archives using RMAN backup and copy it to the target node
- Clean up the target database and application node
- Copy the source application binaries and database binaries to the target node
- Catalog Backup pieces, and restore the database on Amazon EC2
- Run post-restore on the Target database node
- Untar the application stack on the target EC2 node
- Run post-clone steps on the application node
- Sync your $APPLCSF directory which includes all your APPLOG and APPLOUT files
Some might ask if Amazon DMS can do all this job by replicating the data directly from an Oracle EBS to either Amazon RDS or Amazon EC2. Although Amazon DMS looks like a great solution to copy the database data from source to destination, however, AWS doesn't recommend this approach for E-Business Suite Databases knowing that replicating or migrating Oracle E-Business Suite database is unlike any other regular Oracle Database and you can not simply use Golden Gate or Amazon DMS to replicate the entire database. Thus, specific data types used in the application might not work well if Amazon DMS was used and the supportability may be a challenge post-migration.
In this blog post, we have discussed in brief one of the migration patterns used to migrate Oracle E-Business Suite to AWS in a single zone architecture. In my next posts, I will work on another blog that will explain how you can perform this migration with real-time replication of the Oracle database and demonstrate the methods and AWS tools needed to achieve a highly available and resilient Oracle EBS environment on AWS.
References:
