Pythian Blog: Technical Track

Considerations for Converting from Oracle to Other RDBMS Platforms

by Robert Hamel on Sep 3, 2019 12:00:00 AM

Oracle software is known for being complex, expensive, and even cumbersome. However, while legacy database management systems (DBMS) like Oracle often hang around well past their best before date – in many cases due to corporate inertia and well-worn habit – the recent explosion in mainstream open-source databases (OSDBs) is quickly changing this dynamic. More than ever before, organizations formerly wedded to a monolithic Oracle system are now seriously questioning their vows. Potential cost savings on licensing fees, easier supportability and reduced operating costs, and a desire to simplify the data platform are all big push factors towards other commercial or open-source DBMSs such as MySQL, PostgreSQL, or Microsoft SQL Server. But exactly how easy is switching to an alternative platform while keeping the same functionality, reliability, and performance – and also saving on costs?

Key points to consider

There are three key points that, in a general sense, can make these kinds of conversions technically tricky:
  • Oracle database is, in most cases, a superset of the feature sets offered by alternatives
  • None of the alternative DBMSs match Oracle’s architecture exactly
  • Changing your applications to work with the new engine can require even more work than the data transfer itself, including code changes, driver changes, etc.
That’s why it’s crucial for your organization to carefully assess both your current and aspirational systems, so as to not dive into the deep end of the pool right away.

Why a TCO analysis is critical

Running a clear-eyed Total Cost of Ownership (TCO) analysis of both your current Oracle platform and the desired alternative by experts both in Oracle and the desired target platform is imperative. Because while Oracle conversions may seem relatively simple, it’s not uncommon for them to take many person years of effort to complete and cost millions of dollars – especially if planned badly. Your analysis must go far beyond simply counting object types. Level of complexity matters a great deal. We suggest running a much deeper analysis, using tools such as Microsoft’s SQL Server Migration Assistant (SSMA) or Ora2Pg . It’s also very important to take into consideration the ability to test (it may be relatively easy if you use DevOps CI/CD techniques and tooling, for example, but if not, it could end up as another significant expense), along with the expected code translation effort for your desired platform. (PostgreSQL and MariaDB have similar programmatic languages which can minimize code translation efforts, while Microsoft SQL Server’s Transact SQL is quite different).

Other complexities that could cause problems

Along with evaluating functional and performance requirements, organizations are remiss if they don’t also evaluate non-functional requirements such as:
  • Recoverability: Oracle offers several features designed for DBAs to roll back the database in case of error, but most other platforms only offer some of these features.
  • Security: Features like database native redaction, compression, or robust auditing aren’t always available on other platforms, and Oracle’s Database Vault is simply unavailable.
  • Support: Having to pay annual maintenance fees can be a drag, but there are advantages: you can open an unlimited number of tickets, and can count on Oracle support in case of catastrophic error.
  • Availability: Other platforms often have reduced online maintenance capabilities, or depend on external, third-party tools.

Why the cloud could be the best option

While it’s not a panacea by any means, migrating to the cloud, specifically Oracle’s second generation cloud known as Oracle Cloud Infrastructure (OCI) , could be a more reliable (and less frustrating) avenue.  

No Comments Yet

Let us know what you think

See all

See all

Subscribe by email
Follow us
Love Your Data
Pythian Logo

© 2024 All rights reserved.