Best Practices from Navisite for Running Amazon RDS Custom with Oracle EBS

By Tom Monk, Sr. Director, Product Management – Navisite
By Tom Camarro, Vice President, Solution Architecture – Navisite
By Lesley Ajanoh, Partner Database Leader; and Andrew Boyd, DPS, Sr. PMSA – AWS
By Varvara Murphy, Sr. Solutions Architect; and Simon Cunningham, Sr. Oracle Specialist SA – AWS

Navisite

Amazon RDS Custom for Oracle provides all the management benefits of Amazon Relational Database Service (Amazon RDS), as well as the ability to customize the database.

While Amazon RDS makes it easy to set up, operate, and scale relational databases within Amazon Web Service (AWS), legacy applications like Oracle E-Business Suite (E-BS) require customization of database environments not supported by Amazon RDS.

Amazon RDS Custom for Oracle solves the need for creating customized database workloads, but many organizations still have questions about how it works and how it differs from Amazon RDS or self-managed Amazon Elastic Compute Cloud (Amazon EC2) environments.

In this post, we present Navisite’s proof of concept (POC) implementation of Oracle E-BS with Amazon RDS Custom for Oracle, along with advice for setup and management.

Navisite is an AWS Premier Tier Services Partner and Managed Service Provider (MSP) with specialized AWS Migration and Oracle Competencies. With over a decade of experience guiding Oracle-to-AWS migrations, Navisite brings proven methodologies to help organizations modernize Oracle applications and databases leveraging Amazon RDS and other AWS services and technologies.

Proof of Concept Goals

Navisite commonly conducts POCs with customers and in collaboration with AWS. With Amazon RDS Custom for Oracle, we decided to conduct a POC to answer anticipated customer questions, and ensure we’d be in the best position to support this new AWS service.

The team at Naviste had two goals for this POC:

Support organizations considering implementing and managing Oracle E-BS with Amazon RDS Custom for Oracle.
Understand how Oracle enterprise applications work with Amazon RDS Custom for Oracle.

We also wanted to cover all phases of deployment, from migration to ongoing support. To help customers evaluate and implement Amazon RDS Custom for Oracle, we sought to understand:

How does the service affect the build process and what capabilities exist for CI/CD and build integration?
What does one need to do to accommodate Oracle E-BS?
Are there limitations to the build?
How does the service affect the migration?
How does one get on-premises data into the system, and how does that process differ from Amazon EC2 or RDS?
How to use the service to improve build and migrate processes?
Will the service work with older versions of Oracle no longer in support?

To help customers understand how Amazon RDS Custom for Oracle can help support daily operations, we sought to understand how to:

Facilitate cloning.
Facilitate patching and maintenance.
Handle backups and disaster recovery.
Monitor and administer the service.

Proof of Concept Design

We designed the POC using a real-world example of a common Oracle E-BS architecture and performed all the steps we’d take to migrate and go live. Our teams tested migrating an Oracle E-BS database from a virtual machine (VM) to an Amazon RDS Custom for Oracle instance.

High availability and disaster recovery configuration.
Backup and recovery processes.
Oracle E-BS database patching.
Database cloning.
Infrastructure monitoring.
Use of third-party tools or products.

Figure 1 – Oracle E-BS architecture used by Navisite.

Execution and Outcomes

Navisite’s close relationship with AWS leveraged exceptional support and collaboration from the AWS specialist solution architects and product teams, enabling it to achieve specialist knowledge when designing and executing this POC.

Migration

Migrations are often complex, especially when factoring in cutovers with requirements for zero or low downtimes. To validate E-BS capabilities, Navisite devised an end-to-end migration scenario. For each phase, capabilities were specified that supported a complex migration, as well as services supporting the full application stack using the pillars of the AWS Well-Architected Framework.

Tests performed included:

Oracle E-BS Vision environment deployed on Amazon EC2 instances. Full high availability can be achieved using AWS services such as AWS Lambda and AWS Step Functions. Further information can be found at this AWS blog post.
Full backup of the source system using RMAN.
Deployment of Amazon RDS Custom for Oracle version 12.1 Enterprise Edition using the command line interface (CLI), although it’s possible to deploy through a CI/CD pipeline using AWS CloudFormation or Terraform.
Migration of the database tier from Amazon EC2 to Amazon RDS Custom for Oracle, and repointing of the application tier.

Navisite-RDS-Oracle-2

Figure 2 – Navisite’s migratin process.

Amazon RDS Custom for Oracle automates database administrator (DBA) activities, specifically uptime, and has a feature called support perimeter that ensures the database remains in a viable configuration so that automation is not impacted.

Automation mode must be paused when making any changes. Otherwise, automation will restart the database automatically, which could impact changes. If a DBA makes a change to an environment that risks impacting Amazon RDS Custom automation, the instance will be flagged as being in an unsupported configuration, and automation will be disabled.

Additional steps taken included:

Amazon RDS Custom for Oracle instance required customization to support Oracle E-BS. Navisite executed these activities as one would on an EC2 instance by installing Linux packages, installing Examples, and patching the Oracle Home.
The service comes with a default database, which the team dropped and then created a new database from its RMAN backup, similar to that on an EC2 instance.
Navisite encountered an Oracle cloning bug when applying the PSU patches (Doc ID 2235541.1), and the team completed the database configuration and began to repoint the application tier.
Updated the tnsnames configuration and ran adautocfg.sh on the application and database tiers. Navisite had a few challenges with tnsnames, hostname, and domain name system (DNS) configuration, but these were common issues one would see during clone, upgrade, or migration.
Finally, the team ran through an adop cycle to apply an application patch without issue.

Navisite successfully installed a two-tier Oracle E-BS 12.2 environment running database version 12.1. The environment was performant and fully available.

Disaster Recovery

Navisite followed Oracle best practices for setting up Oracle Data Guard with Oracle E-BS (1963472.1):

Paused the automation mode.
Provisioned a basic read replica using the AWS CLI and ensured network connectivity was available between primary and secondary instances.
Created a database user for Oracle Data Guard and configured the service using Oracle Data Guard following standard AWS documentation.
Once configured, the team enabled automation mode.

Further information on deploying RDS Custom Oracle Data Guard can be found in this AWS blog post.

To test this process, the team paused automation mode, executed a switchover, and executed the switch roles command from Oracle Data Guard broker, switching application services to repoint to the new primary database node using the standard process. In a production environment, many of the manual switchover tasks can be eradicated by configuring a highly available network to switch the network information automatically.

Navisite noticed a few items during distaste recovery (DR) testing:

Standard archive log retention period was set as 24 hours; it was too short for most Oracle E-BS environments, so the team increased it to support an industry-standard recovery point objective (RPO).
The longer retention period meant more archived redo logs on disk. Disk consumption went up.

Backup and Recovery

There are two backup and recovery methods for Amazon RDS Custom for Oracle:

One method is the tightly integrated AWS Native Snapshot. Backups and snapshots are configured like an Amazon RDS for Oracle instance and can be created to a schedule or on demand. The process to recover from a snapshot is the same as Amazon RDS for Oracle. Navisite successfully executed a full database snapshot and restore.
Backups can be done manually using Oracle or third-party backup tools. These are executed directly on RDS instances or from within the database. Navisite tested RMAN, its backup tool of choice from Oracle databases, and successfully executed a backup script from within the instance and restored the database from that backup.

Cloning

Cloning an Oracle E-BS environment is an essential process. Using both AWS Backup and manual RMAN backups, Navisite created an Oracle EBS clone environment following the Oracle process (1383621.1).

Monitoring and Third-Party Tooling

Many enterprise workloads require the use of a third-party tool, and all require monitoring. Amazon RDS Custom for Oracle can be monitored using Amazon CloudWatch metrics, which collects data on both the infrastructure and database status. Following familiar patterns and processes, Navisite was able to direct these metrics to generate alerts.

The team installed an Oracle Enterprise Manager agent to collect additional data and alerts without additional steps required for an EC2 instance. Navisite uses many management tools, including antivirus, which it was also able to install without issues. Further information is available in this AWS blog post.

Patching

A benefit of Amazon RDS Custom for Oracle is the ability to create a baseline of the Oracle Home patch level. This is done by creating a Custom Engine Version (CEV), which is a snapshot of one’s Oracle Home. Along with an Amazon Machine Image (AMI), it builds a gold image of the database instance. This helps with configuration management and enables the promotion of a set of Oracle patches through database environments with a simple API call.

Once a CEV is created, it’s easy to launch an instance from that baseline or to apply it to an existing instance.

However, updating or creating the CEV is more complicated. The process is to copy all required Oracle patches to an Amazon Simple Storage Service (Amazon S3) bucket and then use a JSON document to define the patches to include in the CEV. This process should construct the Oracle Home definition for application to a new or existing database.

Key Takeaways

Migration: A benefit of Amazon RDS Custom for Oracle is the openness of the instance. Customers can take advantage of Oracle Data Guard to migrate their workload into AWS, a reliable process that was previously unavailable. Customers will still be able to use logical replication services for migration, including Oracle GoldenGate and AWS Database Migration Service (AWS DMS).
Disaster recovery: Amazon RDS Custom for Oracle does an excellent job of supporting and monitoring Oracle Data Guard processes. However, application and network aspects are not covered. Anyone wishing to adopt Amazon RDS Custom for Oracle needs to develop a process for the application and network switchover to meet RTO/RPO requirements. Fortunately, AWS supports the ability to automate many of those activities.
Backup and recovery: Both custom and AWS Backups worked well. Navisite anticipated a combination of AWS Backup-managed snapshots and custom backup scripts would be required to support customer requirements. Point-in-time recovery (PITR) is also supported out of the box.
Cloning: Database cloning should be simplified by moving to Amazon RDS Custom for Oracle, as many of the steps can be automated within AWS using AWS Batch and AWS Step Functions.
Monitoring and third-party tooling: Amazon RDS Custom for Oracle can be monitored with Amazon CloudWatch metrics. Customers can rationalize their monitoring tools and remove third-party products without a loss of functionality. Further information is available in this AWS blog post.
Patching: Issues with CEV creation and updates prevented Navisite from environment patching as efficiently as we desired. These issues were resolved in later database engine versions.

Conclusion

Amazon RDS Custom for Oracle is a strong option for organizations looking to migrate custom Oracle workloads to AWS. The success of Navisite’s proof-of-concept, however, should be viewed as a starting point. The team recommends a tailored POC to review the service ahead of adoption, just as you would for any other critical workload.

Navisite has migrated hundreds of Oracle applications and databases to AWS since 2011, guiding customers through the migration lifecycle—from roadmap and migration analysis, including Oracle licensing impact, to migration execution, managed cloud services, and ongoing innovation and support.

Since completing this POC, Navisite has expanded its professional services capabilities to support organizations looking to adopt Amazon RDS Custom for Oracle. Navisite has also expanded its managed services cloud operating model to provide first-in-class managed services for Amazon RDS Custom for Oracle.

To learn more about Navisite’s services for Oracle-to-AWS migrations, visit the Navisite website. You can also learn more about Navisite in AWS Marketplace.

.

.

Navisite – AWS Partner Spotlight

Navisite is an AWS Premier Tier Services Partner and MSP with specialized AWS Migration and Oracle Competencies. With over a decade of experience guiding Oracle-to-AWS migrations, Navisite brings proven methodologies to help organizations modernize Oracle applications and databases.

Contact Navisite | Partner Overview | AWS Marketplace

AWS Partner Network (APN) Blog