A medida que pasa el tiempo, más empresas están migrando, o al menos evaluando, Azure SQL Database como una alternativa al alto costo de ejecutar SQL Server en las instalaciones.
Comprobación de compatibilidad
Uno de los primeros aspectos de mover su base de datos a Azure SQL Database es verificar la compatibilidad y Microsoft le brinda numerosos formas de hacer esto para Azure SQL Database V12 (en lo sucesivo, simplemente 'V12'). Uno de estos métodos es usar SQL Server Data Tools para Visual Studio (SSDT), que usa las reglas de compatibilidad más recientes para detectar incompatibilidades V12. En SSDT, puede importar el esquema de su base de datos y crear un proyecto para una implementación de V12, y si se encuentran incompatibilidades, se pueden corregir dentro de SSDT y luego volver a sincronizarse con la base de datos de origen.
También puede usar una herramienta de línea de comandos llamada SqlPackage que puede generar un informe de problemas de compatibilidad (y siempre asegúrese de tener la última versión). SQL Server Management Studio es otra forma de hacerlo, utilizando la función Exportar aplicación de nivel de datos, que puede detectar e informar errores en la pantalla. Si no se detectan errores, puede migrar su base de datos a V12. Si se detectan incompatibilidades, se pueden corregir mediante SSMS antes de la migración.
El Asistente de migración de datos es una herramienta independiente (que se confunde fácilmente con el Asistente de migración de SQL Server) que se puede usar para ayudar a reducir el esfuerzo de actualización y reemplaza a la versión preliminar del Asesor de actualizaciones de SQL Server 2016. DMA también puede recomendar mejoras de rendimiento y confiabilidad. Otra herramienta, el Asistente de migración de SQL Azure (SAMW), es una herramienta de Codeplex que usa las reglas de compatibilidad de Azure SQL Database V11 para detectar las incompatibilidades de V12. SAMW también puede completar la migración a V12 y solucionar algunos problemas de compatibilidad. Algo a tener en cuenta al usar SAMW es que puede detectar incompatibilidades que no necesitan ser reparadas.
Migración de datos
Una vez que su base de datos haya pasado la verificación de compatibilidad, debe determinar el mejor método para migrar. Algunos de los métodos más comunes incluyen el uso del Asistente de migración de SSMS, la exportación a un BACPAC, el uso de la replicación transaccional o la creación manual de scripts en las bases de datos e inserción de sus datos.
El uso del asistente de migración de SSMS es excelente para SQL Server 2005 y bases de datos de tamaño pequeño a mediano. Puede activar este asistente en SSMS 2016 haciendo clic con el botón derecho en una base de datos, seleccione Tareas y luego Implementar base de datos en Microsoft Azure SQL Database. En SSMS 2014 se llama Implementar base de datos en la base de datos SQL de Windows Azure. El uso de este asistente le permite especificar la base de datos para migrar, conectarse a su suscripción de Azure, elegir la ubicación para el archivo .bacpac, el nuevo nombre de la base de datos y a qué nivel migrar. Cuando haga clic en Finalizar, el asistente extraerá y validará el esquema y luego exportará los datos. Una vez que se exportan los datos, creará un plan de implementación y comenzará a importar los datos a la nueva base de datos V12.
Muy similar al asistente de migración de SSMS es la aplicación de nivel de datos de exportación. Para seleccionar esta opción, haga clic derecho en la base de datos, elija Tareas y luego Exportar aplicación de nivel de datos. En la configuración de exportación, especifique dónde le gustaría crear el archivo .bacpac. Puede guardar esto localmente o guardarlo directamente en su cuenta de almacenamiento de Azure. También hay una pestaña avanzada donde puede seleccionar qué tablas incluir. Esto es útil si su base de datos local contiene copias de tablas que no desea migrar a V12. Cuando elija Finalizar, exportará sus datos. Luego puede conectarse a su servidor Azure a través de SSMS y elegir Importar aplicación de nivel de datos. Deberá especificar la ubicación del archivo, el nombre de la base de datos y el nivel de Azure SQL Database. Cuando elija finalizar, la base de datos comenzará a importar. Este método le brinda un poco más de control sobre el proceso, ya que separa la exportación de la importación. También le brinda la opción de almacenar el archivo .bacpac en su cuenta de almacenamiento de Azure para que el proceso de importación más vulnerable no dependa de su conexión a Internet.
Una opción al usar el asistente de migración de SSMS o la aplicación de nivel de datos de exportación es crear una máquina virtual de Azure con SQL Server y configurar el trasvase de registros. Esto preparará previamente su base de datos en la nube de Azure para ayudar a minimizar el tiempo de importación de la base de datos. Cuando llegue el momento de realizar la migración, simplemente restaure las copias de seguridad de registros finales en el secundario y luego elimine el trasvase de registros. Para poner la base de datos en línea, realice una restauración con recuperación. Básicamente, esto eliminará el tiempo que lleva copiar su base de datos desde su centro de datos al centro de datos de Azure.
La replicación transaccional es otro método para ayudar a reducir el tiempo de inactividad de la migración a V12. Es la mejor opción si tiene una ventana de mantenimiento extremadamente pequeña para cambiar a V12, si la base de datos puede admitir la replicación transaccional. La configuración de la replicación transaccional requiere claves principales para cada tabla publicada, lo que puede ser problemático para muchas bases de datos. La configuración de la replicación transaccional también puede ser complicada, ya que debe configurar la base de datos de distribución, configurar el publicador y el suscriptor, y supervisar los trabajos.
También puede migrar manualmente mediante el asistente Generar secuencias de comandos y generar secuencias de comandos del esquema o los datos de la base de datos. A continuación, puede crear una base de datos vacía en Azure e importar su esquema o datos ejecutando el script. He oído hablar de algunas personas que usan este método para crear la base de datos vacía y luego insertan manualmente sus datos una tabla a la vez usando SSMS y un servidor vinculado. Este método puede funcionar para usted, pero también puede ser muy complicado si tiene muchas construcciones de esquema como relaciones de clave externa y columnas de identidad, en cuyo caso los otros métodos anteriores serían más confiables y eficientes.
Otras consideraciones de migración
Cuando planee migrar bases de datos locales a V12, el tamaño de la base de datos es un factor muy importante en el tiempo que llevará la migración. La exportación de la base de datos, la transferencia de los datos y la importación aumentarán en proporción al tamaño de la base de datos.
Otro factor importante en el tiempo de restauración/importación al mover sus bases de datos a V12 es el nivel de rendimiento que también está restaurando. El proceso de restauración/importación requiere mucha potencia, por lo que para ayudar a acelerar su migración, debe considerar restaurar a un nivel de rendimiento más alto. Cuando la base de datos está en línea, puede descender fácil y rápidamente a un nivel inferior que satisfaga sus necesidades diarias de rendimiento. Poder cambiar los niveles de rendimiento con unos pocos clics del mouse es uno de los grandes beneficios de Azure SQL Database.
Monitoreo
Una parte importante de la administración de cualquier base de datos es la supervisión. Si no está monitoreando algo, no puede medirlo. Si no sabe cuáles son sus métricas cuando las cosas funcionan normalmente, ¿cómo sabrá qué cosas son peores cuando se degrada el rendimiento? Con las bases de datos locales, tenemos herramientas con las que estamos familiarizados:SQL Server Management Studio, Performance Monitor, Task Manager, DMV, etc. Cuando movemos nuestras bases de datos a V12, perdemos la capacidad de monitorear desde la perspectiva del sistema operativo y otros conceptos también cambian un poco. Ahora tenemos esta métrica llamada DTU para trabajar, que significa Unidades de transacción de base de datos. Piense en ello como una combinación de CPU, E/S de registro de transacciones y datos, y memoria. Azure Portal incluye un gráfico de supervisión que, de forma predeterminada, tiene marcado el porcentaje de DTU, y puede editar este gráfico para incluir métricas adicionales, como:
- Bloqueado por cortafuegos
- % de CPU
- Límite de DTU
- DTU utilizada
- Porcentaje de E/S de datos
- Tamaño de la base de datos %
- Interbloqueos
- Conexiones fallidas
- Porcentaje de almacenamiento OLTP en memoria
(versión preliminar)
- % de E/S de registro
- Porcentaje de sesiones
- Conexiones exitosas
- Tamaño total de la base de datos
- % de trabajadores
Como mínimo, agregaría el porcentaje de CPU, el porcentaje de E/S de datos, los interbloqueos y el porcentaje de tamaño de la base de datos. Actualmente, este gráfico muestra la hora anterior de utilización de recursos.
El monitoreo por parte de los DMV no ha cambiado mucho, aparte de tener algunos DMV nuevos relacionados con métricas de bases de datos individuales y cómo calcular el tamaño de la base de datos. Uno de mis artículos anteriores aquí, Primeros pasos para ajustar el rendimiento en Azure SQL Database, cubre algunas de las diferencias en los scripts comunes que se usan para recopilar latencias de disco y estadísticas de espera en relación con Azure SQL Database.
Las herramientas de terceros también han comenzado a incluir enlaces en Azure SQL Database, como SentryOne con DB Sentry. DB Sentry le brinda la capacidad de monitorear el rendimiento y administrar los eventos que ocurren en su sistema. Una característica interesante es la función Top SQL que le permite ver las consultas que tienen el mayor impacto en su rendimiento general para que pueda ajustar/arreglar cualquier problema con esa consulta. Otro es trazar DTU a lo largo del tiempo y visualizarlo en un tablero junto con otras métricas importantes.
 Top SQL en el cliente SentryOne |  Uso de DTU en el panel DB Sentry |
Estas métricas se almacenan en una base de datos dedicada, lo que le brinda la capacidad de establecer una línea base y una tendencia sobre el rendimiento a lo largo del tiempo, lo cual es mucho mejor que los gráficos limitados que obtiene actualmente en Azure Portal.
Resumen
Hay muchos beneficios de migrar a Azure SQL Database V12, si su base de datos es compatible, así que aproveche una de las herramientas disponibles para verificar su compatibilidad con V12. Si su base de datos es compatible o se puede modificar fácilmente para que sea compatible, puede migrar fácilmente a Azure SQL Database V12 y comenzar a probar y comparar sus aplicaciones y cargas de trabajo.
