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.

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.

Azure Migrate auxilia na migração de máquinas virtuais on-premises 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 Azure Database Migration Service, o Azure Migrate não é uma oferta de serviço de migração de banco de dados especializada para as plataformas de banco de dados relacional PaaS do Azure, como o Azure SQL Database ou o Azure SQL Managed Instance.

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

Para o SQL Server na VM do Azure e destinos de Instância Gerenciada de SQL do Azure, o DMS usa migração física, ou seja, backup e restauração. Conforme descrito na seção a seguir, 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 Server em VM do Azure e Instância Gerenciada de SQL do Azure, o tempo de inatividade do aplicativo começa quando a migração é iniciada. O DMS restaura todos os arquivos de backup para o destino, desde que os arquivos de backup/s 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 checksum, a integridade do backup é verificada de forma explícita 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 nome do último arquivo de backup da origem, com o arquivo de backup aplicado/restaurado no destino mostrado na página de monitoramento de migração do DMS e validar suas respectivas somas de verificação.

• Migração online: durante a migração online para destinos SQL Server no Azure VM e Instância Gerenciada de SQL do Azure, o tempo de inatividade começa assim que você inicia a migração e interrompe o aplicativo. O DMS restaura todos os arquivos de backup para o destino, desde que os arquivos de backup/s 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 transição, o DMS mostra a contagem de arquivo(s) de backup pendente(s) (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 ou restaurados no alvo. 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 nome do último arquivo de backup da origem, com o arquivo de backup aplicado/restaurado no destino mostrado na página de monitoramento de migração do DMS e validar suas respectivas somas de verificação.

Para destinos do Banco de Dados SQL do Azure, o DMS realiza 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 dá suporte apenas à migração offline para o Banco de Dados SQL do Azure, o tempo de inatividade do aplicativo é iniciado 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 banco de dados SQL do Azure de destino) da página de monitoramento de migração. Como confirmação adicional, você pode executar o seguinte Transact-SQL para obter a soma de verificação nos bancos de dados de origem e de destino e verificar se os dados de origem e os de restauração são idênticos.

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

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
• 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 poderiam ser incluídos na telemetria, têm aplicação de 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 processamento. Os tópicos do Azure Service Bus 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 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 dump 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 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 endereços de endpoints 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 Integration Runtime 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 legados que necessitam de versões mais antigas do TLS precisam das versões necessárias habilitadas na página do portal clássico do DMS. Para o DMS, o computador no qual o Integration Runtime auto-hospedado 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, consulte o 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 endpoint, todos os recursos são dedicados e delimitados 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 DMS (clássico) permite que versões mais antigas do TLS sejam usadas para clientes legados. Para o DMS, o computador no qual o Integration Runtime auto-hospedado 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, consulte o 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 6 meses.

TDE

O DMS dá suporte à migração de CMK (chaves gerenciadas pelo cliente) para o SQL do Azure na TDE (Transparent Database Encryption).

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.

Sempre Criptografado

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 de backup/restauração, como ao mover de uma instância existente do SQL Server para o SQL Server em uma VM do Azure ou uma Instância Gerenciada do Azure SQL.

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 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 se destinam a serem migrados da origem.

A injeção de rede virtual é a ação de adicionar um recurso do Azure que reside dentro do locatário da Microsoft a uma sub-rede em uma rede virtual 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 ServiceTags 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 dos bancos de dados de origem, talvez você precise 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 seu 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 interface de rede começa com o prefixo NIC e seguido por um caractere exclusivo e sequência de 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ê também 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 ser configurado para escutar em 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. Crie bancos de dados de destino.
2. Avalie seus bancos de dados de origem com SSMA. O SSMA também pode converter objetos de banco de dados e migrar o esquema para sua plataforma de destino.
3. Crie uma instância do Serviço de Migração de Banco de Dados do Azure.
4. Crie um projeto de migração especificando os bancos de dados de origem, os bancos de dados de destino e as tabelas a serem migradas.
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.
• Aumente temporariamente a escala da sua instância de destino do Banco de Dados SQL do Azure para o SKU do nível 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 de um compartilhamento de arquivos local para o Armazenamento de Blobs do Azure ou fazendo a migração para um banco de dados SQL do Azure de destino, o DMS usará o nó SHIR como seu computador. Portanto, certifique-se de monitorar o uso de recursos desse nó SHIR.
• Expanda temporariamente sua instância de destino do Banco de Dados SQL do Azure para a 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, consulte Como melhorar o desempenho da migração do Banco de Dados SQL – Serviço de Migração de Banco de Dados do Azure.

Conteúdo relacionado

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