En resumen La mayoría de las migraciones de Oracle a PostgreSQL que fallan no fallan porque PostgreSQL no estuviera listo.
Fracasan porque el proyecto no estaba preparado.
Los cinco patrones que se repiten en todas las organizaciones y sectores se deben a que los equipos hacen las mismas suposiciones: que las herramientas manejan más de lo que lo hacen, que el volumen de PL/SQL es menor de lo que es y que un plan de reversión se puede improvisar a las 2 de la mañana.
He visto proyectos de migración fallar en todas las direcciones.
Desbordamientos presupuestarios en los que la estimación original se desvió por un factor de ocho.
Noches de lanzamiento que terminaron con una operación de recuperación de tres días.
Sistemas de producción donde seis meses de marcas de tiempo se convirtieron silenciosamente en medianoche.
Ninguno de estos fue causado por PostgreSQL.
Ninguno de ellos fue causado por las herramientas de migración.
Cada uno fue causado por una suposición de planificación que resultó ser errónea.
Estos son cinco de los patrones de fracaso más comunes – anonimizados, pero representativos de lo que sucede cuando la preparación no coincide con la complejidad del trabajo.
Índice
¿Por qué fallan las migraciones de Oracle a PostgreSQL?
La mayoría de los fracasos de la migración se deben a tres causas fundamentales: subestimación del volumen de PL/SQL, dependencias específicas de Oracle en el código de la aplicación que nadie auditó antes de iniciar el proyecto y planes de transición que daban por sentado que no se produciría el peor de los casos.
La tecnología funciona.
La planificación es donde falla.
Fallo 1: El equipo que se saltó la evaluación
Saltarse la evaluación previa a la migración no ahorra tiempo, sino que lo traslada a una parte más costosa del proyecto.
Un equipo que descubre a mitad de la migración que tiene 200 procedimientos almacenados en lugar de 20 no ha evitado el esfuerzo de evaluación; lo ha pagado a tasas de cambio sprint mientras un plazo ya se está moviendo.
Una empresa de telecomunicaciones ejecutó ora2pg directamente sobre su esquema sin generar primero el informe de evaluación.
La herramienta de migración proporciona una calificación de complejidad y un recuento de objetos; se la saltaron porque confiaban en que el esquema era simple.
Tres semanas después, el equipo encontró más de 200 procedimientos almacenados en paquetes de Oracle.
El informe de evaluación lo habría demostrado en una hora.
El plazo original del proyecto era de cuatro semanas.
La línea de tiempo final fue catorce.
El informe de evaluación (ora2pg -t SHOW_REPORTtoma menos de un día para ejecutarse y revisarse.
Es el documento que establece el presupuesto, el cronograma y el tamaño del equipo.
Ejecutar una migración sin él es equivalente a cotizar un proyecto de construcción sin un estudio previo.
Fallo 2: El PL/SQL que nadie contó
El índice de complejidad ora2pg es un punto de partida útil, pero no es una estimación de la carga de trabajo.
Un esquema clasificado como de “baja complejidad” puede contener miles de líneas de PL/SQL si la estructura del paquete es profunda, ya que ora2pg cuenta los paquetes como objetos individuales independientemente del número de procedimientos y funciones que contengan.
Una firma de servicios financieros utilizó la calificación de complejidad de ora2pg para estimar el esfuerzo de migración y la presentó a la junta directiva como base para el presupuesto.
La calificación decía baja complejidad.
Nadie amplió el informe a detalle a nivel de objeto.
Nadie contó los procedimientos individuales dentro de cada paquete.
El esquema tenía doce paquetes.
Los doce paquetes contenían 140 procedimientos almacenados y funciones individuales.
El esfuerzo real de migración a PL/pgSQL resultó ser ocho veces mayor que la estimación original.
La solución es sencilla: profundice siempre en el informe ora2pg a nivel de objeto.
Cuente los procedimientos individuales dentro de los paquetes, no sólo los paquetes en sí.
Luego agregue 30% para probar cada unidad portada.
Fallo 3: Las columnas de FECHA que perdieron tiempo silenciosamente
Este es el patrón de pérdida de datos silenciosa más común en las migraciones de Oracle a PostgreSQL.
Oracle DATE almacena fecha y hora. PostgreSQL DATE almacena solo fecha.
Cuando Oracle DATE es mapeado a PostgreSQL DATE - que es el valor por defecto en algunas configuraciones - el componente de tiempo de cada valor es silenciosamente descartado. No hay error. No hay advertencia. Los datos se cargan limpiamente y la hora desaparece.
Una empresa minorista migró su sistema de reservas.
La aplicación se ha probado perfectamente.
Pruebas unitarias superadas.
El equipo de UAT dio el visto bueno.
Los datos de la prueba se habían generado sin componentes temporales: cada fecha era medianoche por coincidencia.
El sistema de producción tenía dos años de registros de reservas con marcas de tiempo reales.
Salieron al aire un sábado.
El lunes, todas las reservas históricas mostraban la medianoche como hora.
Los datos de las citas de los últimos dos años tuvieron que ser restaurados de la copia de seguridad de Oracle y revalidados.
La solución es una línea en la configuración de ora2pg: MODIFICAR_TIPO fecha TIMESTAMP.
Aplícalo sin excepción a cada columna DATE en el esquema.
No cuesta nada y evita por completo este fallo.
¿A punto de comenzar una evaluación de migración y no estás seguro de lo que te espera?
Ofrezco una evaluación con una tarifa fija que revisa la complejidad del esquema, el volumen PL/SQL y las dependencias SQL de la aplicación, y proporciona un registro de riesgos por escrito antes de que comience cualquier trabajo de migración.
Ver qué cubre la evaluación
Fallo 4: El código de la aplicación que nadie leyó
La migración de la base de datos es la parte visible del proyecto.
Los cambios en la aplicación son lo que la descarrila.
Dialecto SQL de Oracle - ROWNUM, DE DUAL, NVL(), (+) uniones externas, CONECTAR POR, FECHA_SISTEMA — no se ejecuta en PostgreSQL.
Si no se han buscado estos patrones en el código base de la aplicación antes de iniciar la migración, se desconoce el alcance del trabajo de cambio de la aplicación.
El alcance desconocido es la forma más rápida de incumplir un plazo.
Una empresa de logística migró una base de datos de operaciones básicas.
La migración en sí se completó sin problemas.
Conteo de filas coincidente.
Los valores de secuencia se restablecieron correctamente.
La ventana de transición se cerró a tiempo.
La aplicación se negó a comenzar.
El código base contenía 140 apariciones de Oracle dialect SQL en once servicios diferentes.
Nada de esto se.
El equipo había asumido que la capa de aplicación utilizaba SQL ANSI estándar.
No fue así.
La reparación requirió tres semanas de trabajo de desarrollo de aplicaciones que no se habían presupuestado.
La solución: antes de escribir una sola línea de script de migración, busca en la base de código de la aplicación patrones SQL específicos de Oracle.
La búsqueda toma horas.
Encontrar los resultados en producción tarda semanas.
Fallo 5: El cambio sin plan de reversión
“Retrocederemos si es necesario” no es un plan de retroceso.
Un plan de reversión es un documento escrito que especifica exactamente lo que requiere la reversión a Oracle, cuánto tiempo lleva, quién ejecuta cada paso y cuál será el estado de los datos en el punto de reversión.
Si ese documento no existe antes de que se abra la ventana de corte, no hay retroceso: sólo hay una recuperación improvisada bajo presión.
Una organización sanitaria se puso en marcha un domingo por la noche.
Los problemas de rendimiento aparecieron a las 2 a. m.
El equipo tomó la decisión de dar marcha atrás.
El entorno de Oracle había sido desmantelado parcialmente tres días antes para recuperar costos de infraestructura.
El DBA que había realizado el desmantelamiento no formaba parte del equipo de transición.
Nadie había documentado lo que se había retirado.
La recuperación duró tres días.
La organización operó con procedimientos manuales de respaldo en todo momento.
La lección no es que el cambio debió haberse retrasado.
La lección es que el plan de reversión debe redactarse, probarse en staging, y el entorno de Oracle debe permanecer completamente intacto; no parcialmente, no en su mayoría; hasta que el nuevo sistema haya sido aprobado en producción.
Desinstale Oracle después de la aprobación, no antes de la entrada en funcionamiento.
Preguntas frecuentes
¿Cuál es la razón más común por la que fallan las migraciones de Oracle a PostgreSQL?
El volumen subestimado de PL/SQL es la causa más común de fallas en el presupuesto y el cronograma.
Los equipos evalúan el número de objetos de base de datos pero no cuentan los procedimientos individuales dentro de los paquetes.
La segunda causa más común es el SQL dialectal de Oracle no descubierto en el código de la aplicación que sólo sale a la luz en el momento de la transición.
¿Puede recuperarse de una migración fallida de Oracle a PostgreSQL?
Sí, si el entorno Oracle sigue intacto.
El requisito previo fundamental es mantener el sistema Oracle de origen plenamente operativo hasta que la migración se haya aprobado en producción.
Si Oracle se ha desmantelado parcialmente antes del cierre, la recuperación se convierte en un ejercicio de restauración en lugar de una reversión, que es significativamente más costosa y lenta.
¿Cómo se evita exceder el presupuesto en una migración?
Ejecute el informe completo de evaluación ora2pg antes de fijar un presupuesto.
Amplíelo al nivel de detalle de los objetos y cuente los procedimientos individuales dentro de los paquetes.
Busque en la base de código de la aplicación el dialecto SQL de Oracle antes de definir el alcance del trabajo de cambio de la aplicación.
Presupueste al menos el 30 %% del esfuerzo del proyecto para pruebas.
Toda migración que se ha excedido significativamente del presupuesto ha omitido al menos uno de estos pasos.
¿Cuál es la cosa más importante que hacer antes de comenzar una migración?
Ejecute la evaluación previa a la migración.
El informe de evaluación de ora2pg (ora2pg -t SHOW_REPORT) le ofrece el recuento de objetos, una clasificación de complejidad y una estimación del esfuerzo de migración.
Se tarda menos de un día y es la única base fiable para el presupuesto y el calendario de un proyecto.
Cada otra decisión de planificación emana de ella.
En resumen
Estos cinco fallos no son inusuales.
Son el resultado por defecto cuando la preparación no se corresponde con la complejidad del trabajo.
La tecnología de las bases de datos no es el riesgo.
PostgreSQL es maduro, listo para producción y se usa a gran escala en la banca, las telecomunicaciones y la sanidad en la UE.
El riesgo está en la planificación: evaluaciones omitidas, clasificaciones de complejidad mal interpretadas, tipos de datos no mapeados, código de aplicación no auditado y planes de reversión que sólo existen como intenciones.
Cada uno de estos fracasos fue evitable con una semana de preparación adecuada al inicio del proyecto.
Si estás planeando una migración y quieres una opinión independiente sobre dónde reside el riesgo antes de comprometerte con un cronograma o presupuesto, ponerse en contacto