More about AWS database
- AWS Data Analytics: Choosing the Best Option for You
- Amazon DocumentDB: Basics and Best Practices
- AWS NoSQL: Choosing the Best Option for You
- AWS Big Data: 6 Options You Should Consider
- Oracle on AWS: Managed Service vs. Managed Storage Options
- AWS Oracle RDS: Running Your First Oracle Database on Amazon
- SQL Server in AWS: Two Deployment Options
- DynamoDB Pricing: How to Optimize Usage and Reduce Costs
- AWS Databases: The Power of Purpose-Built Database Engines
- AWS MySQL: Two Ways to Enjoy MySQL as a Service
- AWS Oracle: How to Lift and Shift Your Oracle DB to Amazon
- Overcome AWS RDS instance Size Limits with Data Tiering to AWS S3
Managing Oracle databases is not an easy task, especially at large scale. Many organizations are performing ‘lift and shift’ of Oracle databases to the public cloud, to consume Oracle as a managed service rather than manage the infrastructure themselves. There are two main AWS database services that can run Oracle databases: The Relational Database Service (RDS) and Amazon EC2.
In this post, we’ll help you understand the options, and the tools and techniques available for migrating your existing databases to AWS. In addition, we’ll show how NetApp Cloud Volumes ONTAP can help optimize storage for AWS Oracle databases.
In this article, you will learn:
- Oracle database on AWS: RDS vs EC2
- Strategies for migrating Oracle to AWS
- Oracle to AWS migration tools
- Optimizing AWS Oracle Database Storage with Cloud Volumes ONTAP
Oracle Database on AWS: RDS vs EC2
When you want to run an Oracle database on AWS, you have two main options. You can run it on the Amazon Relational Database Service (RDS) or you can run it on EC2 instances.
RDS is a managed service in which AWS manages and maintains the database for you. Services include provisioning, updating, monitoring, backups, and hardware scaling. You can use it with either Provisioned IOPS storage or General Purpose (SSD) storage. RDS also offers push-button, synchronous Multi-AZ replication.
Amazon RDS is good for:
- Focusing on using your database without all the maintenance
- Maximizing high-availability and synchronous replication
- Avoiding upfront license investments; RDS includes the cost of the Oracle license in your hourly payments
- Hands-free backup management
Hosting Oracle on EC2 means self-managing your database. You have full control over the setup and configuration, but you are also responsible for all of the maintenance. This option is similar to hosting your database on-premises. When using EC2, you need to provision EC2 instances, storage, and networking resources.
AWS EC2 is good for:
- Maintaining control over your environment and operating systems
- Large databases that exceed 80% or more of the RDS instance size
- Running Oracle Real Application Clusters (RACs)
- Fast, high volume migrations
- Preserving database and application IP addresses
How to choose
RDS is simpler to set up and enables you to focus on using the database rather than administering it. EC2 is more challenging to set up but provides greater scalability, flexibility and control than RDS. The option that is right for you depends on your applications and requirements. Additionally, if you are running multiple databases, you may find that both services are useful for different implementations.
Strategies for Migrating Oracle to AWS
When migrating an existing Oracle database to AWS, there are a few different strategies you can use. The strategy that is right for you depends on:
- Database size
- Oracle version
- Network connectivity limitations
- Database configurations and tools availability
- Time allotted for migration
A one-step migration is the simplest option and is good for small databases. With this method, you must stop your database, extract the data, and upload the data to your AWS resources. Once uploaded you can test that your data was transferred successfully, and that the new database is faithful to the source.
Provided everything went smoothly, you can then connect your applications to the new database and continue working. The downsides of this method are that it requires downtime and that the data must be moved in one go.
The two-step method eliminates some of the downtime required by the one-step. It can also support databases of any size, making it a more flexible option. In this method, you extract a point in time copy of your data from your database while it is running. This data is then uploaded to your AWS resources and the new database is checked and verified for accuracy and usability.
Next, you need to account for any data that has changed in the source database since your point in time copy. This requires shutting down the database and copying the changes over to your prepared database in AWS. Since the bulk of your data has already been moved, this should be a much shorter process. After this new data is validated, you can switch over to the new database.
For some organizations and mission-critical applications, any downtime period is unacceptable. In these cases, there is a more complex method you can use. This method is similar to the two-step method but rather than shutting down your database in the second step, you set up a sync to account for changes.
Like the two-step method, you start out by taking a point in time copy and transferring it to AWS. Then, you need to set up a replication process that syncs changes in real-time between your existing and new databases.
This sync enables you to avoid downtime but can impact the performance of your source database. If a few minutes of downtime are acceptable, a better option is asynchronous replication. Since this method keeps your databases identical, you can move applications at any time.
Continuous data replication
Similar to the above method is the continuous data replication method. This method simply leaves the synchronization link between the two databases, even after you have swapped over your applications. This method is best suited for business intelligence or disaster recovery purposes. When using this method, you should use asynchronous replication to avoid performance issues.
Oracle to AWS Migration Tools
After you have determined the migration strategy that’s right for you, you can begin planning the functional processes of your migration. Many of these processes can be simplified with tools made available from AWS or Oracle. Below are a few tools you can consider using.
AWS Database Migration Service
The AWS Database Migration Service is a paid service you can use to migrate with minimal downtime. The service continually replicates changes between your source and target databases. This enables you to continue using the source database until your migration is complete. With this service, you can also leave the replication active for as long as you wish. Just keep in mind that there are costs for replication.
AWS Snowball is an appliance you can use to transfer large amounts of data. It can help you avoid large network costs, long transfer times, and can provide greater data security during transfer.
To use Snowball, you simply create a transfer job in the AWS Management Console to have the appliance shipped to you. After you transfer your data, the appliance is picked up and data is transferred to S3. From there, you can transfer it to your database instances.
Oracle Recovery Manager (RMAN)
To extract data from your source database, you can use Oracle RMAN. This tool enables you to back up your source data. You can then export this data to AWS directly via a VPN or AWS Direct Connect connection, or transfer it to a Snowball appliance.
Oracle Data Pump
Oracle Data Pump is a tool you can use to move data and metadata from your source database. It enables you to smoothly perform export/import operations and to send files directly to Oracle machines or Amazon S3 buckets. From there, you can import data to your desired database.
Optimizing AWS Oracle Database Storage with Cloud Volumes ONTAP
NetApp Cloud Volumes ONTAP, the leading enterprise-grade storage management solution, delivers secure, proven storage management services on AWS, Azure and Google Cloud. Cloud Volumes ONTAP supports up to a capacity of 368TB, and supports various use cases such as file services, databases, DevOps or any other enterprise workload.
In particular, Cloud Volumes ONTAP helps in addressing database workloads challenges in the cloud, and filling the gap between your cloud-based database capabilities and the public cloud resources it runs on.
Cloud Volumes ONTAP can be especially useful when considering running Oracle in the cloud.