- Newest
- Most votes
- Most comments
I have migrated several on-premises Oracle environments to EC2 (OEL/RHEL) across several AWS regions using Data Guard. While the process is essentially identical to an on-premises setup, there are several cloud-specific nuances to keep in mind.
I generally treat every migration as a planned project with a defined runbook, as each environment presents unique challenges - much like a traditional on-premises migration, but with additional cloud/AWS architectural decisions. Key considerations include:
- Storage Strategy: Evaluate whether EBS volumes (Single-AZ) meet your requirements or if you should host database storage on FSx for NetApp ONTAP (via NFS or iSCSI) to better support failover and DR scenarios.
- Failover & Oracle Licensing: Depending on your agreement with Oracle, you must be careful with your choice of EC2 instance types and families. Always verify that the specific instance type and family are officially supported by Oracle and are okay with your licensing model.
- RPO/RTO Alignment: Ensure your recovery objectives are properly mapped to AWS network and architectural constraints. For example, consider whether you need an Active-Active setup on two DB servers across different AZs, or if you can achieve high availability at the storage tier (FSxN Multi-AZ) while keeping the EC2 instance level in a single AZ. In case, should an AZ outage occur, you would simply restart the DB server in the secondary AZ.
- Naming Conventions: Do not overlook "Oracle technical limitations"; e.g. verify that your AWS naming conventions align with the character limit often found in Oracle environments.
I hope this helps. As this is my day-to-day work, I can confirm that migrating Oracle to AWS generally works well. However, I always treat these migrations as part of a larger project - not just due to the technical requirements, but also because of the complexities surrounding Oracle licensing and support.
Your approach of using Oracle Data Guard to migrate your on-premises Oracle database to EC2 is a solid strategy that aligns with AWS best practices. Here are some expert feedback and suggestions for your migration:
Architecture Considerations: Your planned setup with a primary database on-premises synchronizing to standby databases on EC2 is appropriate. For high availability in AWS, placing your standby instances (S1 and S2) in different Availability Zones within the Melbourne region is recommended. This provides resilience against AZ-level failures.
Data Guard offers both synchronous and asynchronous redo transport options - choose based on your Recovery Point Objective (RPO) and Recovery Time Objective (RTO) requirements. The synchronous mode provides zero data loss but may impact performance depending on network latency, while asynchronous mode offers better performance with minimal data loss risk.
Network Connectivity: A dedicated, high-bandwidth connection between your on-premises data center and AWS is strongly recommended. AWS Direct Connect would be ideal for this migration approach, as it provides consistent network performance and lower latency, which is crucial for Data Guard synchronization.
Infrastructure Setup Tasks: Before migration, ensure you complete these foundational tasks:
- Create a Virtual Private Cloud (VPC) and subnets in your AWS account
- Configure security groups and network access control lists (ACLs) to allow Data Guard traffic
- Properly size and configure your EC2 instances based on your database workload requirements
- Install Oracle software on the EC2 instances with the same version as your source database
Migration Execution: Your cutover strategy of switching roles from standby to primary during a maintenance window is the correct approach. During cutover, applications will need to be temporarily unavailable until they can connect to the new primary database on EC2.
Additional Considerations:
- Validate that your source and target Oracle database versions are compatible
- Test the switchover process thoroughly before the actual cutover
- Plan for application connection string updates to point to the new primary database
- Consider using logical hostnames to simplify the migration and future disaster recovery scenarios
This Data Guard approach minimizes downtime and provides a reliable rollback option if issues arise during cutover, making it an excellent choice for your migration requirements.
Sources
Migrate an on-premises Oracle database to Amazon EC2 by using Oracle Data Pump - AWS Prescriptive Guidance
Database migration tools - Migrating Oracle E-Business Suite on AWS
Migrate an on-premises Oracle database to Oracle on Amazon EC2 - AWS Prescriptive Guidance
Relevant content
asked 2 years ago
