Tydligen är svaret:"När du definierar artikeln måste du ställa in @vertical_partition
parametern till true och lägg sedan till de kolumner du vill ha med sp_articlecolumn
."
Men jag måste fråga varför du gör det här. Replikering i mitt sinne är inte ett allmänt verktyg för att flytta runt data mellan olika databaser utan för att hålla två identiska databaser synkroniserade.
Andra brainstormidéer:
- Du kan skapa en ny källtabell som matchar måltabellen och använda en utlösare för att hålla källtabellen synkroniserad.
- Skjut källtabellen intakt till destinationen och gör MERGE i destinationsdatabasen.
- Replikering kanske inte riktigt är den rätta lösningen här. Vilka är de affärsregler och krav som kräver att detta ska göras? Har du funderat på att använda SSIS?
- Om det FINNS ett behov av att de två tabellerna är i exakt synkronisering hela tiden, vad är då kanalen för ändringar av källtabellen - ett program? Det låter nästan som att din applikation behöver en ny abstraktionsnivå, ett dataskrivlager som vet hur man skriver till två källor samtidigt.
Att försöka hålla data synkroniserad mellan två olika databaser kan vara ett problem. Det kan finnas alla möjliga subtila problem med rasförhållanden, brist på distribuerade transaktioner (som påverkar konsekvens och svar på misslyckanden), problem med de lösningar som skapats för att hantera att inte ha distribuerade transaktioner, och så vidare och så vidare. Kan du istället skapa en länkad server och några vyer som faktiskt gör att data i den ena databasen nås i realtid från den andra?
Berätta mer om dina krav och varför du behöver göra detta.
Uppdatera
Om du går vägen för manuell uppdatering, observera att du inte kan tillämpa en tidsperiods åtgärder för att infoga, uppdatera och radera en masse. Du måste tillämpa dem en i taget, i ordning . Om du istället arbetar med nuvarande tillstånd istället för mellanliggande dataoperationer kan du göra alla rader samtidigt. Jag kommer att visa dig MERGE-exemplet, inte historikuppspelningsexemplet.
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;
Du kanske tycker att det är bättre att trycka på hela tabellen och göra sammanslagningen på destinationsservern.
Låstipsen jag satte i den första frågan är viktiga om du ska ha en konsekvent ögonblicksbild. Om du inte bryr dig om det, ta då bort låstipsen.
Om du upptäcker att uppdateringar över den länkade servern är långsamma, skjut sedan hela tabellen i ett stycke till en temporär uppsättningstabell på fjärrservern och gör MERGE i ett skript helt på fjärrservern.