View a markdown version of this page

Phase 1: Prepare - AWS Prescriptive Guidance

Phase 1: Prepare

During the preparation phase, assess your existing database and identify its dependencies. The following sections cover the main items to evaluate before you plan the migration.

Dependency analysis

When preparing for the Oracle migration, identify interdependencies and their impact on the interfacing applications. Answer the following initial questions:

  • Dependency check – Identify applications that connect to the database directly. To avoid any latency concerns, we recommend that you migrate the applications along with the database. For applications that access data indirectly through an API, identify the performance impact and the downtime requirement for migration.

  • Access to other databases – Oracle Database provides a mechanism for accessing data in another database over a network by using a database link. The database link helps you read from, and write to, tables in a remote database. For example, a reporting application might fetch data from a centralized database that uses database links to fetch data from other databases in the same business unit. It's important to identify all such connections and recreate the database links after migration.

  • External jobs – Sometimes database jobs are scheduled and controlled outside the database. To avoid any downstream impact, make sure that those jobs continue to run during the database migration.

  • Data center dependencies – During migration there might be times when some of your systems are in the cloud whereas other systems are still in the on-premises data center. Network latency plays a big factor in these configurations. Decide whether you want to migrate applications and databases that are sensitive to latency together, or if you want to move the functionality to the migrating database. In either case, we recommend that you migrate your applications to the same Availability Zone as your migrated database to avoid any network latency.

  • Access to host – Some applications create reports that are stored in a file system on a database server. When you migrate your database, you can decide to modernize your report generation as well by saving the reports in cloud-native storage. Based on how complex it might be to change report generation, you can decide to use Amazon EC2, Amazon RDS, or Amazon RDS Custom as a target for the Oracle database.

  • Specific database options, features, and patch requirements – Review the Oracle database features you use and your requirements after migration. Feature use and post-migration needs help determine the database setup in the cloud. One-off patches in the source Oracle database might require your database to be migrated to Amazon RDS Custom or an EC2 instance.

Availability requirements

Depending on business needs, some databases must be operational all day, every day. Other databases can afford downtime after business hours or during weekends. In the preparation phase of migration planning, it's important to understand the business impact of database downtime and choose the appropriate migration strategy. For example, online migration has minimal downtime, whereas offline migration involves a longer downtime period.

Workload analysis

Understanding the nature of your database workload helps you determine your database migration strategy. The window for migration and any downtime needed depend on the workload. Workloads can range from being highly transactional to consisting mostly of batch jobs and reporting. To help with your migration planning and strategy, identify where your workload lies in this spectrum.

Tools are available to help you qualify your database workload. The tools that you can use depend on your Oracle Database license and include the following:

  • Host metrics such as CPU, I/O, and memory help you decide the instance and storage requirements for your databases in the cloud.

  • Oracle reports such as Automatic Workload Repository (AWR) for Oracle Database Enterprise Edition or Statspack for Standard Edition help you determine the nature of transactions that occur in your database.

  • Redo and archive log generation help you determine the rate of change that occurs in your database.