Asif
Asif  | Founder - KloudOne

Migrating from Oracle - Evaluating alternatives

Migrating from Oracle - Evaluating alternatives

Migrating from Oracle – Evaluating alternatives

As enterprises shift towards cloud, there is an accelerated trend to migrate out of Oracle to other cloud native databases. While planning such migration, businesses have several important considerations to plan for including ensuring that there’s business as usual in terms of services with no downtime.

So how does one plan for a migration out of a proven enterprise grade database and what options do businesses have? This blog talks about various options. The first step is really figuring out how to select an alternative. For most simpler options, PostgresQL (Enterprise DB or equivalent) or even MariaDB will suffice. But most apps have individual use cases. So how does one go about selecting the right option?

Preparing the requirements for qualifying the target database

Before we can decide on a target database, it is important to ask several key questions to understand how the Oracle database is used. Check list should include:

  • DB Topology – physical architecture.
  • Type of Oracle DB setup – master – slave, or Oracle RAC cluster
  • DB replication frequency and how is it configured today
  • Current DB Configuration information (OCM snapshot)
  • Snapshot of Oracle using ADDM during peak and normal workload
  • Backup frequency and how is it configured.
  • Cross DC replication (for DR) - required, and how is it configured (example Goldengate).
  • What is the replication strategy used.

Adhoc reporting / Datamart on DB

  • Does the db have an adhoc reporting solution
  • Does the adhoc reporting solution read against a datamart or a primary database.
  • Is the adhoc reporting solution being read against a read replica.
  • Is the data within each application, manually sharded?
  • If yes is the answer to previous question, how is the sizing and capacity planning done per shard. How do you determine that a cluster of size (n) will fit users (u).
  • Do you have sizing / performance guidelines per application (at DB layer)

Oracle specific dependency checklist

  • Extract full DDL including stored procedures, triggers, indexes, tables etc.
  • Does the application introduce specific database dependencies - example allow customers to write db code
  • Are there specific application level requirements for the database, for example:
  • Database response time should be within 20 ms.
  • Database should store large amounts of log data for 13 months etc.
  • Performance needs
  • Max write latency
  • Max read latency
  • Total no of writes per second.
  • Cluster specific requirements
  • Can the data be sharded or is a multi-master write environment needed.
  • Specific reasons why Oracle RAC cluster is required
  • RTO and RPO needs

Once there is a comprehensive inventory of information available regarding the Oracle db, it is then easy to compare options available. As there is no 1:1 feature mapping across every single database, any choice of database would require ways to verify that each individual requirement can be met by the target database.

Choosing a target database

Choosing an alternative to Oracle is not an easy task. Much of it really depends on the kind of needs and dependencies that you have on Oracle. Here are some broad options and their ranking for specific needs

Source DB Relational databases such as PostgreSQL, MariaDB etc Relational Cloud Hosted Databases RDS, Cloud SQL or scale out Cloud hosted dbs like Cloud SQL or Amazon Aurora or cloud native dataware houses like Snowflake
Simple db schema Most logical choice, although cloud hosted databases give an added advantage of no / low maintenance with a vendor lock-in Choice #2 Least expensive choice both in terms of cost, as well as maintenance. Watch out for performance, blocksizes, write speeds etc. Choice #1 Not applicable
Heavier performance, or high use of stored procedures, triggers Choice #1 Requires some amount of migration of schema using tools, or manually along with verification of data and application. Choice #2 Better choice if the management overhead of databases is not necessary, however limited support for Oracle specific schema and objects. No real vendor lock-in but can get expensive quickly. Migration assistance is available on AWS supported tools like Data migration Service or AWS Schema Conversion Tool. However the limitation in terms of how you can tune / manage performance makes this a secondary choice. How to migrate your Oracle database to Amazon Aurora Easiest choice if you would like to scale out without having to manage the database. Vendor lockin. Can get expensive. Migration assistance is available on AWS supported tools like Data migration Service or AWS Schema Conversion Tool. However the limitation in terms of how you can tune / manage performance makes this a secondary choice. How to migrate your Oracle database to Amazon Aurora
DR requirements Choice #2 for having to setup and manage DR as per needs using databases in different regions of the cloud. #1 choice as the cloud db provides DR as a service as opposed to you having to manage it. Worry free choice with vendor lockin.
Multi-master, HA and failover needs Can be configured using EnterpriseDB (Postgres) or Mariadb Maxscale or Percona to achieve multi-master setup to deliver HA, and failover. However, this option comes with high overhead of management. Enterprise support license recommended #1 choice. Can be delivered using a cloud based database with limited support for Oracle specific stored procedures / triggers and data types, all of which have go through some amount of automated conversion and verification of data.
Heavy OLTP usage Better choice if you don’t want to have vendor lock-in. Better choice if you want to reduce the cost of maintenance however watch out for long term costs. Cloud hosted databases can be very expensive in the long run.
Data warehousing use casess Not a great choice to begin with Not a good choice to begin with Cloud native data warehouses like Redshift, Snowflake, or large scale database systems like Aurora are better choices hence our recommender choice for this use case.

Summary

With this the first step in evaluating an alternative to Oracle is complete. As you understand, we have just accomplished a preliminary step of a) understanding what we have and b) understanding what are the alternative options available.

================================================== -->