Aparentemente, a resposta é:"Ao definir o artigo, você terá que definir o
@vertical_partition parâmetro para true e, em seguida, adicione as colunas que você deseja com sp_articlecolumn ." No entanto, eu tenho que perguntar por que você está fazendo isso. Replicação em minha mente não é uma ferramenta geral para mover dados entre bancos de dados diferentes, mas para manter dois bancos de dados idênticos em sincronia.
Outras ideias de brainstorming:
- Você pode criar uma nova tabela de origem que corresponda à tabela de destino e usar um gatilho para manter a tabela de origem sincronizada.
- Envie a tabela de origem intacta para o destino e faça o MERGE no banco de dados de destino.
- A replicação pode não ser a solução certa aqui. Quais são as regras e requisitos de negócios que exigem que isso seja feito? Você já pensou em usar o SSIS?
- Se for necessário que as duas tabelas estejam em sincronização exata o tempo todo, qual é o canal de alterações na tabela de origem - um aplicativo? Quase parece que seu aplicativo precisa de um novo nível de abstração, uma camada de gravação de dados que saiba como gravar em duas fontes ao mesmo tempo.
Tentar manter os dados sincronizados entre dois bancos de dados diferentes pode ser um problema. Pode haver todos os tipos de problemas sutis com condições de corrida, falta de transações distribuídas (afetando consistência e resposta a falhas), problemas com as soluções alternativas criadas para lidar com a falta de transações distribuídas e assim por diante. Em vez disso, você pode criar um servidor vinculado e algumas visualizações que realmente tornem os dados em um banco de dados acessados em tempo real do outro?
Por favor, conte-nos mais sobre suas necessidades e por que você precisa fazer isso.
Atualizar
Se você estiver seguindo a rota de atualização manual, observe que não pode aplicar as operações de inserção, atualização e exclusão de um período de tempo em massa. Você precisa aplicá-los um de cada vez, em ordem . Se você estiver trabalhando com estado atual em vez de operações de dados intermediárias, você pode fazer todas as linhas de uma vez. Vou mostrar o exemplo de MERGE, não o de reprodução de histórico.
BEGIN TRAN;
DELETE D
FROM LinkedServer.dbo.Dest D WITH (TABLOCKX, HOLDLOCK)
WHERE
NOT EXISTS (
SELECT *
FROM Source S
WHERE D.Key = S.Key
);
UPDATE D
SET
D.Col1 = S.Col4,
D.Col2 = S.Col5,
D.Col3 = S.Col6,
D.Col4 = S.Col7,
FROM
LinkedServer.dbo.Dest D
INNER JOIN Source S ON D.Key = S.Key
WHERE
D.Col1 <> S.Col4
OR EXISTS (
SELECT D.Col2, D.Col4
EXCEPT
SELECT S.Col3, S.Col6
); -- or some other way to handle comparison of nullable columns
INSERT LinkedServer.dbo.Dest (Col1, Col2, Col3)
SELECT Col4, Col5, Col6
FROM Source S WITH (TABLOCK, HOLDLOCK)
WHERE
NOT EXISTS (
SELECT *
FROM LinkedServer.dbo.Dest D
WHERE S.Key = D.Key
);
COMMIT TRAN;
Você pode achar melhor enviar toda a tabela e fazer a operação de mesclagem no servidor de destino.
As dicas de bloqueio que coloquei na primeira consulta são importantes se você quiser ter um instantâneo consistente de um ponto no tempo. Se você não se importa com isso, tire as dicas de bloqueio.
Se você achar que as atualizações no servidor vinculado estão lentas, envie a tabela inteira de uma só vez para uma tabela de preparação temporária no servidor remoto e faça o MERGE em um script inteiramente no servidor remoto.
