Migração de Banco de Dados On-Premise para Azure SQL (PARTE3)

Olá, espero que você esteja bem! 😉

Dando continuidade à nossa série sobre migração de banco de dados on-premises, hoje vamos falar sobre mais um método!

Se você ainda não leu os dois posts anteriores, corre lá, porque eles são essenciais para entender todo o processo:

Agora, na Parte 3, vamos explorar a migração usando o DMA.

3. DMA (Data Migration Assistant)

Ferramenta da Microsoft usada para:
✅ Avaliar e realizar migrações de banco de dados.
✅ Identificar e corrigir incompatibilidades antes da migração.
✅ Sugerir melhorias de performance e segurança.

Vantagens do método DMA:

✔ Análise de Compatibilidade: O DMA verifica problemas antes da migração, identificando funcionalidades não suportadas e potenciais riscos.
✔ Relatórios Detalhados: Gera relatórios com recomendações para corrigir incompatibilidades e melhorar a performance.
✔ Interface Intuitiva: Fácil de usar, sendo ideal para migrações de pequeno e médio porte.
✔ Custo Zero: O DMA é gratuito!

Desvantagens do DMA:

❌ Tempo de indisponibilidade: O DMA não realiza migração online (com sincronização contínua), o que pode exigir downtime durante o processo.
❌ Não recomendado para bancos muito grandes: Para bases de dados muito grandes, o DMA pode ser lento e impactar o desempenho do ambiente.
❌ Migração em Lote: A transferência ocorre em lotes, podendo levar horas ou até dias, dependendo do tamanho do banco e da latência da rede.

Curiosidades sobre o DMA!

🔹 Avaliação de Consultas Dinâmicas (Ad Hoc)
O DMA consegue analisar consultas dinâmicas (ad hoc) que não estão armazenadas em procedures, functions ou views, ajudando a prever possíveis impactos antes da migração para o Azure SQL Database.

🔹 Coleta de Dados através de Extended Events
Para avaliar queries ad hoc, o DMA pode analisar dados coletados via Extended Events, ajudando a identificar consultas problemáticas.

🔹 O DMA NÃO monitora o ambiente em tempo real
Ele não captura queries automaticamente, apenas avalia dados já coletados. Para monitoramento contínuo, considere usar ferramentas como Azure Monitor, Query Store ou Extended Events no SQL Server.

3.1. Preparação do Ambiente

Verifique a Conectividade: Certifique-se de que o computador onde o DMA está instalado consegue acessar tanto o banco de origem quanto o Azure SQL Database.
Backup Completo: Antes de iniciar a migração, faça um backup completo do banco de dados por segurança.

3.2. Instalação do DMA e Avaliação (Assesment) de Compatibilidade

No meu primeiro post, ensinei essa parte com mais detalhes, inclusive mencionei que ela seria utilizada aqui na Parte 3 (link acima).

Após a análise do relatório e a validação das compatibilidades, seguiremos para o próximo passo.

3.2. Criando o SQL Database no Portal do Azure

Agora, vamos criar o banco de dados no Azure SQL Database, que será o destino da migração.

Acesse https://portal.azure.com.
No menu de pesquisa, digite “SQL databases” e clique na opção correspondente.
Clique em “+ Create” (Criar banco de dados).

Configuração do Servidor:

Server: Selecione um servidor SQL existente ou crie um novo.
Caso opte por criar um novo servidor, defina:
✅ Nome do servidor (exemplo: labmigracao).
✅ Região do servidor.
✅ Login do administrador do SQL Server (exemplo: admindma).
✅ Senha segura.

Resumo:

Escolha as opções que melhor atendam às suas necessidades, considerando fatores como:

✔ Frequência de acesso
✔ Performance requerida
✔ Custo estimado

Essas escolhas impactam diretamente o desempenho e orçamento do seu projeto.

🔹 A collation padrão é SQL_Latin1_General_CP1_CI_AS, mas certifique-se de usar a mesma collation do banco on-premises para evitar problemas de compatibilidade.

🔹 Se seu banco já foi criado no Azure, não precisa criar outro.

🔹 Se precisar de mais bancos no mesmo servidor, pode criá-los diretamente pelo portal.

Vamos anotar essas informações para uso posterior:

Server Name: labmigracao.database.windows.net
Admin: admindma
Senha: ******

Agora, vamos testar a conexão com o banco recém-criado

Erro ao conectar: E agora?

Erro:

Reason: An instance-specific error occurred while establishing a connection to SQL Server. Connection was denied since Deny Public Network Access is set to Yes.
(Microsoft SQL Server, Error: 47073)

O que isso significa?

Por padrão, a opção “Deny Public Network Access” no Azure SQL Database vem configurada como “Yes”, bloqueando conexões públicas externas.

Isso impede conexões via SSMS (SQL Server Management Studio) e outros clientes de fora da rede privada do Azure.

🔹 Como resolver?

Precisamos permitir nossa conexão inserindo o IP no firewall do Azure SQL Database. Vamos corrigir isso!

Tudo certo! Nossa futura base foi criada, porém ainda sem tabelas, como esperado.

Agora vamos para o DMA, criar o projeto de migração.

Opções de “Migration Scope”

Ao configurar o DMA, temos algumas opções para definir o que será migrado:

1️⃣ Schema and Data (Esquema e Dados)

Migra toda a estrutura do banco de dados (tabelas, índices, constraints, procedures, etc.).
Migra todos os dados dentro das tabelas.

2️⃣ Schema only (Apenas Esquema)

Apenas cria as estruturas do banco no Azure SQL Database.
Não migra os dados das tabelas.
Quando usar? Se você precisa configurar o banco antes e migrar os dados separadamente.

3️⃣ Data only (Apenas Dados)

Migra somente os dados, sem recriar a estrutura do banco.
Quando usar? Se o esquema já foi criado anteriormente no Azure SQL Database e você precisa apenas preencher as tabelas.

Para o nosso exemplo vamos usar o “Schema and Data”.

Conectando no Servidor de Origem

Na primeira etapa, conectamos ao servidor on-premises e escolhemos a base a ser migrada.

Passo 2: Conectar ao servidor de destino (Azure SQL Database).

💡 Dica: Neste momento, o DMA permite a criação de um novo Azure SQL Database, mas, no nosso caso, já criamos anteriormente — então basta preencher as informações e prosseguir.

O DMA reconhece o nome da base de destino criada anteriormente, mas há um campo adicional a ser preenchido.

O que isso significa?

Se você estiver migrando um banco de dados on-premises para o Azure SQL Database e deseja que usuários externos do Azure AD continuem acessando após a migração, você pode definir esse usuário aqui.

Esse campo NÃO é obrigatório se você estiver usando SQL Server Authentication (como no nosso caso, onde usamos o usuário “admindma”).

O que fazer aqui?

Se estiver usando autenticação SQL Server Authentication, deixe o campo em branco e continue a migração.

Se precisar configurar usuários do Azure AD no destino, insira o domínio do usuário externo (exemplo: usuario@dominio.com).

Se for necessário migrar logins do Azure AD, pode ignorar essa opção e seguir em frente!

Preparando…

Após carregar, devemos selecionar os objetos a serem migrados — então, marcaremos tudo.

Scripts sendo gerado.

Próxima tela é importante o entendimento para seguir com nossa migração.

O DMA agora gera um script SQL contendo todas as instruções para recriar os objetos no banco de destino.

Este script inclui:
✔ DDL Triggers
✔ Full-Text Catalogs
✔ Schemas
✔ Stored Procedures
✔ Tables
✔ User-Defined Types
✔ Functions
✔ Views

🚨 Importante!

Este script NÃO migra os dados — apenas a estrutura do banco!
O DMA pode aplicar o script automaticamente para criar os objetos no Azure SQL Database, bastando realizar o Deploy.

Executar o Script Manualmente ou Não?

Antes de permitir que o DMA execute o script automaticamente, podemos optar por rodá-lo manualmente.

Por que executar o script manualmente pode ser uma boa ideia?

Revisão: Permite identificar comandos incompatíveis com o Azure SQL Database (ex: USE, FILEGROUPS, LINKED SERVERS).
Correção de Erros: Se ocorrer um erro na execução automática, pode ser difícil depurar. Rodando manualmente, você pode corrigir antes da migração.
Customização: Caso precise ajustar permissões, renomear objetos ou excluir itens desnecessários, é mais fácil modificar antes.

O que fazer?

✔ Se estiver testando em um ambiente de laboratório, pode permitir que o DMA execute o script automaticamente.
✔ Se for uma migração real, recomendo gerar e revisar o script antes de continuar.

Agora, iniciamos o Deploy e seguimos para a migração dos dados!

Terminou.

Vamos conectar no SSMS e conferir as tabelas.

Tudo certo! As tabelas foram criadas, porém ainda estão vazias, como esperado.

Agora, seguimos no DMA e clicamos no botão “Migrate Data”.

Passo 5 em execução.

Escolhemos quais tabelas migrar. Nesta base, temos um total de 71 tabelas.

Apareceu uma mensagem importante:

A Microsoft recomenda aumentar temporariamente o nível de desempenho do Azure SQL Database para P15 durante a migração para melhorar a performance e reduzir o tempo do processo.

O que significa o nível P15?

🔹 P15 pertence ao modelo de preços Premium (DTU-based) do Azure SQL Database.
🔹 Projetado para cargas de trabalho intensas, com alto throughput e baixa latência.
🔹 Possui mais recursos de CPU, memória e IOPS (Entrada/Saída por Segundo).

O que acontece se eu não mudar para P15?

⚠ O processo pode ser mais lento devido a limitações de recursos.
⚠ Se o banco de destino estiver em um plano Básico ou Standard, a transferência de dados pode levar mais tempo.
⚠ Em alguns casos, a migração pode falhar se os recursos forem insuficientes.

O que fazer?

1️⃣ Se sua base for pequena, pode ignorar essa recomendação e seguir com a migração no plano atual.
2️⃣ Se sua base for grande, pode aumentar temporariamente o plano para otimizar a migração e reduzir após a conclusão para evitar custos desnecessários.

Seguimos com a migração…

Terminou! Porém, o resultado foi:
✔ 61 tabelas migradas com sucesso
❌ 10 tabelas apresentaram falhas

Agora, vamos validar!

Validando uma das tabelas migradas.

Os erros na migração podem ter várias causas. Para identificar o motivo exato, você precisa analisar os logs de erro clicando em “Error log” para cada tabela com falha.

Tabela Person

Erro: O Azure SQL Database atingiu o limite de armazenamento (size quota), impedindo a inserção de mais dados na tabela.

A tabela ficou vazia!

Possíveis Causas

⚠ Tamanho máximo do banco de dados atingido

Se escolheu o plano Basic ou Standard com cota pequena, o banco pode ter atingido o limite permitido.

⚠ Falta de espaço devido a índices ou logs de transação

Se há muitos índices ou operações de migração em andamento, o espaço pode ser consumido rapidamente.

Soluções Possíveis

Aumentar o Limite de Armazenamento

Passo a passo para aumentar o tamanho do banco de dados no Azure Portal:

1️⃣ No Azure Portal, vá até o SQL Database

2️⃣ Clique em Configurações > Compute + Storage

3️⃣ Aumente o tamanho máximo permitido (exemplo: de 5GB para 50GB no DTU-Based model).

Se estiver usando DTU-Based (Basic, Standard, Premium) → Ajuste o tamanho permitido.

Se estiver usando vCore-Based (General Purpose, Business Critical) → Aumente o armazenamento alocado.

Conforme a solução indicada, optei propositalmente pelo plano Basic com apenas 100 MB para destacar um ponto importante. Toda migração exige planejamento e atenção para evitar desperdício de tempo e erros que poderiam ser facilmente prevenidos.

Para resolver, vou aumentar um pouco mais o max size.

Mudança realizada com sucesso.

Vamos repetir o processo e para isso vou criar um novo Projeto.

Ótima notícia!

O DMA detectou que já há um projeto em andamento e não foi necessário refazer tudo.

Agora, o DMA reconheceu que algumas tabelas já foram migradas com sucesso e exibiu apenas as 7 tabelas que deram erro para nova tentativa.

Mas algo chamou atenção:

No primeiro erro, 10 tabelas falharam, mas agora apenas 7 estão disponíveis para migração.

Dica Importante: Conferindo Logs de Erros

Sempre abra os logs de erro de cada tabela antes de continuar!

Exemplo: estas três tabelas não aparecem mais para migração.

[Production].[TransactionHistory]
[Production].[TransactionHistoryArchive]
[Sales].[SpecialOffer]

Algumas validações simples a se fazer:
✔ Execute um COUNT(*) no banco on-premise e no Azure SQL Database para comparar os registros.

Motivo possível: O DMA pode ter reconhecido que essas tabelas já foram migradas corretamente e, por isso, não as listou novamente.

Seguimos para a migração das 7 tabelas pendentes!

Validando novamente as propriedades atuais.

✅ Migração concluída com sucesso!

Agora, vamos simular a criação de outro projeto para ver o que acontece.

Mensagem: “Já existe um projeto em andamento. Deseja continuar?”

Optei por não sobrepor o projeto atual.

Resultado esperado:

✔ O DMA reconheceu todas as 71 tabelas migradas.
✔ Nenhuma tabela ficou disponível para nova migração.

Conclusão: O DMA entende que o banco de dados já foi todo migrado com sucesso.

Ao terminar, por curiosidade, fui conferir o espaço usado nas bases e percebi que havia diferenças entre a base local e a migrada no Azure. Isso é esperado?

Sim, é normal que os valores de espaço utilizado sejam diferentes entre o SQL Server on-premises e o Azure SQL Database. As principais razões para essa diferença incluem:

Arquitetura Diferente:
O Azure SQL Database possui uma arquitetura gerenciada distinta do SQL Server on-premises, influenciando a alocação de espaço.
Índices e Estatísticas:
Nem todos os índices ou estatísticas podem ser migrados integralmente, dependendo da configuração do DMA e da compatibilidade no Azure SQL Database.
Tabelas Temporárias e Fragmentação:
Espaços reservados para tabelas temporárias ou fragmentação local não são migrados para o Azure.
Configuração das Páginas e Alocação:
As páginas de dados no Azure SQL Database podem ser gerenciadas de maneira diferente, afetando a utilização do espaço.
Arquivos de Log:
Os logs de transação são tratados de forma diferente no Azure SQL Database, influenciando diretamente no tamanho final da base migrada.

Para validações mais simples, recomenda-se realizar comparações diretas, como:

Contagem de registros (COUNT(*)) em tabelas específicas;
Verificação da integridade dos dados migrados;
Comparação das estruturas das tabelas entre as bases.

Testes e Validações Pós-Migração

Teste da Base no Azure:
Execute consultas para confirmar se os dados foram migrados corretamente.
Verificação da Aplicação:
Caso haja uma aplicação conectada ao banco, realize testes funcionais para garantir seu funcionamento adequado.
Reaplicação de Permissões:
Configure logins e permissões manualmente, pois não são migrados automaticamente.
Testes Funcionais:
Valide todas as funcionalidades nos sistemas que utilizam o banco de dados.

Troca para Ambiente de Produção

Redirecionamento da Conexão:
Ajuste a aplicação para apontar para o novo banco de dados no Azure.
Monitoramento Inicial:
Monitore o desempenho e possíveis incidentes nos primeiros dias após a migração.

Conclusão

A migração com o Data Migration Assistant (DMA) é uma excelente alternativa para migrar bancos de dados do SQL Server on-premises para o Azure SQL Database. A ferramenta facilita a avaliação da compatibilidade, identifica antecipadamente possíveis problemas e reduz riscos durante a migração. Entretanto, assim como em qualquer método de migração, é essencial planejar cuidadosamente para garantir que o resultado atenda aos requisitos técnicos e às regras de negócio.

Mais um POST encerrado. Espero que tenha agregado valor ao seu aprendizado.

E claro, essa série continua, então fique ligado para os próximos conteúdos! 🚀

Aguardem…