AWS DMS tips for Oracle migrations

3 min read

Oct 27, 2016 12:00:00 AM

Some time ago I published a post regarding the Database Migration Service (DMS) on AWS. The service had just appeared at that time and looked very promising. It is still appealing and has a good use and potential to mature and be better. I was able to test and try it in several cases moving data to AWS and between RDS databases inside AWS. During those exercises, I ran into some issues and wanted to make other people aware of some things to keep in mind when starting or planning to use the DMS. Most of my experience with DMS is related to migrations to and from Oracle databases. So the following tips are about Oracle migrations and replications. Before planning any kind of a logical replication based on transaction logs please check what kind of data types you have and whether you have primary keys on all your replicated tables. The primary key existence in some cases is not only desirable but is required to properly replicate the objects. As an example, if you want to replicate a table with some lob objects using DMS you must have a primary key for the table because if you don't your lob columns will be excluded from replication and you end up with null values instead of the lobs on the target database. Check for data types used for the tables. All logical replications have some limitations in terms of replicated data types. You may find some of your tables can be replicated with some limitations or not replicated at all. Let's speak about DMS. When you plan your DMS replication tasks keep in mind that you can combine replication of several schemas to one task. It may significantly reduce load on the source system. Each migration or replication task may apply a considerable load to the source system. In my experience, we hit 100% CPU and max IO load running 8 replication tasks on the source m3.large system. Remember you cannot change the created task. You are able to stop, start or resume the task but you cannot alter any rules or parameters for the task. It will maybe change soon but currently, it is not possible yet. If you choose the truncate option for your migration and replication task it may change your metadata. You may find your indexes and constraints to be renamed and you even can lose some of the indexes. In my case, I got renamed primary key and unique key constraints and couple of indexes were lost. Please be careful. After that case, I tried to choose "do nothing" mode and do everything by myself preparing the target for data migration and replication. You can use RDS snapshot to instantiate your data if you plan to setup a replication between two RDS instances of the same type. In our case, it was done to minimize downtime when the database was migrated to an encrypted storage. When you use RDS snapshot you can use snapshot creation time as "Custom CDC start time" for your DMS replication task. If you use one universal user for your endpoints to replicate multiple schemas you will need to use transformation rules because the replication will try to use schema from endpoint as destination target by default. By other words, you set up a target endpoint using user "DMS" and try to replicate schema SCOTT it will use schema "DMS" as a destination by default if you don't have the transformation rules. You have to enable minimal supplemental logging on database level and supplemental logging for all columns explicitly for each replicated table. Even you enable supplemental logging for all columns on database level using "alter database" you still need to add it on table level. The DMS task will be aborted without it complaining about the lack of supplemental logging for all column for the table. If you create a table in one of your replicated schema you need to add a clause for supplemental logging like "CREATE TABLE ...ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS; " . In that case, the table and data will be replicated. It is better to use AWS cli to get most of the service since all new features and additions will be in cli first. As an example, if you want a debug logging for your replication you have to use AWS cli. If you have only unique index on a table and it is function based index your data migration and replication task can fail. Also, it may fail if you have more than one unique index on a table. I hit some issues with monitoring. The idea looks good but it requires some fixing. It looks like it doesn't work correctly in Firefox and Safari. At least for me, it was not working right. The status of a task may not tell you everything. Sometimes it shows state "ERROR" but nevertheless, it works and replicates data behind the scenes. So, it can be bit misleading. I look to statistics and monitoring pages for the task to get the full picture. As a summary, I can say the service deserves attention and can be considered as a valuable option when you plan your migration strategy and AWS DMS team works hard to make it better. Happy migrations!

On this page

Ready to unlock value from your data?

With Pythian, you can accomplish your data transformation goals and more.

Speak with Pythian consultants now →

What We Do

AWS DMS tips for Oracle migrations

Share this

Share this

More resources

Amazon EFS Top-Talkers

Redshift table maintenance: vacuuming

Build a Data Lake Using Lake Formation on AWS

Ready to unlock value from your data?