Geralmente, há a necessidade de sincronizar dados de tabelas mestras em um banco de dados para clonar tabelas em outros bancos de dados, geralmente em outros servidores. Por exemplo, considere o caso em que um sistema back end gerencia os dados do inventário e que os dados do inventário devem, por fim, ser enviados para um ou mais bancos de dados que fazem parte de um aplicativo de site.

Os dados de origem no sistema backend são altamente normalizados, com dezenas de tabelas e restrições de chave estrangeira. É um sistema OLDB RDBMS bem projetado. Muitas das tabelas em questão contêm milhões de linhas. A necessidade é empurrar esses dados para os outros bancos de dados regularmente. Tão freqüentemente quanto possível; latência pode ser tolerada. Acima de tudo, o tempo de atividade máximo dos bancos de dados back-end e remotos é imperativo.

Estou usando o SQL Server e estou familiarizado com o controle de alterações, a conversão de linha, os gatilhos e assim por diante. Eu sei que a Microsoft sobrecarrega a replicação, SyncFx e SSIS para esses cenários. No entanto, há uma grande diferença entre white papers de fornecedores e visões gerais que recomendam tecnologias e a implementação, implantação e manutenção reais da solução. No mundo do SQL Server, a replicação é geralmente vista como a solução pronta para uso, mas estou tentando explorar soluções alternativas. (Há algum receio de que a replicação seja difícil de administrar, torna difícil alterar o esquema e, no caso de uma reinicialização ser necessária, haverá um grande tempo de inatividade para os sistemas críticos.)

Existem muitas dicas. Devido aos complexos relacionamentos de chaves estrangeiras entre grandes números de tabelas, determinar qual ordem realizar captura ou aplicar atualizações não é trivial. Devido a índices exclusivos, duas linhas podem ser interligadas de forma que a atualização de linha por vez nem funcionará (é necessário executar atualizações intermediárias em cada linha antes da atualização final). Estes não são necessariamente “show-stoppers”, uma vez que os índices únicos podem frequentemente ser alterados para índices regulares e as chaves estrangeiras podem ser desabilitadas (embora a desabilitação das chaves estrangeiras seja extremamente indesejável). Muitas vezes, você ouvirá "apenas" usar o rastreamento de alterações do SQL 2008 e o SSIS ou SyncFx. Esses tipos de respostas realmente não fazem justiça às dificuldades práticas. (E, é claro, os clientes realmente têm dificuldade em entender como copiar dados pode ser tão difícil, tornando a situação difícil ainda pior!)

Em última análise, esse problema é muito genérico: executar a sincronização unidirecional de muitas tabelas de banco de dados altamente relacionadas com várias linhas. Quase todos os envolvidos em bancos de dados precisam lidar com esse tipo de problema. Os whitepapers são comuns, a perícia prática é difícil de encontrar. Sabemos que isso pode ser uma questão difícil, mas o trabalho deve ser feito. Vamos ouvir sobre o que funcionou para você (e o que evitar). Conte sua experiência com produtos ou produtos da Microsoft de outros fornecedores. Mas se você pessoalmente não testou a solução com um grande número de tabelas e linhas fortemente relacionadas, por favor, evite responder. Vamos manter isso prático - não teórico.