En resumen El trabajo manual en una migración de Oracle a PostgreSQL depende enteramente de cómo se construyó el esquema, no de su tamaño.
Esta guía mapea tres patrones comunes de esquemas de Oracle al ejemplo de migración específico que cubre cada uno: OLTP heredado, OLTP moderno y data warehouse.
Si no está seguro de cuál se aplica a su base de datos, la sección de diagnóstico a continuación le da cuatro preguntas para averiguarlo.
Tres administradores de bases de datos pueden decir “Estoy migrando Oracle a PostgreSQL” y enfrentar problemas completamente diferentes.
El primero tiene un ERP de 15 años funcionando en Oracle 10g con pares de secuencias-disparadores en cada tabla.
El segundo tiene una aplicación de pedidos de clientes construida sobre Oracle 19c con columnas IDENTITY y JSON almacenado en BLOBs.
La tercera es migrar un almacén de datos con tablas de hechos particionadas por rangos, vistas materializadas e índices de mapa de bits.
ora2pg maneja los tres.
El trabajo manual es completamente diferente en cada caso.
Índice
¿Por qué el tipo de esquema determina el esfuerzo de migración?
Oracle soporta varios patrones de aplicación — OLTP heredado, OLTP moderno y análisis/almacén de datos — y cada uno usa un conjunto distinto de características específicas de Oracle.
PostgreSQL admite los mismos patrones, pero de manera diferente.
El trabajo de traducción se concentra donde las características de Oracle no tienen un equivalente directo en PostgreSQL: secuencias conectadas a disparadores, gestión de secuencias de columnas IDENTITY, índices de mapa de bits, programación de actualización de vistas materializadas.
Conocer tu patrón de esquema antes de empezar te dice exactamente dónde está el trabajo manual, antes de abrir ora2pg.
Legado OLTP: El esquema RRHH
A qué se parece esto Tablas con claves primarias basadas en secuencias, disparadores `BEFORE INSERT` que asignan el siguiente valor de secuencia al insertar, procedimientos almacenados y restricciones de clave foránea.
Ejemplos del mundo real: sistemas ERP, plataformas de recursos humanos, bases de datos CRM, cualquier aplicación de Oracle creada antes de Oracle 12c.
El problema central es el patrón de auto-incremento de Oracle anterior a la versión 12c:
CREATE OR REPLACE TRIGGER employees_bir
BEFORE INSERT ON employees
FOR EACH ROW
BEGIN
SELECT employees_seq.NEXTVAL INTO :NEW.employee_id FROM DUAL;
END;
ora2pg exporta este disparador como PL/pgSQL.
Se compila sin errores en PostgreSQL.
El patrón es incorrecto — PostgreSQL maneja el autoincremento a través de valores predeterminados de columna que apuntan a una secuencia, no a triggers.
El enfoque de disparador funciona, pero añade una sobrecarga innecesaria en cada inserción y enmascara la dependencia de la secuencia del lector del esquema.
La guía de esquemas de RR. HH. cubre esta conversión en su totalidad, junto con otros dos problemas que aparecen en casi todas las migraciones de OLTP heredadas: el %TIPO fallo de parámetros en funciones PL/pgSQL exportadas, y el fallo de volver a aplicar FK de ora2pg.
Lee el ejemplo completo de migración del esquema HR →
OLTP Moderno: El Esquema CO
A qué se parece esto Claves primarias usando GENERADO POR DEFECTO EN NULO COMO IDENTIDAD, columnas BLOB que almacenan JSON y vistas que utilizan funciones SQL específicas de Oracle.
Ejemplos del mundo real: bases de datos de transacciones orientadas al cliente, sistemas de gestión de pedidos, cualquier aplicación Oracle creada o modernizada en Oracle 12c o posterior.
CO introduce tres problemas que no aparecen en el esquema de Recursos Humanos.
La primera es el reinicio de la secuencia de la columna IDENTITY.
Después de que ora2pg carga los datos, las secuencias todavía están en su valor inicial — no en el valor máximo cargado.
La primera inserción de aplicación falla después de la migración con una violación de clave duplicada.
La corrección es de una línea ALTER SEQUENCE por tabla, pero debe ejecutarse después de la carga de datos.
El segundo es JSON almacenado en BLOB.
ora2pg exporta la columna como bytea.
Los datos están ahí pero son inutilizables para consultas JSON.
El tipo de destino correcto es jsonb, lo que requiere un paso de migración de datos junto con la conversión del esquema.
El tercero es SQL específico de Oracle en vistas.LISTAGG, Pívot, CONECTAR PORy NVL no tienen equivalentes directos en PostgreSQL.
Las vistas que utilizan estas funciones deben reescribirse en SQL estándar antes de que funcionen.
Lee el ejemplo completo de migración del esquema de CO →
Si su esquema combina patrones tanto de OLTP heredado como moderno, por ejemplo, una aplicación de 15 años ampliada en Oracle 19c, lea ambas guías, la de RR. HH. y la de CO.
Si prefiere que un experto mapee el trabajo manual antes de comprometer a su equipo con el proyecto, una evaluación a precio fijo cubre exactamente eso
Data Warehouse: El Esquema SH
A qué se parece esto Tablas de hechos particionadas por rangos, vistas materializadas utilizadas para informes preagregados e índices de mapas de bits en columnas de dimensiones de baja cardinalidad.
Ejemplos del mundo real: almacenes de datos de Oracle, plataformas de informes de BI, bases de datos analíticas, cualquier esquema diseñado para informes en lugar de procesamiento transaccional.
SH introduce tres problemas no vistos en RR. HH. o CO.
La primera es exportar partición.
ora2pg divide una tabla particionada en dos archivos de exportación separados: uno para la definición de la tabla padre y otro para las tablas de partición hijas.
Cargarlos en el orden incorrecto rompe la migración.
El orden correcto es primero tabla padre, luego datos, luego particiones hijas, y ese orden es diferente de lo que sugiere la plantilla del proyecto ora2pg por defecto.
La segunda es la conversión de índices de mapa de bits.
Los índices de mapa de bits de Oracle no tienen un equivalente en PostgreSQL.
ora2pg los convierte en índices B-tree estándar, lo que es el resultado correcto, pero produce un índice GIN en columnas de clave externa enteras en algunas configuraciones, lo cual es incorrecto.
Cada índice convertido debe ser verificado antes de la carga de datos.
La tercera es la programación de actualización de vistas materializadas.
PostgreSQL REFRESCAR VISTA MATERIALIZADA es equivalente a Oracle's DBMS_MVIEW.REFRESH.
El mecanismo de programación no lo es.
Oracle utiliza DBMS_JOB o DBMS_SCHEDULER.
PostgreSQL no tiene ninguno.
Los trabajos de actualización deben recrearse utilizando pg_cron o un programador externo.
Lee el ejemplo completo de migración de esquema de SH →
¿A qué guía se aplica su esquema?
Responde estas cuatro preguntas:
1. ¿Cómo se implementan las claves primarias?
Secuencia + disparador BEFORE INSERT → Guía de RR. HH. (OLTP heredado).GENERADO ... COMO IDENTIDAD → Guía de CO (OLTP moderno).
Claves naturales o ningún patrón de identidad → leer ambos.
2. ¿Tiene su esquema tablas particionadas?
Sí, con PARTICIÓN POR RANGO o PARTITION BY LIST → Guía SH almacén de datos.
No → omite la guía SH a menos que tengas vistas materializadas.
3. ¿Tienes vistas materializadas?
Sí Guía SH cubre el problema de programación de la actualización de forma completa.
No → esta sección no aplica.
4. ¿Alguna vista utiliza funciones específicas de Oracle? NVL, DECODIFICAR, LISTAGG, CONECTAR POR, ROWNUM, o Pívot?
Sí Guía de CO cubiertas vista manual reescribiendo en detalle.
No → sus vistas probablemente se exportarán limpiamente con ora2pg.
La mayoría de los esquemas de producción reales son una combinación.
Un ERP de 15 años extendido en Oracle 19c podría tener pares de disparadores de secuencia en tablas heredadas y columnas IDENTITY en otras más nuevas; lea ambas guías (RRHH y CO).
Si el mismo esquema también impulsa las consultas de informes sobre tablas particionadas, agregue la guía SH.
Preguntas frecuentes
¿Con qué guía debería empezar si nunca antes he realizado una migración de Oracle a PostgreSQL?
Comienza con la guía del esquema de RR. HH.
Cubre el esquema más pequeño con los problemas más universales.
Los pares de secuencias activadas, las incompatibilidades de tipo de procedimiento almacenado y el error de reaplicación de FK aparecen en casi todas las migraciones de Oracle, independientemente del tamaño o la complejidad del esquema.
La guía de RRHH también explica el flujo de trabajo completo de ora2pg antes de que las guías CO y SH introduzcan sus capas adicionales.
¿Necesito leer las tres guías?
No necesariamente.
Lee primero el que coincide con tu patrón de esquema principal.
Si su esquema combina elementos de más de una categoría —columnas IDENTITY y tablas particionadas, por ejemplo— lea las secciones correspondientes de ambas guías.
Cada guía está estructurada de forma que el flujo de trabajo principal se encuentre en la primera mitad y los problemas específicos del esquema en la segunda.
¿Son estas guías específicas de una versión particular de Oracle?
Los pasos de migración funcionan con Oracle 12c y versiones posteriores.
Las columnas IDENTITY, cubiertas en la guía de CO, requieren Oracle 12c como mínimo.
El patrón sequence-trigger, cubierto en la guía de RRHH, es el idioma pre-12c de Oracle, pero también aparece en esquemas de 12c y 19c que no fueron modernizados.
Los tres guías utilizan ora2pg 25.0 con Oracle 19c como origen y PostgreSQL 18 como destino.
¿Y si mi esquema no tiene ninguno de estos patrones?
Un esquema sin pares de disparadores de secuencia, sin columnas de IDENTIDAD, sin particionamiento y sin vistas materializadas es el caso de migración más simple.
La guía de RR. HH. todavía aplica; cubre el flujo de trabajo base de ora2pg, el mapeo de tipos de datos, el orden de carga de archivos y la validación de PRUEBAS que requiere cada migración.
En resumen
Los problemas de migración de Oracle a PostgreSQL son predecibles, una vez que sabes desde qué patrón de esquema estás partiendo.
Los esquemas OLTP heredados creados antes de Oracle 12c necesitan limpieza de triggers de secuencia y correcciones de procedimientos almacenados.
Los esquemas OLTP modernos en Oracle 12c y posteriores necesitan reinicios de secuencias IDENTITY y reescrituras de vistas.
Los esquemas de data warehouse de Oracle necesitan un manejo cuidadoso de las particiones, los índices bitmap y la programación de vistas materializadas.
Ejecute el informe de migración primero para confirmar la estimación del esfuerzo antes de comprometerse con un cronograma.
ora2pg -t SHOW_REPORT --estimate_cost --dump_as_html > reports/migration_report.html
Si su esquema combina patrones de más de una categoría, o si el informe de migración señala complejidad que usted no sabe cómo resolver, ponerse en contacto.
Ofrezco una evaluación de migración a precio fijo que mapea cada elemento de conversión manual y le proporciona una estimación clara del esfuerzo antes de que comience el proyecto.