Apuntes sobre migración de SQL Server

Hace poco completé la fase preliminar para la migración de SQL Server, de la versión 2008 a la versión 2012, en uno de los proyectos más retadores que he afrontado, por su complejidad, variedad de casos y tamaño de la información (alrededor de 3Tb)

Para lograr una migración a tiempo y libre de complicaciones, llevamos a cabo una planificación detallada e identificamos las complejidades de los servidores SQL Server y de las aplicaciones. Como todo proyecto de tecnología, la planificación y la validación del plan nos da la confianza de que vamos a completar el trabajo con éxito. Pero si se ignora el proceso de planeamiento, se aumenta las probabilidades de que se presenten dificultades que puedan descarrilar y demorar la migración

El proceso de migración se llevará a cabo en dos fases:

  1. La primera fase donde se planifica todo el proceso y donde se analiza la información de los servidores a ser migrados
  2. La segunda fase en la que se validará lo desarrollado en la primera fase y donde se ejecutará la migración de los servidores, se ejecutarán las pruebas de validación y aceptación y se concluirá el proceso

El flujo proceso completo de migración se detalla en el siguiente diagrama:

Upgrade Work Flow

Escenarios de migración

Existen dos escenarios principales para la migración de SQL Server:

Actualización en sitio (In Place)

Se procede ejecutando el instalador de SQL Server 2012 en los servidores que se desean migrar y ejecutar la actualización automática de la instancia SQL Server 2008. La instancia original en la versión 2008 es reemplazada por la nueva en la versión 2012

En este caso el programa de actualización detectará todos los componentes de la instancia a ser actualizada y va a requerir que todos sean actualizados el mismo tiempo. Es decir, no se puede actualizar el motor de base de datos sin actualizar, por ejemplo, Analysis Services

Ventajas Desventajas
  • Simple y rápida, especialmente para sistemas pequeños
  • Es, en su mayoría, un proceso automático
  • Al ser automático, se requiere menos recursos para el despliegue
  • La instancia resultante tiene el mismo nombre que la original
  • Todos los sistemas y aplicaciones se siguen conectando a la misma instancia
  • No se requiere hardware adicional, aunque si se requiere espacio adicional para el proceso
  • Se tiene que migrar toda la instancia, por completo. No se puede actualizar un servicio o una base de datos en particular
  • Se requiere que todos los problemas de compatibilidad sean resueltos antes de proceder con la migración
  • La actualización en sitio no es recomendad para ciertos componentes, como algunos paquetes DTSX
  • No se puede deshacer la actualización directamente. Si se desea regresar al estado original, se tiene que reinstalar todo el servidor original, reconfigurar y restaurar las bases de datos del sistema y de usuario

image

Figura 1. Escenario de actualización en sitio

Lado a lado (side by side)

Se procede instalando una nueva instancia de SQL Server 2012 y mover manualmente los componentes que se desean migrar desde la instancia SQL Server 2008 a la instancia SQL Server 2012. En este caso se mantienen tanto la instancia original SQL Server 2008 como la instancia nueva SQL Server 2012. Hay dos variaciones de esta estrategia:

  • Un Servidor: La nueva instancia SQL Server 2012 se instala en el mismo servidor donde reside la instancia actual SQL Server 2008
  • Dos servidores: La nueva instancia SQL Server 2012 se instala en un servidor diferente que el de la instancia actual SQL Server 2008

A pesar de que el espacio en disco utilizado por las bases de datos SQL Server 2008 es alto, lo ideal es contar con similar tamaño para duplicar las bases de datos al momento de migrarlas. En este escenario se migrarán las bases de datos en una nueva ubicación y se mantendrán ambas versiones en línea

Ventajas Desventajas
  • Ofrece un control granular sobre los componentes y bases de datos que se desean migrar
  • El servidor anterior puede seguir operando al lado del nuevo. Ideal para llevar a cabo pruebas y resolver los problemas de compatibilidad sin alterar el sistema de producción
  • Las aplicaciones pueden ser migradas por etapas, en vez de ser migradas todas a la vez.
  • El sistema original está disponible. Si se detectan problemas en el sistema migrado se puede regresar al sistema original
  • El espacio de disco es independiente por lo que se mantienen las bases de datos de cada instancia
  • Puede requerir hardware y recursos adicionales
  • Si las instancias lado a lado se instalan en un servidor, puede que los recursos sean insuficientes
  • Las aplicaciones y los usuarios tienen que ser redireccionados a la nueva instancia. Esto puede requerir algún tipo de reconfiguración o recodificación de las aplicaciones
  • Se deben transferir manualmente las bases de datos, así como las configuraciones, seguridad y otros objetos de soporte, lo cual requiere de mayores habilidades y tiempo
  • Es posible que se requieran sincronizaciones de datos desde el servidor original a la nueva instancias mientras se configura y prueba el nuevo sistema
  • Al ser discos independientes, se requiere de mayor infraestructura de almacenamiento

image

Figura 2. Escenario de actualización Lado a lado, un servidor

image

Figura 3. Escenario de actualización Lado a lado con discos In dependientes

La siguiente tabla resume las principales diferencias entre los diferentes escenarios:

En sitio Lado a lado
Número de instancias resultantes Solo una Dos
Número de servidores físicos involucrados Uno Uno o mas
Transferencias de archivos de datos Automática Manual
Configuración de la instancia de SQL Server Automática Manual
Herramienta de soporte SQL Server Setup Varios métodos de transferencia

Les dejo el link de un whitepaper extenso sobre el proceso de migración hacia SQL Server 2012:

SQL Server 2012  Upgrade Technical Guide

2 comentarios en “Apuntes sobre migración de SQL Server

  • Muy buen articulo ALberto. Gracias

    Fue necesaria la ejecución de este código al finalizar la migración:

    ALTER DATABCOMPATIBILITY_LEVEL ASE nameDB SET = xxx;

    • Buen apunte Enrique, ya que SQL mantiene el nivel de compatibilidad de la versión original de la base de datos

      Saludos

Deja una respuesta

Tu dirección de correo electrónico no será publicada.