Oracle Notes from Guatemala: ¿Cómo elegir un método de migración de Base de Datos?

Reciban un cordial saludo amigos tecnólogos, esta vez trataremos un tema que a simple vista parece ser sencillo, sin embargo, la mayoría de veces suele ser complicado o ambiguo, se trata de elegir un método adecuado de migración.

Existen varios método de migración, los cuales se prestan a diferentes necesidades que el negocio requiera, los hay desde sencillos hasta muy complicados y arriesgados; también existen rápidos o muy lentos; existen gráficos y a nivel de ejecución manual de scripts. Todo depende del entorno que se pretende migrar.

A continuación algunos métodos de migración:

Usando Database Upgrade Assistant (DBUA)
Migración Manual
Oracle Data Pump Export e Import
Oracle Export e Import originales
Oracle Transportable Tablespaces
Oracle Data Guard SQL Apply (Logical Standby)
Oracle Golden Gate

Antes de poder crear un “algortimo” de elección de un método de migración adecuado, considero que es necesario, dar una pequeña descripción de cada uno de ellos.

Usando Database Upgrade Asssitant (DBUA): Este método es fuertemente recomendado por oracle, es gráfico, ejecuta todos los scripts necesarios en el orden correcto, realiza recomendaciones para mejorar la migración o acelerarla, valida la base de datos origen, migra instancias de Automatic Storage Management (ASM), realiza migraciones de ambientes en alta disponibilidad con Real Application Cluster (RAC), etc.

Como ven, es una herramienta muy completa, sin embargo posee algunas restricciones:

Requiere un buen porcentaje de tiempo muerto (downtime), el cual es una ventana de tiempo en que el ambiente no está disponible.
Únicamente migra bases de datos donde la plataforma origen y destino son las mismas.

Migración Manual: Este método de migración le otorga todo el control sobre la migración al Administrador de Base de Datos (DBA), el cual es el encargado de ejecutar todos los scripts necesarios, debe conocer el orden de ejecución de cada uno de ellos, debe realizar las validaciones necesarias antes de migrar, etc.

Este método se presta mucho a errores, pues es muy sensible.

Las principales restricciones de este método son:

Requiere más tiempo de downtime que la migración con DBUA, pues todo debe ser realizado manualmente.
Únicamente migra bases de datos donde la plataforma origen y destino son las mismas.

Oracle Data Pump Export e Import: Este método es muy flexible comparado con los demás métodos, pues se puede migrar toda o solo una parte de la base de datos origen, se puede realizar una migración completamente por red con la funcionalidad “network_link”. Es útil cuando se desea que la base de datos objetivo sea reestructurada pues todos los datos vuelven a ser insertados nuevamente, esto es útil cuando existen índices que necesitan ser recreados o los objetos están físicamente mal ubicados. Esta herramienta también puede utilizarse con paralelismo si el servidor posee varios cores. Para poder utilizar este método la base de datos origen debe ser al menos 10g. Esta herramienta es útil para migrar una base de datos origen a una plataforma diferente.

Las restricciones de este método son:

Se requiere espacio adicional para almacenar el archivo que genera el Export, esto es si no se usa la opción “network_link”.
Requiere un largo tiempo de downtime, desde que se empieza el export hasta que termina el import.

Oracle Export e Import originales: Esté método es útil para realizar migraciones de bases de datos muy antiguas, también posee la flexibilidad de poder migrar toda la base de datos origen o solo una parte de ella. No posee la funcionalidad “network_link”. Esta herramienta es útil para migrar una base de datos origen a una plataforma diferente.

Las restricciones de este método son:

Se requiere espacio adicional para almacenar el archivo que genera el Export, esto es si no se usa la opción “network_link”.
Requiere un largo tiempo de downtime, desde que se empieza el export hasta que termina el import.

Oracle transportable tablespaces: Este método requiere que el DBA posea bastante experiencia, ya que es posible que si no se realice correctamente los datos terminen dañados. La característica principal de éste método es que provee una migración rápida, menos de una hora aproximadamente (según oracle). Toda la metadata de los objetos debe ser migrada por medio de un export e import.

Las restricciones principales de éste método son:

La plataforma origen y destino deben tener el mismo Endian Format si la base de datos origen es menor a 10g.
A partir de 10g pueden convertirse tablespaces a diferentes plataformas.

A continuación muestro una tabla en la que se muestran algunos Sistemas Operativos y sus respectivos Endian_Format:

Para poder verificar el endian format de nuestra base de datos origen se puede ejecutar la siguiente consulta:

SQL> SELECT tp.platform_id,substr(d.PLATFORM_NAME,1,30), ENDIAN_FORMAT FROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE d WHERE tp.PLATFORM_NAME = d.PLATFORM_NAME;

Oracle Data Guard SQL Apply: Este método utiliza una base de datos standby de tipo “Logical” para poder realizar la migración. La base de datos destino, por medio de “SQL Apply” está sincronizando todos los datos y prácticamente el downtime se reduce al tiempo que tarda la configuración en realizar el cambio de roles (Switchover). La manera en que funciona una Logical Standby es por medio de los Archivelogs generados en la base de datos origen, trasladados por el proceso “Log Writter” a través de la red, almacenados después en la base de datos destino y luego son aplicados en la misma por medio de “SQL Apply”. SQL Apply se encarga de abrir los Archivelogs y convertir toda la información en sentencias SQL, las cuales son ejecutadas en la base de datos objetivo, de esta manera se obtiene la característica de “reestructuración”, pues todos los objetos son creados nuevamente, a diferencia de una Physical Standby en la cual la base de datos destino es una copia bloque a bloque de la base de datos origen.

Las principales restricciones de este método son:

Base de datos origen es al menos 10.1.0.3
Plataforma origen y destino es la misma

Oracle Golden Gate: Con este método al igual que SQL Apply son de los más rápido, el downtime se resume al tiempo que implica el cambio de roles (Swtichover), sin embargo, esta herramienta es más flexible: Se puede realizar transformaciones de los datos, ruteo, mirar solo una parte o toda la base de datos origen.

Se pueden migrar bases de datos a través de plataformas diferentes, incluso a RDBMS distintos, por ejemplo desde un SQL Server a Oracle.

Las restricciones de este método son:

Se necesita comprar la licencia de Oracle Golden Gate.
Base de datos origen es al menos 8.1 (Si se trata de Oracle).

Existen más métodos de migración, sin embargo, ya son más complejos o no son tan comunes. Como por ejemplo el uso de Oracle Streams o el uso de Backups Incrementales en el Método de Tablespaces Transportables, entre otros.

Ahora, regresando al objetivo del artículo, el cual es un algoritmo para poder elegir un adecuado método de migración, organizaremos los métodos en base a downtime, plataformas diferentes y antigüedad de la versión origen.

Nuestro algoritmo a nivel general será de esta manera:

En base a la antigüedad de la versión de base de datos origen: ¿Cuántas migraciones debo hacer para llegar a la versión destino?
Al tener el número de migraciones necesarias, debemos ahora preguntarnos: ¿Son plataformas diferentes?
Al saber si son plataformas diferentes, ahora debemos preguntarnos ¿Cuanto Downtime es permitido?

Para determinar el número de migraciones que debemos realizar utilizaremos la siguiente imagen: