Preguntas más frecuentes sobre el uso de Azure Database Migration Service

Azure Database Migration Service es un servicio totalmente administrado diseñado para permitir migraciones completas desde varios orígenes de base de datos hasta las plataformas de datos de Azure con un tiempo de inactividad mínimo. El servicio está actualmente disponible con carácter general, con trabajos de desarrollo continuados centrados en:

• Confiabilidad y rendimiento
• Adición iterativa de pares de origen-destino
• Inversión continuada en migraciones libres de problemas

El servicio admite actualmente varios pares de origen/destino o escenarios de migración. Para obtener una lista completa del estado de cada escenario de migración disponible, consulte el artículo Estado de los escenarios de migración que admite Azure Database Migration Service.

Al migrar desde SQL Server, los orígenes admitidos para Azure Database Migration Service son SQL Server 2008 y versiones posteriores. Si usa Azure Data Studio con la extensión SQL Migration, los orígenes admitidos son SQL Server 2008 a SQL Server 2022.

Puede usar Azure Database Migration Service para realizar migraciones sin conexión o en línea. Con una migración sin conexión, el tiempo de inactividad de la aplicación se inicia cuando comienza la migración. Con una migración en línea, el tiempo de inactividad se limita al momento de la migración al final del proceso. Se recomienda que pruebe una migración sin conexión para determinar si el tiempo de inactividad es aceptable; si no es así, realice una migración en línea.

Azure Database Migration Service es el método preferido para la migración de bases de datos a Microsoft Azure a escala. Para obtener más información sobre cómo Azure Database Migration Service se compara con otras herramientas de migración de bases de datos de Microsoft y para obtener recomendaciones sobre el uso del servicio para varios escenarios, consulte Diferenciación de las herramientas y servicios de migración de bases de datos de Microsoft.

Azure Migrate ayuda con la migración de máquinas virtuales locales a IaaS de Azure. El servicio evalúa la idoneidad de la migración y el ajuste de tamaño basado en el rendimiento, y proporciona estimaciones del costo que supone la ejecución de máquinas virtuales locales en Azure. Azure Migrate es útil para las migraciones mediante lift-and-shift de cargas de trabajo basadas en VM locales a máquinas virtuales de IaaS de Azure. Sin embargo, a diferencia de Azure Database Migration Service, Azure Migrate no es una oferta de servicio de migración de bases de datos especializada para plataformas de bases de datos relacionales PaaS de Azure, como Azure SQL Database o Azure SQL Managed Instance.

No. Database Migration Service no almacena los datos de los clientes.

En el caso de las máquinas virtuales de Azure SQL y los destinos de MI de Azure SQL, DMS usa la migración física, es decir, el uso de copia de seguridad y restauración. Como se describe a continuación, el modo de migración elegido determinará cómo los datos se mantienen coherentes entre el origen y el destino.

• Migración sin conexión: durante la migración sin conexión a la máquina virtual de Azure SQL y a los destinos de MI de Azure SQL, el tiempo de inactividad de la aplicación se inicia cuando se inicia la migración. DMS restaurará todos los archivos de copia de seguridad en el destino, siempre que los archivos de copia de seguridad más recientes del origen se hayan transferido al almacenamiento de red SMB o al contenedor de blobs de Azure (según la configuración de la migración). Si la copia de seguridad se realizase con la opción SUMA DE COMPROBACIÓN, la operación de restauración de DMS realizará automáticamente la validación. En ausencia de la suma de comprobación, la integridad de la copia de seguridad se comprobará explícitamente antes de la restauración. Esto garantizará que el archivo de restauración sea idéntico al archivo de copia de seguridad y, por lo tanto, tenga los mismos datos. Es posible comprobar todos los archivos de copia de seguridad, incluyendo el último nombre de archivo de copia de seguridad del origen, con el archivo de copia de seguridad aplicado o restaurado en el destino que se muestra en la página de supervisión de la migración de DMS y validar las sumas de comprobación respectivas.

• Migración en línea: durante la migración en línea a la máquina virtual de Azure SQL y a los destinos de MI de Azure SQL, se inicia el tiempo de inactividad una vez que se inicia la transición de la migración, junto con la detención de la aplicación. DMS restaurará todos los archivos de copia de seguridad en el destino, siempre que los archivos de copia de seguridad más recientes del origen se hayan transferido al almacenamiento de red SMB o al contenedor de blobs de Azure (según la configuración de la migración). Después de presionar el botón de transición de la migración, DMS mostrará el recuento de archivos de copia de seguridad pendientes (si los hubiera) presentes en el almacenamiento de red SMB o en el contenedor de blobs de Azure y que todavía se deban aplicar o restaurar en el destino. Si la copia de seguridad se realizase con la opción SUMA DE COMPROBACIÓN, la operación de restauración de DMS realizará automáticamente la validación. En ausencia de la suma de comprobación, la integridad de la copia de seguridad se comprobará explícitamente antes de la restauración. Esto garantizará que el archivo de restauración sea idéntico al archivo de copia de seguridad y, por lo tanto, tenga los mismos datos. Es posible comprobar todos los archivos de copia de seguridad, incluyendo el último nombre de archivo de copia de seguridad del origen, con el archivo de copia de seguridad aplicado o restaurado en el destino que se muestra en la página de supervisión de la migración de DMS y validar las sumas de comprobación respectivas.

En el caso de los destinos de bases de datos de Azure SQL, DMS realiza la migración lógica en el caso de bases de datos de Azure SQL, es decir, copia los datos de las tablas de la base de datos SQL de origen y los escribe en las tablas de la base de datos de Azure SQL de destino. Como DMS solo admite la migración sin conexión a bases de datos de Azure SQL, el tiempo de inactividad de la aplicación se inicia cuando se inicia la migración. Es posible supervisar y validar el número de filas leídas (de la tabla de la base de datos de origen) y copiadas (escritas en la tabla de la base de datos de Azure SQL de destino) desde la página de supervisión de la migración. Como confirmación adicional, ejecute el siguiente TSQL para obtener la suma de comprobación en las bases de datos de origen y destino y validar que los datos de origen y restauración sean idénticos.

  "SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>"
  

Nota: siempre que no escriba ninguna aplicación en la base de datos de origen o de destino. Aproveche también herramientas como la Herramienta de comparación de bases de datos para la comparación de datos.

La lista siguiente contiene los recursos de Azure que se pueden crear en segundo plano para realizar una migración de datos. Los servicios usados pueden variar según el escenario de migración.

• Azure Monitor
• MV de Azure
• Azure Storage
• Azure Service Bus
• Azure Data Factory

Internamente, DMS mantiene un almacén de metadatos que incluye información sobre ubicaciones de red, credenciales, archivos de copia de seguridad y tareas completadas. Las credenciales y los campos seleccionados, como las claves de cuenta, están cifrados. Los datos, como los nombres de tabla que se pueden incluir en la telemetría, se aplica un hash. Los nombres de usuario pueden aparecer en texto sin formato en los registros de servicio, pero las contraseñas nunca lo harán. La telemetría está aislada por región, se rige por las directivas de retención y solo está disponible para el personal autorizado dentro de Microsoft con fines de solución de problemas válidos. Los nombres de recursos de Azure, como los nombres de servidor y de base de datos, siguen las reglas de los recursos de Azure.

DMS (clásico) utiliza temas de Azure Service Bus para facilitar la comunicación entre las capas de proceso. Los temas de Azure Service Bus son únicos para cada instancia de DMS y todos los datos personales están cifrados.

Azure SQL Managed Instance y SQL Server en Azure Virtual Machines

El esquema y los datos se migran mediante copias de seguridad y restauración. Los clientes tienen la opción de restaurar desde un recurso compartido de red o directamente desde un contenedor de almacenamiento. Un archivo que contiene datos de rendimiento de Windows puede ser consumido para proporcionar recomendaciones opcionales (pero altamente recomendadas) de dimensionamiento de la carga de trabajo.

Azure SQL Database

Las migraciones a Azure SQL Database se realizan en dos pasos. El primer paso es una migración de esquema. DMS (clásico) usa objetos de administración de SQL (SMO) para la migración de esquemas. El segundo paso es la migración de datos real. SqlBulkCopy se usa para realizar la migración de datos. DMS no admite la migración de esquemas. Los datos se migran mediante Azure Data Factory. Opcionalmente, pero muy recomendable, es posible que se consuma un archivo que contenga datos de rendimiento de Windows para proporcionar recomendaciones de dimensionamiento de carga de trabajo.

Azure Database para PostgreSQL

En este escenario, el usuario final extrae los metadatos, en este caso el esquema, mediante las utilidades de la linea de comandos pg_dump y pg_restore. Al configurar la captura de datos modificados para PostgreSQL, DMS usa pg_dump y pg_restore internamente para realizar la inicialización de CDC. Los datos se almacenan en un almacenamiento temporal cifrado que solo es accesible para la instancia de DMS. Un archivo que contiene datos de rendimiento de Windows puede ser consumido para proporcionar recomendaciones opcionales (pero altamente recomendadas) de dimensionamiento de la carga de trabajo.

Azure Database for MySQL

En este escenario, la extracción y migración de esquemas se realiza mediante DMS (Classic) a través del mysql-net/MySqlConnector. Siempre que sea posible, la replicación binlog de MySQL se usa para replicar los cambios de datos y esquemas. El código personalizado se usa para sincronizar los cambios en los que no se puede usar la replicación binlog.

De MongoDB a Azure Cosmos DB

DMS extrae e inserta datos de MongoDB en Cosmos DB. También ofrece la opción de extraer los datos de un volcado BSON o JSON.

En el caso de los volcados de memoria BSON, DMS usa los datos en formato bsondump dentro de la misma carpeta dentro de un contenedor de blobs. DMS solo busca archivos de metadatos con el formato collection.metadata.json.

En el caso de los volcados de JSON, DMS leerá los archivos de las carpetas de contenedor de blobs denominadas después de las bases de datos contenedoras. Dentro de cada carpeta de base de datos, DMS solo usa archivos de datos colocados en la data subcarpeta. DMS solo examina los archivos colocados en la subcarpeta metadata y nombrados usando el formato collection.json para metadatos.

Oracle a Azure SQL Database

En este escenario, el informe de AWR o un archivo perfmon de Windows se consume para proporcionar recomendaciones de dimensionamiento de carga de trabajo opcionales (pero muy recomendadas). El usuario que realiza la migración usa Database Schema Conversion Toolkit para realizar una migración de esquema para preparar la base de datos de destino.

Oracle a Azure Database for PostgreSQL

Al igual que Oracle a Azure SQL Database, en este escenario, el informe de AWR o un archivo perfmon de Windows se consume para proporcionar recomendaciones de dimensionamiento de carga de trabajo opcionales (pero muy recomendadas). La biblioteca ora2pg se usa para extraer el esquema y migrar los datos manualmente por el usuario que realiza la migración.

DMS (clásico) se basa en la configuración de red del cliente. Si el origen de la migración usa puntos de conexión privados, usamos puntos de conexión privados, que es la configuración preferida. Usamos puntos de conexión públicos si son la única opción.

DMS usa ADF en gran medida en segundo plano para programar y coordinar el movimiento de datos. Además, Integration Runtime Autohospedado no es diferente del que probablemente ya use para sus propias canalizaciones de ADF. Para obtener más información sobre los problemas de firewall y servidor proxy, consulte Creación y configuración de un entorno de ejecución de integración autohospedado.

Todos los datos del cliente se cifran en reposo. Algunos metadatos, incluidos, entre otros, los nombres de servidor lógico y los nombres de base de datos, así como el estado de migración y el progreso de la migración aparecen en los registros de servicio que no están cifrados.

Todos los datos en tránsito están protegidos con cifrado TLS 1.2 de manera predeterminada. Los clientes heredados que requieren versiones anteriores de TLS necesitan las versiones necesarias habilitadas en la página del portal de DMS (clásico). Para DMS, la máquina en la que está instalado Integration Runtime Autohospedado se puede configurar para permitir que la configuración de TLS necesaria admita clientes heredados. Para obtener más información sobre la configuración de TLS para SQL Server, consulte KB3135244: compatibilidad de TLS 1.2 con Microsoft SQL Server.

Siempre que sea posible, se usan puntos de conexión privados. Si los puntos de conexión privados no son una opción, los puntos de conexión públicos se usan para la comunicación entre las capas de servicio. Independientemente del tipo de punto de conexión, todos los recursos se dedican o limitan a la instancia concreta de DMS y se protegen con credenciales únicas.

No se admiten claves administradas por el cliente para el cifrado de datos dentro de nuestro plano de datos o plano de control. Sin embargo, todos los datos del cliente se cifran en reposo mediante claves administradas por el servicio. Algunos metadatos, incluidos, entre otros, los nombres de servidor lógico y los nombres de base de datos, así como el estado de migración y el progreso aparecen en los registros de servicio en formato sin cifrar.

Todos los datos en tránsito se cifran con el cifrado TLS 1.2 de forma predeterminada. La página del portal de DMS (clásico) permite usar versiones anteriores de TLS para clientes heredados. Para DMS, la máquina en la que está instalado Integration Runtime Autohospedado se puede configurar para permitir la administración de la configuración de TLS para dar cabida a los clientes heredados. Para obtener más información sobre la configuración de TLS para SQL Server, consulte KB3135244: compatibilidad de TLS 1.2 con Microsoft SQL Server.

No exponemos la capacidad de cifrar los datos en nuestro control o plano de datos con claves administradas por el cliente. Todos los datos del cliente se eliminan en el momento en que se elimina la instancia de DMS, excepto los registros de servicio. Los registros del servicio DMS solo se conservan durante 30 días.

TDE

DMS admite la migración de claves administradas por el cliente (CMK) a Azure SQL para Cifrado de base de datos transparente (TDE). Para obtener instrucciones paso a paso para migrar las claves de TDE, consulte Tutorial: Migración de bases de datos habilitadas para TDE (versión preliminar) a Azure SQL en Azure Data Studio.

Cifrado de celdas

El cifrado de nivel de celda se controla en el nivel de esquema. Las herramientas de migración de esquema migran todos los objetos de esquema, incluidas las funciones y los procedimientos almacenados necesarios para implementar el cifrado de nivel de celda.

Always Encrypted

DMS no admite actualmente la migración de Always Encrypted a través de escenarios en los que se migran filas de datos individuales entre el origen y el destino. Las columnas cifradas a través de Always Encrypted se migran según lo previsto en escenarios que usan copias de seguridad o restauración, como pasar a una máquina virtual de Azure SQL o a una instancia administrada de Azure SQL desde una instancia de SQL Server existente.

No implementamos ningún control de acceso compatible con la ubicación más allá de lo que ya está disponible en Azure. Todos los datos asociados a una instancia de DMS residen en la misma región que el recurso DMS.

Nuestros servicios se usan en varios entornos con diferentes controles internos y procesos empresariales. DMS mueve datos desde y hacia cualquier lugar al que tenga acceso la cuenta a la que está usando. Es responsabilidad del usuario comprender los permisos y los controles internos del entorno en el que trabajan. Es especialmente importante asegurarse de que la cuenta que DMS usa para conectarse al origen tenga acceso para ver todos los datos que están diseñados para migrarse desde el origen.

La inyección VNET es la acción de agregar un recurso de Azure que reside en el inquilino de Microsoft a una subred de una red virtual en el inquilino del cliente. Este enfoque se ha adoptado con DMS para permitirnos administrar el proceso en nombre del cliente, a la vez que se mantiene el acceso a los recursos del cliente. Dado que la red está en la suscripción del cliente, Microsoft no puede administrar la máquina virtual más allá de emitir comandos Start, Stop, Delete o Deploy. Todas las demás acciones de administración que necesitan acceso a la máquina virtual requieren una solicitud de soporte técnico iniciada por el cliente y aprobación.

Hay varios requisitos previos necesarios para garantizar que Azure Database Migration Service se ejecute sin problemas al realizar migraciones de bases de datos. Algunos de los requisitos previos se aplican en todos los escenarios (pares origen-destino) compatibles con el servicio, mientras que otros son exclusivos para un escenario específico.

Los requisitos de Azure Database Migration Service que son comunes en todos los escenarios de migración compatibles incluyen la necesidad de:

• Cree una instancia de Azure Virtual Network para Azure Database Migration Service mediante el modelo de implementación de Azure Resource Manager, que proporciona conectividad de sitio a sitio a los servidores de origen local mediante ExpressRoute o VPN.
• Asegúrese de que las reglas del grupo de seguridad de red de la red virtual no bloqueen el puerto 443 para ServiceTags de ServiceBus, Storage y Azure Monitor. Para más información sobre el filtrado del tráfico con grupos de seguridad de red para redes virtuales, vea el artículo Filtrado del tráfico de red con grupos de seguridad de red.
• Cuando se usa un dispositivo de firewall frente a las bases de datos de origen, puede que sea necesario agregar reglas de firewall para permitir que Azure Database Migration Service acceda a las bases de datos de origen para realizar la migración.

Para obtener una lista de todos los requisitos previos que se necesitan para completar los escenarios de migración específicos mediante Azure Database Migration Service, consulte los tutoriales relacionados en la documentación de Azure Database Migration Service.

Puede que tenga que agregar reglas de firewall para permitir que Azure Database Migration Service acceda a la base de datos de origen para la migración. La dirección IP del servicio es dinámica, pero si se usa ExpressRoute, esta dirección la asigna la red corporativa de manera privada. La manera más sencilla de identificar la dirección IP adecuada es buscar en el mismo grupo de recursos que el recurso de Azure Database Migration Service aprovisionado para buscar la interfaz de red asociada. Normalmente, el nombre del recurso de interfaz de red comienza con el prefijo NIC y seguido de una secuencia de números y caracteres únicos, por ejemplo, "NIC-jj6tnztnmarpsskr82rbndyp". Al seleccionar este recurso de interfaz de red, puede ver la dirección IP que se debe incluir en la lista de permitidos en la página de información general de los recursos de Azure Portal.

Puede que también tenga que incluir en la lista de permitidos el origen de puerto en que SQL Server escucha. De manera predeterminada, se trata del puerto 1433, pero la instancia de SQL Server de origen también puede estar configurada para escuchar en otros puertos. En este caso, debe incluir también esos puertos en la lista de permitidos. Puede determinar el puerto en que SQL Server escuchar mediante una consulta de vista de administración dinámica:

SELECT DISTINCT
    local_tcp_port
FROM sys.dm_exec_connections
WHERE local_tcp_port IS NOT NULL;

También puede determinar el puerto en que SQL Server escucha mediante una consulta del registro de errores de SQL Server:

USE master;
GO
xp_readerrorlog 0, 1, N'Server is listening on';
GO

Si bien existen varios tutoriales de Microsoft que pueden guiarlo en el proceso de configurar una red virtual, la documentación oficial aparece en el artículo Azure Virtual Network.

Durante una migración de base de datos sencilla típica, debe:

1. Crear bases de datos de destino.
2. Evaluar las bases de datos de origen.
   • En el caso de las migraciones homogéneas, evalúe las bases de datos existentes mediante DMA.
   • En el caso de las migraciones heterogéneas (desde orígenes de competición), evalúe las bases de datos existentes con SSMA. También se usa SSMA para convertir los objetos de base de datos y migrar el esquema a la plataforma de destino.
3. Cree una instancia de Azure Database Migration Service.
4. Crear un proyecto de migración al especificar las bases de datos de origen, las bases de datos de destino y las tablas que se migrarán.
5. Iniciar toda la carga.
6. Seleccionar la validación posterior.
7. Realizar un cambio manual del entorno de producción a la nueva base de datos basada en la nube.

Si tiene problemas para conectarse al sistema de la base de datos de origen mientras trabaja en la migración, cree una máquina virtual en la misma subred de la red virtual con la que ha configurado la instancia de DMS. En la máquina virtual, debería poder ejecutar una prueba de conexión (por ejemplo, usar un archivo UDL para probar una conexión con SQL Server o descargar Robo 3T para probar las conexiones de MongoDB). Si la prueba de conexión se realiza correctamente, no debería tener ningún problema al conectarse a la base de datos de origen. Si la prueba de conexión no se realiza correctamente, póngase en contacto con el administrador de la red.

Si el usuario detiene explícitamente Azure Database Migration Service (DMS) o si el servicio está inactivo durante 24 horas, el servicio se encuentra en estado detenido o en pausa automática. En cada caso, el servicio no está disponible y está en un estado detenido. Para reanudar las migraciones activas, reinicie el servicio.

Hay algunas opciones que puede realizar para acelerar la migración de las bases de datos mediante el servicio:

Para DMS(clásico):

• Use el plan de tarifa de uso general de varias CPU cuando cree la instancia de servicio para permitir que el servicio aproveche las diversas CPU virtuales para la paralelización y realizar una transferencia de datos más rápida.
• Escale verticalmente temporalmente la instancia de destino de Azure SQL Database a la SKU de nivel Premium durante la operación de migración de datos para minimizar la limitación de Azure SQL Database que puede afectar a las actividades de transferencia de datos al usar SKU de nivel inferior.

Para DMS-

• Si va a copiar copias de seguridad desde el recurso compartido de archivos local a Azure Blob Storage O mientras realiza la migración a Azure SQL DB de destino, DMS usa el nodo SHIR como proceso. Por lo tanto, asegúrese de supervisar el uso de recursos de ese nodo SHIR.
• Escale verticalmente de forma temporal la instancia de destino de Azure SQL Database a la SKU de nivel Premium durante la operación de migración de datos para minimizar la limitación de disco de Azure SQL Database que puede afectar a las actividades de transferencia de datos al usar las SKU de nivel inferior.
• Para obtener información más detallada, consulte blog.

Pasos siguientes

• Qué es Azure Database Migration Service.