Migracion de Bases de Datos Oracle usando Oracle Golden Gate.
Cuando se debe hacer una migración con prácticamente zero downtime entre bases de datos Oracle dispuestas en distintas plataformas, hay pocas opciones tecnológicas disponibles. En ese contexto, es importante saber:
- Realizar Operaciones de export/import, lo cual, para bases de datos grandes, con hardware antiguo, toma demasiada cantidad de tiempo.
- Usar algún software de replicacion en tiempo real, que siga las transacciones a nivel lógico y las lleve a la nueva plataforma. Para esto usamos Oracle Golden Gate (OGG)
Opciones como Oracle DataGuard quedan descartadas porque no opera entre Arquitecturas diferentes, por ejemplo, AIX y Linux 64 bits, y, además, es una opción disponible solo en ediciones Enterprise de Oracle, que son las más caras.
En una operación reciente, hemos tenido una exitosa migracion de una base de datos Oracle 10g EE entre AIX y Linux, usando el software de Replicacion Oracle Golden Gate (OGG). El tamaño de la Base de datos es de 5 Terabytes, core de negocio, por lo tanto, hiper crítica.
Contexto:
- La máquina legacy estaba mostrando signos de fatiga, ya que llevaba más de 10 años entregando servicios.
- La carga sobre la referida máquina había subido llevándola a los límites de capacidad operativa, soportando 2000+ conexiones de aplicaciones y usuarios.
- La Base de datos se caía a una tasa de 2 veces por semana promedio.
- .Cantidad de Tablas 6.500 tablas
- Cantidad de Tablas sin PK/UK/Unique Index 2.500+ tablas
- Cantidad de Tablas con propiedad COMPRESS más de 100 tablas, pero tablas muy grandes.
Desafío: Migracion de Bases de Datos Oracle usando Oracle Golden Gate
- Migración de Base de Datos Oracle usando Oracle Golden Gate en un periodo de un mes.
Arquitectura desplegada de Oracle Golden Gate:
- Base de datos AIX1 es el servidor Productivo antes del Switchover
- .Base de Datos Linux es la nueva plataforma productiva
- Base de Datos AIX2, es un servidor de respaldo del Linux, en caso de una vuelta atrás durante las primeras semanas de operación de la nueva BD Linux. Su uso sería de remota baja probabilidad, pero por compliance se debía tener esta opción.
Precondiciones en la base de datos Origen:
- Activar Supplemental Log a nivel de base de datos, como a nivel de cada tabla
- Base de Datos en Modo ARCHIVELOG
Precondiciones en la base de datos Destino:
- Activar Supplemental Log a nivel de base de datos, como a nivel de cada tabla
- Desactivar Triggers
- Desactivar Jobs
- Desactivar Scheduler
- Desactivar cron
- Desactivar FK con opción DELETE CASCADE
- Otras precondiciones menores
Resultado de Migracion de Bases de Datos Oracle usando Oracle Golden Gate
- La migración se hizo en un mes y medio.
Estrategia:
- Analizar que esquemas de la BD se iban a replicar con OGG.
- Estudiar las características de estos esquemas, en tamaño, tipos de datos (hay tipos de datos no soportados por OGG), presencia de tablas sin PK, UK, o índices únicos (precondición de OGG), intensidad transaccional de cada esquema.
- Definir objetos a replicar via export/import en la última milla, ya que por distintos motivos.
- Definir tareas de validación de la migración como reportes de cuadratura y checksum
- -Definir set de pruebas de las áreas de negocio por etapas. Conexiones, Reporteria, Transaccional
- Dejar maquina productiva legacy durmiendo, en caso de una vuelta atrás surgida por pruebas incipientes.
- Asegurar una vuelta atrás con replicacion OGG Linux à AIX a una maquina gemela de la productiva, que llamaremos AIX2. Esto permitiría volver atrás incluyendo las modificaciones de las pruebas transaccionales realizadas en la nueva máquina Linux.
- Armar grupos de extracción y replicacion independientes para tener más grados de libertad en caso de errores o administrar los extractores/replicadores de una forma más flexible.
Claves del éxito:
- Gerencia General involucrada
- Alta gerencia involucrada
- Equipo de TI con buen liderazgo
- Mucha comunicación
- Gestión del cambio
- Task Force multidisciplinario, donde concurren actores tales como Proveedores, Servicios TI, Arquitectura, Desarrollo, y usuarios del negocio, cada uno con sus tareas y misiones.
- Daily meeting en cada uno de los grupos de tareas para controlar avances y problemas en forma diaria.
Enfoque Metodológico para OGG:
La siguiente figura es un resumen muy agregado del enfoque metodológico que inicialmente se propuso para el proyecto. Este enfoque tuvo pequeños cambios por la táctica del proyecto y los hallazgos que significaron cambiar un poco las tareas. Sin embargo, en términos gruesos, esta es la estrategia que se siguió.
Problemas
Hubo muchos problemas en el transcurso de nuestra participación en el proyecto. La mayoría de estos problemas fueron de carácter técnico. Solo por mencionar algunos, se tuvo los siguientes problemas:
- Muchas tablas sin PK/UK/Unique Index. En la versión de OGG que usamos, OGG no garantiza la replicacion exitosa de este tipo de tablas.
- Extractores generaron un overhead sobre los procesos del servidor legacy que afectaba el desempeño del resto de las funcionalidades del sistema. Como se mencionó antes, el servidor estaba en el límite de sus capacidades. Para resolver estos problemas había que bajar los extractores del OGG en los momentos de mayor intensidad transaccional y subirlos en los periodos de más tranquilidad. Esto agregaba un problema extra, a saber, el aumento de lag en la cola de procesamiento de transacciones del OGG, lo que su vez presionaba el almacenamiento de retención de archivelogs necesarios para procesar las colas retrasadas.
- Con la misma idea anterior se configuró que OGG leyera transacciones solo desde los Archivelogs. OGG puede leer desde los Online redolog, pero ese feature es altamente exigente en consumo de recursos y por lo mismo se deshabilitó. Esta configuración obliga a hacer redolog switch en la ultima milla, antes del switchover.
- Problemas con el ASM. Los archivos de base de datos, redolog files y archivelog residían en un ASM que tenía algunos problemas producto que la base de datos era un remanente single node de una instalación Oracle RAC previa. Fue necesario borrar los grupos de redolog asociados al Thread # 2, que ya se encontraba inactivo, ya que el otro nodo estaba muerto, pero OGG igual intentaba de leer y entraba en conflicto con el nivel de checkpoint de esos grupos de redolog que eran muy antiguos.
Conclusiones de la experiencia
- Oracle Golden Gate es un excelente producto para realizar migraciones con bajo downtime de servicios.
- Si bien, dependiendo de la versión de producto, pueden existir restricciones, ninguna de ellas inhabilita un proyecto de migración exitoso.
- Un proyecto de esta naturaleza requiere una organización muy detallada, con una cobertura de riesgos muy completa y debe ser acompañado por una buena estrategia de gestión del cambio.
Escríbanos a nuestros correo [email protected] para consultar por nuestro servicio de Migracion de Bases de Datos Oracle usando Oracle Golden Gate.
Lea lo último en nuestro blog «Servicios de Auditoría Oracle».
