Ha estado ejecutando la misma instancia de SQL Server en hardware antiguo durante años. Los ciclos de parcheo son implacables, los costos de las licencias siguen aumentando y su administrador de base de datos acaba de entregarle un proyecto de migración con una fecha límite. mudarse a Base de datos SQL de Azure—La oferta de base de datos de plataforma como servicio (PaaS) totalmente administrada de Microsoft—lo saca del negocio de la infraestructura. No más copias de seguridad manuales, ni parches en las capas del sistema operativo, ni preocupaciones por la capacidad del disco a las 2 a.m.

Esta guía lo guía a través de las tres fases de una migración real: evaluación, movimiento de datos y validación posterior a la migración. Utilizará las herramientas que Microsoft recomienda actualmente, incluidas Servicio de migración de bases de datos de Azure (DMS) y Paquete Sql.

Requisitos previos

Antes de tocar cualquier cosa, confirme que su entorno cumpla con estos requisitos:

• SQL Server 2008 o posterior en su instancia de origen (DMS admite este rango)

• Una suscripción de Azure con acceso de colaborador o propietario

• Una base de datos Azure SQL de destino ya aprovisionada

• Conectividad de red desde su servidor local a Azure (VPN o RutaExpresao reglas de firewall abiertas para puntos finales públicos)

• El Módulo Az.DataMigration PowerShell instalado: Install-Module -Name Az.DataMigration

• Paquete Sql instalado en una máquina con acceso a la base de datos de origen

Una cosa para establecer expectativas desde el principio: las migraciones de DMS a Azure SQL Database son solo sin conexión. Su aplicación deja de funcionar cuando comienza la migración y vuelve a activarse cuando finaliza. Si eso es un problema, Instancia administrada de Azure SQL apoya la migración en línea, pero ese es un objetivo diferente y una publicación diferente.

Antes de comenzar, aprovisione su base de datos Azure SQL de destino. Necesitará un servidor SQL lógico en Azure y una base de datos con suficiente DTU (Unidad de transacción de base de datos) o capacidad de núcleo virtual para su carga de trabajo. Si no está seguro del tamaño, la fase de evaluación (a continuación) le brindará recomendaciones de SKU del tamaño correcto; ejecute la evaluación antes de aprovisionar, no después.

Consejo profesional: si todavía usa la extensión Azure SQL Migration para Azure Data Studio, deténgase. Ha llegado al final de su vida útil. Azure Portal y PowerShell son las rutas admitidas en el futuro.

Fase 1: Evalúe su base de datos

No puedes migrar lo que no entiendes. Saltarse la fase de evaluación es cómo las personas descubren incompatibilidades a las 11 de la noche durante la transición real.

Si sus instancias de SQL Server están inscritas en Arco Azulobtienes evaluación continua de la migración gratis, no se requiere ninguna herramienta adicional. El Panel de migración en Azure Portal muestra el estado de preparación, los problemas de compatibilidad y las recomendaciones de SKU calculadas a partir de datos de carga de trabajo reales. Se ejecuta automáticamente en un horario semanal.

Para las instancias que no están en Azure Arc, inscríbalas ahora:

# Install the Azure Connected Machine agent on your SQL Server host
# Then register it with Arc using the azcmagent binary
azcmagent connect `
  --resource-group "rg-migration" `
  --location "eastus" `
  --subscription-id "<your-subscription-id>"

El informe de preparación para la evaluación clasifica cada base de datos como:

“No está listo” para Azure SQL Database a menudo significa que está usando características como trabajos del Agente SQL Server o consultas entre bases de datos. Están disponibles en Instancia administrada; vale la pena señalarlos si se topa con ese muro.

Información clave: Un resultado de “No listo” no es un callejón sin salida. La mayoría de los bloqueadores surgen de lagunas en las funciones que maneja Instancia administrada de Azure SQL. Verifique ambos objetivos antes de descartar por completo la ruta PaaS.

Fase 2: migrar el esquema

Aquí es donde la mayoría de las guías se saltan silenciosamente un paso crítico: DMS migra solo datos. Su esquema debe existir en la base de datos de destino antes de que se ejecute DMS o la migración fallará.

Exporte su esquema desde la fuente usando SqlPackage Extract acción, que produce una Archivo DACPAC—una instantánea portátil del esquema de su base de datos:

sqlpackage /Action:Extract \
  /SourceServerName:"your-sql-server" \
  /SourceDatabaseName:"YourDatabase" \
  /SourceUser:"sa" \
  /SourcePassword:"YourPassword" \
  /TargetFile:"YourDatabase.dacpac"

Luego publique el esquema en su destino de Azure SQL Database:

sqlpackage /Action:Publish \
  /SourceFile:"YourDatabase.dacpac" \
  /TargetServerName:"yourserver.database.windows.net" \
  /TargetDatabaseName:"YourDatabase" \
  /TargetUser:"sqladmin" \
  /TargetPassword:"YourPassword"

Advertencia: la acción Publicar de SqlPackage es destructiva de forma predeterminada: elimina y recrea objetos para que coincidan con el DACPAC. Ejecútelo en una base de datos nueva, no en un objetivo de producción con datos existentes.

Verifique que el esquema haya llegado correctamente antes de continuar:

-- Run against your Azure SQL Database target
SELECT TABLE_NAME, TABLE_TYPE
FROM INFORMATION_SCHEMA.TABLES
ORDER BY TABLE_NAME;

Si el recuento de su tabla coincide con la fuente, está listo para el movimiento de datos.

Fase 3: Migrar los datos

Con el esquema implementado, puede ejecutar la migración de DMS. DMS utiliza un Tiempo de ejecución de integración autohospedado (SHIR)(un agente seguro instalado en su red) para leer datos de su origen y enviarlos a Azure sin necesidad de conexiones entrantes directas.

Comience creando una instancia de DMS si no tiene una:

New-AzDataMigrationSqlService `
  -ResourceGroupName "rg-migration" `
  -Name "dms-prod" `
  -Location "eastus"

Registre su SHIR con el servicio DMS. usted descargar e instalar el SHIR desde Azure Portal en su recurso DMS, luego instálelo en una máquina local con línea de visión a su SQL Server de origen y regístrelo con una clave de autenticación generada durante la instalación. La máquina SHIR necesita acceso HTTPS saliente (puerto 443) a Azure; no requiere reglas de firewall entrantes, por lo que funciona incluso cuando su servidor SQL se encuentra detrás de un firewall corporativo.

Verifique que SHIR esté conectado y en buen estado antes de iniciar la migración:

# Check SHIR status
Get-AzDataMigrationSqlService `
  -ResourceGroupName "rg-migration" `
  -Name "dms-prod" | Select-Object -ExpandProperty IntegrationRuntimeState

un estado de Online significa que estás listo para continuar. Limited o Offline significa que SHIR no puede comunicarse con Azure; verifique las reglas de red saliente de la máquina antes de dedicar tiempo a un intento de migración.

Aquí hay una referencia rápida para los estados SHIR y lo que le dicen:

Luego inicie la migración:

New-AzDataMigrationToSqlDb `
  -ResourceGroupName "rg-migration" `
  -SqlDbInstanceName "yourserver" `
  -TargetDbName "YourDatabase" `
  -MigrationService "/subscriptions/<sub-id>/resourceGroups/rg-migration/providers/Microsoft.DataMigration/sqlMigrationServices/dms-prod" `
  -Scope "/subscriptions/<sub-id>/resourceGroups/rg-migration/providers/Microsoft.Sql/servers/yourserver/databases/YourDatabase" `
  -SourceSqlConnectionAuthentication "SqlAuthentication" `
  -SourceSqlConnectionDataSource "your-sql-server" `
  -SourceSqlConnectionUserName "sa" `
  -SourceSqlConnectionPassword "YourPassword" `
  -SourceDatabaseName "YourDatabase" `
  -TargetSqlConnectionAuthentication "SqlAuthentication" `
  -TargetSqlConnectionDataSource "yourserver.database.windows.net" `
  -TargetSqlConnectionUserName "sqladmin" `
  -TargetSqlConnectionPassword "YourPassword"

Monitorear el estado de la migración:

Get-AzDataMigrationToSqlDb `
  -ResourceGroupName "rg-migration" `
  -SqlDbInstanceName "yourserver" `
  -TargetDbName "YourDatabase"

El State el campo se mueve desde InProgress a Succeeded cuando se completa el movimiento de datos. Los scripts de muestra completos para este patrón están disponibles en el Repositorio Azure-Samples/data-migration-sql.

Información clave: para bases de datos más pequeñas donde el tiempo de inactividad no es una preocupación, puede omitir DMS por completo y usar un archivo BACPAC en su lugar. La acción Exportar de SqlPackage agrupa esquemas y datos en un solo archivo: es más simple, pero no adecuado para bases de datos grandes o transaccionalmente activas debido a riesgos de coherencia.

Fase 4: Validar y Optimizar

La migración se completa, cambias las cadenas de conexión y listo. Más o menos.

Antes de declarar la victoria, realice comprobaciones del recuento de filas para confirmar que los datos estén completos:

-- Run this on both source and target, compare results
SELECT
  t.name AS TableName,
  p.rows AS RowCount
FROM sys.tables t
JOIN sys.partitions p ON t.object_id = p.object_id
WHERE p.index_id IN (0, 1)
ORDER BY t.name;

Una vez que haya confirmado que los recuentos de filas coinciden, deje que su carga de trabajo se ejecute durante unos días antes de optimizar. Información sobre el rendimiento de consultas muestra las consultas de mayor duración y que consumen más recursos en toda su carga de trabajo; verifíquelas después de tener tráfico real para analizar.

Bases de datos SQL de Azure sintonización automática Puede crear y eliminar índices basados ​​en patrones de carga de trabajo sin intervención manual. Habilítelo, luego verifique lo que está haciendo en lugar de dejar que funcione a ciegas:

-- Check auto-tuning recommendations in your target database
SELECT name, reason, score, details
FROM sys.dm_db_tuning_recommendations
WHERE JSON_VALUE(state, '$.currentValue') = 'Active'
ORDER BY score DESC;

Una sorpresa común después de la migración: las consultas que se ejecutaron correctamente en las instalaciones se ralentizan en Azure SQL Database porque el recuento de DTU o núcleos virtuales del nivel de servicio no coincide con su carga de trabajo real. El Documentación de orientación de rendimiento Cubre cómo interpretar los datos de monitoreo y escalarlos adecuadamente. La ampliación es un comando CLI:

az sql db update \
  --resource-group rg-migration \
  --server yourserver \
  --name YourDatabase \
  --service-objective S4

Elegir el nivel de servicio adecuado

Si aprovisionó su base de datos de destino basándose en una suposición en lugar de en las recomendaciones de la evaluación de Arc, es posible que deba cambiar el tamaño después de observar el tráfico del mundo real. Azure SQL Database ofrece dos modelos de compra:

Para la mayoría de las migraciones desde SQL Server local, el modelo de núcleo virtual le brinda una asignación de costos más predecible: su servidor local tiene un recuento de núcleos conocido y los precios de núcleo virtual se traducen directamente.

Qué mirar después de la transición

La migración de SQL Server a Azure SQL Database sigue una secuencia predecible: evaluar la compatibilidad con Azure Arc, migrar el esquema con SqlPackage, mover datos con DMS y validar antes de cortar el tráfico de producción. Las partes que causan problemas casi siempre son las que la gente se salta: ya sea la fase de evaluación (que muestra los bloqueadores de compatibilidad antes de que usted se comprometa) o el paso de migración del esquema (que DMS no manejará por usted).

Si obtiene un resultado de evaluación de “no listo”, no asuma inmediatamente que la migración está estancada. Muchos bloqueadores se reducen a brechas de características que maneja la Instancia administrada de Azure SQL; vale la pena verificar ambos objetivos uno al lado del otro antes de descartar por completo la ruta PaaS.

Las herramientas que Microsoft recomienda cambiar periódicamente: la extensión Azure SQL Migration para Azure Data Studio ha llegado al final de su vida útil y el Asistente de migración de datos (DMA) ha quedado obsoleto. Quedarse con el Flujo de trabajo de Azure Portal DMS y el Módulo Az.DataMigration PowerShell lo mantiene en el camino apoyado.