Te pongo en situación, tu empresa decidió hace tiempo empezar a desplegar servicios en la nube de azure. En una fase inicial del proyecto se decidió usar bases de datos de Azure SQL sin servidor, la gama de entrada a SQL en Azure. Ha pasado el tiempo y se ha descubierto que el proyecto no puede continuar debido a las limitaciones de esta solución SAAS. Hay que migrar las bases de datos.
¿Por qué migrar y donde?
Como ya te he adelantado en la descripción, el problema es que necesitas alguna de las características de SQL Server que no incluyen las bases de datos de Azure SQL. Sin embargo, sí que sigues convencido de que la mejor opción es un producto SaaS administrado en la nube, con un tiempo de disponibilidad del 99,99%, con actualizaciones automáticas, seguridad de datos avanzada y análisis de registros SQL de Azure. Básicamente no tener que administrar una máquina local o virtual IaaS.
Parece que la solución es clara, necesitas una instancia administrada de SQL en Azure. Las características de Azure MI que no tienen las bases de datos de Azure SQL son:
- Consultas entre bases de datos
- Usar las bases de datos como publicadoras en replicación.
- Copias de seguridad y restauraciones a petición por T-SQL.
- Compatibilidad con .NET SQL CLR
- Activadores de ámbito de servidor o triggers de inicio de sesión
- Captura de datos modificados (CDC)
- Acceso a Resource Governor.
- Agente de SQL.
- Y más…
¿Cómo no migrar?
En este punto te piden a ti, DBA, llevar a cabo esta migración. Parece una tarea sencilla, ¿verdad? Pues vamos a ver que de eso nada. Como acabamos de ver en el apartado anterior, una de las limitaciones de las bases de datos de Azure SQL es que no permiten copias de seguridad por T-SQL. Aunque si tienen copias de seguridad automáticas por parte de Azure, estas solo se pueden restaurar como otra base de datos de Azure SQL, no las vas a poder llevar a una instancia.
Tampoco vas a poder usar una base de datos de Azure SQL como origen de datos en Azure Data Migration Service (DMS) ni en Data Migration Assistant (DMA). Y esto no es todo, tampoco admiten DB Mirroring, AlwaysOn, Log Shipping o Replicación. Estás perdido, solo te queda implementar una solución de copia de datos manual con T-SQL, SSIS o Azure Data Factory lo que te va a suponer mucho esfuerzo y una sobrecarga de trabajo difícil de asumir. Pero, no te preocupes, yo te voy a contar cómo hacerlo de manera fácil.
¿Qué opciones tienes?
Visto lo visto, partiendo de las premisas anteriores lo primero que tienes que asumir es que esto va a ser un proceso manual. Podrías automatizarlo con las alternativas que hemos mencionado antes de T-SQL, SSIS o Data Factory pero eso no es lo que buscas. Necesitas una solución simple, mover los datos y ya está. Para eso tenemos dos opciones o usar el asistente de Import/Export con SSIS en SSMS o usar el asistente para importar/exportar aplicaciones de capa de datos, también en SSMS.
Asume que durante la migración vas a tener un tiempo de inactividad total de las bases de datos. Realmente vas a poder seguir leyendo la base de datos Azure SQL de origen pero si haces cambios es posible que luego no los veas replicados en la Azure MI.
Ahora bien, puedes reducir el tiempo de inactividad migrando las tablas por partes siempre que tu aplicación lo permita. Si tienes unos datos “frios”, una especie de diccionarios con pocos o ningún cambio puedes migrar esas primero sin parar la aplicación para luego reducir el tiempo al migrar solo el resto de tablas.
Migrar con el asistente de import/export de SSIS en SSMS
Este asistente, lo puedes ejecutar desde SSMS y genera un paquete de SSIS básico para la copia de datos. OJO, solo para la copia de datos. Si las tablas no existen si que las va a crear pero no va a crear ningún otro objeto, ni siquiera los índices. No, ni los índices clustered ni las PK ni nada. Por supuesto tampoco va a crear vistas, triggers, funciones, procedimientos, etc…
Paso 1
Como este asistente solo copia datos lo primero que tienes que hacer es crear en tu instancia administrada de Azure la base de datos con todos los objetos de la base de datos. Sin embargo, en este punto no te recomiendo crear ni los triggers ni las Foreign Keys para evitar problemas con la copia de datos. Para generar los script de creación de objetos puedes usar el asistente que incluye el propio SSMS.
Paso 2
Ahora que ya tienes toda la estructura de tu base de datos creada en Azure MI puedes usar el asistente de importación y exportación para copiar los datos. No vamos a profundizar en este punto porque ya lo hemos explicado en este artículo y en este vídeo. Solo vas a tener que elegir el origen y el destino correctos.
Paso 3
Ahora que ya tienes todos los datos copiados es el momento de crear los triggers y las FK que antes hemos dejado pendientes. También debes validar que todo está correcto y ya estaría listo para trabajar en el nuevo entorno.
Migrar con el asistente de import/export de aplicaciones de capa de datos en SSMS
Este asistente, lo puedes ejecutar desde SSMS y genera un archivo bacpac que luego vas a poder importar sobre la base de datos de tu instancia administrada usando el mismo asistente. Es muy parecido a una copia de seguridad tradicional aunque no es exactamente lo mismo. Vas a ver que los pasos son muy simples.
Paso 1
A diferencia del anterior, este asistente no solo copia datos sino que te va a migrar también los objetos. Además, para importarlo, solo vas a poder hacerlo sobre una base de datos nueva así que en este paso vas a exportar directamente los datos de origen en formato bacpac desde tu SSMS. Haz clic derecho sobre la base de datos, ve al menú tareas y ahí a la opción Exportar aplicación de capa de datos…
Paso 2
Es el momento de restaurar en el destino. Conectate con SSMS a tu instancia administrada de Azure y con clic derecho sobre “bases de datos” ve a restaurar aplicación de capa de datos. Sigue los pasos del asistente para importar tu archivo bacpac.
Paso 3
Ahora que ya tienes todos los datos copiados es el momento de validar que todo está correcto y ya estaría listo para trabajar en el nuevo entorno.
Otras opciones
Existe un tercer método simple que no te había comentado hasta ahora pero que también te puede servir para migrar tus datos. Es bastante más sencillo que los anteriores pero su uso queda limitado a bases de datos realmente pequeñas. Esta tercera opción consiste en generar los scripts de base de datos igual que has hecho en el primer paso de la primera solución que te he enseñado pero, en las opciones avanzadas, seleccionar también que genere los script para migrar los datos. De esta manera te generará los scripts con un insert por cada registro de cada tabla que tengas. Como ves te va a mover los datos pero es del todo ineficiente y solo es para bases de datos con pocas tablas y muy pocos registros.
Conclusión
Has visto las formas sencillas de migrar tus datos de una base de datos de Azure SQL a una instancia administrada de Azure. Con estos métodos vas a poder salir airoso de esta difícil tarea. Ahora ya si te quieres complicar te recomiendo crear un paquete SSIS que copie los datos con un bucle por cada una de las bases de datos en tu servidor de bases de datos de Azure SQL y lo que se te ocurra. A mi es la solución que más me gusta pero, cierto es, que solo merece la pena si las que tienes que migrar son muchas bases de datos.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
