Em resumo
- A origem é lida em páginas por chave: muitas consultas curtas em vez de uma longa.
- Acesso de leitura na origem e acesso de gravação no destino bastam.
- Por padrão, nada é criado em nenhum dos dois bancos: nem tabelas, nem triggers, nem objetos temporários.
- Execuções interrompidas retomam do último ponto de controle.
- Depois da execução, o Record Diff mostra quais chaves ainda faltam.
1. Por que uma consulta grande prejudica um sistema em uso
O jeito mais simples de copiar uma tabela é SELECT * FROM big_table e ir lendo o resultado. Num sistema em uso, essa consulta fica aberta durante toda a cópia: minutos ou horas de um cursor aberto, recursos presos e, conforme o nível de isolamento, locks que outras sessões precisam esperar. Se ela falha em 90%, recomeça do zero.
2. Paginação por chave: muitas leituras curtas
O dbSlice lê a origem página a página, ordenada por uma coluna-chave:
SELECT ... FROM orders WHERE order_id > @last_key ORDER BY order_id -- one pageCada página é uma consulta curta que termina e libera o que usou. A página seguinte começa depois da última chave lida. Nada fica aberto entre as páginas; então a origem continua atendendo os usuários enquanto a cópia roda.
Escolha bem a chave. Use uma coluna única e indexada — normalmente a chave primária. Uma chave única e indexada mantém cada página barata e deixa a ordem estável. Para chaves de várias colunas, o dbSlice tem um modo de ordenação por chave composta, porque alguns bancos ordenam o ORDER BY de um jeito diferente de como comparam com >.
3. Peça menos ao seu DBA
| Do que o dbSlice precisa | Origem | Destino |
|---|---|---|
| Permissão | Ler a tabela ou a view | Inserir/atualizar linhas na tabela de destino |
| Objetos criados | Nenhum | Nenhum, por padrão |
Se a tabela de destino ainda não existe, o dbSlice para antes de gravar e mostra o script CREATE TABLE traduzido do esquema da origem, para o seu DBA revisar e rodar. Alguns modos de gravação mais rápidos usam uma tabela temporária; eles vêm desligados por padrão e você só os liga se o seu DBA permitir.
4. Escolha o modo para o trabalho
| Modo | O que faz no destino | Uso típico |
|---|---|---|
| Initial load | Insere numa tabela vazia | Primeira cópia |
| Insert new | Insere as chaves que faltam; as linhas existentes não são tocadas | Pôr em dia uma tabela que quase só recebe inclusões |
| Upsert | Insere as chaves novas e atualiza as linhas alteradas | Manter uma cópia em dia |
| Update only | Atualiza as linhas que já existem | Atualizar valores sem acrescentar linhas |
| Full reload | Esvazia a tabela de destino e carrega de novo | Tabelas de referência pequenas |
Execuções incrementais. Aponte o job para uma coluna que só cresce, como updated_at ou uma versão de linha. Cada execução lembra o maior valor lido, e a seguinte só lê as linhas acima dele. Junto com o Upsert, uma atualização noturna lê o que mudou em vez da tabela inteira. Exclusões na origem não são detectadas por uma execução incremental: agende uma comparação periódica ou uma recarga completa se linhas forem excluídas.
5. Antes da primeira gravação
- Confira os selos de ambiente. As conexões são marcadas como DEV, QAS, UAT ou PROD, cada uma com a sua cor, e o dbSlice avisa antes de uma execução que cruza ambientes — por exemplo, dados de produção indo para um destino de teste.
- Mascare o que não deve sair da produção. Colunas sensíveis podem ser ofuscadas durante a cópia, com chaves e chaves estrangeiras preservadas, e você pode ver o resultado numa linha de amostra.
- Comece pequeno. Rode a primeira sincronia contra um destino que não seja de produção, ou com um filtro WHERE numa fatia da tabela, e compare o resultado antes da execução completa.
6. Durante a execução
Leitura e gravação se sobrepõem: enquanto uma página é gravada no destino, a seguinte já está sendo lida da origem; então o lado mais lento dita o ritmo. Onde o banco de destino tem um caminho nativo de carga em massa — SqlBulkCopy no SQL Server, COPY binário no PostgreSQL nas cargas iniciais —, o dbSlice o usa.
O painel de status mostra a hora de início, o tempo decorrido, o fim estimado e os contadores de linhas. O Cancel para a execução num ponto seguro; o trabalho parcial fica registrado no histórico.
7. Quando a execução é interrompida
As linhas são gravadas página a página. Se a rede cai, o destino reinicia ou você cancela, a execução retoma do último ponto de controle em vez de recomeçar, e falhas passageiras são repetidas. No modo Upsert, uma página gravada de novo atualiza as mesmas chaves em vez de duplicá-las.
8. Confira com o Record Diff
Depois da execução, o Record Diff compara as chaves dos dois lados e informa, por tabela, quantas linhas cada lado tem e quais chaves faltam. O relatório lista a tabela, a chave, os dois lados, quando cada lista foi lida e as chaves divergentes prontas para colar numa cláusula IN (...) e olhar de perto.
9. Transforme em job agendado
Salve a execução como job e rode pela linha de comando ou pelo Agendador de Tarefas do Windows. Os jobs podem mandar um e-mail ou chamar um webhook quando terminam com sucesso ou falha; assim a sincronia noturna avisa quem está de plantão.
Velocidade, com as condições
Uma execução medida: 31,4 milhões de linhas no Azure SQL em cerca de 30 minutos (≈17.200 linhas/s), no modo initial load, a partir de uma origem SQLite num disco local, pelo app desktop (dbSlice 2.3, setembro de 2026, antes de otimizações posteriores). Nessa execução, a leitura da origem foi o gargalo; as gravações no Azure se sobrepuseram a ela.
A vazão depende de volume, rede, bancos, largura das linhas e transformações. Os seus números vão variar — teste nos seus próprios dados antes de planejar uma janela.
O que o dbSlice não faz
- Não é replicação em tempo real nem captura de mudanças. As execuções são jobs, sob demanda ou agendados, no intervalo que você escolher.
- Não sincroniza nos dois sentidos. Cada job copia num sentido, da origem para o destino.
- Move dados, não código. Procedures, triggers e views não são convertidos.
Funciona com
SQL Server, PostgreSQL, Oracle, MySQL, MariaDB, Firebird, SQLite e InterSystems Caché/IRIS, em qualquer par, e MongoDB, Cassandra, Elasticsearch, Couchbase ou Redis como destino. Veja também Sincronizar SQL Server com PostgreSQL e Mova os dados certos e mascare antes de chegarem.
Teste
A versão gratuita da Microsoft Store conecta nos seus bancos, mostra os dados, compara estruturas e exporta para CSV, sem chave de licença. Sincronizar grava no destino e exige uma licença Desktop ou Server (perpétua, com garantia de reembolso de 14 dias).