Estrategias de MIgración de Bases de Datos

La migración, según el diccionario de la lengua española, está definido como la “Acción y efecto de pasar de un país a otro para establecerse en él. Se usa hablando de las migraciones históricas que hicieron las razas o los pueblos enteros. Desplazamiento geográfico de individuos o grupos, generalmente por causas económicas o sociales”, por lo que podemos concluir que la migración de base de datos es el proceso de llevar los datos y objetos asociados (Tablas, Vistas, Procedimientos Almacenados, Índices, Triggers, etc.) de un servidor origen o antiguo a un servidor destino o nuevo.

La migración de bases de datos es generalmente una tarea compleja que no sólo supone transferir datos entre tipos de almacenaje y formatos de un servidor origen de base de datos a otro servidor destino, sino que también supone reescribir sentencias SQL o incluso procedimientos almacenados (SP) de lógica de negocio, con la finalidad de adaptarlos al nuevo servidor de destino.

Existen muchas estrategias de actualización y migración de SGBD. Algo común en todas las estrategias es la necesidad de instalar/ejecutar el software del SGBD en el que será el servidor destino o nuevo. Es una buena idea ejecutar más de una prueba del proceso de actualización y migración, antes de realizarlo en el ambiente de producción, por lo que será necesario contar con un ambiente de pruebas. A continuación se detallan y describen las estrategias comunes y más utilizadas por los principales fabricantes de SGBD:

Actualización In-Place

Probablemente la estrategia de actualización y migración más fácil de realizar. En este caso el servidor origen y el servidor destino, es el mismo servidor. Mientras el servidor cumpla con los requerimientos mínimos del nuevo SGBD, el instalador permitirá la migración o como se trata del mismo servidor se le suele llamar solamente actualización del SGBD.

La ventaja que tiene esta estrategia es:

• No se requiere nuevo hardware para el servidor destino. Los costos de Hardware de nuevo servidor son reducidos. 
• No es necesario cambiar las cadenas de conexiones de las aplicaciones que apuntan a este SGBD.

Las desventajas que presenta son:

• Si bien se puede probar en un ambiente de prueba, el momento de realizarlo en el ambiente de producción no existe posibilidad de vuelta atrás. La única posibilidad de vuelta atrás incluye restaurar backups previos a la actualización del SGBD, lo cual dejaría al SGBD fuera de servicio, mientras se realiza la restauración.
• Es necesario una ventana de tiempo para realizar este proceso, que generalmente necesita bajar los servicios del SGBD.
• Se utiliza esta estrategia para actualizar y migrar a una edición/versión del SGBD superior a la que se está utilizando. Dependiendo de los requerimientos de cada proveedor/fabricante de SGBD.
• No se puede cambiar la plataforma o sistema operativo del servidor, como parte del proceso de actualización.

Actualización lado a lado

La idea de esta estrategia es sencilla y fácil, se debe instalar una nueva instancia del software de SGBD en el mismo servidor Lado a Lado, donde se está ejecutando la instancia antigua (origen) que se quiere actualizar. Una vez instalada el software de SGBD de la nueva instancia y que este con sus servicios funcionando, se debe simplemente cambiar las bases de datos de usuarios desde la antigua instancia (origen) y cargarlas en la nueva instancia (destino) y conectar su aplicación a la nueva instancia.

En caso de encontrase con problemas, se debe restaurar los backups de las bases de datos de usuarios a la instancia antigua y reconectar las aplicaciones. Una vez que se está seguro que la actualización Lado a Lado está bien, se puede desinstalar la instancia antigua.

Las ventajas que tiene esta estrategia de actualización es:

• No se requiere nuevo hardware para el servidor destino. Por lo que los costos de Hardware de nuevo servidor son reducidos.
• Se puede contar con un plan de vuelta atrás, utilizando la instancia antigua u origen

Las desventajas de esta estrategia, son:

• Se debe cambiar la cadena de conexión de las aplicaciones que apuntan a la instancia antigua (origen), para que apunten a la nueva instancia (destino).
• Es necesario una ventana de tiempo para realizar este proceso, que generalmente necesita bajar los servicios del SGBD. 
• No se puede cambiar la plataforma o sistema operativo del servidor, como parte del proceso de actualización.

Actualización por migración

Es la forma ideal para realizar una actualización, básicamente se debe proporcionar un nuevo servidor (destino) y realizar la instalación del software del SGBD, restaurar los backups de las bases de datos, reconectar las cadenas de conexión de las aplicaciones al nuevo servidor, si se encuentran problemas, se puede volver atrás utilizando el servidor antiguo (origen), hasta que se resuelvan los problemas.

Esta estrategia es más limpia, ya que asegura que solo estén instalados los bits del nuevo software de SGBD, de esta forma los administradores de SGBD no deben preocuparse por mantener los bits antiguos del software de SGBD. Existe toda clase de trucos que se pueden utilizar para permitir que la migración al nuevo servidor (destino) sea lo más rápido posible y minimice al mismo tiempo el tiempo de parada del servicio del SGBD mientras se realiza la migración.

La ventaja de esta estrategia es:

• Se puede contar con un plan de vuelta atrás, utilizando el servidor antiguo u origen.
• Se puede minimizar el tiempo que deja de proporcionar servicios el SGDB antiguo u origen.
• Se puede cambiar la plataforma o sistema operativo del servidor destino. Aprovechando que el Hardware es nuevo. 
• Permite la consolidación de bases de datos en un solo servidor de SGBD, esto por contar un nuevo Hardware que seguramente será de mayor capacidad.

Las desventajas que tiene son:

• Necesita de inversión en hardware, ya que se debe proporcionar un nuevo servidor (destino) donde se migrará el SGBD.
• Se debe cambiar la cadena de conexión de las aplicaciones que apuntan al antiguo servidor (origen)
• Requiere de un ambiente de pruebas similar al de producción, donde se pruebe la migración de los datos y objetos asociados (Tablas, Vistas, Procedimientos almacenados, Índices, etc.), así como se debe probar el funcionamiento de las aplicaciones que utilizan las bases de datos.