Era enables small, nimble teams of database administrators (DBAs) to easily manage large fleets of SQL Server, Oracle Database, and PostgreSQL databases using a single console and API. DBAs are charged with the often tedious work of deploying, managing, and operating hundreds to thousands of development, test, and production databases. Additionally, DBAs must make sure that business requirements for these databases, including high availability, disaster recovery, performance, scale, and cost are met. With Era, DBAs can meet business requirements for both new and already deployed databases on-premises and in the public cloud (using Nutanix Cloud Infrastructure), freeing their time and skills to focus on the most critical databases. Finally, customers can use Era to deliver their own Database-as-a-Service (DBaaS) solution to provide their developers with an easy-to-use self-service database experience on-premises.
With the latest Era [v2.3.1 release date 29th of October 2021] release, support for EDB Postgres Advanced Server (EPAS) is introduced. Era already supports community edition of PostgreSQL.
What is EPAS?
Why add support for EPAS? EPAS is EDB’s core database product and is included with their Enterprise subscription plan. It is a managed fork of open-source PostgreSQL with additional functionality that focuses on Oracle database compatibility, security, productivity, and performance.
So, it can help customers migrate database and client applications faster with fewer rewrite problems. They can continue to use their Oracle skills and more easily integrate PostgreSQL into existing Oracle database infrastructures.
One-way EDB helps is with the Migration Platform, see https://migration.enterprisedb.com/. In that platform, customers can upload schemas they want to migrate. Those schemas will be assessed in the background and code that is not compatible is either system repaired (EDB will change the DDL for the majority of incompatible DDL, so it becomes compatible) or need to be user repaired. For code that could be changed automatically, EDB will produce a possible workaround. When the compatibility is at 100% you can simply download the EPAS compatible SQL file and start importing the schemas into the PostgreSQL database. Sure, extensive testing still needs to be carried out but the complexity of the migration itself is minimized tremendously.
How does that work in real life?
The high-level steps are easy.
• Log in to Migration Portal with your EDB credentials
• Download EDB DDL Extractor for Oracle Database.
• Run the DDL Extractor on the database that you want to assess for compatibility from SQL*PLUS with the command @edb_ddl_extractor.sql.
• Enter the schema name, the path where the extraction file will be created, and enter (yes/no) to extract dependent objects. For multiple schema extraction, you must use a comma (‘,’) delimiter.
• Create a new project in the EDB migration portal. You will need to make some choices regarding the application interface, the source database version, the target DB version and so on.
• By clicking “Create & Assess” the project is created and the DDL file will be assessed.
• When finished you get an overview like this.
This is a simple Oracle schema with 36 objects. 11 of the objects were good as they were, 25 are system repaired (automatically changed to match the target DB code), 0 failed and 0 user repaired. This brings the compatibility at 100%.
• With the report button you can generate a schema assessment report. In this report, more detailed information is given regarding the different object types that are part of the schema(s).
The system repaired objects are repaired by so called repair handlers. There is an overview of all the different handlers used for the different objects.
• When you have reached 100% compatibility you can continue with the “Migrate to” action. This will present a couple of different options like migrate schemas to:
o Existing on-premises EDB Postgres Advanced Server
o New on-premises EDB Postgres Advanced Server Installation
o EDB Postgres Advanced Server on Cloud
• The result for all three is a sql file with all the DDL needed to create a Postgres compatible schema in an EPAS database.
• After that, data can be transferred between source and destination and testing the application and all the processes can begin.
With the addition of EPAS as a supported database engine in Era, customers get all the simplification and automation that Era brings and combine that with all the migration support to assist customers on their journey from Oracle towards PostgreSQL.
Want to know more?
If you want to know more, please go to this page: https://www.nutanix.com/products/era or contact one of the Nutanix partners in your region. Or leave a comment on this blog post and I will come back to you on that.