Compartir vía

Procedimientos recomendados para ejecutar Data Migration Assistant

  • Artículo

Importante

Data Migration Assistant (DMA) está en desuso. Para conocer las opciones de migración de SQL Server a Azure SQL, consulte las opciones de migración de SQL Server a Azure SQL.

En este artículo se proporciona información de procedimientos recomendados para la instalación, la evaluación y la migración.

Instalación

No instale ni ejecute Data Migration Assistant directamente en la máquina host de SQL Server.

Valoración

  • Ejecute las evaluaciones en las bases de datos de producción durante las horas de menor actividad.
  • Realice las evaluaciones de problemas de compatibilidad y recomendaciones de nuevas características por separado para reducir la duración de la evaluación.

Migración

  • Realice la migración a un servidor durante las horas de poca actividad.

  • Al migrar una base de datos, proporcione una única ubicación de recurso compartido a la que puedan acceder el servidor de origen y el de destino, y evite una operación de copia si es posible. La operación de copia puede implicar un retraso según el tamaño del archivo de copia de seguridad. La operación de copia también aumenta las posibilidades de que se produzca un error en la migración debido a un paso adicional. Cuando se proporciona una sola ubicación, Data Migration Assistant omite la operación de copia.

    Asegúrese de proporcionar los permisos correctos a la carpeta compartida para evitar errores en la migración. Los permisos correctos se especifican en la herramienta. Si una instancia de SQL Server se ejecuta en credenciales de servicio de red, asigne los permisos correctos de la carpeta compartida a la cuenta de la máquina para la instancia de SQL Server.

  • Habilite la conexión cifrada al conectarse a los servidores de origen y de destino. El uso del cifrado TLS (seguridad de la capa de transporte) aumenta la seguridad de los datos transmitidos a través de las redes entre el Data Migration Assistant y la instancia de SQL Server, lo que resulta ventajoso especialmente al migrar inicios de sesión de SQL. Si no se usa el cifrado TLS y un atacante pone la red en peligro, el atacante podría interceptar o modificar al instante los inicios de sesión de SQL que se están migrando.

    Sin embargo, si todo el acceso se realiza dentro de una configuración de intranet segura, el cifrado podría no ser necesario. La habilitación del cifrado ralentiza el rendimiento debido a la sobrecarga adicional necesaria para cifrar y descifrar paquetes. Para obtener más información, consulte: Cifrado de conexiones a SQL Server.

  • Compruebe si hay restricciones que no son de confianza tanto en la base de datos de origen como en la base de datos de destino antes de migrar los datos. Después de la migración, vuelva a analizar la base de datos de destino para ver si alguna restricción no es de confianza como resultado del movimiento de datos. Corrija las restricciones que no sean de confianza según considere necesario. Dejar las restricciones que no son de confianza puede dar lugar a planes de ejecución deficientes y afectar al rendimiento.