Perguntas Frequentes sobre como usar o Serviço de Migração de Banco de Dados do Azure

O Serviço de Migração de Banco de Dados do Azure é um serviço totalmente gerenciado desenvolvido para permitir migrações perfeitas de várias fontes de banco de dados para plataformas de dados do Azure com tempo de inatividade mínimo. Atualmente, o serviço está em Disponibilidade Geral, com esforços de desenvolvimento contínuo focados em:

• Confiabilidade e desempenho.
• Adição iterativa de pares de fonte-destino.
• Investimento contínuo em migrações sem conflitos.

O serviço atualmente oferece suporte a uma variedade de pares de origem/destino ou cenários de migração. Para obter uma listagem completa do status de cada cenário de migração disponível, consulte o artigo Status dos cenários de migração com suporte pelo Serviço de Migração de Banco de Dados do Azure.

Ao migrar do SQL Server, os recursos com suporte no Serviço de Migração de Banco de Dados do Azure são o SQL Server 2008 e versões posteriores. Se você usar o Azure Data Studio com a extensão de Migração de SQL, as fontes com suporte serão o SQL Server 2008 até o SQL Server 2022.

Você pode usar o Serviço de Migração de Banco de Dados do Azure para executar as migrações online e offline. Com uma migração offline, o tempo de inatividade do aplicativo começa quando a migração é iniciada. Com uma migração online, o tempo de inatividade é limitado ao tempo de transferência no final da migração. Sugerimos que você teste uma migração offline para determinar se o tempo de inatividade é aceitável; caso contrário, faça uma migração online.

O Serviço de Migração de Banco de Dados do Azure é o método preferencial para a migração de banco de dados para o Microsoft Azure em grande escala. Para obter mais informações sobre como o Serviço de Migração de Banco de Dados do Azure se compara a outras ferramentas de migração de banco de dados da Microsoft e para obter recomendações sobre como usar o serviço para vários cenários, consulte Diferenciar serviços e ferramentas de migração de banco de dados da Microsoft.

As Migrações para Azure ajudam na migração de máquinas virtuais locais para o Azure IaaS. O serviço avalia a adequação da migração e o dimensionamento com base no desempenho, e fornece estimativas de custo para a execução das máquinas virtuais locais no Azure. As Migrações para Azure são úteis para migrações de lift-and-shift de cargas de trabalho baseadas em VM local para VMs de IaaS do Azure. No entanto, ao contrário do Serviço de Migração de Banco de Dados do Azure, as Migrações para Azure não são uma oferta de serviço de migração de banco de dados especializada para plataformas de banco de dados relacional de PaaS do Azure, como o Banco de Dados SQL do Azure ou a Instância Gerenciada de SQL do Azure.

Não. O Serviço de Migração de Banco de Dados não armazena os dados do cliente.

Para destinos de VM do SQL do Azure e MI do SQL do Azure, o DMS usa a migração física, ou seja, usando backup e restauração. Conforme descrito abaixo, o modo de migração escolhido determina como os dados são mantidos consistentes entre a origem e o destino.

• Migração offline: durante a migração offline para destinos de VM do SQL do Azure e MI de SQL do Azure, o tempo de inatividade do aplicativo começa quando a migração é iniciada. O DMS restaurará todos os arquivos de backup para o destino, desde que os arquivos de backup mais recentes da origem tenham sido transferidos para o armazenamento de rede SMB ou para o contêiner de blobs do Azure (de acordo com a configuração de migração). Se o backup for feito com a opção CHECKSUM, a operação de restauração do DMS executará automaticamente a validação. Na ausência de soma de verificação, a integridade do backup é explicitamente verificada antes da restauração. Isso garante que o arquivo de restauração seja idêntico ao arquivo de backup e, portanto, tenha os mesmos dados. Você pode verificar todos os arquivos de backup, incluindo o último nome do arquivo de backup da origem, com o arquivo de backup aplicado/restauração no destino mostrado na página de monitoramento de migração do DMS e validar sua respectiva soma de verificação.

• Migração online: durante a migração online para destinos de VM do SQL do Azure e MI de SQL do Azure, o tempo de inatividade é iniciado quando você inicia a substituição de migração, juntamente com a interrupção do aplicativo. O DMS restaurará todos os arquivos de backup para o destino, desde que os arquivos de backup mais recentes da origem tenham sido transferidos para o armazenamento de rede SMB ou para o contêiner de blobs do Azure (de acordo com a configuração de migração). Depois de pressionar o botão de substituição, o DMS mostra a contagem de arquivos(s) de backup pendentes (se houver) que estão presentes no armazenamento de rede SMB ou no contêiner de blobs do Azure e ainda não foram aplicados/restaurados no destino. Se o backup for feito com a opção CHECKSUM, a operação de restauração do DMS executará automaticamente a validação. Na ausência de soma de verificação, a integridade do backup é explicitamente verificada antes da restauração. Isso garante que o arquivo de restauração seja idêntico ao arquivo de backup e, portanto, tenha os mesmos dados. Você pode verificar todos os arquivos de backup, incluindo o último nome do arquivo de backup da origem, com o arquivo de backup aplicado/restauração no destino mostrado na página de monitoramento de migração do DMS e validar sua respectiva soma de verificação.

Para destinos do BD SQL do Azure, o DMS faz a migração lógica no caso do BD SQL do Azure, ou seja, copia os dados das tabelas do banco de dados SQL de origem e os grava nas tabelas do BD SQL do Azure de destino. Como o DMS dá suporte apenas à migração offline para o BD SQL do Azure, o tempo de inatividade do aplicativo começa quando a migração é iniciada. Você pode monitorar e validar o número de linhas lidas (da tabela de banco de dados de origem) e copiadas (gravadas na tabela de BD SQL do Azure de destino) da página de monitoramento de migração. Como confirmação adicional, você pode executar o TSQL abaixo para obter soma de verificação nos bancos de dados de origem e de destino e validar os dados de origem e restauração idênticos.

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

Observação: desde que nenhum aplicativo esteja gravando no banco de dados de origem ou destino. Você também pode aproveitar ferramentas como a ferramenta de Comparação de Banco de Dados para comparação de dados.

A lista a seguir contém os recursos do Azure que podem ser criados nos bastidores para executar uma migração de dados. Os serviços usados podem variar de acordo com o cenário de migração.

• Azure Monitor
• VM do Azure
• Armazenamento do Azure
• Barramento de Serviço do Azure
• Fábrica de dados do Azure

Internamente, o DMS mantém um repositório de metadados que inclui informações sobre locais de rede, credenciais, arquivos de backup e tarefas concluídas. As credenciais e os campos selecionados, como chaves de conta, são criptografados. Os dados, como nomes de tabela que podem ser incluídos na telemetria, passam por hash. Os nomes de usuário podem aparecer em texto sem formatação nos logs de serviço, mas as senhas nunca aparecerão. A telemetria é isolada por região, regida por políticas de retenção e fica disponível apenas para pessoas autorizadas na Microsoft para solução de problemas válidos. Nomes de recursos do Azure, como nomes de servidor e banco de dados, seguem as regras para recursos do Azure.

O DMS (Clássico) utiliza tópicos do Barramento de Serviço do Azure para facilitar a comunicação entre camadas de computação. Os tópicos do Barramento de Serviço do Azure são exclusivos para cada instância do DMS e todos os dados pessoais são criptografados.

Instância Gerenciada de SQL do Azure e SQL Server em Máquinas Virtuais do Azure

Esquema e dados são migrados usando backup e restauração. Os clientes têm a opção de restaurar de um compartilhamento de rede ou diretamente de um contêiner de armazenamento. Um arquivo que contém dados de desempenho do Windows pode ser consumido para fornecer recomendações opcionais (mas altamente recomendadas) de dimensionamento de carga de trabalho.

Banco de Dados SQL do Azure

As migrações para o Banco de Dados SQL do Azure são executadas em duas etapas. A primeira etapa é uma migração de esquema. O DMS (Clássico) usa o SMO (SQL Management Objects) para a migração de esquema. A segunda etapa é a migração de dados em si. O SqlBulkCopy é usado para executar a migração de dados. O DMS não dá suporte à migração de esquema. Os dados são migrados usando o Azure Data Factory. Opcionalmente, mas altamente recomendado, um arquivo que contém dados de desempenho do Windows pode ser consumido para fornecer recomendações de dimensionamento de carga de trabalho.

Banco de Dados do Azure para PostgreSQL

Nesse cenário, o usuário final extrai os metadados, nesse caso, o esquema, usando os utilitários de linha de comando pg_dump e pg_restore. Ao configurar a captura de dados de alterações no PostgreSQL, o DMS usa pg_dump e pg_restore internamente para executar a propagação inicial para CDC. Os dados são armazenados em um armazenamento temporário criptografado que só pode ser acessado pela instância do DMS. Um arquivo que contém dados de desempenho do Windows pode ser consumido para fornecer recomendações opcionais (mas altamente recomendadas) de dimensionamento de carga de trabalho.

Banco de Dados do Azure para MySQL

Nesse cenário, a extração e a migração de esquema são feitas pelo DMS (Clássico) usando o mysql-net/MySqlConnector. Sempre que possível, a replicação de binlog do MySQL é usada para replicar as alterações de dados e de esquema. O código personalizado é usado para sincronizar alterações em que a replicação do binlog não pode ser usada.

MongoDB para o Azure Cosmos DB

O DMS extrai e insere dados de um MongoDB no Cosmos DB. Ele também oferece a opção de extrair os dados de um despejo BSON ou JSON.

Para despejos BSON, o DMS usa os dados em formato bsondump na mesma pasta de um contêiner de blob. O DMS procura apenas arquivos de metadados que usam o formato collection.metadata.json.

Para despejos JSON, o DMS lerá os arquivos nas pastas de contêiner de blob com o nome dos bancos de dados que os contêm. Em cada pasta de banco de dados, o DMS usa apenas arquivos de dados colocados na subpasta data. O DMS examina apenas os arquivos colocados na subpasta metadata e nomeados usando o formato collection.json para metadados.

Oracle para o Banco de Dados SQL do Azure

Nesse cenário, o relatório AWR ou um arquivo do Windows perfmon é consumido para fornecer recomendações opcionais (mas altamente recomendadas) de dimensionamento de carga de trabalho. O usuário que executa a migração conta com o Kit de ferramentas de conversão de esquema de banco de dados para executar uma migração de esquema para preparar o banco de dados de destino.

Oracle para o Banco de Dados do Azure para PostgreSQL

Assim como no Oracle para o Banco de Dados SQL do Azure, nesse cenário, o relatório AWR ou um arquivo do Windows perfmon é consumido para fornecer recomendações opcionais (mas altamente recomendadas) de dimensionamento de carga de trabalho. A biblioteca ora2pg é usada para extrair o esquema e migrar os dados manualmente pelo usuário que executa a migração.

O DMS (Clássico) depende da configuração de rede do cliente. Se a origem da migração usar pontos de extremidade privados, usaremos pontos de extremidade privados, que é a configuração preferencial. Usaremos pontos de extremidade públicos se eles forem a única opção.

O DMS usa o ADF fortemente nos bastidores para agendamento e coordenação da movimentação de dados. Além disso, o IR auto-hospedado não é diferente do que você provavelmente já usa em seus pipelines do ADF. Para obter mais informações sobre problemas de firewall e servidor proxy, consulte Criar e configurar um runtime de integração auto-hospedada.

Todos os dados do cliente são criptografados em repouso. Alguns metadados, incluindo, dentre outros, nomes de servidor lógico e nomes de banco de dados, bem como status de migração e progresso de migração, aparecem em logs de serviço que não são criptografados.

Todos os dados em trânsito são protegidos com criptografia TLS 1.2 por padrão. Os clientes herdados que exigem versões mais antigas do TLS precisam das versões necessárias habilitadas na página do portal do DMS (Clássico). Para o DMS, o computador no qual o Runtime de integração auto-hospedada está instalado pode ser configurado para permitir que as configurações de TLS necessárias acomodem clientes herdados. Para obter mais informações sobre a configuração do TLS para SQL Server, confira KB3135244 – suporte do TLS 1.2 para o Microsoft SQL Server.

Sempre que possível, pontos de extremidade privados são usados. Se pontos de extremidade privados não estiverem disponíveis, os pontos de extremidade públicos serão usados para comunicação entre as camadas de serviço. Independentemente do tipo de ponto de extremidade, todos os recursos são dedicados/com escopo para a instância específica do DMS e protegidos com credenciais exclusivas.

Não damos suporte a Chaves gerenciadas pelo cliente para criptografia de dados em nosso plano de dados ou painel de controle. No entanto, todos os dados do cliente são criptografados em repouso usando chaves gerenciadas pelo serviço. Alguns metadados, incluindo, dentre outros, nomes de servidor lógico e nomes de banco de dados, bem como status e progresso de migração, aparecem em logs de serviço em formato não criptografado.

Todos os dados em trânsito são criptografados com criptografia TLS 1.2 por padrão. A página do portal do DMS (Clássico) permite que versões mais antigas do TLS sejam usadas para clientes herdados. Para o DMS, o computador no qual o Runtime de integração auto-hospedada está instalado pode ser configurado para permitir o gerenciamento das configurações de TLS para acomodar clientes herdados. Para obter mais informações sobre a configuração do TLS para SQL Server, confira KB3135244 – suporte do TLS 1.2 para o Microsoft SQL Server.

Não expomos a capacidade de criptografar dados em nosso painel de controle ou plano de dados com chaves gerenciadas pelo cliente. Todos os dados do cliente são excluídos no momento em que a instância do DMS é excluída, exceto os logs de serviço. Os logs de serviço do DMS são mantidos apenas por 30 dias.

TDE

O DMS dá suporte à migração de CMK (chaves gerenciadas pelo cliente) para o SQL do Azure na TDE (Transparent Database Encryption). Para obter instruções passo a passo para migrar chaves TDE, veja o Tutorial: Migrar bancos de dados habilitados para TDE (versão prévia) para o SQL do Azure no Azure Data Studio.

Criptografia de célula

A criptografia no nível da célula é tratada no nível do esquema. As ferramentas de migração de esquema migram todos os objetos de esquema, incluindo as funções e os procedimentos armazenados necessários para implementar a criptografia no nível da célula.

Always Encrypted

Atualmente, o DMS não dá suporte à migração do Always Encrypted em cenários em que linhas de dados individuais são migradas entre a origem e o destino. As colunas criptografadas por meio do Always Encrypted são migradas conforme o esperado em cenários que usam backup/restauração, como migrar de uma instância existente do SQL Server para a VM SQL do Azure ou a instância gerenciada de SQL do Azure.

Não implementamos nenhum controle de acesso com reconhecimento de localização além do que já está disponível no Azure. Todos os dados associados a uma instância de DMS residem na mesma região que o recurso DMS.

Nossos serviços são usados em vários ambientes com diferentes controles internos e processos de negócios. O DMS move dados de/para qualquer lugar ao qual a conta que ele está usando tem acesso. É responsabilidade do usuário entender as permissões e os controles internos do ambiente em que ele está trabalhando. É especialmente importante garantir que a conta que o DMS está usando para se conectar à origem tenha acesso para ver todos os dados que devem ser migrados da origem.

A injeção de VNET é a ação de adicionar um recurso do Azure que reside no locatário da Microsoft a uma sub-rede em uma VNet no locatário do cliente. Essa abordagem foi feita com o DMS para nos permitir gerenciar a computação em nome do cliente, mantendo o acesso aos recursos do cliente. Como a rede está na assinatura do cliente, a Microsoft não pode gerenciar a VM a não ser para emitir comandos Iniciar, Parar, Excluir ou Implantar. Todas as outras ações de gerenciamento que precisam de acesso à VM exigem uma solicitação e aprovação de suporte iniciadas pelo cliente.

Existem vários pré-requisitos necessários para garantir que o Serviço de Migração de Banco de Dados do Azure funcione sem problemas ao executar migrações de bancos de dados. Alguns dos pré-requisitos se aplicam em todos os cenários (pares de origem e destino) com suporte do serviço, enquanto outros pré-requisitos são exclusivos para um cenário específico.

Os pré-requisitos do Serviço de Migração de Banco de Dados do Azure que são comuns a todos os cenários de migração compatíveis incluem a necessidade de:

• Criar uma Rede Virtual do Microsoft Azure para o Serviço de Migração de Banco de Dados do Azure usando o modelo de implantação do Azure Resource Manager, que fornece conectividade site a site aos servidores de origem locais usando o ExpressRoute ou a VPN.
• Verifique se as regras do grupo de segurança de rede da rede virtual não bloqueiam a porta 443 para ServiceTag de ServiceBus, Storage e AzureMonitor. Para obter mais detalhes sobre a filtragem de tráfego do NSG da rede virtual, confira o artigo Filtrar o tráfego de rede com grupos de segurança de rede.
• Ao usar um dispositivo de firewall na frente de seus bancos de dados de origem, talvez seja necessário adicionar regras de firewall para permitir que o Serviço de Migração de Banco de Dados do Azure acesse os bancos de dados de origem para migração.

Para obter uma lista de todos os pré-requisitos necessários para competir com cenários de migração específicos usando o Serviço de Migração de Banco de Dados do Azure, consulte os tutoriais relacionados na documentação do Serviço de Migração de Banco de Dados do Azure.

Talvez seja necessário adicionar regras de firewall permitindo que o Serviço de Migração de Banco de Dados do Azure acesse o banco de dados de origem para migração. O endereço IP para o serviço é dinâmico, mas se você estiver usando o ExpressRoute esse endereço em particular será atribuído pela sua rede corporativa. A maneira mais fácil de identificar o endereço IP apropriado é pesquisar no mesmo grupo de recursos fornecido para o recurso de Serviço de Migração de Banco de Dados do Azure para localizar a Interface de Rede associada. Normalmente, o nome do recurso de Adaptador de Rede começa com o prefixo de NIC e é seguido por uma sequência exclusiva de caracteres e números, por exemplo "NIC-jj6tnztnmarpsskr82rbndyp". Ao selecionar esse recurso de interface de rede, você pode ver o endereço IP que deve ser incluído na lista de permissões na página do portal do Azure para visão de geral de recursos.

Talvez você precise incluir a origem da porta que o SQL Server está escutando na lista de permissões. Por padrão, é a porta 1433, mas o SQL Server de origem também pode estar configurado para escutar outras portas. Nesse caso, você também precisa incluir as portas na lista de permissões. Você pode determinar a porta que o SQL Server está escutando usando uma consulta de modo de exibição de Gerenciamento Dinâmico:

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

Você também pode determinar a porta que o SQL Server está escutando consultando o log de erros do SQL Server:

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

Embora existam vários tutoriais da Microsoft que podem orientar você durante o processo de configuração de uma rede virtual, a documentação oficial aparece no artigo Rede Virtual do Azure.

Durante uma migração de banco de dados típica e simples, você:

1. Cria um banco de dados de destino.
2. Avaliar o banco de dados de origem.
   • Para migrações homogêneas, avalie seus bancos de dados existentes usando o DMA.
   • Para migrações heterogêneas (de fontes de concorrentes), avalie seus bancos de dados existentes com o SSMA. Você também usa o SSMA para converter objetos de banco de dados e migrar o esquema para a plataforma de destino.
3. Crie uma instância do Serviço de Migração de Banco de Dados do Azure.
4. Cria um projeto de migração especificando os bancos de dados de origem, os bancos de dados de destino e as tabelas para migração.
5. Inicie a carga completa.
6. Escolhe a validação subsequente.
7. Execute uma mudança manual do seu ambiente de produção para o novo banco de dados baseado em nuvem.

Se você tiver problemas para se conectar ao sistema do banco de dados de origem enquanto trabalha na migração, crie uma máquina virtual na mesma sub-rede da rede virtual com a qual você configurou a instância de DMS. Na máquina virtual, você deverá ser capaz de executar um teste de conexão, como usar um arquivo UDL para testar uma conexão com SQL Server ou baixar o Robo 3T para testar conexões do MongoDB. Se o teste de conexão tiver sucesso, você não deverá ter um problema com a conexão com o banco de dados de origem. Se o teste de conexão não for bem-sucedido, contate o administrador da rede.

Se o usuário parar explicitamente o DMS (Serviço de Migração de Banco de Dados do Azure) ou se o serviço ficar inativo por um período de 24 horas, o serviço será interrompido ou ficará em estado de pausa automático. Em cada caso, o serviço ficará indisponível e em status parado. Para retomar as migrações ativas, reinicie o serviço.

Você pode fazer algumas coisas para acelerar a sua migração de banco de dados usando o serviço:

Para DMS(Clássico)-

• Use os vários tipos de preços de uso geral da CPU ao criar sua instância de serviço para permitir que o serviço aproveite as várias vCPUs para paralelização e transferência de dados mais rápida.
• Temporariamente, escale verticalmente a sua instância de destino de banco de dados SQL do Azure para o SKU da camada Premium durante a operação de migração de dados para minimizar a limitação do banco de dados SQL do Azure que pode afetar as atividades de transferência de dados ao usar SKUs de nível inferior.

Para DMS-

• Se você estiver copiando backups do compartilhamento de arquivos local para o armazenamento de blobs do Azure OU durante a execução da migração para o BD SQL do Azure de destino, o DMS usará o nó SHIR como a sua computação. Portanto, certifique-se de monitorar o uso de recursos desse nó SHIR.
• Expanda temporariamente a sua instância de destino do Banco de Dados SQL do Azure para o SKU da camada Premium durante a operação de migração de dados para minimizar a limitação de disco do Banco de Dados SQL do Azure que pode afetar as atividades de transferência de dados ao usar SKUs de nível inferior.
• Para obter informações mais detalhadas, confira o blog.

Próximas etapas

• O que é o Serviço de Migração de Banco de Dados do Azure.