Migrating from Oracle RAC to AWS RDS with 15 minutes downtime.

A few days ago, we were challenged to reduce the database downtime for an Oracle RAC (on-premisses) migration to AWS RDS.
Other teams had already tried to optimize the migration process and reduce database downtime ( which makes it even more challenging ) but their best estimation was a 4 hours downtime, which was yet too high for the customer expectations and criticality of the business.
Don’t have to mention that we also had a tight deadline of a few days to define the new migration strategy.

Scenario:

• Version migration: From Oracle 11g on RAC (with ASM) to Oracle 12g on AWS RDS;
• Network latency: From an on-premisses environment located at São Paulo region to AWS RDS at US East (N. Virginia);
• LOB objects: ~40% of the the database size in a single table;

We knew, based on past migrations projects, that AWS Database Migration Service (DMS) would help us to solve this challenge.

First we tried loading the target database and creating a single CDC task, but the combination of large LOBs and high latency between the two environments made the task to run slower then transactions on the source database and consequently this approach did not work.

After failing on the first approach, we analysed the database model and identified no database object was dependent on the table with the LOB columns, so we decided to processe the table with LOB columns separately.

On the second approach, we loaded the the target database and, this time, we created two CDC task, one for all database objects except the table with LOBs and a second task exclusively with the table with LOB columns.

This way, the first task, with all the objects except the table with lobs, started running faster then the transactions on the source database and quickly we had the target database in-sync with the source database.

For the table with LOB columns, our strategy was to load all records until one day before and during the dawn, when transactions volume decreased significantly on the source database, we loaded only the records of the day and started the second task. This time the task was able to run faster then the source database and keep the target database in-sync with the source database.

As soon as we had both tasks synced, we stopped the source database and redirected the application to the AWS RDS database.

"With this approach, we achieved a downtime of just 15 minutes which greatly reduced the impact on our business." — Eugênio Barbaresco, Diretoria de TI do Grupo Comporte S/A.