Anscheinend lautet die Antwort:"Wenn Sie den Artikel definieren, müssen Sie den @vertical_partition setzen Parameter auf true und fügen Sie dann die gewünschten Spalten mit sp_articlecolumn hinzu ."
Allerdings muss ich fragen, warum du das machst. Replikation ist meiner Meinung nach kein allgemeines Werkzeug, um Daten zwischen unterschiedlichen Datenbanken zu verschieben, sondern um zwei identische Datenbanken synchron zu halten.
Weitere Brainstorming-Ideen:
- Sie könnten eine neue Quelltabelle erstellen, die mit der Zieltabelle übereinstimmt, und einen Trigger verwenden, um die Quelltabelle synchron zu halten.
- Schieben Sie die Quelltabelle intakt an das Ziel und führen Sie das MERGE in der Zieldatenbank durch.
- Replikation ist hier vielleicht nicht wirklich die richtige Lösung. Welche Geschäftsregeln und Anforderungen erfordern dies? Haben Sie die Verwendung von SSIS in Erwägung gezogen?
- Wenn es erforderlich ist, dass die beiden Tabellen die ganze Zeit exakt synchronisiert sind, was ist dann der Kanal für Änderungen an der Quelltabelle – eine Anwendung? Es klingt fast so, als ob Ihre Anwendung eine neue Abstraktionsebene benötigt, eine Datenschreibebene, die gleichzeitig in zwei Quellen schreiben kann.
Der Versuch, Daten zwischen zwei verschiedenen Datenbanken zu synchronisieren, kann ein Problem darstellen. Es kann alle möglichen subtilen Probleme mit Race-Bedingungen geben, fehlende verteilte Transaktionen (die sich auf die Konsistenz und Reaktion auf Fehler auswirken), Probleme mit den Problemumgehungen, die erstellt wurden, um mit nicht verteilten Transaktionen fertig zu werden, und so weiter und so weiter. Können Sie stattdessen einen Verbindungsserver und einige Ansichten erstellen, die den Echtzeitzugriff auf die Daten in einer Datenbank von der anderen ermöglichen?
Bitte erzählen Sie uns mehr über Ihre Anforderungen und warum Sie dies tun müssen.
Aktualisieren
Wenn Sie sich für die manuelle Aktualisierung entscheiden, beachten Sie, dass Sie die Einfüge-, Aktualisierungs- und Löschvorgänge eines Zeitraums nicht massenhaft anwenden können. Sie müssen sie einzeln der Reihe nach anwenden . Wenn Sie stattdessen mit dem aktuellen Stand arbeiten Anstelle von Zwischendatenoperationen können Sie alle Zeilen auf einmal ausführen. Ich zeige Ihnen das MERGE-Beispiel, nicht das History-Playback-Beispiel.
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;
Möglicherweise finden Sie es besser, die gesamte Tabelle zu verschieben und die Zusammenführungsoperation auf dem Zielserver durchzuführen.
Die Sperrhinweise, die ich bei der ersten Abfrage eingefügt habe, sind wichtig, wenn Sie einen konsistenten Point-in-Time-Snapshot haben möchten. Wenn dir das egal ist, dann nimm die Sperrhinweise raus.
Wenn Sie feststellen, dass Aktualisierungen auf dem Verbindungsserver langsam sind, verschieben Sie die gesamte Tabelle in einem Stück in eine temporäre Staging-Tabelle auf dem Remote-Server und führen Sie das MERGE in einem Skript vollständig auf dem Remote-Server durch.
