Migrating Oracle Databases to Open Source Technologies AUTHOR John Schulz Principal Consultant, Microsoft MCM & MVP V01-012021-HW MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 2 Introduction Some Oracle customers today are beginning to weigh other options, often for a host of reasons including Oracle’s license and contract restrictions, customer audits, concern about eventually being locked in, and high support costs. One option they may choose is to migrate to open source databases (OSDBs) with much less restrictive licenses and no license fees. In this document, we will review the options current Oracle users have to migrate to open source database technology. We will start with what Oracle database technologies are currently in use, compare those to the many Open source options available, and then review how best to get there, including an evaluation of many of the robust tools available to help. All OSDBs offer a subset of the capabilities and feature options of the Oracle database, so first reviewing the Pythian white paper “Considerations For Converting From Oracle To Other RDBMS Platforms” is highly recommended. This will help ensure that the options, features, and non-functional capabilities unique to Oracle are either not used or are a palatable loss. No matter which Oracle database technologies are in use, there are three general approaches to migrating to an OSDB: 1. Direct migration Migrate the schema into the new OSDB format, modify the data manipulation language (DML) to work with the new OSDB technology, and copy over the data to the new database. This approach, while straightforward, is usually only practical for a small subset of OSDB technologies and in some cases not even for those. 2. Refactor the application and re-write for the new OSDB technologies chosen This approach, while daunting, is often the better one as it allows for a new application which eliminates technical debt and improves operability, including scaling and availability and faster features to market. It is also a major undertaking, and the return on investment is likely to be years away. 3. Find the right off-the-shelf application which supports the OSDB of your choice. The application itself may be either proprietary or open-source. pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 3 Oracle Single-Instance vs RAC vs Exadata Oracle offers several products, and Oracle Database can roll out several specific feature sets to suit certain workloads. The kind of workload will, at least in part, drive the final decision as to which OSDB technologies are good use cases for the migration. Single-Instance Oracle Databases Many Oracle databases run on a single host, optionally with one or more standby databases providing disaster recovery (DR) , backup or query off-loading. These configurations are typically used by most small to medium-sized businesses for the majority of their database traffic. The workloads tend to vary extensively and can include transactional, content management, business intelligence, and data warehouse use cases. Oracle RAC This is Oracle’s premier high-volume transactional engine, designed for high availability (HA) via horizontal scalability. It operates as a cluster of computers with shared storage designed to scale beyond a single system while offering HA without replication. For DR, RAC installations also replicate to one or more standby RAC (or non-RAC) databases as part of Oracle’s Maximum Availability Architecture (MAA). Exadata Exadata is Oracle’s hardware-based product (with unique hardware and software capabilities, not replicable outside of the Exadata platform) designedto support large data warehouse applications and high volume OLTP applications. It is the only Oracle Database product that supports on-disk column store technology. Business Requirements Before thinking about which database technology to which you might want to migrate, you should evaluate your business requirements. Knowing what your real business requirements are will help you select the best OSDB technology in terms of the database itself, along with the way you’ll configure it and what tools you’ll use. High Availability (HA) We all want our databases to be highly available. But there is always a cost to keeping a database up 24X7, 365 days a year with 99.9999% uptime. Understanding your real needs will help identify what technologies you should investigate and how you might want to configure them. pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 4 Disaster Recovery (DR) What are your DR requirements? Will you need an active disaster site able to seamlessly take over from the primary? Will a passive backup be acceptable? Can you just rebuild from the data you have in another database, meaning the cost of DR may not even be justified? Global Data Distribution Will your database need to be available globally, with data replicated between nodes more or less transparently? Or will you want a single central database with geographically distributed copies? Or maybe you just want to store customer data in the closest datacenter, and then safely replicate it in just one other place. Rapid Response to Changing Requirements Will your database need to support rapid changes due to fluctuations in market conditions? To take advantage of new business opportunities? Or will the database structure be more or less static, changing only slightly over time? Regulatory Requirements What are your regulatory and compliance requirements? This matters a good deal. Depending on what kind of data you have, one or more of the OSDB databases may not meet your needs – or you may need additional software to make it work. If you are thinking of migrating to a public cloud, is the cloud or the database offering in the cloud certified and able to meet your compliance requirements? Continuous Availability during Migration When it comes time to migrate to the new database technology, will users of the source Oracle Database and the target OSDB database(s) require continuous uninterrupted access to all the data? Will access to most of the data be acceptable? Will it be okay for applications to be down? If so, for how long? Migrating data in a batch inside of a downtime window is clearly the easiest and simplest route but is not always acceptable. What is your requirement? Migration Approaches We mentioned up top that there are three general options when migrating from your Oracle Database. However, within those three options are many additional considerations. pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 5 Direct Migration With direct migration, you will need to evaluate the existing schema and SQL code, especially any stored program code (PL/SQL). There are a number of tools available to help in this effort, such as Ora2Pg and AWS Database Migration Services (DMS). After determining what features and functions are missing or just named differently, you will need to convert the schema and code. In many cases, this means changing at least some program logic. If your code used an object-relational mapper (ORM), this may prove relatively painless. If not, and if there are many lines of code to change, this could be a major effort. Once you complete the analysis and translation phases, you will next need to set up a test environment to validate the schema and code changes. After all these considerations are carefully weighed, it’s finally time to migrate the data. There are two approaches you can take: 1. Batch Shut down the existing application, dump the data, and restore it to the new database. This can be done through utilities like Ora2Pg or AWS DMS. It also can typically be done by performing a SQL-level dump from Oracle, suitably modifying it, and restoring it into the new database. This approach is generally straightforward and if downtime is acceptable, it’s often the simplest approach 2. Online heterogeneous replication In this case, you bring up both databases, load a copy of the production data into the new database, and start replicating from the existing Oracle Database to the new one. Oracle Golden Gate can target many databases and do this for you. You can also use AWS DMS (if you are migrating to AWS). There are also numerous other third-party options, with one of the most versatile being Kafka. In that case, you use an Oracle sink to write to Kafka, which can be done via Golden Gate. You must then use a source for your database to write to your new database. This approach allows for transformation work to take place between the source and destination, which is sometimes useful. Method two is the most common since it requires no downtime and can sometimes accommodate a slow roll migration with replication going in both directions. But it is also much harder to implement. Refactor and Rewrite For many large, complex databases using many Oracle-specific features and large amounts of stored program code, this is the correct approach. pythian.com MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 6 It also provides additional benefits: • Eliminate Technical debt – Old code and workarounds to resolve compatibility with old features make code fragile and difficult to fix or enhance • Move to a modern microservice framework – Allows developers to create new features faster with generally lower error rates • An updated codebase is a golden opportunity to implement data governance best practices from the ground up When taking this approach it is common to break a single monolithic database