Migrar DB2 z/OS a DB2 LUW

FEDERACIÓN DE DATOS

El pilar fundamental sobre la que sustenta la solución aportada, se apoya en el concepto de la federación de datos entre DB2 Z/OS y DB2 LUW. La federación de datos, junto con el protocolo de conectividad DRDA, es fundamental para conseguir:

  • Transparencia en el acceso desde aplicativos.
  • Compromiso en dos fases sobre transacciones distribuidas, técnicamente, Two Phase Commit.
  • Traducción automática de página de códigos EBCDIC y ASCII.
  • Conversión automática de la disposición física de los datos binarios, Big Endian y Little Endian.

La siguiente ilustración, muestra el escenario de partida para la migración.

Como se puede comprobar en la gráfica, pueden convivir aplicativos accediendo al entorno Z/OS con aplicativos accediendo directamente desde la plataforma distribuida . Todos estos aplicativos, acceden de manera transparente a los datos de las tablas de ambos entornos productivos.

Por supuesto, dado que el propio sistema de federación es un Gestor de Transacciones distribuidas, está garantizado de manera automática y transparente, el compromiso en dos fases, (Two Phase Commit).

Con respecto al proyecto de migración, esta solución incorpora la posibilidad de realizarlo en distintas fases. Esto es así, tanto para la migración de los objetos de la base de datos (tablas), como la de los aplicativos y/o programas que acceda a tales objetos.

Una vez finalizada el trasvase completo de la base de datos del sistema Z/OS a los sistemas distribuidos, el cliente puede incluso decidir mantener los aplicativos en entornos HOST, si así lo desea.

MIGRACIÓN POR FASES

La migración por fases viene determinada por la generación de grupos de migración. Un grupo de migración lo conforman un conjunto de tablas, vistas y/o alias que tengan entre sí, alguna de las siguientes relaciones

a)Integridad Referencial: Conforman un Grupo de Migración, la tabla padre de una integridad referencial, con todas sus tablas dependientes.

b)Vistas Dependientes: Conforman un Grupo de Migración, una tabla junto con sus vistas dependientes, y todos los alias que apuntan bien a la tabla del grupo, o bien a sus vistas dependientes.

c)Sentencias SQL donde aparezcan uniones de tablas: El gestor DB2 z/OS, no es capaz de dar respuesta a una consulta donde se mezclan tablas locales con tablas remotas. Por esta razón, todas las tablas que integran este tipo de sentencias, conforman un mismo grupo de migración.

En estos momentos, solamente tenemos acceso a las sentencias ESTATICAS de los paquetes, por lo que, los grupos resultantes se han conformado utilizando esta información. Si se tuviera en un futuro, las sentencias ejecutadas dinámicamente en el sistema, es muy posible que se conformen otros grupos de migración.

Los grupos de migración resultante del estudio de los datos del cliente, determinan que existen "G" grupos de migración, de los cuales el primer grupo consta de "t"  tablas. El total de tablas para todos los grupos de migración es de "t" tablas. Dado que el sistema productivo tiene "T" tablas, se ha creído poco eficiente, realizar "G" fases para las "t" tablas y una última fase posterior, con las tablas restantes hasta llegar a los "T".

Tomando como base estas "t" tablas, se ha diseñado realizar "n" fases de migración (ahora suponemos 3):

a)    En la primera fase de la migración, se realizaría la migración de las "t"  tablas que están y pertenecen a algún grupo de migración.

b)    Durante la segunda fase de la migración, se realizaría la migración del resto de tablas que pertenezcan a las mismas bases de datos que las "t" tablas anteriores. Se calcula que en esta fase se migrarían "t1" tablas.

c)    Por último, en la tercera fase de la migración de datos, se procederá a la migración del resto de tablas, hasta alcanzar los "T" del sistema productivo.

Gestor de Bases de Datos DB2 LUW

Todos los componentes, sus funcionalidades y el diseño utilizado dentro de la arquitectura de la solución aportada, son  plenamente soportados por el gestor de bases de datos DB2 LUW, bajo sistema operativo AIX.

 Entendemos esencial que el entorno de la solución, esté soportado oficialmente por el proveedor desde su concepción. Por un lado, se considera la utilización de una versión del gestor de bases de datos totalmente en vigor durante las fases de migración, con un nivel de mantenimiento lo más cercano posible al último nivel recomendado.

Por otro, se evitarán utilizar métodos, procedimientos, atajos, etc. donde pueda ponerse en entredicho, un entorno oficialmente soportado por el proveedor. De esta manera, se evita la denegación por parte del proveedor para la resolución de posibles problemas futuros. Y de la misma manera, se asegura que los distintos niveles mantenimiento que proporcione el proveedor para solucionar problemas detectados en otros entornos, puedan ser implementados en el entorno operacional del cliente sin problema alguno.

  • SECUENCIA DE ORDENACIÓN Y PÁGINA DE CODIGOS DE LA BASE DE DATOS
  • TIPOLOGIA DE DATOS.
  • TRATAMIENTO DE FECHAS.
  • TRATAMIENTO DE FUNCIONES.
  • COMPATIBILIDAD ENTRE GESTORES.
    1. Niveles de Aislamiento.
    2. Cláusulas de Optimización y Delimitación.
    3. Tratamiento de cursores con atributo ‘WITH HOLD’.

       -Para aquellas unidades de trabajo que finalizan con COMMIT.

       -Para aquellas unidades de trabajo que finalizan con ROLLBACK.

    1. Tratamiento de Códigos de Retorno:

Declaración explicita de variables que contengan el código de retorno (SQLCODE y SQLSTATE):

Declaración de la estructura SQLCA, que contiene ambas variables SQLCODE y SQLSTATE

 

DB2 z/OS

DB2 UDB

Descripción (DB2 UDB)

-911

-911

La transacción actual se ha retrotraído a causa de una situación de punto muerto o por haberse excedido el tiempo de espera.

100

100

No se ha encontrado ninguna fila para FETCH, UPDATE o DELETE o bien el resultado de una consulta es una tabla vacía.

-545

-545

La operación solicitada no está permitida porque una fila no cumple la restricción de comprobación nombre-restricción.

-803

-803

Uno o varios valores de la sentencia INSERT, la sentencia UPDATE o la actualización de clave foránea producida por una sentencia DELETE no son válidos porque la clave primaria, la restricción exclusiva o el índice exclusivo identificado por el id-índice, impide que la tabla nombre-tabla tenga valores duplicados para la clave de índice.

-811

-811

El resultado de una selección escalar completa, de la sentencia SELECT INTO o de la sentencia VALUES INTO es superior a una fila.

-204

-204

es un nombre no definido.

Escenario con Plan de Contingencia (Marcha Atrás)

Es requerimiento del proyecto de migración disponer de un plan de contingencia, es decir, un sistema de marcha atrás, en caso de que se detecten problemas en el entorno operativo LUW, una vez que se haya entrado en producción

Se ha diseñado un escenario de marcha atrás, basado en el producto de replicación integrado dentro del gestor de bases de datos, DB2 Replication Server.

Las actualizaciones que los usuarios y/o aplicativos vayan realizando sobre las tablas del entorno productivo LUW y/o los alias de ZOS que apunten a las tablas del entorno LUW, se replican a tablas gemelas del entorno de replicación. Estas tablas replicadas se sincronizan con las tablas originales de ZOS.

 

La solución tecnológica consta de los siguientes componentes:

  • DB2 Replication Server.
  • Sistema de Replicación: Automatización del Entorno.
  • Sistema de Sincronización: Procedimientos de Actualización incrementales.

Escenario de Alta Disponibilidad:

Con respecto al subsistema de Alta Disponibilidad, se ha diseñado un escenario basado en la utilización de los componentes High Availability Desaster Recovery (HADR) y Tivoli System Automation (TSA), ambos componentes del gestor de bases de datos DB2 LUW.

En el siguiente diagrama, se muestra de manera general, los distintos sistemas que componen la solución:

La propuesta toma como supuesto de partida, que el sistema dedicado para el entorno de producción llevará activado el componente de alta disponibilidad, mientras que el resto de bases de datos, no llevan necesariamente incorporado esta tecnología.

 En el caso de que ocurriera cualquier incidencia en la estación primaria, la estación standby conmuta de rol, pasando a ser primaria, tal y como se muestra en la figura: