Compartilhar via

Melhores práticas para a execução do Assistente de Migração de Dados

  • Artigo

Importante

O Assistente de Migração de Dados (DMA) está obsoleto. Para opções de migração do SQL Server para o SQL do Azure, consulte opções de migração do SQL Server para o SQL do Azure.

Este artigo fornece algumas informações de prática recomendada para instalação, avaliação e migração.

Instalação

Não instale e execute o Assistente de Migração de Dados diretamente no computador host do SQL Server.

Avaliação

  • Execute avaliações em bancos de dados de produção fora de horários de pico.
  • Execute os problemas de compatibilidade e as novas avaliações de recomendações de recurso separadamente para reduzir a duração da avaliação.

Migração

  • Migre um servidor fora dos horários de pico.

  • Ao migrar um banco de dados, forneça um único local de compartilhamento acessível pelo servidor de origem e pelo servidor de destino e evite uma operação de cópia se possível. Uma operação de cópia pode gerar um atraso dependendo do tamanho do arquivo de backup. A operação de cópia também aumenta as chances de uma migração falhar devido a uma etapa adicional. Quando um único local é fornecido, o Assistente de Migração de Dados ignora a operação de cópia.

    Além disso, forneça as permissões corretas para a pasta compartilhada a fim de evitar falhas de migração. As permissões corretas são especificadas na ferramenta. Se uma instância do SQL Server for executada sob credenciais de serviço de rede, conceda as permissões corretas na pasta compartilhada à conta do computador da instância do SQL Server.

  • Habilite a criptografia de conexão ao se conectar com os servidores de origem e de destino. O uso da criptografia TLS aumenta a segurança dos dados transmitidos pelas redes entre o Assistente de Migração de Dados e a instância de SQL Server, o que é benéfico, sobretudo ao migrar logons do SQL. Se a criptografia TLS não for usada, e a rede estiver comprometida por um invasor, os logons do SQL que estão sendo migrados poderão ser interceptados e/ou modificados imediatamente pelo invasor.

    No entanto, se todos os acessos envolverem uma configuração de intranet segura, a criptografia poderá não ser necessária. A habilitação da criptografia reduz o desempenho por causa da sobrecarga extra necessária para criptografar e descriptografar pacotes. Para saber mais, confira Criptografando conexões com o SQL Server.

  • Verifique se há restrições não confiáveis no banco de dados de origem e no banco de dados de destino antes de migrar dados. Após a migração, analise o banco de dados de destino novamente para ver se alguma restrição se tornou não confiável como parte da movimentação de dados. Corrija restrições não confiáveis conforme a necessidade. Deixar as restrições não confiáveis pode resultar em planos de execução ruins e pode afetar o desempenho.