FAQ sobre a utilização do Azure Database Migration Service

O Serviço de Migração de Banco de Dados do Azure é um serviço totalmente gerenciado projetado para permitir migrações contínuas de várias fontes de banco de dados para plataformas de Dados do Azure com tempo de inatividade mínimo. O serviço está atualmente em disponibilidade geral, com esforços de desenvolvimento contínuos focados em:

• Fiabilidade e desempenho.
• Adição iterativa de pares origem-destino.
• Continuação do investimento em migrações sem fricções.

Atualmente, o serviço suporta vários pares de origem/destino ou cenários de migração. Para obter uma lista completa do status de cada cenário de migração disponível, consulte o artigo Status dos cenários de migração suportados pelo Serviço de Migração de Banco de Dados do Azure.

Ao migrar do SQL Server, as fontes com suporte para o 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 SQL, as fontes com suporte serão SQL Server 2008 a SQL Server 2022.

Você pode usar o Serviço de Migração de Banco de Dados do Azure para executar migrações offline e online. 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 redução no final da migração. Sugerimos que teste uma migração offline para determinar se o período de inatividade é aceitável; se não for, 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 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 Diferenciando as ferramentas e serviços de migração de banco de dados da Microsoft.

O Azure Migrate auxilia 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 baseado no desempenho e fornece estimativas de custo para executar suas máquinas virtuais locais no Azure. O Azure Migrate é útil para migrações de elevação e deslocamento de cargas de trabalho locais baseadas em VM para VMs IaaS do Azure. No entanto, ao contrário do Serviço de Migração de Banco de Dados do Azure, o Azure Migrate não é uma oferta de serviço de migração de banco de dados especializado para plataformas de banco de dados relacional PaaS do Azure, como o Banco de Dados SQL do Azure ou a Instância Gerenciada SQL do Azure.

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

Para destinos SQL VM do Azure e SQL MI do Azure, o DMS usa 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 SQL VM do Azure e SQL MI 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 o(s) arquivo(s) de backup mais recente da origem tenham sido transferidos para o armazenamento de rede SMB ou para o contêiner de blob 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/restaurado no destino mostrado na página de monitoramento de migração DMS e validar sua respetiva soma de verificação.

• Migração online: durante a migração online para destinos SQL VM do Azure e SQL MI do Azure, o tempo de inatividade começa assim que você inicia a substituição de migração junto com a interrupção do aplicativo. O DMS restaurará todos os arquivos de backup para o destino, desde que o(s) arquivo(s) de backup mais recente da origem tenham sido transferidos para o armazenamento de rede SMB ou para o contêiner de blob 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 blob 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/restaurado no destino mostrado na página de monitoramento de migração DMS e validar sua respetiva soma de verificação.

Para destinos do Banco de Dados SQL do Azure, o DMS faz a migração lógica no caso do Banco de Dados SQL do Azure, ou seja, copia os dados das tabelas do banco de dados SQL de origem e os grava nas tabelas do Banco de Dados SQL do Azure de destino. Como o DMS só dá suporte à migração offline para o Banco de Dados 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 do banco de dados de origem) e copiadas (gravadas na tabela do Banco de Dados SQL do Azure de destino) na página de monitoramento da 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 destino e validar os dados de origem e restauração sendo idênticos.

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

Nota: Desde que nenhum aplicativo esteja gravando no banco de dados de origem ou de 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
• Azure Service Bus
• Azure Data Factory

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 tabelas que podem ser incluídos na telemetria, são colocados em 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 disponível apenas para pessoal autorizado na Microsoft para fins de solução de problemas válidos. Os 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 SQL do Azure e SQL Server em Máquinas Virtuais do Azure

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

Base 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. DMS (Classic) usa o SQL Management Objects (SMO) para migração de esquema. A segunda etapa é a migração de dados real. SqlBulkCopy é usado para executar a migração de dados. O DMS não suporta migração de esquema. Os dados são migrados usando o Azure Data Factory. Opcionalmente, mas altamente recomendado, um arquivo contendo dados de desempenho do Windows pode ser consumido para fornecer recomendações de dimensionamento de carga de trabalho.

Base de Dados do Azure para PostgreSQL

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

Base de Dados do Azure para MySQL

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

MongoDB para 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 dump BSON ou JSON.

Para dumps BSON, o DMS usa os dados em bsondump formato dentro da mesma pasta dentro de um contêiner de blob. DMS só procura arquivos de metadados usando o formato collection.metadata.json.

Para dumps JSON, o DMS lerá os arquivos nas pastas de contêiner de blob nomeadas após os bancos de dados que o contêm. Dentro de cada pasta de banco de dados, o data DMS usa apenas arquivos de dados colocados na subpasta. O DMS examina apenas os metadata ficheiros colocados na subpasta e nomeados utilizando o formato collection.json dos metadados.

Banco de Dados SQL Oracle para 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 usa o Database Schema Conversion Toolkit para executar uma migração de esquema para preparar o banco de dados de destino.

Banco de Dados Oracle para Azure para PostgreSQL

Assim como o 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 ora2pg biblioteca é usada para extrair o esquema e migrar os dados manualmente pelo usuário que executa a migração.

O DMS (Classic) depende da configuração de rede do cliente. Se a fonte de migração usa pontos de extremidade privados, usamos pontos de extremidade privados, que é a configuração preferida. Usamos endpoints públicos se eles forem a única opção.

O DMS usa fortemente o ADF nos bastidores para agendamento e coordenação da movimentação de dados. Além disso, o Self-Hosted Integration Runtime não é diferente daquele que você provavelmente já usa para seus próprios pipelines do ADF. Para obter mais informações sobre problemas de firewall e servidor proxy, consulte Criar e configurar um tempo de execução de integração auto-hospedado.

Todos os dados do cliente são criptografados em repouso. Alguns metadados, incluindo, entre outros, nomes de servidores lógicos e nomes de bancos de dados, bem como o status da migração e o progresso da migração, aparecem em logs de serviço que não estão criptografados.

Todos os dados em trânsito são protegidos com criptografia TLS 1.2 por padrão. Os clientes herdados que requerem versões mais antigas do TLS precisam das versões necessárias habilitadas na página do portal DMS (Clássico). Para DMS, a máquina na qual o Self-Hosted Integration Runtime está instalado pode ser configurada para permitir as configurações TLS necessárias para acomodar clientes herdados. Para obter mais informações sobre a configuração TLS para SQL Server, consulte KB3135244 - Suporte TLS 1.2 para Microsoft SQL Server.

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

Não suportamos Chaves Geridas pelo Cliente para encriptação de dados no nosso plano de dados ou plano de controlo. No entanto, todos os dados do cliente são criptografados em repouso usando chaves gerenciadas pelo serviço. Alguns metadados, incluindo, entre outros, nomes de servidores lógicos e nomes de bancos de dados, bem como o status e o progresso da migração, aparecem nos logs de serviço de forma não criptografada.

Todos os dados em trânsito são criptografados com criptografia TLS 1.2 por padrão. A página do portal DMS (Classic) permite que versões mais antigas do TLS sejam usadas para clientes herdados. Para DMS, a máquina na qual o Self-Hosted Integration Runtime está instalado, pode ser configurada para permitir o gerenciamento de configurações TLS para acomodar clientes herdados. Para obter mais informações sobre a configuração TLS para SQL Server, consulte KB3135244 - Suporte TLS 1.2 para Microsoft SQL Server.

Não expomos a capacidade de criptografar dados em nosso plano de controle ou 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 DMS são mantidos apenas por 30 dias.

Encriptação de Dados Transparente

O DMS dá suporte à migração de chaves gerenciadas pelo cliente (CMK) para o SQL do Azure para TDE (criptografia transparente de banco de dados). Para obter instruções passo a passo para migrar suas chaves TDE, consulte Tutorial: Migrar bancos de dados habilitados para TDE (visualização) para o SQL do Azure no Azure Data Studio.

Encriptação de células

A criptografia no nível da célula é manipulada 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 oferece suporte à migração do Always Encrypted por meio de 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 mover para a VM SQL do Azure ou para a instância gerenciada do SQL do Azure a partir de uma instância existente do SQL Server.

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

Os nossos serviços são utilizados em vários ambientes com diferentes controlos internos e processos de negócio. O DMS move dados de e para qualquer lugar que a conta que está usando tenha acesso. É responsabilidade do usuário entender as permissões e os controles internos do ambiente em que está trabalhando. É especialmente importante garantir que a conta que o DMS está usando para se conectar à fonte tenha acesso para ver todos os dados que se destinam a ser migrados da fonte.

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 sob o locatário do cliente. Essa abordagem foi adotada 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 além de emitir comandos Iniciar, Parar, Excluir ou Implantar. Todas as outras ações de gerenciamento que precisam de acesso à VM exigem uma solicitação de suporte iniciada pelo cliente e aprovação.

Há vários pré-requisitos necessários para garantir que o Serviço de Migração de Banco de Dados do Azure seja executado sem problemas ao executar migrações de banco de dados. Alguns dos pré-requisitos aplicam-se a todos os cenários (pares origem-destino) suportados pelo serviço, enquanto outros são exclusivos de um cenário específico.

Os pré-requisitos do Azure Database Migration Service comuns em todos os cenários de migração suportados incluem a necessidade de:

• Criar uma Rede Virtual do Microsoft Azure para o Azure Database Migration Service com o modelo de implementação Azure Resource Manager, que proporciona conectividade site a site aos seus servidores de origem no local através do ExpressRoute ou de uma VPN.
• Certifique-se de que as regras do Grupo de Segurança de Rede da rede virtual não bloqueiem a porta 443 para ServiceTags do ServiceBus, Storage e AzureMonitor. Para obter mais detalhes sobre a filtragem de tráfego do NSG da rede virtual, veja o artigo Filtrar o tráfego de rede com grupos de segurança de rede.
• Quando utilizar uma aplicação de firewall à frente da base de dados de origem, poderá ter de adicionar regras de firewall para permitir que o Azure Database Migration Service aceda à base 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 que permitam que o Serviço de Migração de Banco de Dados do Azure acesse seu banco de dados de origem para migração. O endereço IP do serviço é dinâmico, mas se você estiver usando a Rota Expressa, esse endereço será atribuído de forma privada pela sua rede corporativa. A maneira mais fácil de identificar o endereço IP apropriado é procurar no mesmo grupo de recursos que seu recurso provisionado do Serviço de Migração de Banco de Dados do Azure para localizar a Interface de Rede associada. Normalmente, o nome do recurso Interface de Rede começa com o prefixo NIC e é seguido por um caractere exclusivo e uma sequência numérica, por exemplo, 'NIC-jj6tnztnmarpsskr82rbndyp''. Ao selecionar este recurso de interface de rede, você pode ver o endereço IP que precisa ser incluído na lista de permissões na página de visão geral do recurso do portal do Azure.

Também pode ser necessário incluir a fonte de 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 ser configurado para escutar em outras portas. Nesse caso, você também precisa incluir essas portas na lista de permissões. Você pode determinar a porta na qual o SQL Server está escutando usando uma consulta do 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

Enquanto vários tutoriais da Microsoft que podem orientá-lo através do 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 simples e típica, você:

1. Crie um banco de dados de destino.
2. Avalie o(s) seu(s) banco(s) de dados(s) de origem.
   • Para migrações homogêneas, avalie o(s) banco(s) de dados existente(s) usando DMA.
   • Para migrações heterogêneas (de fontes concorrentes), avalie o(s) seu(s) banco(s) de dados existente(s) com o SSMA. Você também usa o SSMA para converter objetos de banco de dados e migrar o esquema para sua plataforma de destino.
3. Crie uma instância do Azure Database Migration Service.
4. Crie um projeto de migração especificando o(s) banco(s) de dados de origem, o(s) banco(s) de dados de destino e as tabelas a serem migradas.
5. Inicie a carga completa.
6. Escolha a validação subsequente.
7. Execute uma transição 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 de 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 sua instância DMS. Na máquina virtual, você deve ser capaz de executar um teste de conexão, como usar um arquivo UDL para testar uma conexão com o SQL Server ou baixar o Robo 3T para testar conexões do MongoDB. Se o teste de ligação for bem-sucedido, não deverá ter problemas com a ligação à base de dados de origem. Se o teste de ligação não for bem-sucedido, contacte o administrador de rede.

Se o usuário parar explicitamente o Serviço de Migração de Banco de Dados do Azure (DMS) ou se o serviço estiver inativo por 24 horas, o serviço estará em um estado interrompido ou pausado automaticamente. Em cada caso, o serviço está indisponível e em um status interrompido. Para retomar as migrações ativas, reinicie o serviço.

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

Para DMS (Clássico)-

• Utilize o Escalão de Preço Fins Gerais multi CPU quando criar a instância de serviço para permitir que o serviço tire partido de várias vCPUs para paralelização e transferência de dados mais rápida.
• Aumente temporariamente a instância de destino do Banco de Dados SQL do Azure para a SKU de 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 ao executar a migração para o Banco de Dados SQL do Azure de destino, o DMS usará o nó SHIR como sua computação. Portanto, certifique-se de monitorar o uso de recursos desse nó DIR.
• Aumente temporariamente a instância de destino do Banco de Dados SQL do Azure para a SKU de 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, consulte o blog.

Próximos passos

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