Migración de Oracle a Postgres: Problemas y Soluciones del Esquema CO

Sea Ice Patterns

Oracle's CO (Customer Orders) schema is the modern replacement for the older OE schema.

It ships with Oracle 19c, it is actively maintained, and it is built the way most real Oracle applications are built today: IDENTITY columns instead of sequence-trigger pairs, JSON stored in BLOB columns, and views that use Oracle-specific SQL functions.

Ejecuté la migración completa usando ora2pg 25.0 con Oracle 19c como origen y PostgreSQL 18 como destino.

This post covers the five problems that required manual intervention — and why each one will appear in almost every production schema you migrate.

This is the third post in the series.

En HR schema post covered sequence-trigger patterns, %TIPO parameters, and the FK re-apply bug.

En SH schema post covered partitioned tables, bitmap indexes, and materialized views.

CO introduces three new problem categories not seen in either of those.

Continuar leyendo “Oracle to Postgres Migration: CO Schema Issues and Fixes”

Migración de Oracle a Postgres Paso a Paso: El Esquema SH (Particiones, Vistas Materializadas, Índices Bitmap)

multicolored paint splatter

The Oracle SH (Sales History) schema is the standard Oracle example of a star schema data warehouse.

It has a central SALES fact table, six dimension tables, two materialized views, range-partitioned fact tables, and bitmap indexes on low-cardinality columns.

All of those features exist in every real Oracle data warehouse.

And all of them require decisions that a straightforward ora2pg run won't make for you.

This post walks through the exact steps I used to migrate SH from Oracle 19c to PostgreSQL 18 using ora2pg.

The Oracle SH sample schema is available on GitHub.

Continuar leyendo “Oracle to Postgres Migration Step by Step: The SH Schema (Partitions, Materialized Views, Bitmap Indexes)”