AWS Prescriptive Guidance

Migrating Oracle databases

to the AWS Cloud
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud

AWS Prescriptive Guidance: Migrating Oracle databases to the AWS

Cloud
Copyright © 2020 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.

Amazon's trademarks and trade dress may not be used in connection with any product or service that is not
Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or
discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may
or may not be affiliated with, connected to, or sponsored by Amazon.
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud

Table of Contents
Home ............................................................................................................................................... 1
Overview ................................................................................................................................... 1
Oracle database migration strategies .................................................................................................... 3
Choosing the right migration strategy .......................................................................................... 3
Online and offline migration ....................................................................................................... 4
Homogeneous database migration ....................................................................................................... 5
Amazon RDS for Oracle .............................................................................................................. 5
When to choose Amazon RDS .............................................................................................. 5
High availability ................................................................................................................. 6
Read replicas ..................................................................................................................... 7
Amazon EC2 for Oracle ............................................................................................................... 9
When to choose Amazon EC2 .............................................................................................. 9
High availability ............................................................................................................... 10
VMware Cloud on AWS for Oracle .............................................................................................. 11
When to choose VMware Cloud on AWS .............................................................................. 11
Tools ....................................................................................................................................... 11
Oracle SQL Developer ....................................................................................................... 13
Oracle SQL *Loader .......................................................................................................... 13
Oracle Export and Import .................................................................................................. 13
AWS DMS ........................................................................................................................ 13
Oracle Data Pump ............................................................................................................ 14
Oracle GoldenGate ........................................................................................................... 15
Oracle Data Guard ............................................................................................................ 16
Oracle RMAN ................................................................................................................... 16
CloudEndure Migration ..................................................................................................... 17
VMware HCX .................................................................................................................... 17
Licensing options ..................................................................................................................... 17
License Included ............................................................................................................... 18
BYOL .............................................................................................................................. 18
Heterogeneous database migration .................................................................................................... 19
Tools ....................................................................................................................................... 20
AWS WQF ........................................................................................................................ 21
AWS SCT ......................................................................................................................... 21
AWS DMS ........................................................................................................................ 21
Best practices for migrating to Amazon RDS for Oracle ......................................................................... 22
Provisioning your target database .............................................................................................. 22
Exporting data from your source database .................................................................................. 22
Transferring data dump files to AWS .......................................................................................... 23
Importing data to your target database ...................................................................................... 23
Post-import steps ..................................................................................................................... 23
Testing the migration ............................................................................................................... 23
Operating and optimizing your Amazon RDS database .................................................................. 24
Oracle database migration patterns .................................................................................................... 25
Partners .......................................................................................................................................... 26
Additional resources ......................................................................................................................... 27
Appendix: Oracle migration questionnaire ........................................................................................... 28
General information ................................................................................................................. 28
Infrastructure ........................................................................................................................... 28
Database backups ..................................................................................................................... 29
Database security ..................................................................................................................... 29
Database high availability and disaster recovery ........................................................................... 29
AWS Prescriptive Guidance glossary .................................................................................................... 30
Document history ............................................................................................................................. 34

iii
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Overview

Migrating Oracle databases to the

AWS Cloud
Sagar Patel, Database Specialty Architect, AWS Professional Services

February 2020 (last update (p. 34): March 2020)

Amazon Web Services (AWS) provides a comprehensive set of services and tools for deploying Oracle
Database on the reliable and secure AWS Cloud infrastructure. This guide explains the options available
for migrating your Oracle on-premises databases to the AWS Cloud. It also dives into the best practices
and scenarios for exercising these migration options.

This guide is for program or project managers, product owners, database administrators, database
engineers, and operations or infrastructure managers who are planning to migrate their on-premises
Oracle databases to AWS.

Overview
Before you migrate your Oracle databases to AWS, you should understand and evaluate your migration
strategy by using the framework discussed in Migration strategy for relational databases.

The first step is to perform an analysis of your application and Oracle Database workloads to understand
the complexity, compatibility, and cost of migration. Here are some of the top points you should consider
when you plan to migrate:

• Check the database current size and overall capacity growth. For example, if you’re planning to
migrate your Oracle database to Amazon Relational Database Service (Amazon RDS), you can create
Amazon RDS DB instances with up to 64 TiB of storage. For the latest information, see Amazon RDS DB
Instance Storage in the Amazon RDS documentation.
• Review Oracle Automatic Workload Repository (AWR) reports to check the resource usage and
database health of your on-premises database.
• Check current database dependencies on other databases. If your database is dependent on other
databases, you can either migrate them together or create dependencies after you migrate your main
database.
• Determine the IOPS and throughput of your databases. If you’re planning to migrate to Amazon RDS,
consider the I/O performance of Amazon RDS DB instances.
• Review your current architecture and auditing or compliance needs, to make sure you can satisfy these
requirements after moving to either Amazon RDS or Amazon Elastic Compute Cloud (Amazon EC2).
• Check the version and edition of your Oracle Database software to make sure it’s supported if you're
planning to move to Amazon RDS for Oracle (see currently supported versions).
• Check the network connectivity between your on-premises environment and AWS, to make sure that it
provides enough bandwidth for fast transfers of data between on premises and AWS.
• Determine the amount of downtime you have available for migration so you can plan your migration
approach and decide whether you want to use online or offline migration.
• Identify your recovery time objective (RTO), recovery point objective (RPO), and service-level
agreement (SLA) requirements for your existing database workloads.
• Check the chipset endian platform of the database workload. AWS supports x86-x64 little-endian
platforms. Other platforms, such as Sun SPARC, HP Tru64, or IBM zSeries-based big-endian platforms,
require cross-platform migration.

1
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Overview

• AWS supports Linux (32-bit and 64-bit) and Windows operating systems. It doesn't support Solaris,
HP-UX, or IBM AIX operating systems, which are commonly used for Oracle databases. Migrating
Oracle databases from these operating systems requires platform conversion.

2
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Choosing the right migration strategy

Oracle database migration strategies

At a high level, there are two options for migrating an Oracle database from on premises to the AWS
Cloud: either stay on Oracle (homogenous migration) or move off Oracle (heterogenous migration). In a
homogenous migration, you don’t change the database engine (that is, your target database is also an
Oracle database). In a heterogenous migration, you switch either to an open-source database engine
such as MySQL, PostgreSQL, or MariaDB, or to an AWS Cloud-native database such as Amazon Aurora,
Amazon DynamoDB, or Amazon Redshift.

There are three common strategies for migrating your Oracle databases to AWS: rehost, replatform, and
re-architect (refactor). These are part of the 6 Rs of application migration strategies and described in the
following table.

Strategy Type When to choose Example

Rehost Homogeneous You want to migrate Oracle Database to

your Oracle database Amazon EC2
as is, with or without
changing the (Browse rehost
operating system, patterns)
database software, or
configuration.

Replatform Homogeneous You want to reduce Oracle Database to

the time you spend Amazon RDS for Oracle
managing database
instances by using a (Browse Replatform
database-as-a-service patterns)
(DBaaS) offering.

Re-architect (refactor) Heterogeneous You want to restructure, Oracle Database

rewrite, and re-architect to Amazon Aurora
your database and PostgreSQL, MySQL, or
application to take MariaDB
advantage of open-
source and cloud-native Browse Re-architect
database features. patterns)

Choosing the right migration strategy

Choosing the correct strategy depends on your business requirements, your resource constraints, your
migration timeframe, and cost considerations. The following diagram shows the effort and complexity
involved in migrations, including all six strategies.

3
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Online and offline migration

Refactoring your Oracle database and migrating to an open-source or AWS Cloud-native database
such as Amazon Aurora PostgreSQL or MySQL can help you modernize and optimize your database.
By moving to an open-source database, you can avoid expensive licenses (resulting in lower costs),
vendor lock-in periods, and audits, and you won’t have to pay additional fees for new features. However,
depending on the complexity of your workload, refactoring your Oracle database can be a complicated,
time-consuming, and resource-intensive effort. AWS provides a tool called AWS Workload Qualification
Framework (AWS WQF) that can help you assess the complexity of your workload and recommend
migration strategies and tools. For more information, see the AWS WQF (p. 21) section later in this
guide.

To reduce complexity, instead of migrating your database in a single step, you might consider a phased
approach. In the first phase, you can focus on core database functionality. In the next phase, you
can integrate additional AWS services into your cloud environment, to reduce costs, and to optimize
performance, productivity, and compliance. For example, if your goal is to replace your on-premises
Oracle database with Aurora PostgreSQL, you might consider rehosting your database on Amazon EC2
or replatforming your database on Amazon RDS for Oracle in the first phase, and then refactor to Aurora
PostgreSQL in a subsequent phase. This approach helps reduce costs, resources, and risks during the
migration phase and focuses on optimization and modernization in the second phase.

Online and offline migration

You can use two methods to migrate Oracle Database from an on-premises environment to the AWS
Cloud, based on your migration timeline and how much downtime you can allow: online migration or
offline migration.

• Offline migration: This method is used when your application can afford a planned downtime.
In offline migration, the source database is offline during the migration period. While the source
database is offline, it is migrated over to the target database on AWS. After the migration is complete,
validation and verification checks are performed to ensure data consistency with the source database.
When the database passes all validation checks, you perform a cutover to AWS by connecting your
application to the target database on AWS.
• Online migration: This method is used when your application requires near zero to minimal
downtime. In online migration, the source database is migrated in multiple steps to AWS. In the initial
steps, the data in the source database is copied to the target database while the source database
is still running. In subsequent steps, all changes from the source database are propagated to the
target database. When the source and target databases are in sync, they are ready for cutover. During
the cutover, the application switches its connections over to the target database on AWS, leaving
no connections to the source database. You can use AWS Database Migration Service (AWS DMS),
Oracle GoldenGate, Quest SharePlex, or tools available from AWS Marketplace (such as Attunity) to
synchronize the source and target databases.

4
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Amazon RDS for Oracle

Homogeneous database migration

for Oracle databases
AWS offers you the ability to run Oracle Database in a cloud environment. For developers and database
administrators, running Oracle Database in the AWS Cloud is very similar to running Oracle Database
in a data center. This section describes options for migrating Oracle Database from an on-premises
environment or a data center to the AWS Cloud.

AWS offers three options for running Oracle Database on AWS, as described in the following table.

Option Highlights More information

Oracle Database on Amazon Managed service, provides easy Amazon RDS for
RDS provisioning and licensing Oracle (p. 5) section

Oracle Database on Amazon Self-managed, provides full Amazon EC2 for

EC2 control and flexibility Oracle (p. 9) section

Oracle Database on VMware Minimal disruption, easy to VMware Cloud on AWS for
Cloud on AWS manage Oracle (p. 11) section

Your application requirements, database features, functionality, growth capacity, and overall architecture
complexity will determine which option to choose. If you are migrating multiple Oracle databases to
AWS, some of them might be a great fit for Amazon RDS whereas others might be better suited to run
directly on Amazon EC2. You might have databases that are running on Oracle Enterprise Edition (EE) but
are a good fit for Oracle Standard Edition One (SE1) or Standard Edition Two (SE2). You can save on cost
and licenses for those databases. Many AWS customers run multiple Oracle Database workloads across
Amazon RDS, Amazon EC2, and VMware Cloud on AWS.

Amazon RDS for Oracle

Amazon RDS for Oracle is a managed database service that simplifies the provisioning and management
of Oracle Database on AWS. Amazon RDS makes it easy to set up, operate, and scale Oracle Database
deployments in the cloud. You can deploy your database in minutes and choose either General Purpose
(SSD) storage or Provisioned IOPS storage. (For details, see Amazon RDS Storage Types in the AWS
documentation.)

Amazon RDS frees you up to focus on application development, because it manages time-consuming
database administration tasks, including provisioning, backups, software patching, monitoring, and
hardware scaling. Amazon RDS for Oracle easily provisions read replica and Multi-AZ databases to
enhance availability, performance, and reliability for production workloads.

For more information about migrating from Oracle to Amazon RDS, see the replatform patterns on the
AWS Prescriptive Guidance website.

When to choose Amazon RDS

Amazon RDS for Oracle is a good migration option when:

5
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
High availability

• You want to focus on your business and applications, and you want AWS to take care of
undifferentiated heavy lifting tasks such as the provisioning of the database, management of backup
and recovery tasks, management of security patches, minor Oracle version upgrades, and storage
management.
• You need a highly available database solution, and you want to take advantage of the push-button,
synchronous Multi-AZ replication offered by Amazon RDS, without having to manually set up and
maintain a standby database.
• You want to have synchronous replication to a standby instance, to provide high availability for your
Oracle Database Standard Edition One (SE1) or Standard Edition Two (SE2) database, instead of having
to pay for Oracle Database Enterprise Edition (EE).
• You want to pay for the Oracle license as part of the instance cost on an hourly basis instead of making
a large, upfront investment.
• Your database size and IOPS needs are supported by Amazon RDS for Oracle. See Amazon RDS DB
Instance Storage in the AWS documentation for the current maximum limits.
• You don’t want to manage backups or point-in-time recoveries of your database.
• You would rather focus on high-level tasks, such as performance tuning and schema optimization,
instead of the daily administration of the database.
• You want to scale the instance type up or down based on your workload patterns without being
concerned about licensing complexities.

After assessing your database and project requirements, if you decide to migrate to Amazon
RDS for Oracle, see the details provided in the following sections, and review the migration best
practices (p. 22) we discuss later in this guide.

High availability
Amazon RDS provides high availability and failover support for databases that are deployed with the
Multi-AZ option. When you provision your database with the Multi-AZ option, Amazon RDS automatically
provisions and maintains a synchronous standby replica in a different Availability Zone. The primary
database synchronously replicates the data to the standby replica across Availability Zones. In case of
infrastructure failure or Availability Zone disruption, Amazon RDS performs an automatic failover to the
standby replica so you can resume database operations as soon as the failover is complete. This provides
high redundancy, durability, and enhanced availability of your primary database. It also offloads your
primary database by taking automated backups from the standby replica. For more information, see
High Availability (Multi-AZ) for Amazon RDS in the AWS documentation.

The following diagram illustrates the Amazon RDS for Oracle Multi-AZ deployment option. The database
application and users connect to the primary Oracle database, and all changes are synchronously
replicated to the secondary database, which is in a different Availability Zone. The secondary database
is not available to users until the failover is complete. After failover, the endpoint remains the same, so
users and database applications can resume database operations without any manual intervention.

6
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Read replicas

Read replicas
A read replica is a special type of Amazon RDS for Oracle DB instance that helps reduce the load on your
primary DB instance. Updates made to your primary DB instance are asynchronously copied to the read
replica, which you can set up in the same AWS Region or in another AWS Region.

You can provision an Amazon RDS for Oracle database with read replicas by using Oracle Active Data
Guard to offload your read-only workload from the primary Oracle database. Oracle Active Data Guard
replicates database changes from the source DB instance to the read replicas. This feature supports
managed disaster recovery for mission-critical databases by allowing a read replica in another AWS
Region to be promoted as a new, standalone, production database. You can provision up to five read
replicas for your Amazon RDS for Oracle database.

Amazon RDS for Oracle makes it easy to create the read replicas by managing the configuration of Active
Data Guard and maintaining secure network connections between a primary DB instance and its read
replicas. For more information, see Working with Oracle read replicas for Amazon RDS in the Amazon
RDS documentation.

To use the read replica feature, you must use the Bring Your Own License (BYOL) model with Oracle
Database Enterprise Edition (EE) and also have an Active Data Guard license.

Using a read replica in the same AWS Region

The following diagram illustrates an Amazon RDS for Oracle DB instance in a Multi-AZ environment
with a read replica in another Availability Zone in the same AWS Region. Not all AWS Regions offer more
than two Availability Zones, so you should check the Region you’re planning to use before adopting this
strategy.

7
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Read replicas

Using a read replica in another AWS Region

Amazon RDS for Oracle also supports cross-Region read replicas. It uses Oracle Active Data Guard to
create and manage the configuration of physical standby DB instances in different AWS Regions from the
primary DB instance. It replicates data over secure network connections between a primary DB instance
and its read replicas across Regions.

Cross-Region read replicas provide:

• High availability and data protection agains single-Region failure.

• The ability to scale read operations to another AWS Region that's closer to your application's users.

You can promote an Oracle read replica to a standalone DB instance explicitly, or you can promote
it implicitly by deleting its source DB instance. When you promote a read replica, the DB instance is
rebooted before it becomes available. The promoted read replica behaves the same as any other Oracle
DB instance.

The following diagram shows the configuration of Amazon RDS for Oracle cross-Region read replicas.

8
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Amazon EC2 for Oracle

The data transferred for cross-Region replication incurs Amazon RDS data transfer changes.

For more information about using read replicas, see Working with read replicas and Working with Oracle
read replicas for Amazon RDS in the AWS documentation. For more information about data transfer
pricing, see Amazon RDS Pricing.

Amazon EC2 for Oracle

Amazon EC2 supports a self-managed Oracle database—that is, it gives you full control over the setup
of the infrastructure and the database environment. Running the database on Amazon EC2 is very
similar to running the database on your own server. You have full control of the database and operating
system-level access, so you can use your choice of tools to manage the operating system, database
software, patches, data replication, backup, and restoration. This migration option requires you to set
up, configure, manage, and tune all the components, including Amazon EC2 instances, storage volumes,
scalability, networking, and security, based on AWS architecture best practices.

For more information about migrating from Oracle to Amazon EC2, see the rehost patterns on the AWS
Prescriptive Guidance website.

When to choose Amazon EC2

Amazon EC2 is a good migration option for your Oracle database when:

• You need full control over the database and access to its underlying operating system.
• You want to control your backups, replication, and clustering.
• You want to use features and options that aren’t currently supported by Amazon RDS. For details, see
Oracle Database Feature Support in the Amazon RDS documentation.
• You need a specific Oracle Database version that isn’t supported by Amazon RDS. For a list of
supported version and editions, see Oracle on Amazon RDS in the Amazon RDS documentation.
• Your database size and performance needs exceed Amazon RDS offerings. For details, see Amazon RDS
DB Instance Storage in the Amazon RDS documentation.
• You want to avoid automatic software patches that might not be compliant with your applications.
• You want to achieve higher IOPS and provision storage capacity than the current limits. For details, see
Amazon RDS DB Instance Storage in the Amazon RDS documentation.

9
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
High availability

High availability
Oracle Database on Amazon EC2 can work with any Oracle-supported replication technology to achieve
high availability and disaster recovery. Some of the common solutions are Oracle Data Guard, Oracle
Active Data Guard, and Oracle GoldenGate.

An Oracle database on Amazon EC2 uses Oracle Data Guard or Oracle Active Data Guard to achieve high
availability, data protection, and disaster recovery.

• Oracle Data Guard provides a set of services for creating, maintaining, and managing standby
databases, to help protect Oracle production databases against disasters and data corruption. Oracle
Data Guard automatically maintains each standby database by transmitting redo changes from the
primary database, and then applying the redo to the standby database. If the primary database goes
down for any planned or unplanned reason, you can fail over to the standby database by converting
it into a primary read-write database. Oracle Data Guard is included with Oracle Database Enterprise
Edition (EE) only and doesn’t require a separate license.
• Oracle Active Data Guard provides read-only access to a physical standby database for queries, sorting,
reporting, and other read operations while it applies redo changes continuously from the primary
database. Oracle Active Data Guard requires a separate license that must be additionally purchased
with Oracle Database EE. Oracle Active Data Guard features include Real-Time Query, Automatic Block
Repair, Far Sync, Standby Block Change Tracking, Active Data Guard Rolling Upgrade, Global Database
Services, and Application Continuity.

The following diagram shows how you can use Oracle Database on Amazon EC2 in two Availability Zones
within a single AWS Region. The primary database is a read-write database, and the standby database is
configured with either Data Guard (physical standby with no read access) or Active Data Guard. All the
redo data from the primary database is transferred and applied to the standby database asynchronously
by default.

You can also use Oracle Data Guard or Oracle Active Data Guard to configure high availability and
disaster recovery across multiple AWS Regions, using Oracle Database on Amazon EC2 for your primary
database and standby database, as illustrated in the following diagram.

10
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
VMware Cloud on AWS for Oracle

VMware Cloud on AWS for Oracle

VMware Cloud on AWS is an integrated cloud offering jointly developed by AWS and VMware. When
you migrate Oracle Database to VMware Cloud on AWS, you have full control of the database and
operating system-level access, as with Amazon EC2. You can run advanced architectures like Oracle
Real Application Cluster (RAC) and Oracle RAC extended clusters (across different Availability Zones) in
VMware Cloud on AWS. You can choose from a number of migration methods and tools based on your
needs and your existing system.

For online migrations, VMware technologies like VMware Hybrid Cloud Extension (VMware HCX) and
HCX vMotion help you migrate VM workloads from on-premises VMware clusters to VMware Cloud on
AWS. For offline migrations of Oracle workloads, you can use Oracle Recovery Manager (RMAN), AWS
Snowball, AWS Storage Gateway, or VMware HCX.

When to choose VMware Cloud on AWS

VMware Cloud on AWS is a good option for your Oracle database when:

• Your Oracle databases are already running in an on-premises data center in vSphere virtualized
environments.
• You need to run Oracle RAC in the cloud.
• You have a large number of databases and you need fast migration (for example, only a few hours) to
the cloud without requiring any additional work from the migration team.

For more information, see the blog posts How to Migrate Oracle Workloads to VMware Cloud on AWS
and Best Practices for Virtualizing Oracle RAC with VMware Cloud on AWS on the AWS Partner Network
(APN) blog.

Tools for homogeneous database migrations

A number of tools and technologies are available for data migration. You can perform the migration
in a single phase or in multiple phases, based on your database size, consistency, the bandwidth of

11
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Tools

the network connection between your on-premises environment and AWS, and the allowed time for
database migration. The following chart provides a list of tools and information to help you choose the
option that best meets your needs.

Migration tool Database size Supports Recommended for

Oracle SQL Up to 200 MB Amazon RDS Small databases with

Developer (p. 13) any number of objects.
(Database Copy feature) Amazon EC2

Oracle SQL Up to 10 GB Amazon RDS Small to medium-

*Loader (p. 13) size databases with
Amazon EC2 a limited number of
objects.

Oracle Export and Up to 10 GB Amazon RDS Small to medium-size

Import (p. 13) databases with a large
Amazon EC2 number of objects.

Oracle Data Up to 20 TB Amazon RDS Preferred method for

Pump (p. 14) any database that’s 10
Amazon EC2 GB – 20 TB in size.

AWS DMS (p. 13) Any size Amazon RDS Minimal downtime
migration. Database
Amazon EC2 size is limited by
bandwidth. You can use
AWS DMS with Oracle
Data Pump for large
database migrations.

Oracle Any size Amazon RDS Minimal downtime

GoldenGate (p. 15) migration. Used with
Amazon EC2 Oracle Data Pump
for large database
VMware Cloud on AWS migrations.

Oracle Data Any size Amazon EC2 Minimal downtime

Guard (p. 16) migration. Used with
VMware Cloud on AWS Oracle RMAN to
replicate changes after
initial data transfer.

Oracle RMAN (p. 16) Any size Amazon EC2 Databases over 2 TB,
or if database backup
VMware Cloud on AWS is already in Amazon
Simple Storage Service
(Amazon S3).

CloudEndure Any size Amazon EC2 Fast replication with

Migration (p. 17) minimal downtime
VMware Cloud on AWS during cutover.

VMware HCX (p. 17) Any size VMware Cloud on AWS HCX vMotion provides
online or offline
migration of a single
virtual machine (VM)

12
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Oracle SQL Developer

Migration tool Database size Supports Recommended for

at a time with no
downtime.

The following subsections provide more information about each tool.

Oracle SQL Developer

Oracle SQL Developer is a free GUI tool from Oracle for data manipulation, administration, development,
and management. This Java-based tool is available for Microsoft Windows, Linux, or macOS. You can
use the Database Copy feature to migrate small databases to AWS, where the total size of your data is
under 200 MB. The data transfer between source and target database is done directly over the network.
To use this option, you will need a reliable network connection between the source and target database.
In addition, keep in mind that this method does not encrypt data during transfer.

Oracle SQL Developer supports both Amazon RDS for Oracle and Oracle databases on Amazon EC2.

Oracle SQL *Loader

Oracle SQL *Loader is a bulk data load utility available from Oracle for loading data from external files
into a database. SQL *Loader is included with the full Oracle Database client binaries. You can use SQL
*Loader for small to medium-size databases under 10 GB that contain a limited number of objects.
Because this is a schema-based method, it involves exporting specific schemas individually from the
source database and loading them into the target database. If you have multiple schemas in a database,
you have to repeat the process for each schema.

Oracle SQL *Loader supports both Amazon RDS for Oracle and Oracle databases on Amazon EC2.

Oracle Export and Import

Oracle Export and Import utilities help you migrate databases that are smaller than 10 GB and don’t
include binary float and double data types. The import process creates the schema objects, so you don’t
have to run a script to create them beforehand. This makes the process well suited for databases that
have a large number of small tables.

You can use this tool for both Amazon RDS for Oracle and Oracle databases on Amazon EC2.

AWS DMS
AWS Database Migration Service (AWS DMS) is a managed service that helps you move data to and from
AWS easily and securely. AWS DMS supports most commercial and open-source databases, and facilitates
both homogeneous and heterogeneous migrations. AWS DMS offers both one-time full database copy
and change data capture (CDC) technology to keep the source and target databases in sync and to
minimize downtime during a migration.

AWS DMS can perform a full copy of your Oracle database schema for small (10-20 GB) to medium
(100-200 GB) databases. For very large databases, you can migrate the data to Amazon RDS or Amazon
EC2 by using Oracle Data Pump, and then use the AWS DMS CDC feature for ongoing replication with
minimal downtime. When the data is synchronized, you can cut over to the target database.

The following diagram shows how you can use Oracle Data Pump and AWS DMS together to migrate an
on-premises database to Amazon RDS for Oracle with minimal downtime. The Oracle Data Pump export
utility exports the schema to database dump files, and then transfers those files to Amazon S3 by using

13
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Oracle Data Pump

either AWS Direct Connect or AWS Snowball (depending on the size of the database, network bandwidth,
and allowed migration time). After the dump files are loaded into Amazon S3, you can upload the files
over to an Amazon RDS for Oracle DB instance. The Oracle Data Pump import utility then imports the
data to Amazon RDS for Oracle, and AWS DMS CDC replicates all the changes from the source database
to the target Amazon RDS for Oracle database.

For more information about using AWS DMS to migrate Oracle source databases, see Using an Oracle
Database as a Source for AWS DMS in the AWS documentation.

Oracle Data Pump

Oracle Data Pump is an enhanced version of Oracle Export and Import. This utility is used to export and
import data and metadata from or to Oracle databases. You can run Data Pump export/import on an
entire database, selective schemas, tablespaces, or database objects. Data Pump is the recommended
tool for migrating data to AWS, for large databases that range from 10 GB to 20 TB in size. It allows a
high degree of parallelism, flexible data extraction options, and scalable operations, which enable high-
speed movement of data and metadata from source database to target database. Oracle Data Pump also
supports encryption and compression when exporting your data to data dump files.

You can use this tool for both Amazon RDS for Oracle and Oracle databases on Amazon EC2. You can
also use Oracle Data Pump with AWS DMS and Oracle GoldenGate to handle the initial data transfer for
large databases.

For Amazon RDS for Oracle, after the data is exported into dump files using the Oracle Data Pump
export utility, the Oracle Data Pump import utility requires the data files to be available in the database
server instance to import them into the database. You can’t access the file system in the Amazon RDS DB
instance directly, so you will need to transfer the dump files to Amazon RDS using one of these options:

• Use a database link between the two databases. This process uses Oracle Data Pump and the Oracle
DBMS_FILE_TRANSFER package. It creates a database link between the source (on-premises) Oracle
database and the target Amazon RDS for Oracle database. This option requires higher bandwidth
connectivity between source and target databases; we recommend that you use AWS Direct Connect.
This option is recommended only for small databases. For more information, see Importing Data with
Oracle Data Pump and a Database Link in the Amazon RDS documentation.

14
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Oracle GoldenGate

• Use an Amazon S3 bucket. Amazon RDS for Oracle supports Amazon S3 integration. This option is
recommended when you have large data dump files and your database size is in terabytes. You can
then copy the data dump files from on premises to your S3 bucket by using AWS Direct Connect (if
your data size is from 10 GB to 5 TB) or AWS Snowball (if your data size is more than 5 TB) depending
on the required migration time for your database.

After the data pump file is uploaded to Amazon S3, you can download it to the DATA_PUMP_DIR
directory on the target Amazon RDS for Oracle DB instance, and then import the data into the DB
instance. For more information, see Importing Data with Oracle Data Pump and an Amazon S3 Bucket
in the Amazon RDS documentation.

With Oracle Data Pump, you can migrate larger databases in phases, on a schema-by-schema basis. You
can migrate to a different version of the Oracle Database software and also migrate to platforms that
have different hardware and software configurations.

Oracle GoldenGate
Oracle GoldenGate is a tool for replicating data between a source database and one or more destination
databases with minimal downtime. You can use it to build high availability architectures, and to
perform real-time data integration, transactional change data capture, replication in heterogeneous
environments, and continuous data replication.

You can run Oracle GoldenGate from your on-premises server in your source environment. However, we
recommend that you install and run this tool from an EC2 instance, which serves as the GoldenGate hub,
on AWS for better performance. You can have multiple GoldenGate hubs, especially if you are migrating
data from one source database to multiple destinations. You can use GoldenGate with Amazon RDS
for Active-Active database replication, zero-downtime migration and upgrades, disaster recovery, data
protection, and in-region and cross-region replication. For details, see Using Oracle GoldenGate with
Amazon RDS in the AWS documentation.

The following diagram shows how to use Oracle Data Pump and Oracle GoldenGate together to migrate
an on-premises Oracle database to Amazon RDS for Oracle.

Oracle GoldenGate requires a separate license from Oracle.

15
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Oracle Data Guard

Oracle GoldenGate supports both Amazon RDS for Oracle and Oracle databases running on Amazon EC2
or VMware Cloud on AWS.

Oracle Data Guard

Oracle Data Guard provides a set of services for creating, maintaining, monitoring, and managing Oracle
standby databases. You can migrate your entire Oracle database from on premises to Amazon EC2 with
minimal downtime by using Oracle Recovery Manager (RMAN) and Oracle Data Guard. With RMAN, you
restore your database to the target standby database on Amazon EC2, using either backup/restore or
the duplicate database method. You then configure the target database as a physical standby database
with Oracle Data Guard, allowing all the transaction/redo data changes from the primary on-premises
database to the standby database.

When the primary on-premises Oracle database is in sync with the target standby database on the EC2
instance, you can switch over to the target database, which will convert it to a read-write database. You
can then point your application connections to the new primary database. With this option, you can
achieve minimum downtime and get an exact physical copy of your database on AWS. The migration is
illustrated in the following diagram.

Oracle Data Guard supports Oracle databases running on Amazon EC2 or VMware Cloud on AWS.

Oracle RMAN
Oracle Recovery Manager (RMAN) is a tool provided by Oracle for performing and managing Oracle
database backups and restorations. You can use RMAN to back up your Oracle database from on
premises or from your data center, and restore it to an Oracle database on an EC2 instance. Use this
method if you are planning to move your entire database to a self-managed Oracle database on an EC2
instance. The database can be of any size, and you can use parallelism, compression, and encryption in
your backups.

16
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
CloudEndure Migration

You can place the Oracle RMAN backup of your on-premises Oracle database directly in an S3 bucket
by using the Oracle Secure Backup (OSB) Cloud module, AWS Storage Gateway, or AWS DataSync. You
can then use an AWS Identity and Access Management (IAM) role to give the S3 bucket access to your
target Oracle database on an EC2 instance, and restore the database by using the RMAN backup files.
You can use Oracle Data Guard to capture incremental backups from your on-premises Oracle database
and apply them to the target Oracle database on the EC2 instance until the on-premises and target
databases are in sync. You can then perform the switchover at a convenient time.

Oracle RMAN supports Amazon EC2 and VMware Cloud on AWS migrations only. It’s the recommended
approach when you can allow enough downtime for migrating your data to AWS.

CloudEndure Migration
If you are looking to rehost a large number of machines from an on-premises environment to the
AWS Cloud, you can use CloudEndure Migration without worrying about compatibility, performance
disruption, or long cutover windows. CloudEndure is a highly automated migration tool that expedites
and reduces the cost of cloud migration by offering a highly automated lift-and-shift solution.

Using CloudEndure Migration, you can migrate all applications and databases that run on supported
versions of Windows and Linux OS. This includes Windows Server versions 2003, 2008, 2012, 2016, 2019
and Linux distributions such as CentOS, Red Hat Enterprise Linux (RHEL), Oracle Linux (OEL), SUSE Linux
Enterprise Server (SLES), Ubuntu, and Debian.

CloudEndure Migration works through an agent that you install on your source machines. You do
not have to reboot your on-premises servers, and there is no performance impact on your source
environment.

CloudEndure Migration automated rehosting consists of three main steps:

1. Install the agent. The CloudEndure agent replicates entire machines to a staging area in your target
environment without causing downtime or impacting performance.
2. Configure and test. You configure your target machine settings and launch non-disruptive tests.
3. Cut over. When you’re ready to launch the production machines, CloudEndure automatically converts
them to the AWS infrastructure so they can boot and run natively on AWS.

For more information about using CloudEndure Migration, see Automating your lift-and-shift migration
at no cost with CloudEndure Migration in the AWS Compute blog.

VMware HCX
VMware Hybrid Cloud Extension (HCX) enables you to migrate your on-premises Oracle databases to
AWS without having to retrofit your VMware infrastructure. It includes several migration methods that
are detailed in the blog posts How to Migrate Oracle Workloads to VMware Cloud on AWS and Migrating
Workloads to VMware Cloud on AWS with Hybrid Cloud Extension (HCX). One of these methods, HCX
vMotion, provides a live migration of a single VM with no downtime and high availability.

HCX is available free of charge to VMware Cloud on AWS customers.

Licensing options
Oracle Database licensing on AWS is based on the size of the instance on which the database is installed.
Many Oracle Database workloads need high memory, storage, and I/O bandwidth, but are not CPU-
bound, so you can reduce the number of virtual CPUs (vCPUs) in your deployment without affecting
performance.

17
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
License Included

AWS offers the following CPU options for optimizing your Amazon RDS and EC2 instances for specific
workload or business needs:

• Number of CPU cores: You can customize the number of CPU cores for the instance.
• Threads per core: You can disable multithreading by specifying a single thread per CPU core.

For more information, see Optimizing CPU Options in the Amazon EC2 documentation and Introducing
Optimize CPUs for Amazon RDS for Oracle on the AWS website.

You can run Oracle Database on AWS under two different licensing models:

• License Included
• Bring Your Own License (BYOL)

License Included
In the License Included model, the Oracle Database software license is made available by AWS, so you
don’t have to purchase your own Oracle license separately. The License Included model pricing includes
software, underlying hardware resources, and Amazon RDS management capabilities for Amazon
RDS for Oracle. You pay for compute capacity by the hour your DB instance runs, with no long-term
commitments. This frees you from the costs and complexities of planning, purchasing, and maintaining
hardware.

For both Single-AZ and Multi-AZ deployments, pricing is per DB instance-hour consumed, from the time
you launch a DB instance until you stop or delete the instance.

The License Included model supports Oracle Database Standard Edition One (SE1) and Standard Edition
Two (SE2). For pricing information, see Amazon RDS for Oracle pricing on the AWS website.

Bring Your Own License

The Bring Your Own License (BYOL) model is intended for customers who prefer to use their existing
Oracle Database licenses or purchase new Oracle licenses. If you already own an Oracle database license,
you can use the BYOL model to run your Oracle database on Amazon RDS. If you’re migrating your
Oracle database to Amazon EC2 or to VMware Cloud on AWS, you must use your own Oracle license.

To run a DB instance under the BYOL model, you must have the appropriate Oracle Database license for
the DB instance class and Oracle Database edition you want to run. You must also follow Oracle’s policies
for licensing Oracle Database software in the cloud computing environment.

If you use the BYOL model, you must have a license for both the primary DB instance and the standby
DB instance in a Multi-AZ deployment. Amazon RDS supports Multi-AZ deployments for Oracle as a high
availability, failover solution. We recommend Multi-AZ for production workloads. For more information,
see High Availability (Multi-AZ) for Amazon RDS in the Amazon RDS documentation.

The BYOL model supports Oracle Database Enterprise Edition (EE), Standard Edition (SE), Standard
Edition One (SE1), and Standard Edition Two (SE2).

For more information about licensing options for Amazon RDS for Oracle, see Oracle Licensing and the
Amazon RDS for Oracle FAQs on the AWS website.

18
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud

Heterogeneous database migration

Because of the innovations and improvements in open-source databases and cloud computing platforms
like AWS, many organizations are moving from proprietary (online transaction processing or OLTP)
database engines such as Oracle to open-source engines. Oracle databases are mission-critical systems
for any organization, but being locked into a particular vendor is a risky and costly situation. Low
operating cost and no licensing fees are compelling reasons to consider switching the underlying
database technology to open-source or AWS Cloud-native databases.

Other reasons for migrating off Oracle are vendor lock-in periods, licensing audits, expensive licensing,
and cost. Oracle’s list pricing is based on a per-core model with additional costs for features such as
partitioning and high availability. For this reason, many organizations choose to migrate their Oracle
databases to either open-source databases (such as PostgreSQL, MySQL, or MariaDB) or AWS Cloud-
native databases (such as Amazon Aurora or Amazon DynamoDB) when they migrate to AWS.

You can also migrate your Oracle data warehouse database to Amazon Redshift, which is a fast, fully
managed cloud data warehouse. Amazon Redshift is integrated with your data lake, offers up to three
times faster performance than any other data warehouse, and costs up to 75 percent less than any other
cloud data warehouse. For more information, see Migrate from Oracle to Amazon Redshift on the AWS
website.

To migrate to an open-source or AWS-native database, choose the right database depending on the type
of data you have, the access model, scalability, application practicalities, and complexity. For example,
PostgreSQL databases have become very popular in recent years for their powerful functionality and
high degree of compatibility with commercial databases, and they’re the most common migration
target for users who are refactoring their Oracle databases. But migrating from Oracle to PostgreSQL
and to other open-source databases has often been difficult and time-consuming, and requires careful
assessment, planning, and testing.

This process becomes easier with services like AWS DMS and AWS Schema Conversion Tool (AWS SCT),
which help you migrate your commercial database to an open-source database on AWS with minimal
downtime.

In heterogeneous database migrations, the source and target databases engines are different, as
in Oracle to Amazon Aurora, or Oracle to PostgreSQL, MySQL, or MariaDB migrations. The schema
structure, data types, and database code in the source and target databases can be quite different, so the
schema and code must be transformed before the data migration starts. For this reason, heterogeneous
migration is a two-step process:

• Step 1. Convert the source schema and code to match that of the target database. You can use AWS
SCT for this conversion.
• Step 2. Migrate data from the source database to the target database. You can use AWS DMS for this
process.

19
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Tools

AWS DMS handles all required data type conversions automatically during migration. The source
database can be located in your own premises outside AWS, it can be a database that’s running on an
EC2 instance, or it can be an Amazon RDS database (see Sources for Data Migration in the AWS DMS
documentation). The target can be a database in Amazon EC2, Amazon RDS, or Aurora.

For more information about refactoring your Oracle database on AWS, see the re-architect patterns on
the AWS Prescriptive Guidance website.

Tools for heterogeneous database migrations

The following chart provides a list of tools that you can use to migrate from Oracle Database to another
database engine.

Migration tool Target database support Used for

AWS WQF (p. 21) Amazon RDS for MySQL Pre-migration analysis

Amazon RDS for PostgreSQL

Amazon Aurora MySQL

Amazon Aurora PostgreSQL

AWS SCT (p. 21) Amazon RDS for MySQL Schema conversion

Amazon RDS for PostgreSQL

Amazon Aurora MySQL

Amazon Aurora PostgreSQL

AWS DMS (p. 21) Amazon RDS for MySQL Data migration

Amazon RDS for PostgreSQL

Amazon Aurora MySQL

Amazon Aurora PostgreSQL

The following subsections provide more information about each tool.

20
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
AWS WQF

AWS WQF
AWS Workload Qualification Framework (AWS WQF) is used to analyze enterprise databases, code, third-
party dependencies, and frameworks for migrating to the AWS Cloud. It assesses and rates the workload
for the entire migration, including database and application modifications. WQF can recommend
strategies and tools that you can use for your migration, and provide actionable feedback. It can also
identify actions for completing a migration to Amazon RDS or Amazon Aurora.

You can use WQF during the planning phase of your migration process to determine what you need to do
to migrate your data and applications. WQF reports on the following:

• Workload assessment, based on complexity, size, and technology used

• Recommendations on migration strategies
• Recommendations on migration tools
• Feedback on what exactly to do
• Assessment of the effort required, based on team size and member roles

AWS doesn’t currently provide the AWS WQF for downloading. If you need help assessing a migration to
AWS with AWS WQF, we recommend opening a support ticket. AWS will engage with you directly to help
make the process work for you.

AWS SCT
AWS Schema Conversion Tool (AWS SCT) converts your existing commercial database schemas to an
open-source engine or to an AWS Cloud-native database. AWS SCT makes heterogeneous database
migrations predictable by automatically converting the source database schema and a majority of the
database code objects, including views, stored procedures, and functions, to a format that’s compatible
with the target database. Any objects that can’t be automatically converted are clearly marked for
manual conversion. AWS SCT can also scan your application source code for embedded SQL statements
and convert them as part of a database schema conversion project.

AWS DMS
AWS Database Migration Service (AWS DMS) migrates your data rapidly and securely to AWS. During
migration, the source database remains fully operational, minimizing application downtime. AWS
DMS supports homogenous migrations such as Oracle to Oracle as well as heterogenous migrations
between different database platforms, such as Oracle to an open-source database or to an AWS Cloud-
native database. AWS DMS manages the complexities of the migration process, including automatically
replicating data changes that occur in the source database to the target database. After the database
migration is complete, the target database remains synchronized with the source database for as long as
you choose, and you can switch over to the target database at a convenient time.

21
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Provisioning your target database

Best practices for migrating to

Amazon RDS for Oracle
Based on the assessment of your database and your project requirements, if your goal is to migrate
to Amazon RDS for Oracle, follow the best practices in this section to provision your target database,
perform the migration, and test, operate, and optimize your Amazon RDS for Oracle database.
Important
Make sure that you have a rollback plan before you migrate your database.

Provisioning your target database

After you finish assessing, planning, and preparing your database migration strategy, follow these best
practices when provisioning your Amazon RDS for Oracle database:

• Right-size the Amazon RDS for Oracle DB instance based on your requirements for CPU, memory,
IOPS, and storage type.
• Set the correct time zone and character set.
• Make sure to launch Amazon RDS in the correct virtual private cloud (VPC).
• Create the security groups with correct port and IP addresses.
• Provision your Amazon RDS database in a private subnet for security.
• If possible, provision the DB instance by using the latest Oracle Database version, which is currently
19c. Earlier versions are nearing end of support. For more information, see the Oracle Database end-
of-support timeline on the AWS discussion forums and Amazon RDS support for Oracle Database 19c.
• If you want to use encryption, always enable it while you are provisioning the Amazon RDS database.
• Create a separate option group and parameter group for each Amazon RDS database.

Exporting data from your source database

There are many tools for migrating an Oracle database to an Amazon RDS for Oracle database. The most
commonly used tool is Oracle Data Pump. Before you export your source Oracle database, check the
following to facilitate the export process:

• Check the database size, to see if you can migrate it schema by schema, instead of migrating the full
database. Migrating schemas individually is less error prone and more manageable than migrating
them all at once.
• Export data in parallel mode, by using the Oracle Data Pump PARALLEL parameter, for better
performance.
• Check if the tables have large objects (LOBs). If you have large tables with LOBs, we recommend that
you export those tables separately.
• During the export process, avoid running long database transactions on your source database to avoid
Oracle read inconsistency errors.
• If you are using replication tools such as AWS DMS, Oracle GoldenGate, or Quest SharePlex, make
sure that you have enough space on your on-premises server to hold archive logs for 24-72 hours,
depending on how long the migration takes.

22
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Transferring data dump files to AWS

Transferring data dump files to AWS

If you’re using AWS Direct Connect, which provides high bandwidth connectivity between your
on-premises environment and AWS, you can copy the Data Pump files by using either the Oracle
DBMS_FILE_TRANSFER utility or the Amazon S3 integration feature. If you do not have high bandwidth
through AWS Direct Connect, use AWS Snowball to transfer large database export dump files.

Importing data to your target database

• If you’re migrating a very large database, we recommend that you provision a bigger Amazon RDS
instance type initially, for the duration of the migration, for faster data loads. After the migration is
complete, you can change the DB instance to the right-sized instance type.
• Increase the size of redo log files, undo tablespaces, and temporary tablespaces to improve
performance during migration, if needed.
• Disable the Multi-AZ option during the import process, and enable it after migration is complete.
• Disable the generation of archive logs by setting the backup retention to zero to achieve faster data
load.
• Prepare the target database by creating tablespaces, users, roles, profiles, and schemas in advance.
• If you have large tables with LOBs, import each LOB table separately.

Post-import steps
• Check the import log files for errors, and fix any errors after the import is complete.
• Check for invalid objects. If you find any, compile and fix them.
• Some procedures might not compile due to lack of permissions on SYS objects that are not allowed or
supported in Amazon RDS. These procedures have to be rewritten.
• If you are using sequences, validate the sequence values against the source database to avoid sequence
inconsistency.
• Make sure that the object count in your Amazon RDS database is the same as in the source database.
Validate tables, indexes, procedures, triggers, functions, packages, constraints, and other objects.
• If your source database has database links to other databases, test the connectivity to confirm that the
links still work.
• Gather dictionary-level and schema-level statistics for optimal performance.

Testing the migration

We recommend the following tests to validate your application against your new Amazon RDS for Oracle
database:

• You might have to upgrade your Oracle client software or JDBC software based on the Amazon RDS
for Oracle database version. If you’ve migrated to a newer version of Oracle Database, it might not
support older versions of Oracle client software.
• Perform functional testing.
• Compare the performance of SQL queries in your source and target databases, and tune the queries as
needed. Some queries might perform more slowly in the target database, so we recommend that you
capture the baselines of the SQL queries in the source database.

23
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Operating and optimizing your Amazon RDS database

• When the application team finishes testing and confirms that your Amazon RDS database is
functioning properly, you can:
• Right-size the Amazon RDS DB instance based on your assessment.
• Enable backup retentions.
• Enable archive logs.
• Reset the size of redo log files.
• Enable the Multi-AZ option.
• Create Amazon CloudWatch alarms and set up Amazon Simple Notification Service (Amazon SNS)
topics for alerts.

For additional validation during the proof-of-concept (POC) phase, we recommend the following
supplemental tests:

• Run performance tests to ensure that they meet your business expectations.
• Test database failover, recovery, and restoration to make sure that you’re meeting RPO and RTO
requirements.
• List all critical jobs and reports, and run them on Amazon RDS to evaluate their performance against
your service-level agreements (SLAs).

Operating and optimizing your Amazon RDS

database
When your database is on AWS, make sure that you are following best practices in areas such as
monitoring, alerting, backups, and high availability in the cloud. For example:

• Set up CloudWatch monitoring, and enable detailed monitoring.

• Use Amazon RDS Performance Insights and the Oracle Enterprise Manager (OEM) Management Agent
to monitor your database.
• Set up alerts by using SNS topics.
• Set up automatic backups using AWS Backup. You can also use Oracle Data Pump backups or take
manual snapshots.
• For high availability, set up the Amazon RDS Multi-AZ feature.
• If you need read-only databases, set up a read replica (p. 7) within the same or across AWS Regions
according to your needs.

24
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud

Oracle database migration patterns

Use the following links to see the AWS Prescriptive Guidance patterns for migrating an Oracle database
to AWS:

• Rehost patterns (from Oracle to Amazon EC2)

• Replatform patterns (from Oracle to Amazon RDS for Oracle)
• Re-architect patterns (from Oracle to open-source and AWS Cloud-native databases)
• Oracle patterns that use CloudEndure Migration

If you’re looking for patterns that cover the use of a specific tool, type in the tool name in the search box
or choose it from a filter. For example, you can use this query to see all Oracle migration patterns that
use AWS DMS.

25
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud

Partners
Database migration can be a challenging project that requires expertise and tools. You can accelerate
your migration and time to results through partnership. AWS Database Migration Service partners have
the required expertise to help customers migrate to the cloud easily and securely. These partners have
the expertise for both homogenous migrations such as Oracle to Oracle, and heterogeneous migrations
between different database platforms, such as Oracle to Amazon Aurora or Microsoft SQL Server to
MySQL.

Based on your requirements and preferences, you can use the partner to handle the complete migration
or to help with only some aspects of the migration. In addition, you can use tools and solutions provided
by AWS Partner Network (APN) Partners to help with the migration. For a complete catalog of migration
tools and solutions, see APN Partner tools and solutions.

26
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud

Additional resources
Blog posts

• Database Migration—What Do You Need to Know Before You Start?

• Migrating Oracle databases with near-zero downtime using AWS DMS
• How to Migrate Your Oracle Database to PostgreSQL
• How to Migrate Your Oracle Database to Amazon Aurora
• How to Migrate Oracle Workloads to VMware Cloud on AWS
• Classify OLTP and OLAP workloads using AWS SCT with Workload Qualification Framework
• Best Practices for Virtualizing Oracle RAC with VMware Cloud on AWS

AWS documentation

• Amazon Aurora
• Amazon EC2
• Amazon RDS
• Amazon Redshift
• AWS DMS
• AWS SCT
• CloudEndure Migration
• Using Oracle GoldenGate with Amazon RDS
• Oracle Licensing

Additional information

• Oracle Data Pump

• Oracle Data Guard
• Oracle Export and Import
• Oracle GoldenGate
• Oracle RMAN
• Oracle SQL Developer
• Oracle SQL *Loader
• Licensing Oracle Software in the Cloud Computing Environment
• VMware HCX

27
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
General information

Appendix: Oracle migration

questionnaire
Use the questionnaire in this section as a starting point to gather information for the assessment and
planning phases of your migration project. You can download this questionnaire in Microsoft Excel
format and use it to record your information.

General information
1. What is the name of your Oracle database?
2. What is the version of your Oracle database?
3. What is the edition of the database: Standard or Enterprise?
4. What is the size of your database?
5. What is the database character set?
6. What is the time zone of the database?
7. What are the average and maximum I/O transactions per second (TPS)?
8. What is the IOPS (on average and maximum) for this database for read/write operations?
9. What is the redo log generation per hour (on average and maximum) per day?
10.How many schemas do you plan to migrate?
11.What is the size of each schema?
12.How many big tables (over 100 GB) do you have per schema?
13.Can you archive the tables that don’t need to migrate?
14.What is the size of system global areas (SGAs) and program global areas (PGAs) or Automatic Memory
Management (AMM) usage, in megabytes?
15.How many tables have LOBs? What is the maximum size of the LOBs?
16.Do all your tables with LOBs have primary keys?
17.Do you have database links that point to other databases?
18.What are the SLA requirements for your database?
19.What are the RTO and RPO requirements for your database?
20.How much database downtime can you allow for migration purposes?
21.Do you have any compliance, regulatory, or auditing requirements?

Infrastructure
1. What is the hostname of the database?
2. What is the operating system used for this database?
3. How many CPU cores does the server have?
4. What is the memory size on the server?
5. Are you using local storage?
6. Do you use network-attached storage (NAS) or storage area network (SAN) storage types?
7. Do you have a RAC database? If yes, how many nodes does it have?

28
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud
Database backups

8. Do you use partitioning features?

9. Do you use Oracle Spatial?
10.Do you have a multi-tenant database?

Database backups
1. How do you back up your database? How often?
2. What is your retention period for archive logs and backups?
3. Do you use backups to clone your database?
4. Where do you store your backup?

Database security
1. Do you use Oracle Database Vault?
2. Do you use data masking?
3. Do you use Secure Sockets Layer (SSL)?
4. Do you use Oracle Advanced Security features such as Transparent Data Encryption (TDE)?
5. Do you use Oracle Advanced Compression?

Database high availability and disaster recovery

1. What are your high availability requirements?
2. Do you use Oracle Data Guard? Where are your primary and standby database regions?
3. Do you use Oracle Active Data Guard?
4. Do you use a Domain Name System (DNS) alias for database connectivity?
5. Do you use replication tools such as Oracle GoldenGate, Quest SharePlex, or Oracle Streams?

29
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud

AWS Prescriptive Guidance glossary

6 Rs Six common migration strategies for moving applications to the cloud. These
strategies build upon the 5 Rs that Gartner identified in 2011 and consist of the
following:

• Rehost (lift and shift) – Move an application to the cloud without making any
changes to take advantage of cloud capabilities. Example: Migrate your on-
premises Oracle database to Oracle on an EC2 instance in the AWS Cloud.
• Replatform (lift and reshape) – Move an application to the cloud, and introduce
some level of optimization to take advantage of cloud capabilities. Example:
Migrate your on-premises Oracle database to Amazon RDS for Oracle in the
AWS Cloud.
• Refactor/re-architect – Move an application and modify its architecture by
taking full advantage of cloud-native features to improve agility, performance,
and scalability. This typically involves porting the operating system and
database. Example: Migrate your on-premises Oracle database to Amazon
Aurora PostgreSQL.
• Repurchase (drop and shop) – Switch to a different product, typically by moving
from a traditional license to an SaaS model. Example: Migrate your customer
relationship management (CRM) system to Salesforce.com.
• Retire – Decommission or remove applications that are no longer needed in
your source environment.
• Retain (revisit) – Keep applications in your source environment. These might
include applications that require major refactoring, and you want to postpone
that work until a later time, and legacy applications that you want to retain,
because there’s no business justification for migrating them.

For details, see the AWS migration whitepaper.

application portfolio A collection of detailed information about each application used by an

organization, including the cost to build and maintain the application, and its
business value. This information is key to the portfolio discovery and analysis
process and helps identify and prioritize the applications to be migrated,
modernized, and optimized.

artificial intelligence The process of using machine learning techniques to solve operational problems,
operations (AIOps) reduce operational incidents and human intervention, and increase service
quality. For more information about how AIOps is used in the AWS migration
strategy, see the operations integration guide.

30
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud

AWS Cloud Adoption A framework of guidelines and best practices from AWS to help organizations
Framework (AWS CAF) develop an efficient and effective plan to move successfully to the cloud. AWS
CAF organizes guidance into six focus areas called perspectives: business,
people, governance, platform, security, and operations. The business, people,
and governance perspectives focus on business skills and processes; the
platform, security, and operations perspectives focus on technical skills and
processes. For example, the people perspective targets stakeholders who handle
human resources (HR), staffing functions, and people management. For this
perspective, AWS CAF provides guidance for people development, training, and
communications to help ready the organization for successful cloud adoption. For
more information, see the AWS CAF website and the AWS CAF whitepaper.

AWS landing zone A landing zone is a well-architected, multi-account AWS environment that is
scalable and secure. This is a starting point from which your organizations can
quickly launch and deploy workloads and applications with confidence in their
security and infrastructure environment. For more information about landing
zones, see Setting up a secure and scalable multi-account AWS environment.

AWS Workload Qualification A tool that evaluates database migration workloads, recommends migration
Framework (AWS WQF) strategies, and provides work estimates. AWS WQF is included with AWS Schema
Conversion Tool (AWS SCT). It analyzes database schemas and code objects,
application code, dependencies, and performance characteristics, and provides
assessment reports.

business continuity planning A plan that addresses the potential impact of a disruptive event, such as a large-
(BCP) scale migration, on operations and enables a business to resume operations
quickly.

Cloud Center of Excellence A multi-disciplinary team that drives cloud adoption efforts across an
(CCoE) organization, including developing cloud best practices, mobilizing resources,
establishing migration timelines, and leading the organization through large-
scale transformations. For more information, see the CCoE posts on the AWS
Cloud Enterprise Strategy Blog.

cloud stages of adoption The four phases that organizations typically go through when they migrate to the
AWS Cloud:

• Project – Running a few cloud-related projects for proof of concept and

learning purposes
• Foundation – Making foundational investments to scale your cloud adoption
(e.g., creating a landing zone, defining a CCoE, establishing an operations
model)
• Migration – Migrating individual applications
• Re-invention – Optimizing products and services, and innovating in the cloud

These stages were defined by Stephen Orban in the blog post The Journey
Toward Cloud-First & the Stages of Adoption on the AWS Cloud Enterprise
Strategy blog. For information about how they relate to the AWS migration
strategy, see the migration readiness guide.

configuration management A database that contains information about a company’s hardware and software
database (CMDB) products, configurations, and inter-dependencies. You typically use data from a
CMDB in the portfolio discovery and analysis stage of migration.

epic In agile methodologies, functional categories that help organize and prioritize
your work. Epics provide a high-level description of requirements and
implementation tasks. For example, AWS CAF security epics include identity and

31
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud

access management, detective controls, infrastructure security, data protection,

and incident response. For more information about epics in the AWS migration
strategy, see the program execution guide.

heterogeneous database Migrating your source database to a target database that uses a different
migration database engine (for example, Oracle to Amazon Aurora). Heterogenous
migration is typically part of a re-architecting effort, and converting the schema
can be a complex task. AWS provides AWS Schema Conversion Tool (AWS SCT)
can help with schema conversions.

homogeneous database Migrating your source database to a target database that shares the same
migration database engine (for example, Microsoft SQL Server to Amazon RDS for SQL
Server). Homogeneous migration is typically part of a rehosting or replatforming
effort. You can use native database utilities to migrate the schema.

IT information library (ITIL) A set of best practices for delivering IT services and aligning these services with
business requirements. ITIL provides the foundation for ITSM.

IT service management (ITSM) Activities associated with designing, implementing, managing, and supporting IT
services for an organization. For information about integrating cloud operations
with ITSM tools, see the operations integration guide.

Migration Acceleration An AWS program that provides consulting support, training, and services to
Program (MAP) help organizations build a strong operational foundation for moving to the
cloud, and to help offset the initial cost of migrations. MAP includes a migration
methodology for executing legacy migrations in a methodical way and a set of
tools to automate and accelerate common migration scenarios.

Migration Portfolio An online tool that provides information for validating the business case for
Assessment (MPA) migrating to the AWS Cloud. MPA provides detailed portfolio assessment
(server right-sizing, pricing, TCO comparisons, migration cost analysis) as well
as migration planning (application data analysis and data collection, application
grouping, migration prioritization, and wave planning). The MPA tool (requires
login) is available free of charge to all AWS consultants and APN Partner
consultants.

Migration Readiness The process of gaining insights about an organization’s cloud readiness status,
Assessment (MRA) identifying strengths and weaknesses, and building an action plan to close
identified gaps, using the AWS CAF. For more information, see the migration
readiness guide. MRA is the first phase of the AWS migration strategy.

Migration Readiness and The process of gaining hands-on migration experience, including tools, processes,
Planning (MRP) and best practices, to prepare your organization for cloud migration. This phase
involves migrating 10 to 30 business applications to lay the foundation for
migrating your systems at scale. It consists of a defined set of activities across
eight workstreams. MRP is the second phase of the AWS migration strategy.

migration at scale The process of moving the majority of the application portfolio to the cloud in
waves, with more applications moved at a faster rate in each wave. This phase
uses the best practices and lessons learned from the earlier phases to implement
a migration factory of teams, tools, and processes to streamline the migration of
workloads through automation and agile delivery. This is the third phase of the
AWS migration strategy.

migration factory Cross-functional teams that streamline the migration of workloads through
automated, agile approaches. Migration factory teams typically include
operations, business analysts and owners, migration engineers, developers,
and DevOps professionals working in sprints. Between 20 and 50 percent of
an enterprise application portfolio consists of repeated patterns that can be

32
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud

optimized by a factory approach. For more information, see the discussion of

migration factories and the CloudEndure Migration Factory guide in this content
set.

operational-level agreement An agreement that clarifies what functional IT groups promise to deliver to each
(OLA) other, to support a service-level agreement (SLA).

operations integration (OI) The process of modernizing operations in the cloud, which involves readiness
planning, automation, and integration. For more information, see the operations
integration guide.

organizational change A framework for managing major, disruptive business transformations from a
management (OCM) people, culture, and leadership perspective. OCM helps organizations prepare for,
and transition to, new systems and strategies by accelerating change adoption,
addressing transitional issues, and driving cultural and organizational changes. In
the AWS migration strategy, this framework is called people acceleration, because
of the speed of change required in cloud adoption projects. For more information,
see the OCM guide.

playbook A set of predefined steps that capture the work associated with migrations, such
as delivering core operations functions in the cloud. A playbook can take the form
of scripts, automated runbooks, or a summary of processes or steps required to
operate your modernized environment.

responsible, accountable, A matrix that defines and assigns roles and responsibilities in a project. For
consulted, informed (RACI) example, you can create a RACI to define security control ownership or to identify
matrix roles and responsibilities for specific tasks in a migration project.

runbook A set of manual or automated procedures required to perform a specific task.

These are typically built to streamline repetitive operations or procedures with
high error rates.

service-level agreement (SLA) An agreement that clarifies what an IT team promises to deliver to their
customers, such as service uptime and performance.

33
 AWS Prescriptive Guidance Migrating
Oracle databases to the AWS Cloud

Document history
The following table describes significant changes to this guide. If you want to be notified about future
updates, you can subscribe to an RSS feed from the top navigation bar on this page.

update-history-change update-history-description update-history-date

Updated AWS WQF We updated the AWS WQF October 16, 2020
information (p. 34) section with the latest support
and availability information.

Added new sections (p. 34) We updated Oracle database March 16, 2020
migration strategies with
additional information, added
best practices for migrating
to Amazon RDS, and added a
questionnaire for migration
assessment and planning.

— (p. 34) Initial publication February 24, 2020

34