Which approach should the Database Specialist take?
Dump all the tables from the Oracle database into an Amazon S3 bucket using datapump (expdp). Run data transformations in AWS Glue. Load the data from the S3 bucket to the Aurora DB cluster.
Order an AWS Snowball appliance and copy the Oracle backup to the Snowball appliance. Once the Snowball data is delivered to Amazon S3, create a new Aurora DB cluster. Enable the S3 integration to migrate the data directly from Amazon S3 to Amazon RDS.
Use the AWS Schema Conversion Tool (AWS SCT) to help rewrite database objects to MySQL during the schema migration. Use AWS DMS to perform the full load and change data capture (CDC) tasks.
Use AWS Server Migration Service (AWS SMS) to import the Oracle virtual machine image as an Amazon EC2 instance. Use the Oracle Logical Dump utility to migrate the Oracle data from Amazon EC2 to an Aurora DB cluster.
Explanations:
While the solution involves dumping data to Amazon S3 and using AWS Glue for transformations, it does not provide near-zero downtime or handle continuous data changes during migration, which is required for the migration of an active database.
Using AWS Snowball to transfer an Oracle backup to S3 and then loading it into Aurora does not allow for near-zero downtime, as it would require stopping the database or making manual adjustments to handle changes during the migration.
This is the recommended solution for migrating an on-premises Oracle database to Amazon Aurora MySQL. AWS SCT helps with schema conversion, and AWS DMS performs the full load and CDC (Change Data Capture), ensuring near-zero downtime during migration.
AWS SMS is used for migrating virtual machines, not databases. The Oracle Logical Dump utility and EC2 migration approach would not ensure near-zero downtime, and it’s not the optimal method for database migration to Aurora.