"Quanto tempo a produção vai ficar parada?" é a pergunta que todo plano de migração precisa responder. A resposta depende menos da velocidade da cópia e mais do padrão escolhido para manter o banco antigo e o novo próximos enquanto o negócio continua gravando.
Esta nota aprofunda o passo 3 do nosso guia de estratégia de migração de dados.
Os quatro padrões
| Padrão | Parada final | Serve quando | Cuidado com |
|---|---|---|---|
| Offline | Cópia inteira + validação | Um fim de semana planejado comporta o volume | A janela cresce com os dados |
| Em fases | Uma fatia por vez | Clientes, entidades ou serviços mudam separados | Roteamento e convivência |
| Carga inicial + atualização agendada | Última atualização + validação | Chaves estáveis e um jeito confiável de achar o que mudou | Exclusões, commits atrasados, duração do job |
| CDC por log | Segundos a minutos | Captura contínua é exigência | Ferramenta, permissões e operação dedicadas |
O dbSlice atende os três primeiros. Faz cargas iniciais e jobs de sincronização repetíveis (upsert, só novos e incremental). Não é CDC por log. Se a exigência é captura contínua, use uma ferramenta de CDC nessa parte e deixe o dbSlice para cargas, conferência e checagens.
A atualização agendada vai alcançar?
Carga inicial + atualização é o meio-termo mais comum: copia-se tudo uma vez com a produção rodando e depois rodam jobs incrementais curtos que pegam o que mudou, até o último caber numa pausa breve de gravação.
Funciona quando cada execução termina bem antes da próxima e as mudanças por execução diminuem. Um teste rápido no ensaio:
- Cronometre a carga inicial (digamos, 9 horas).
- Rode a primeira atualização logo depois e cronometre (digamos, 25 minutos para 9 horas de mudanças).
- Rode de novo (digamos, 3 minutos para 25 minutos de mudanças).
Se as execuções encolhem assim, a parada final é mais ou menos parar as gravações + uma última atualização curta + validação. Se uma atualização leva quase o mesmo tempo do período que ela cobre, ela nunca fecha a diferença: divida o escopo, leve as tabelas mais pesadas numa fase própria ou considere CDC para elas.
Tempos ilustrativos; meça os seus.
Achar o que mudou: as armadilhas da marca d'água
A execução incremental precisa de uma coluna que diga o que mudou: um updated_at ou uma chave que só cresce. Duas armadilhas causam a maioria dos casos de "linhas faltando":
- Commit atrasado. Uma transação que começou antes da última execução faz commit depois, com um horário que você
já passou. Reler uma pequena janela para trás pega esse caso. No dbSlice o filtro incremental usa >= no último valor, e a versão baixada de dbslice.net (2.3.20261030.1730 em diante) traz uma janela de releitura para exatamente isso.
- Alteração sem novo horário. Um trigger, um script em massa ou um default errado grava linhas sem mexer no
updated_at. Nenhuma marca d'água enxerga; a comparação chave a chave enxerga.
Detalhamos as duas em Incremental sync missing rows? (em inglês).
Exclusões pedem uma decisão
O upsert insere e atualiza; não remove linhas apagadas na origem. Escolha uma opção e escreva no runbook:
- Exclusão lógica (tombstone) na origem, sincronizada como qualquer alteração.
- Conferência periódica: compare chave a chave e trate o que "sobra no destino" como candidato a remoção, com
alguém responsável aprovando.
- Recarga final das tabelas pequenas ou voláteis na janela da virada.
A escolha, numa página
- O negócio aguenta parar as gravações durante a cópia inteira? → Offline. A fronteira de consistência mais simples.
- Dá para mudar por cliente, entidade ou serviço? → Em fases.
- As atualizações encolhem no ensaio, e existe política de exclusão? → Carga inicial + atualização agendada.
- O negócio precisa de segundos de atraso, sem parar? → CDC nessas tabelas.
Seja qual for a escolha, prove no ensaio: meça a carga inicial, as atualizações e a validação com dados representativos e dimensione a parada pelo que mediu.
Para levar
- O padrão decide a parada mais do que a velocidade da cópia.
- A atualização agendada precisa convergir; confira com execuções cronometradas no ensaio.
- Marca d'água perde commits atrasados e alterações silenciosas: releia uma janela e compare chave a chave.
- Exclusão é decisão, não efeito colateral.
Meça o seu ensaio: o guia de SQL Server para PostgreSQL mostra os modos de sincronização. A versão gratuita do dbSlice está na Microsoft Store; gravar num banco de destino exige licença Desktop ou Server.
Vai trocar de sistema e precisa de ajuda para desenhar a convivência dos dados? A Thinwork conduz o projeto com você.
