Migrating from Oracle Database to AWS
Enterprises that perform public cloud deployments from scratch, for them chances are high that they have Oracle Database running on premises. Moving those on-premises databases to the cloud has its benefits. However, an Oracle Database migration to AWS depends on various factors. Before undergoing an Oracle Database migration, IT teams must consider few facts like:
- Size of the database
- Available network bandwidth between the local data center and AWS
- Which software edition is running in the data center
- Business needs, such as the amount of time available to perform the move etc.
There are six key criteria that need to be considered when moving the Oracle database to the AWS cloud:
- Functionality / Application Changes: Functional changes are going to cost. Anytime you need to update, or regression test an application you will incur cost everything from developers implementing application code changes to operational training and change management.
- Capacity: Throughput, Response, Volume, and Performance are all inter-related terms or measures of Capacity. It would be rare to have end-users of an application accept a reduction in Capacity
- Resilience (Availability or Continuity): This is arguably the most controversial topic when migrating an Oracle DB to AWS. RAC (real application clusters) has been the default technique for ensuring availability of an Oracle DB for many years now – but you can’t do RAC on AWS.
- Security: We could write a whole article on security, but for the purposes of these general guidelines, let’s just say that migrating to Cloud presents a whole host of new and exciting security considerations. The actual database security doesn’t change – it is about whether you’re securing your infrastructure and storage appropriately and limiting access on a least privilege basis as you normally should.
- Agility: One of the major selling points of migrating to AWS is the agility – the ability to provision and de-provision almost limitless numbers or sizes of the database. (Note we said “almost”). You’ve also got the option to resize compute and storage as required (notwithstanding that you’ll need an outage). You’ll need to work on your internal processes.
- Cost: Deploying your Oracle DB typically incurs a startup capital cost, and ongoing operating cost and a licensing cost. There is no doubt that the AWS “pay as you go” model significantly reduces or even eliminates any up-front capital expenditure on the compute and storage infrastructure.
An Oracle Database migration could be accomplished in one step, but this requires a complete shutdown of the local database to extract and migrate the data to the new database in AWS. The process can take anywhere from one to three days, so this can be the most obtrusive migration strategy. Single-step database migrations are generally preferred for small businesses with limited database sizes that can tolerate prolonged database downtime during the migration.
Two-step migration strategies are common. The first step produces a point-in-time copy of the existing database, which can be moved to AWS without imposing any downtime on the local database. The local database continues to run during this process, so the actual migration can take as long as necessary — there is almost no tangible disruption.
After the initial Oracle Database migration, a second step will capture, migrate and synchronize any incremental changes to the database. Once completed, the local Oracle Database will need to be shut down while the final changes are captured and migrated. This incremental step is considerably less involved than the initial synchronization, so the downtime is shorter. Once the final synchronization is complete, the AWS deployment takes over and the local database is decommissioned.
A third option promises zero downtime. This typically starts with an initial synchronization and then invokes a form of continuous data replication (CDR) to perform complete synchronization of the local and AWS database versions. A variety of tools, including Oracle’s Golden Gate or third-party tools like Db visit Replicate and Attunity Replicate, can handle CDR. A business can make the switch to AWS once replication has synchronized the local and AWS databases. The CDR tool will continue to keep the instances synchronized. This option is typically reserved for the largest or most active Oracle database users who cannot tolerate any downtime. However, there is an added cost to use CDR, and continuous replication can potentially affect database or network performance.
This was almost everything about migrating Oracle database to AWS. Hope this piece of information was helpful.