# Migrating an On-Premises Oracle Database to Amazon Aurora MySQL


Following, you can find a high-level outline and also a complete step-by-step walkthrough that both show the process for migrating an on-premises Oracle database (the source endpoint) to an Amazon Aurora MySQL-Compatible Edition (the target endpoint) using AWS Database Migration Service (AWS DMS) and the AWS Schema Conversion Tool (AWS SCT).

 AWS DMS migrates your data from your Oracle source into your Aurora MySQL target. AWS DMS also captures data manipulation language (DML) and data definition language (DDL) changes that happen on your source database and apply these changes to your target database. This way, AWS DMS helps keep your source and target databases in synch with each other. To facilitate the data migration, DMS creates tables and primary key indexes on the target database if necessary.

However, AWS DMS doesn’t migrate your secondary indexes, sequences, default values, stored procedures, triggers, synonyms, views and other schema objects not specifically related to data migration. To migrate these objects to your Aurora MySQL target, use the AWS Schema Conversion Tool.

We highly recommend that you follow along using the Amazon sample database. To find a tutorial that uses the sample database and instructions on how to get a copy of the sample database, see [Working with the Sample Database for Migration](chap-on-premoracle2aurora.quickstart.md#chap-on-premoracle2aurora.appendix.sampledatabase).

If you’ve used AWS DMS before or you prefer clicking a mouse to reading, you probably want to work with the high-level outline. If you need the details and want a more measured approach (or run into questions), you probably want the step-by-step guide.


| Topic: Migration from On-Premises Oracle to Aurora MySQL or Amazon RDS for MySQL | 
| --- | 
|   **Time:**   | 
|   **Cost:**   | 
|   **Source Database:** Oracle  | 
|   **Target Database:** Amazon Aurora MySQL/MySQL  | 
|   **Restrictions:**   **Oracle Edition:** Enterprise, Standard, Express and Personal  **Oracle Version:** 10g (10.2 and later), 11g, 12c or higher  **MySQL or Related Database Version:** 5.5, 5.6, 5.7, MariaDB, Amazon Aurora MySQL  | 

## Costs


For this walkthrough, you provision AWS Database Migration Service (AWS DMS) resources. You can use a t2.large replication instance with 50 GB of storage to keep your replication logs. Also, you provision an Amazon Aurora MySQL DB instance. You can use a db.r3.large Aurora MySQL DB instance with 10 GB of storage. Provisioning these resources will incur charges to your user by the hour.

To estimate what it will cost to run this walkthrough on AWS, you can use the AWS Pricing Calculator. For more information, see [https://calculator.aws/](https://calculator.aws/) and [Database Migration Service pricing](https://aws.amazon.com/dms/pricing/).

To avoid additional charges, delete all resources after you complete the walkthrough.

# Migration from Oracle to Aurora MySQL using AWS DMS high-level outline


To migrate your data from Oracle to Aurora MySQL using AWS DMS, you take the following steps. If you’ve used AWS DMS before or prefer clicking a mouse to reading, the following summary should help you kick-start your migration. To get the details about migration or if you run into questions, see the step-by-step guide.

## Working with the Sample Database for Migration


We recommend working through the following outline and guide by using the sample Oracle database provided by Amazon. This database mimics a simple sporting event ticketing system. The scripts to generate the sample database can be found at https://github.com/aws-samples/aws-database-migration-samples/tree/master/oracle/sampledb/v1.

To build the sample database, go to the `oracle/sampledb/v1` folder and follow the instructions in the README.md file.

The sample creates approximately 8-10 GB of data. The sample database also includes a *ticketManagment* package, which you can use to generate some transactions. To generate transactions, log into SQL\$1Plus or SQL Developer and run the following as `dms_sample`:

```
SQL>call generateTicketActivity(1000,0.01);
```

The first parameter is the transaction delay in seconds, the second is the number of transactions to generate. The preceding procedure simply sells tickets to people. You’ll see updates to the tables: `sporting_event_ticket`, and `ticket_purchase_history`.

Once you’ve sold some tickets, you can transfer them using the command following:

```
SQL>call generateTransferActivity(100,0.1);
```

The first parameter is the transaction delay in seconds, the second is the number of transactions to generate. This procedure also updates `sporting_event_ticket` and `ticket_purchase_history`.

## Step 1: Prepare Your Oracle Source Database


To use AWS DMS to migrate data from an Oracle source database requires some preparation and we also recommend a few additional steps as best practices.
+  AWS DMS user — It’s a good practice to create a separate user for the specific purpose of migrating your data. This user should have the minimal set of privileges required to migrate your data. You can find specific details regarding those privileges later. If you are simply interested in testing AWS DMS on a non-production database, any DBA user will be sufficient.
+ Supplemental logging — To capture changes, you must enable supplemental logging in order to use DMS. To enable supplemental logging at the database level issue the following command.

  ```
  ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
  ```

  Additionally, AWS DMS requires for each table being migrated, you set at least key-level supplemental logging. AWS DMS automatically adds this supplemental logging for you if you include the following extra connection parameter for your source connection.

  ```
  addSupplementalLogging=Y
  ```
+ Source database – To migrate your data, the AWS DMS replication server needs access to your source database. Make sure that your firewall rules give the AWS DMS replication server ingress.

## Step 2: Launch and Prepare Your Aurora MySQL Target Database


Following are some things to consider when launching your Aurora MySQL instance:
+ For best results, we recommend that you locate your Aurora MySQL instance and your replication instance in the same VPC and, if possible, the same Availability Zone.
+ We recommend that you create a separate user with minimal privileges for migrating your data. The AWS DMS user needs the following privileges on all databases to which data is being migrated.

  ```
  ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT
  ```

  Additionally, AWS DMS needs complete access to the `awsdms_control` database. This database holds information required by AWS DMS specific to the migration. To provide access, run the following command.

  ```
  ALL PRIVILEGES ON awsdms_control.* TO 'dms_user'
  ```

## Step 3: Launch a Replication Instance


The AWS DMS service connects to your source and target databases from a replication instance. Here are some things to consider when launching your replication instance:
+ For best results, we recommend that you locate your replication instance in the same VPC and Availability Zone as your target database, in this case Aurora MySQL.
+ If either your source or target database is outside of the VPC where you launch your replication server, the replication server must be publicly accessible.
+  AWS DMS can consume a fair bit of memory and CPU. However, it’s easy enough to scale up if necessary. If you anticipate running several tasks on a single replication server or if your migration involves a large number of tables, consider using one of the larger instances.
+ The default storage is usually enough for most migrations.

## Step 4: Create a Source Endpoint


For AWS DMS to access your Oracle source database you’ll need to create a source endpoint. The source endpoint defines all the information required for AWS DMS to connect to your source database from the replication server. Following are some requirements for the source endpoint.
+ Your source endpoint needs to be accessible from the replication server. To allow this, you will likely need to modify your firewall rules to whitelist the replication server. You can find the IP address of your replication server in the AWS DMS Management Console.
+ For AWS DMS to capture changes, Oracle requires supplemental logging be enabled. If you want AWS DMS to enable supplemental logging for you, add the following to the extra connection attributes for your Oracle source endpoint.

  ```
  addSupplementalLogging=Y
  ```

## Step 5: Create a Target Endpoint


For AWS DMS to access your Aurora MySQL target database you’ll need to create a target endpoint. The target endpoint defines all the information required for DMS to connect to your Aurora MySQL database.
+ Your target endpoint needs to be accessible from the replication server. You might need to modify your security groups to make the target endpoint accessible.
+ If you’ve pre-created the database on your target, it’s a good idea to disable foreign key checks during the full load. To do so, add the following to your extra connection attributes.

  ```
  initstmt=SET FOREIGN_KEY_CHECKS=0
  ```

## Step 6: Create and Run a Migration Task


A migration task tells AWS DMS where and how you want your data migrated. When you create a migration task, consider setting migration parameters as shown following.

 **Endpoints and replication server** — Choose the endpoints and replication server created before.

 **Migration type** — In most cases you’ll want to choose **migrate existing data and replication ongoing changes**. With this option, AWS DMS loads your source data while capturing changes to that data. When the data is fully loaded, AWS DMS applies any outstanding changes and keeps the source and target databases in sync until the task is stopped.

 **Target table preparation mode** — If you’re having AWS DMS create your tables, **choose drop tables on target**. If you’re using some other method to create your target tables such as the AWS Schema Conversion Tool, choose **truncate.** 

 **LOB parameters** — If you’re just trying AWS DMS, choose **include LOB columns in replication**, **Limited LOB mode**, and set your **max LOB size to 16** (which is 16k.) For more information regarding LOBs, read the details in the step-by-step guide.

 **Enable logging** — To help with debugging migration issues, always enable logging.

 **Table mappings** — When migrating from Oracle to Aurora MySQL, we recommend that you convert your schema, table, and column names to lowercase. To do so, create a custom table mapping. The following example migrates the schema DMS\$1SAMPLE and converts schema, table and column names to lower case.

```
{
  "rules": [
    {
      "rule-type": "selection",
      "rule-id": "1",
      "rule-name": "1",
      "object-locator": {
        "schema-name": "DMS_SAMPLE",
        "table-name": "%"
      },
      "rule-action": "include"
    },
   {
      "rule-type": "transformation",
      "rule-id": "6",
      "rule-name": "6",
      "rule-action": "convert-lowercase",
      "rule-target": "schema",
      "object-locator": {
        "schema-name": "%"
      }
    },
    {
      "rule-type": "transformation",
      "rule-id": "7",
      "rule-name": "7",
      "rule-action": "convert-lowercase",
      "rule-target": "table",
      "object-locator": {
        "schema-name": "%",
        "table-name": "%"
      }
    },
    {
      "rule-type": "transformation",
      "rule-id": "8",
      "rule-name": "8",
      "rule-action": "convert-lowercase",
      "rule-target": "column",
      "object-locator": {
        "schema-name": "%",
        "table-name": "%",
        "column-name": "%"
      }
    }
  ]
}
```

# Step-by-step Oracle to Aurora MySQL using AWS DMS migration walkthrough


Following, you can find step-by-step instructions for migrating an Oracle database from an on-premises environment to Amazon Aurora MySQL. These instructions assume that you have already done the setting up steps for using AWS DMS located at [Setting up for Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.SettingUp.html).

**Topics**
+ [

# Step 1: Configure Your Oracle Source Database
](chap-on-premoracle2aurora.steps.configureoracle.md)
+ [

# Step 2: Configure Your Aurora Target Database
](chap-on-premoracle2aurora.steps.configureaurora.md)
+ [

# Step 3: Create a Replication Instance
](chap-on-premoracle2aurora.steps.createreplicationinstance.md)
+ [

# Step 4: Create Your Oracle Source Endpoint
](chap-on-premoracle2aurora.steps.createoracle.md)
+ [

# Step 5: Create Your Aurora MySQL Target Endpoint
](chap-on-premoracle2aurora.steps.createaurora.md)
+ [

# Step 6: Create a Migration Task
](chap-on-premoracle2aurora.steps.createtask.md)
+ [

# Step 7: Monitor Your Migration Task
](chap-on-premoracle2aurora.steps.monitor.md)
+ [

# Troubleshooting
](chap-on-premoracle2aurora.steps.troubleshooting.md)

# Step 1: Configure Your Oracle Source Database


To use Oracle as a source for AWS Database Migration Service (AWS DMS), you must first ensure that ARCHIVELOG MODE is on to provide information to LogMiner. AWS DMS uses LogMiner to read information from the archive logs so that AWS DMS can capture changes.

For AWS DMS to read this information, make sure the archive logs are retained on the database server as long as AWS DMS requires them. If you configure your task to begin capturing changes immediately, you should only need to retain archive logs for a little longer than the duration of the longest running transaction. Retaining archive logs for 24 hours is usually sufficient. If you configure your task to begin from a point in time in the past, archive logs need to be available from that time forward. For more specific instructions for enabling ARCHIVELOG MODE and ensuring log retention for your on-premises Oracle database see the [Oracle documentation](https://community.oracle.com/thread/3717174).

To capture change data, AWS DMS requires supplemental logging to be enabled on your source database for AWS DMS. Minimal supplemental logging must be enabled at the database level. AWS DMS also requires that identification key logging be enabled. This option causes the database to place all columns of a row’s primary key in the redo log file whenever a row containing a primary key is updated (even if no value in the primary key has changed). You can set this option at the database or table level.

To configure your Oracle source database, do the following:

 **1. Enable database-level supplemental logging** 

Run the following command to enable supplemental logging at the database level, which AWS DMS requires:

```
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
```

 **2. Enable identification key supplemental logging** 

Use the following command to enable identification key supplemental logging at the database level. AWS DMS requires supplemental key logging at the database level unless you allow AWS DMS to automatically add supplemental logging as needed or enable key-level supplemental logging at the table level:

```
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
```

 **3. (Optional) Enable key level supplemental logging at the table level** 

Your source database incurs a small bit of overhead when key level supplemental logging is enabled. Therefore, if you are migrating only a subset of your tables, you might want to enable key level supplemental logging at the table level. To enable key level supplemental logging at the table level, use the following command.

```
alter table table_name add supplemental log data (PRIMARY KEY) columns;
```

If a table does not have a primary key you have two options:
+ You can add supplemental logging to all columns involved in the first unique index on the table (sorted by index name.)
+ You can add supplemental logging on all columns of the table.

To add supplemental logging on a subset of columns in a table, that is those involved in a unique index, run the following command.

```
ALTER TABLE table_name ADD SUPPLEMENTAL LOG GROUP example_log_group (ID,NAME)
ALWAYS;
```

To add supplemental logging for all columns of a table, run the following command.

```
alter table table_name add supplemental log data (ALL) columns;
```

 **4. Create or configure a database account to be used by AWS DMS ** 

We recommend that you use a user with the minimal privileges required by AWS DMS for your AWS DMS connection. AWS DMS requires the following privileges.

```
CREATE SESSION
SELECT ANY TRANSACTION
SELECT on V_$ARCHIVED_LOG
SELECT on V_$LOG
SELECT on V_$LOGFILE
SELECT on V_$DATABASE
SELECT on V_$THREAD
SELECT on V_$PARAMETER
SELECT on V_$NLS_PARAMETERS
SELECT on V_$TIMEZONE_NAMES
SELECT on V_$TRANSACTION
SELECT on ALL_INDEXES
SELECT on ALL_OBJECTS
SELECT on ALL_TABLES
SELECT on ALL_USERS
SELECT on ALL_CATALOG
SELECT on ALL_CONSTRAINTS
SELECT on ALL_CONS_COLUMNS
SELECT on ALL_TAB_COLS
SELECT on ALL_IND_COLUMNS
SELECT on ALL_LOG_GROUPS
SELECT on SYS.DBA_REGISTRY
SELECT on SYS.OBJ$
SELECT on DBA_TABLESPACES
SELECT on ALL_TAB_PARTITIONS
SELECT on ALL_ENCRYPTED_COLUMNS
* SELECT on all tables migrated
```

If you want to capture and apply changes (CDC) you also need the following privileges.

```
EXECUTE on DBMS_LOGMNR
SELECT on V_$LOGMNR_LOGS
SELECT on V_$LOGMNR_CONTENTS
LOGMINING /* For Oracle 12c and higher. */
* ALTER for any table being replicated (if you want to add supplemental logging)
```

For Oracle versions before 11.2.0.3, you need the following privileges. If views are exposed, you need the following privileges.

```
SELECT on DBA_OBJECTS /* versions before 11.2.0.3 */
SELECT on ALL_VIEWS (required if views are exposed)
```

# Step 2: Configure Your Aurora Target Database


As with your source database, it’s a good idea to restrict access of the user you’re connecting with. You can also create a temporary user that you can remove after the migration.

```
CREATE USER 'dms_user'@'%' IDENTIFIED BY 'dms_user';
GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE,
SELECT ON <target database(s)>.* TO 'dms_user'@'%';
```

 AWS DMS uses some control tables on the target in the database awsdms\$1control. The following command ensures that your dms\$1user has the necessary access to the `awsdms_control` database:

```
GRANT ALL PRIVILEGES ON awsdms_control.* TO 'dms_user'@'%';
flush privileges;
```

# Step 3: Create a Replication Instance


An AWS DMS replication instance performs the actual data migration between source and target. The replication instance also caches the changes during the migration. How much CPU and memory capacity a replication instance has influences the overall time required for the migration. Use the following procedure to set the parameters for a replication instance.

To create an AWS DMS replication instance, do the following:

1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/), and open the AWS DMS console at https://console.aws.amazon.com/dms/v2/ and choose **Replication instances**. If you are signed in as an AWS Identity and Access Management (IAM) user, you must have the appropriate permissions to access AWS DMS. For more information on the permissions required, see [IAM Permissions](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Security.html#CHAP_Security.IAMPermissions).

1. Choose **Create replication instance**.

1. On the **Create replication instance** page, specify your replication instance information as shown following.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-on-premoracle2aurora.steps.createreplicationinstance.html)

1. In the **Advanced** section, set the **Allocated storage (GB)** parameter, and then choose **Next**.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-on-premoracle2aurora.steps.createreplicationinstance.html)

# Step 4: Create Your Oracle Source Endpoint


While your replication instance is being created, you can specify the Oracle source endpoint using the [AWS Management Console](https://console.aws.amazon.com/). However, you can only test connectivity after the replication instance has been created, because the replication instance is used to test the connection.

To specify source or target database endpoints, do the following:

1. In the AWS DMS console, choose **Endpoints** on the navigation pane.

1. Choose **Create endpoint**. The **Create database endpoint page** appears, as shown following.  
![\[Create source and target DB endpoints\]](http://docs.aws.amazon.com/dms/latest/sbs/images/datarep-gs-wizard3.png)

1. Specify your connection information for the source Oracle database. The following table describes the source settings.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-on-premoracle2aurora.steps.createoracle.html)

1. Choose the **Advanced** tab to set values for extra connection strings and the encryption key.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-on-premoracle2aurora.steps.createoracle.html)

Before you save your endpoint, you can test it. To do so, select a VPC and replication instance from which to perform the test. As part of the test AWS DMS refreshes the list of schemas associated with the endpoint. (The schemas are presented as source options when creating a task using this source endpoint.)

# Step 5: Create Your Aurora MySQL Target Endpoint


Next, you can provide information for the target Amazon Aurora MySQL database by specifying the target endpoint settings.

To specify a target database endpoint, do the following:

1. In the AWS DMS console, choose **Endpoints** on the navigation pane.

1. Choose **Create endpoint**. The **Create endpoint** appears, as shown following.

1. Specify your connection information for the target Aurora MySQL database. The following table describes the target settings.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-on-premoracle2aurora.steps.createaurora.html)

1. Define additional specific settings for your endpoints using wizard or editor in **Endpoint settings**.

1. Choose the encryption key to use to encrypt replication storage and connection information in **KMS key**. If you choose **(Default) aws/dms**, the default AWS Key Management Service (AWS KMS) key associated with your user and region is used.

1. Add tags to organize your DMS resources in **Tags**. You can use tags to manage your IAM roles and policies, and track your DMS costs.

Prior to saving your endpoint, you have an opportunity to test it in **Test endpoint connection (optional)**. To do so you’ll need to choose a VPC and replication instance from which to perform the test.

# Step 6: Create a Migration Task


When you create a migration task you tell AWS DMS exactly how you want your data migrated. Within a task you define which tables you’d like migrated, where you’d like them migrated, and how you’d like them migrated. If you’re planning to use the change capture and apply capability of AWS DMS it’s important to know transactions are maintained within a single task. In other words, you should migrate all tables that participate in a single transaction together in the same task.

Using an AWS DMS task, you can specify what schema to migrate and one of the following types of migration:
+ Migrate existing data
+ Migrate existing data and replicate ongoing changes
+ Replicate data changes only

This walkthrough migrates existing data only.

To create a migration task, do the following:

1. On the navigation pane, choose **Tasks**.

1. Choose **Create Task**.

1. On the **Create Task** page, specify the task options. The following table describes the settings.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-on-premoracle2aurora.steps.createtask.html)

1. Next, set the Advanced settings as shown following.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-on-premoracle2aurora.steps.createtask.html)

1. Set additional parameters.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-on-premoracle2aurora.steps.createtask.html)

1. Specify any table mapping settings.

   Table mappings tell AWS DMS which tables a task should migrate from source to target. Table mappings are expressed in JSON, though some settings can be made using the [AWS Management Console](https://console.aws.amazon.com/). Table mappings can also include transformations such as changing table names from the upper case to lower case.

    AWS DMS generates default table mappings for each (non-system) schema in the source database. In most cases you’ll want to customize your table mapping. To customize your table mapping select the custom radio button. For details on creating table mappings see the AWS DMS documentation. The following table mapping does these things:
   + It includes the DMS\$1SAMPLE schema in the migration.
   + It excludes the tables NFL\$1DATA, MLB\$1DATA, NAME\$1DATE, and STADIUM\$1DATA.
   + It converts the schema, table, and column names to lower case.

     ```
     {
       "rules": [
         {
           "rule-type": "selection",
           "rule-id": "1",
           "rule-name": "1",
           "object-locator": {
             "schema-name": "DMS_SAMPLE",
             "table-name": "%"
           },
           "rule-action": "include"
         },
     
         {
           "rule-type": "selection",
           "rule-id": "2",
           "rule-name": "2",
           "object-locator": {
             "schema-name": "DMS_SAMPLE",
             "table-name": "MLB_DATA"
           },
           "rule-action": "exclude"
         },
     {
           "rule-type": "selection",
           "rule-id": "3",
           "rule-name": "3",
           "object-locator": {
             "schema-name": "DMS_SAMPLE",
             "table-name": "NAME_DATA"
           },
           "rule-action": "exclude"
         },
     
         {
           "rule-type": "selection",
           "rule-id": "4",
           "rule-name": "4",
           "object-locator": {
             "schema-name": "DMS_SAMPLE",
             "table-name": "NFL_DATA"
           },
           "rule-action": "exclude"
         },
     
         {
           "rule-type": "selection",
           "rule-id": "5",
           "rule-name": "5",
           "object-locator": {
             "schema-name": "DMS_SAMPLE",
             "table-name": "NFL_STADIUM_DATA"
           },
           "rule-action": "exclude"
         },{
           "rule-type": "transformation",
           "rule-id": "6",
           "rule-name": "6",
           "rule-action": "convert-lowercase",
           "rule-target": "schema",
           "object-locator": {
             "schema-name": "%"
           }
         },
         {
           "rule-type": "transformation",
           "rule-id": "7",
           "rule-name": "7",
           "rule-action": "convert-lowercase",
           "rule-target": "table",
           "object-locator": {
             "schema-name": "%",
             "table-name": "%"
           }
         },
         {
           "rule-type": "transformation",
           "rule-id": "8",
           "rule-name": "8",
           "rule-action": "convert-lowercase",
           "rule-target": "column",
           "object-locator": {
             "schema-name": "%",
             "table-name": "%",
             "column-name": "%"
           }
         }
       ]
     }
     ```

# Step 7: Monitor Your Migration Task


Three sections in the console provide visibility into what your migration task is doing:
+ Task monitoring — The **Task Monitoring** tab provides insight into your full load throughput and also your change capture and apply latencies.
+ Table statistics — The **Table Statistics** tab provides detailed information on the number of rows processed, type and number of transactions processed, and also information on DDL operations.
+ Logs — From the **Logs** tab you can view your task’s log file, (assuming you turned logging on.) If for some reason your task fails, search this file for errors. Additionally, you can look in the file for any warnings. Any data truncation in your task appears as a warning in the log file. If you need to, you can increase the logging level by using the AWS Command Line Interface (AWS CLI).

# Troubleshooting


The two most common areas people have issues with when working with Oracle as a source and Aurora MySQL as a target are: supplemental logging and case sensitivity.
+ Supplemental logging — With Oracle, in order to replication change data supplemental logging must be enabled. However, if you enable supplemental logging at the database level, it sometimes still need to enable it when creating new tables. The best remedy for this is to allow DMS to enable supplemental logging for you using the extra connection attribute:

  ```
  addSupplementalLogging=Y
  ```
+ Case sensitivity — Oracle is case-insensitive (unless you use quotes around your object names). However, text appears in the upper case. Thus, AWS DMS defaults to naming your target objects in the upper case. In most cases, you’ll want to use transformations to change schema, table and column names to lower case.

For more tips, see the AWS DMS troubleshooting section in the [Troubleshooting migration tasks in Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html).

To troubleshoot issues specific to Oracle, see the Oracle troubleshooting section: [Troubleshooting issues with Oracle](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.Oracle).

To troubleshoot Aurora MySQL issues, see the MySQL troubleshooting section: [Troubleshooting issues with MySQL](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.MySQL).