Apparemment, la réponse est :"Lorsque vous définissez l'article, vous devez définir le @vertical_partition paramètre à true, puis ajoutez les colonnes souhaitées avec sp_articlecolumn ."
Cependant, je dois vous demander pourquoi vous faites cela. Dans mon esprit, la réplication n'est pas un outil général pour déplacer des données entre des bases de données différentes, mais pour maintenir la synchronisation de deux bases de données identiques.
Autres idées de remue-méninges :
- Vous pouvez créer une nouvelle table source qui correspond à la table de destination et utiliser un déclencheur pour maintenir la table source synchronisée.
- Poussez la table source intacte vers la destination et effectuez la MERGE dans la base de données de destination.
- La réplication n'est peut-être pas vraiment la bonne solution, ici. Quelles sont les règles et exigences commerciales qui exigent que cela soit fait ? Avez-vous envisagé d'utiliser SSIS ?
- S'il est nécessaire que les deux tables soient parfaitement synchronisées en permanence, quel est le canal de modification de la table source :une application ? On dirait presque que votre application a besoin d'un nouveau niveau d'abstraction, une couche d'écriture de données qui sait comment écrire sur deux sources en même temps.
Essayer de garder les données synchronisées entre deux bases de données différentes peut être un problème. Il peut y avoir toutes sortes de problèmes subtils avec les conditions de concurrence, le manque de transactions distribuées (affectant la cohérence et la réponse aux échecs), les problèmes avec les solutions de contournement créées pour gérer l'absence de transactions distribuées, etc. Pouvez-vous plutôt créer un serveur lié et des vues qui rendent les données d'une base de données accessibles en temps réel à partir de l'autre ?
Veuillez nous en dire plus sur vos besoins et pourquoi vous devez le faire.
Mettre à jour
Si vous optez pour la mise à jour manuelle, notez que vous ne pouvez pas appliquer en masse les opérations d'insertion, de mise à jour et de suppression d'une période. Vous devez les appliquer une par une, dans l'ordre . Si vous travaillez plutôt avec l'état actuel plutôt que des opérations de données intermédiaires, vous pouvez effectuer toutes les lignes à la fois. Je vais vous montrer l'exemple MERGE, pas celui de la lecture de l'historique.
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;
Vous trouverez peut-être préférable de pousser toute la table et d'effectuer l'opération de fusion sur le serveur de destination.
Les indices de verrouillage que j'ai mis dans la première requête sont importants si vous voulez avoir un instantané cohérent à un moment donné. Si cela ne vous intéresse pas, supprimez les indices de verrouillage.
Si vous constatez que les mises à jour sur le serveur lié sont lentes, poussez la table entière en un seul morceau vers une table intermédiaire temporaire sur le serveur distant, et effectuez la MERGE dans un script entièrement sur le serveur distant.
