Existem N bancos de dados com estruturas de tabelas idênticas em um sistema multilocatário e multibanco de dados. O desejo é replicar uma tabela (s) desses bancos de dados em uma única tabela maior em um banco de dados OLAP, presumo que possa funcionar.
-Usando replicação transacional-
Recrie o PK para todos os artigos de tabela no editor, incluindo um campo recém-adicionado que identifica o banco de dados.
Defina a opção "Quando o artigo existir" para Não excluir e usar o filtro de linha (que inclui o identificador do banco de dados).
Adicione um filtro de linha para cada tabela usando o identificador exclusivo do banco de dados.
Minha pergunta é, dado o cenário acima, se um novo instantâneo for criado para um editor, os dados obsoletos do assinante seriam removidos e apenas para esse editor? Receio que seja isso que a tabela suspensa e a recriação pretendem resolver :/
Em termos simples, se eu tiver
| Tabela A |
|---|
| ID do banco de dados |
| TableAID |
Se um novo instantâneo para uma publicação chamada Database007 foi reinicializado. Todos os dados da assinatura do Database007 seriam removidos e reidratados para o Database007 ou eu atingiria uma violação de PK.
Também tenho pesquisado o CDC, no entanto, isso não parece suportar um cenário de replicação N-1. Além disso, sinta-se à vontade para descartar quaisquer outras ideias.
Usar uma visualização
Eu tive que resolver exatamente isso antes, e a maneira mais confiável de fazer isso é replicar para tabelas diferentes e, em seguida, criar uma exibição para unir tudo.
dbo.TransactionsparaLocationA.TransactionsouLocA_dbo.Transactions.dbo.Transactionsse tornemdbo.Transactions_LocationA.UNION ALLde todas as tabelas separadas.Alguns cuidados
No plano acima, sugiro que você evite
SELECT *a exibição por todos os motivos usuais. Se uma alteração de esquema for feita para diferentes editores em momentos diferentes, a exibição provavelmente será interrompida desde o momento em que a primeira tabela é alterada até que a tabela final seja alterada. Em vez disso, liste explicitamente as colunas e atualize a exibição apenas quando a alteração do esquema estiver em todos os lugares.As mesmas considerações de mudança de esquema também precisam ser feitas ao replicar em uma única tabela. Embora eu seja esse o caso, é mais provável interromper a replicação do envio, em vez de apenas interromper a visualização.
Replicação muitos-para-um
A maneira como o agente Snapshot funciona é basicamente automatizar o uso do BCP para exportar do editor e importar para o assinante. A opção padrão é truncar e recarregar ao reinicializar uma publicação. Você também pode alterar para usar delete em vez de truncar, mas isso usará uma única
DELETEinstrução não em lote, o que pode causar bloqueio e inchaço do log de transações.Se seus vários editores tiverem PKs sobrepostos, você precisará unificá-los, conforme sugerido. No entanto, isso pode afetar o desempenho - potencialmente um custo significativo. Além das considerações de tamanho de adicionar a coluna a cada PK, se seu PK também for seu índice clusterizado, o unificador também será incluído em cada índice não clusterizado.
Você também precisará garantir que o unificador seja adicionado ao END da definição de PK para não quebrar a SARGability das consultas existentes. No entanto, mesmo se você fizer isso, poderá notar alterações nos planos de consulta que causam regressões de desempenho.
O otimizador de consulta sabe que, se
IDfor uma única coluna PK,ID = @idretornará no máximo uma única linha. As mesmas regras de cardinalidade são usadas durante a otimização de consultas e junções baseadas em conjunto. Assim, você pode começar a ver mudanças nos planos de consulta, onde uma junção 1:1 agora é interpretada como uma junção 1:muitos. Isso pode ser mitigado adicionando um índice exclusivo no "antigo" PK. Você pode até optar por manter o "antigo" PK como um índice clusterizado exclusivo e tornar o "novo" PK um PK não clusterizado.Os vários desafios de adicionar replicação de vários destinos a uma única tabela de assinantes tornam essa solução muito desafiadora. Isso requer mudanças significativas nos bancos de dados do editor. Eu não recomendaria esta opção, exceto no desenvolvimento de campo verde, onde o esquema e o desempenho podem ser levados em consideração desde o início.
Além disso, a inevitável necessidade de capturar novamente um editor significa excluir cuidadosamente apenas as linhas apropriadas do assinante. Usar o particionamento com uma partição por publicador pode ajudar aqui, mas apresenta um conjunto diferente de complicações. IMHO, o pseudo-particionamento é uma solução mais fácil de gerenciar a longo prazo.
A replicação para destinos únicos garante que os editores não precisem de mudanças e testes significativos e alivia a carga de suporte contínuo que estará envolvida em um único destino de replicação 1:muitos