Migrate from Oracle to Postgre by automating the process!

 

 

Migrate from Oracle to Postgre by automating the  process, for a fixed price  !

Many companies are leaving Oracle for PostgreSQL

 

Oracle Database has a reputation for being expensive in terms of licensing and support.  This pricing policy can make Oracle less attractive to some businesses. Bloomberg notes a decline in new Oracle license sales, a decline that has continued for seven consecutive quarters. 

 

On the other hand, there's the PostgreSQL database,  which is free, modifiable, and distributable, and has a reputation for being reliable and stable, with good transaction management. All these elements make it suitable for mission-critical applications where data consistency is essential. PostgreSQL also supports a wide variety of data types, including geospatial types, JSON, and more, making it well-suited for handling complex and diverse data.  

 

Postgre is now the 4th most used database in the world, with significant growth rates .

 

But it remains a difficult movement to initiate.

 

According to Carl Olofson, vice president of research at IDC, "There are a number of Oracle users who would like to try PostgreSQL for at least part of their workload, but are discouraged by the risk and cost of conversion."

It must be said that PL/SQL, Oracle's procedural language, began to be used in 1991. It is the most widely used procedural language in the world!

It offers the possibility of writing complex data manipulation functions without resorting to a third-party language. As it is a query language, it allows for the creation of fairly complex scripts: functions, procedures, triggers, apexes, etc.

PL/SQL cannot be migrated directly to PostgreSQL. At least, not easily. These  migration projects  are often lengthy and expensive, and sometimes unsuccessful. 

 

But not necessarily  😊 .

 

We have developed a proven, 2-step methodology to mechanically make this migration a success, on a fixed-price basis when the Oracle DB is essentially used as a data warehouse with PL chains.

 

Step #1: Simplify the source system

The analysis of logs by  {openAudit} ,  our software, allows us to detect the information that passes through dataviz tools and all queries (JDBC, ODBC...).

The data lineage of  {openAudit} , by tracing all the flows that generate actual usage, makes it possible to define the useful versus the unnecessary parts of the Information System.  This makes it possible to perform mass decommissioning prior to the migration.

 {openAudit}' s detailed introspection of data flows allows it  to factorize the code.

Step #2: Technically migrate from Oracle to PostgreSQL

{openAudit}  will "parse" the PL/SQL, breaking down all the code's complexity using a grammar that allows for exhaustive and ultra-granular analysis.  All the subtleties of the PL/SQL will be taken into account. 

{openAudit}  deduces the  overall kinematics  and intelligence, which will be reconstructed in an agnostic algorithmic tree (it could be simple Scratch).

Based on this,  {openAudit}   will produce standard SQL.

Then the intelligence will be minimally rebuilt in the PgSQL by  {openAudit} .

Some complex processes, not reproducible in simple SQL, will be controlled by a NodeJS executable.  Typically the cursors "For Loop", variables, conditional code "If Else", "Switches", procedure calls, etc. 

 

Optionally, new orchestration mechanisms can be put in place to deconstruct cursors of cursors (loops of loops), or to optimize transformation chains*.

Thus, in general, it is possible to decommission Oracle assets and reproduce all their intelligence in PostreSQL in an extremely efficient way. 

 

We make a commitment  : migrations  are  carried out at a fixed price.

*There are some limitations:  Unit procedures called by external code or triggers  may be subject to ad hoc responses.

Commentaires

Posts les plus consultés de ce blog

Power BI libère les utilisateurs… Mais comment garder la maîtrise de sa plateforme dans le temps ?

De la source à la cellule du dashboard : Cartographier le SI pour le reconstruire intelligemment

Migrer de SAP BO vers GCP Looker - Garder ses données en source ? Possible ?