SEARCH
TOOLBOX
LANGUAGES
Procedimiento de Análisis y Planificación de Migración de Oracle 10g R2 a PostgreSQL 9.1.3

Procedimiento de Análisis y Planificación de Migración de Oracle 10g R2 a PostgreSQL 9.1.3

De WikiCenaticEsp

Volver a Manual de Aplicación de Metodología para Migración de Oracle 10g R2 a PostgreSQL 9.1.3


Contenido


Actividades

Análisis previo

A continuación se describe una propuesta de indicadores y tramos para ayudar a determinar si la aplicación que se desea migrar tiene una base de datos pequeña o mediana, susceptible por tanto de ser migrada con esta metodología con un esfuerzo razonable. Para ofrecer esa estimación inicial se proponen unas métricas relativas a los objetos que se van a migrar (criterios de tamaño), así como un cuestionario para detectar posibles complejidades (criterios de complejidad).

Todas las ponderaciones realizadas en este documento son estimaciones y deberían retroalimentarse y validarse con las sucesivas migraciones que se fueran realizando, refinando de esta manera los valores iniciales propuestos.

Criterios de tamaño

A continuación se enumeran algunos criterios basados en medidas para considerar fuera del umbral de viabilidad de migración a una BBDD. En cada criterio se ha definido un umbral, por encima del cual esta metodología no sería aplicable con garantías para realizar la migración de la base de datos.


Número de registros(filas)

No es lo mismo una base de datos de 1000 registros que una de 10^12 registros. Esta última tendrá más exigencias en rendimiento, especialmente en cuanto a mantener tiempos bajos en tareas como búsqueda, tiempos de inserción, tiempos de propagar disparadores, copias de seguridad, etc. Podría establecerse como umbral a partir del cual empiezan los problemas a causa del volumen en el entorno de los 10^9 para base de datos grandes.

En caso de existir estadísticas actualizadas de Oracle, puede obtenerse este valor con la consulta:

select sum (num_rows) from dba_tables where OWNER = 'SCHEMA_NAME';
SUM(NUM_ROWS)
-------------
    85842591

En el caso de necesitar actualizar el cálculo de las estadísticas en Oracle, la sentencia a ejecutar sería:

execute DBMS_STATS.GATHER_SCHEMA_STATS(ownname=>'SCHEMA_NAME', estimate_percent=>100 , cascade=>TRUE);
Umbral: Número total igual a 10^9

Volver arriba


Número de Atributos (NA)

Un indicador de la complejidad puede obtenerse del número de atributos (columnas) de las tablas. El cálculo del NA para un esquema puede hacerse con la siguiente consulta para un SCHEMA_NAME dado:

SELECT COUNT(ATC.COLUMN_NAME) FROM ALL_TAB_COLUMNS ATC, ALL_TABLES AT
WHERE ATC.TABLE_NAME = AT.TABLE_NAME AND AT.OWNER = 'SCHEMA_NAME' and ATC.OWNER = 'SCHEMA_NAME';

La siguiente consulta, nos devuelve información más pormenorizada para poder conocer como se distribuyen dichas columnas(atributos) y así ayudarnos a evaluar la complejidad de la BBDD.La consulta devuelve para un SCHEMA_NAME dado , el máximo número de columnas en una tabla, el mínimo , la media y la desviación típica para evaluar la complejidad de la BBDD

SELECT  AVG(COUNT(ATC.COLUMN_NAME)),STDDEV(COUNT(ATC.COLUMN_NAME)),
MAX(COUNT(ATC.COLUMN_NAME)),MIN(COUNT(ATC.COLUMN_NAME))
FROM ALL_TAB_COLUMNS ATC, ALL_TABLES AT WHERE ATC.TABLE_NAME = AT.TABLE_NAME
AND AT.OWNER = 'SCHEMA_NAME' and ATC.OWNER = 'SCHEMA_NAME'  GROUP BY ATC.TABLE_NAME;


Ejemplo:

AVG          STDDEV        MAX    MIN
----------- ------------- ------- -----
16.273743    30.3777931    547     2
Umbral: Número total de atributos igual a 10000

Volver arriba


Número de claves foráneas. Referential Degree. (RD)

El cálculo de las claves foráneas presentes en una base de datos puede obtenerse con la siguiente sentencia:

SELECT AC.CONSTRAINT_TYPE,count(*) FROM ALL_CONSTRAINTS AC, ALL_TABLES ALT
WHERE AC.TABLE_NAME = ALT.TABLE_NAME  AND ALT.OWNER = 'SCHEMA_NAME'  AND AC.OWNER = 'SCHEMA_NAME' 
GROUP BY  AC.CONSTRAINT_TYPE;

Ejemplo:

C   COUNT(*)
- ----------
R       1353
U         98
P        628
C      10410

Leyenda: C (check constraint on a table), P (primary key), U (unique key), R (referential integrity), V (with check option, on a view), O (with read only, on a view).

Adicionalmente puede calcularse otros parámetros que aportan más información sobre la complejidad como son :

  • La profundidad del Árbol de referencias (DRT): La longitud de la trayectoria referencial más larga despreciando los bucles.
  • La Cohesión del esquema (COS) : El sumatorio del número de tablas de cada subgrafo al cuadrado (Entendiéndose por subgrafo el subconjunto de tablas no referenciadas entre sí en el esquema).
Umbral: Número total de RD ( conteo de constraints de tipo ‘R’ ) igual a 500.

Volver arriba


Número de Objetos de conversión no trivial.

Hay una serie de objetos en una base de datos Oracle cuya conversión a Postgre es siempre compleja. Tener identificados si estos objetos son demasiados (y su migración supone a priori un esfuerzo excesivo) es de gran ayuda en este punto.

Para obtener estos objetos puede usarse la consulta:

Select owner,object_type,count(*)from dba_objects where owner  = 'SCHEMA_NAME' 
Group by owner,object_type Order by 1,2,3;

Ejemplo:

OBJECT_TYPE          COUNT(*)
------------------ ----------
CLUSTER                    10
CONSUMER GROUP              4
DATABASE LINK              12
DIRECTORY                   1
EVALUATION CONTEXT          1
FUNCTION                  129
INDEX                     992
INDEX PARTITION            25
LIBRARY                    62
LOB                        52
MATERIALIZED VIEW           2
OPERATOR                    2
PACKAGE                   321
PACKAGE BODY              313
PROCEDURE                 183
QUEUE                       8
RESOURCE PLAN               3
SEQUENCE                  168
SYNONYM                  1782
TABLE                     830
TABLE PARTITION            27
TRIGGER                    90
TYPE                      480
TYPE BODY                  21
VIEW                     2414

Los tipos de objetos con una probable traducción o conversión sencilla son: TABLE, INDEX, SEQUENCE, VIEW, SYNONYM, TRIGGER.

Umbral: más de 50 elementos de alguno de los tipos de objetos que no tienen traducción sencilla.

Volver arriba


Tamaño de la aplicación

Para evaluar la complejidad y el tamaño de la migración de la base de datos se puede partir de la complejidad de la aplicación que usa dicha base de datos. Se asume así que una base de datos pequeña (y por consiguiente poco compleja) es la que da servicio a un aplicación simple, una base de datos de complejidad media a una aplicación mediana, etc. Una aplicación sencilla tendría pocos casos de uso (o puntos función, según la métrica que se use).

Establecemos como referencia el hecho de que un caso de uso genera de promedio 4 elementos de la base de datos (se entiende por elementos: tablas, índices, disparadores, relaciones y, en general, cualquier cosa que se derive directamente de la implementación del caso de uso). Un aplicación pequeña y poco compleja implementará aproximadamente unos 10 casos de uso, con lo que tendrá una base de datos de unos 40 elementos.

Umbral: A partir de 100 casos de uso (unos 400 elementos en la base de datos) se considera una aplicación de grande y de complejidad alta.

Volver arriba

Otros aspectos a evaluar

Hay una serie de factores comunes a cualquier base de datos que influyen en la complejidad de la migración y que hay que ponderar:

  • Cantidad y tipo de SQL propietario que se use.
  • Calidad de datos.
  • Existencia de documentación del sistema.
  • Requisitos de diseño tales como la alta disponibilidad y replicación.
  • Software de terceros dependencias.
  • Cambio en el sistema operativo y/o cambio de la plataforma de hardware como consecuencia de la migración.
  • Cualificación y experiencia del personal involucrado en la migración.
  • La disponibilidad de un equipo dedicado para el desarrollo de la migración.
  • Imposibilidad de detener los cambios y los nuevos desarrollos sobre el código a migrar.
  • Tiempo máximo que se permite para la realización de la migración (ventana de corte).

Cuestionario cualitativo para evaluar la complejidad de la migración de una aplicación basada en Oracle

Básicamente el cuestionario pretende detectar posibles complicaciones en la migración. Según las contestaciones podemos inferir la complejidad de la BD y por ende posibles problemas de traducción. A continuación os mostramos las preguntas con posibles respuestas, indicando si deberíamos considerar las respuestas como preocupantes o no.

SIN ALARMA: en principio no plantea problemas frente a una migración ante la pregunta realizada
CON ALARMA: se ha de realizar un estudio en detalle antes de proceder al proceso de migración ya que se podrían detectar incompatibilidades.

  • ¿Cuál es el coste de la parada del servicio? ¿Cuánto cuesta una hora sin servicio la aplicación?
SIN ALARMA: Se trata de una aplicación usada en horario laboral de Lunes a Viernes..
CON ALARMA: Se trata de una aplicación usada 24x7 , las 24 horas del día los 7 días de la semana
  • ¿Cuántos objetos tiene la aplicación? ¿De que tipo? ¿Cual es su crecimiento esperado?
SIN ALARMA: Bajo número de objetos volumen y bajo crecimiento
CON ALARMA: Alto número de objetos volumen y/o alto crecimiento
  • ¿Se tratan datos sujetos a la LOPD? ¿De que nivel: Básico, Medio o Alto?
SIN ALARMA: No , Básico o Medio
CON ALARMA: Alto
  • ¿Cuáles son las características técnicas de la aplicación? ¿Es Cliente-Servidor? ¿Usa Citrix? ¿Qué ancho de banda necesita?
SIN ALARMA: Aplicación web que no requiere de plugins
CON ALARMA: Emuladores de Terminal antiguos , sistemas propietarios TSO,,...etc
  • ¿Justificaría la naturaleza de la aplicación crear más de un tablespace? (Por ejemplo : Un tablespace para DATOS y otro para INDICES, o un tablespace para los Objetos LOB...)
SIN ALARMA: Dos o tres tablespaces
CON ALARMA: Varios tablespaces con configuraciones especificas (READ ONLY, NOLOGGING,....)
  • ¿Se necesitan algún valor concreto en la parametrización de Oracle? (Por ejemplo: OPEN_CURSORS, JAVA_POOL_SIZE,...)
SIN ALARMA: Ninguno, o sólo parámetro opcionales
CON ALARMA: Uno o varios parámetros necesarios para el funcionamiento de la aplicación)
  • ¿Se necesita alguna opción de Oracle? (Por ejemplo: Opción de Intermedia, opción espacial,...)
SIN ALARMA: Ninguno
CON ALARMA: Se hace uso de alguna de las opciones de oracle las opciones oracle se licencian separadamente al gestor RDBMS, y solo pueden usarse en la "Enterprise edition" de Oracle La relación de las mismas es http://www.oracle.com/us/products/database/options/overview/index.html
  • ¿La aplicación puede ser totalmente funcional sin necesidad de otorgar los roles DBA y RESOURCE? ¿Qué privilegios mínimos son requeridos?
SIN ALARMA: La aplicación sólo posee privilegios sobre sus propios esquemas
CON ALARMA: La aplicación necesita privilegios de DBA , y/o privilegios sobre terceros esquemas
  • ¿Existe algún problema en usar como juego de caracteres en la base de datos UTF8 ?
SIN ALARMA: La aplicación usa un solo juego de caracteres(charset) y es de los habituales usados en España (UTF8, WE8ISO8859)
CON ALARMA: La aplicación usa varios charset y/o usa algún charset no habitual en España
  • ¿El esquema que almacena los objetos de la aplicación necesita algún tipo de mantenimiento Oracle? (Reconstrucción de índices, tipo de estadísticas,...)
SIN ALARMA: La aplicación necesita los mantenimientos habituales de una BBDD Oracle
CON ALARMA: La aplicación necesita mantenimientos adicionales a los habituales de una BBDD Oracle
  • ¿Puede separarse en una máquina independiente la Base de Datos Oracle de la máquina que aloja la aplicación?
SIN ALARMA: Si
CON ALARMA: NO
  • ¿La aplicación puede ejecutarse contra una base de datos Oracle en cualquier plataforma? (Windows, Linux, etc.)
SIN ALARMA: Si
CON ALARMA: NO
  • ¿Puede la aplicación usar los tablespaces temporales y los segmentos de rollback públicos que ya existan en la instancia, o es necesaria una gestión particular de dichos recursos? ¿Por qué?
SIN ALARMA: Si
CON ALARMA: NO
  • ¿Qué uso hace la aplicación de Oracle, principalmente es una OLTP o una DSS?
SIN ALARMA: OLTP
CON ALARMA: DSS

Obtención de la configuración de la base de datos origen.

ANEXO: Script genérico para obtener la configuración de la instancia Oracle

Volver arriba

Análisis del Sistema

Una vez que se ha realizado el análisis previo y se ha tomado la decisión de continuar la migración es el momento de empezar con los análisis detallados que llevarán a la elaboración de los planes de migración.

En primer lugar será necesario realizar un análisis exhaustivo de la base de datos origen, para identificar todos los elementos que tenga, ya que éstos permitirán establecer qué trabajos serán necesarios, estimar el esfuerzo asociado y planificar las actividades.

Es importante identificar qué tipos de datos utiliza la base de datos a migrar, puesto que hay tipos de datos no soportados en PostgreSQL. Del mismo modo es importante identificar qué funciones se utilizan, qué tipo de triggers, qué tipo de elementos de DML, qué elementos de PL/SQL se usan en los procedimientos almacenados, etc.

En segundo lugar será importante evaluar otros aspectos relacionados más bien con la arquitectura y soporte de la aplicación origen y con la migración, en lugar de tener que ver con la propia composición de la base de datos. Estos aspectos se identificaron en el análisis previo.

Volver arriba

Análisis de la Migración

En este punto deben identificarse los cambios específicos que hay que realizar para transformar cada elemento de la base de datos Oracle en un elemento de PostgreSQL que funcione de la misma manera. También hay que identificar los cambios a realizar en el código de la propia aplicación para que funcione sobre una base de datos PostgreSQL.

Para consultar cómo realizar cambios de elementos de Oracle 10 para que al replicarlos en Postgre 9 sigan comportándose de la misma manera puede consultarse el índice de la guía de transformaciones:

Guía de transformaciones de base de datos en migraciones de Oracle 10g R2 a PostgreSQL 9.1.3

O bien acceder a esa misma información pero a través de su clasificación en categorías:

Índice General de Transformaciones en migraciones de Oracle 10g R2 a PostgreSQL 9.1.3

Para consultar los cambios en el código existen actualmente dos guías, una para JAVA y otra para PHP.

Guía de transformaciones para aplicaciones Java en migraciones de Oracle 10g R2 a PostgreSQL 9.1.3


Guía de transformaciones para aplicaciones PHP en migraciones de Oracle 10g R2 a PostgreSQL 9.1.3

Volver arriba

Elaborar el plan de formación

Dentro del plan de formación deberán reflejarse las acciones de detección de necesidades formativas que permitan identificar las carencias de formación de los actores que se vayan a hacer cargo de las distintas tareas asociadas a la migración (equipos de soporte y desarrollo de la aplicación, usuarios si fuese necesario, etc.).

Por el momento no hay cursos oficiales de PostgreSQL ni certificaciones reconocidas, por lo que será necesario buscar los cursos y/o manuales adecuados a cada perfil, según las tareas que vaya a desempeñar. No obstante, los expertos en Oracle en la organización no deberían tener demasiados problemas para continuar sus tareas en PostgreSQL tras la migración del sistema.

Volver arriba

Elaborar el Plan de Ejecución

El plan de Ejecución debe contener todas las tareas necesarias para pasar del sistema origen al sistema destino. Entre esas tareas está la implementación de todas las transformaciones que se hayan identificado, tanto de base de datos como de código, pero también la elaboración de todos los planes asociados a la ejecución de la migración, como pueden ser:

  • Plan de Marcha atrás.
Es la salvaguarda ante posibles accidentes que se produzcan en la migración. El objetivo es volver a dejar operativa la aplicación/plataforma inicial. La solución tradicional sería un backup (de aplicación y de la base de datos original). No obstante la situación ideal es dejar inalterada la plataforma original Oracle, para que la marcha atrás simplemente consista en levantar dicha plataforma y redirigir a los clientes a dicha plataforma original. Las acciones para realizar esto dependerán de la propia aplicación y de su infraestructura, pero algunas actuaciones típicas para conseguir esta marcha atrás son cambios en DNS, o cambios en redirecciones web.
En alguna casuística concreta, por ejemplo sistemas de nóminas complejos que traten a miles de perceptores pero manejados por una cantidad muy pequeña de usuarios, se puede dejar que ambos sistemas (original y migrado) trabajen simultáneamente, dado que los costes de mantener los dos sistemas se ven compensados por la posibilidad de realizar paralelos (verificarla la compleja salida de ambos sistemas).
  • Mecanismo de escalado y manejo de problemas.
Debería contener las posibles contingencias ante problemas externos a la migración, como podrían ser cortes de luz, imposibilidad acceso al CPD, etc. Estas contingencias deben incluir personal de contacto, listas de correo, posibilidad de reuniones de urgencia, etc.
  • Plan de Implantación.
Debe contener toda la información de los pasos a seguir para la realización del cambio de un SGBDR al otro.
    • Intervinientes con sus suplentes y sus datos de contacto (teléfonos,emails , …)
    • Desglose de Tareas de cada paso ( implementadores , probadores,..)
    • Duración prevista de cada paso (Margen máximo de desviación,... )
    • Flujo de los pasos (dependencias entre tareas , posibilidad de paralelización de las mismas)
    • Eventos o responsable que toma la decisión de éxito de la migración o marcha atrás de la misma

Volver arriba

Elaborar el plan de soporte

No hay consideraciones específicas. Consultar el Elaborar el plan de formación del modelo metodológico.

Volver arriba

Elaborar el plan de comunicación

No hay consideraciones específicas. Consultar el Elaborar el plan de comunicación del modelo metodológico.

Volver arriba

Definición de la estrategia de migración

No hay consideraciones específicas. Consultar el Definición de la estrategia de migración del modelo metodológico.

Volver arriba