Este documento presenta una metodología para migrar una base de datos Oracle a PostgreSQL de forma sistemática. Explica los objetivos de la migración, el escenario de migración de Oracle a EnterpriseDB, y los pasos involucrados en un proyecto de migración como la obtención de datos, la elaboración de un assessment, la migración de objetos, datos y código, y las pruebas. También cubre la compatibilidad entre Oracle y PostgreSQL, las estrategias de migración y las herramientas disponibles como Ora2Pg.

1. Casos prácticos en servicios de migración
Migración de Oracle a PostgreSQL
Benito Cuesta
Junio 2014

2. • Objetivos
• Escenario
• Proyectos de migración
• Compatibilidad Oracle
• Estrategias de Migración
• Migración
• Herramientas (Ora2Pg)
• Caso práctico
Contenido
27/06/14 Copyright (c) Open Canarias, 2014 2

3. • Conocer la metodología para abordar proyectos
de migración de bbdd Oracle a PG de forma
sistemática.
• Conocer las herramientas existentes que
facilitan la migración.
• Conocer los problemas de dichas herramientas
y que requieren de intervención manual.
Objetivos
27/06/14 Copyright (c) Open Canarias, 2014 3

4. • Migración del SGBD Oracle a la plataforma
Enterprise DB Advanced Server
– Migración de objetos
– Migración de lógica de negocio (PL/SQL a PLpgSQL)
Escenario
27/06/14 Copyright (c) Open Canarias, 2014 4

5. • ¿Qué es EnterpriseDB?
PostgreSQL / EnterpriseDB
27/06/14 Copyright (c) Open Canarias, 2014 5

6. ¿Porqué Postgres?
27/06/14 Copyright (c) Open Canarias, 2014 6

7. • Lógica de Negocio fuera del SGBD.
• Funcionalidad aportada por otros productos
Oracle (GoldenGate, Reports, …)
• Productos de terceros que necesitan Oracle.
¿Qué NO solucionamos con
PostgreSQL?
27/06/14 Copyright (c) Open Canarias, 2014 7

8. • Pasos de un proyecto de migración
– Obtención de datos del sistema actual.
– Elaboración de assessment, oferta y plan de proyecto.
– Preparación de los diferentes entornos (infraestructura)
– Migración de objetos
– Migración de datos
– Migración de código
– Adaptación de las aplicaciones
– Pruebas
– Corrección de defectos
Proyectos de migración
27/06/14 Copyright (c) Open Canarias, 2014 8

9. – Obtener medidas para definir la estrategia
• Cuantificación de objetos
• Identificación del uso de constraints
• Especificidades (tipos de datos de usuario, campos tipo blob, tablas
particionadas, …)
• Cuantificación de LOC
• Uso de características específicas (Spatial, XML, Text Search, …)
– Entender la arquitectura de la base de datos y su configuración
• Infraestructura actual (versiones, hardware, cpu, almacenamiento)
• Profiling (usuarios/día, transacciones/día)
• Índice de crecimiento del almacenamiento
• Configuración de alta disponibilidad (SLAs)
• Políticas y herramientas de backup
• Plataforma de aplicación
Obtención de datos del sistema actual
27/06/14 Copyright (c) Open Canarias, 2014 9

10. • Introducción
• Datos obtenidos Perfil de BBDD/Aplicación
• Factores de compatibilidad (Object parameters,
características, sintaxis del código, paquetes,
implementación)
• Mapa de Compatibilidad
Elaboración de Assessment (I)
27/06/14 Copyright (c) Open Canarias, 2014 10

11. • Estimación del tiempo según Enterprise DB
– Score 7 – 10 : 2 – 4 semanas
– Score 4 -7 : 4 – 8 semanas
– Score 0 – 4 : características no soportadas, riesgo de
pérdida de funcionalidad, estimación en tiempo
dependiendo de los problemas encontrados.
• Estimación en PoC (sólo PL/SQL): 1,5 d por
10000 LOC
Elaboración de Assessment (II)
27/06/14 Copyright (c) Open Canarias, 2014 11

12. • Ejemplo de cuadro de costes con Oracle
• Ejemplo de cuadro de costes con PostgreSQL
Realización de Assessment (III)
27/06/14 Copyright (c) Open Canarias, 2014 12

13. • Oracle Compatibility Developers’s Guide (¡680
páginas!)
– Parámetros de configuración compatibles
(edb_redwood_date, edb_redwood_strings,
oracle_home,…)
– Tipos de datos compatibles
– Funciones de sistema compatibles
– Vistas de sistema compatibles
– Lenguaje compatible
Compatibilidad Oracle (I)
27/06/14 Copyright (c) Open Canarias, 2014 13

14. • Ejecutar aplicaciones escritas para Oracle sin
necesidad de cambiarlas.
• Soporte para paquetes, procedimientos
almacenados, triggers y mucho más
• Soporte para OCI, PRO*C
• Sin dependencia de un proveedor
Compatibilidad Oracle (II)
27/06/14 Copyright (c) Open Canarias, 2014 14

15. • Soporte a SQL extendido
– Decode, NVL, Substr, NVL2
– Date/time functions: add_month, extract, next_day
• Soporte PL/SQL
– REF Cursors
– Looping
– Cursores implícitos y explícitos
– Declaración de variables
– Sentencias condicionales
– Arrays Associativos (INDEX BY)
• Herramientas
– EDB*Plus – equivalente a SQL*Plus
– EDB*Loader – equivalente a SQL*Loader
• Características
– Procedimientos almacenados
– Paquetes
– Hints
Compatibilidad Oracle (III)
27/06/14 Copyright (c) Open Canarias, 2014 15

16. • Características (cont)
– Database links
– Consultas jerárquicas
– Sinónimos
– Rownum
– Tipos de datos
– Control explícito de transacción
• No soportado en el interior de un procedimiento almacenado.
– Tipos objetos
• Create type … as object
• Create type … as table
• Object methods
– Bulk Binding / Fetch
– Usuarios / Roles
– SQL Dinámico
Compatibilidad Oracle (IV)
27/06/14 Copyright (c) Open Canarias, 2014 16

17. • Paquetes incluidos
Compatibilidad Oracle (V)
27/06/14 Copyright (c) Open Canarias, 2014 17

18. • Diccionario de datos equivalente
– Vistas ALL_, DBA_, USER_
• Diagnóstico – DRITA (Dynamic Runtime
Instrumentation Tools Architecture)
– System and session waits
• No expuestos en PostgreSQL
• Parte de Advanced Server
– Statspack como reporting
Compatibilidad Oracle (y VI)
27/06/14 Copyright (c) Open Canarias, 2014 18

19. Estrategia Beneficios
Desarrollo /
Despliegue
Aplicaciones
nuevas
• Significativo ahorro de costes para
sistemas no-críticos
• Bajo Riesgo
Despliegue de
Postgres Plus como
un Oracle
Replication Server
• Significativo ahorro de costes
• Aprovecha Postgres Plus RS
• Mejora rendimiento de consultas y
transacciones.
Migrar aplicaciones
Oracle no críticas a
Postgres
• Significativo ahorro de costes
• Bajo riesgo
Migrar aplicaciones
de misión crítica a
Postgres
• Ahorro de costes muy significativos
• Mayor flexibilidad de implementación.
Estrategias de migración
27/06/14 Copyright (c) Open Canarias, 2014 19

20. Recursos de EnterpriseDB
• Compatibilidad con Oracle [video]
• Estrategias de contención de coste
• Oracle Compatibility Developers’s Guide
• Oracle Migration Tutorial
• Ejemplo de Assessment.
http://www.enterprisedb.com/solutions/oracle-compatibilit
27/06/14 Copyright (c) Open Canarias, 2014 20

21. • Migración de esquemas
– Crear usuarios y esquemas con el mismo nombre
(search_path)
• Identificadores
– Ojo con los nombres de los esquemas, tablas,
columnas, funciones,…
– Limitar el uso de comillas en los identificadores
(posible problemas en las aplicaciones)
Migración de esquema.
Consideraciones (I)
27/06/14 Copyright (c) Open Canarias, 2014 21

22. • Tablas
– CREATE TABLE compatible, excepto
• Tablas temporales globales Usar LOCAL TEMP
– Clausulas de particionamiento
– Clasulas de almacenamiento INITTRANS,
MAXEXTENTS Eliminarlas
– PCTFREE : Usar fillfactor
• Columnas
– Columnas virtuales Usar vistas
– Tipos de datos
Migración de esquema.
Consideraciones (II)
27/06/14 Copyright (c) Open Canarias, 2014 22

23. • Constraints
– Primary Key, Foraign Key, Unique, CHECK, NOT NULL  OK
• Índices
– Btree / Descending  OK
– Reverse Key / Bitmap / Bitmap Join  No implementado
– Índices Globales  No soportado
• Particiones
– Hash, List, Range  OK (implementado con table inheritance
y rules)
• Tablespaces
– No es lo mismo que en Oracle, pero tienen el mismo
propósito.
Migración de esquema.
Consideraciones (III)
27/06/14 Copyright (c) Open Canarias, 2014 23

24. • Transformación de código a código debido a la
similitud entre lenguajes.
• No hay extracción de arquitectura ni de
conocimiento del sistema.
• Cuando el gap entre lenguajes es más amplio,
se han de usar otro tipo de técnicas.
Migración de código
27/06/14 Copyright (c) Open Canarias, 2014 24

25. • Las migraciones de Oracle a Postgres son
posibles!
• Las migraciones 100% automáticas no son
posibles (o sólo en casos muy simples)
• No hay milagros  Es necesario reescribir
código
• Herramientas:
– EDB Migration Toolkit (MTK)
– Ora2Pg
– ETL (para grandes volúmenes de datos,
campos blob,...)
Posibilidades
27/06/14 Copyright (c) Open Canarias, 2014 25

26. • Reescribe código de PL/SQL a PlpgSQL.
• Reemplaza expresiones.
• Elimina código sobrante.
¿Qué hace Ora2Pg con el código PL/SQL?
27/06/14 Copyright (c) Open Canarias, 2014 26

27. • Problemas de encoding.
– Cambiar el encoding en los ficheros SQL
SET client_encoding TO ‘ISO-8859-1’;
• Nomenclatura de objetos. Objetos con nombres
con espacios, vocales acentuadas y caracteres
especiales.
• Usar comillas dobles en el nombre de los objetos.
• Expresiones regulares de Ora2Pg no son
perfectas.
Dificultades habituales
27/06/14 Copyright (c) Open Canarias, 2014 27

28. CasoPráctico

29. Escenario Demo
27/06/14 Copyright (c) Open Canarias, 2014 29
Oracle 11g
PostgreSQL
9.3
Centos 6.5
JDBC
Export
Schema
Code
Dataora2pg
java8
Create
DB
User
pg
psql
JDBC

30. Gracias