replicatie tussen twee tabellen met verschillende namen en die verschillende kolomnamen hebben. Is het mogelijk om zo'n replicatie te maken?

Blijkbaar is het antwoord:"Als je het artikel definieert, moet je de @vertical_partition parameter op true en voeg vervolgens de gewenste kolommen toe met sp_articlecolumn ."

Ik moet echter vragen waarom je dit doet. Replicatie is naar mijn mening geen algemeen hulpmiddel om gegevens tussen verschillende databases te verplaatsen, maar om twee identieke databases gesynchroniseerd te houden.

Andere brainstormideeën:

• Je zou een nieuwe brontabel kunnen maken die wel overeenkomt met de doeltabel, en een trigger gebruiken om de brontabel gesynchroniseerd te houden.
• Duw de brontabel intact naar de bestemming en doe de MERGE in de doeldatabase.
• Replicatie is hier misschien niet echt de juiste oplossing. Wat zijn de bedrijfsregels en vereisten die dit vereisen? Heb je overwogen om SSIS te gebruiken?
• Als er een noodzaak is dat de twee tabellen altijd exact gesynchroniseerd zijn, wat is dan het kanaal voor wijzigingen in de brontabel - een toepassing? Het klinkt bijna alsof uw toepassing een nieuw abstractieniveau nodig heeft, een gegevensschrijflaag die weet hoe naar twee bronnen tegelijk te schrijven.

Het kan een probleem zijn om gegevens tussen twee verschillende databases gesynchroniseerd te houden. Er kunnen allerlei subtiele problemen zijn met race-omstandigheden, gebrek aan gedistribueerde transacties (die de consistentie en reactie op fouten beïnvloeden), problemen met de tijdelijke oplossingen die zijn gecreëerd om het niet hebben van gedistribueerde transacties aan te pakken, enzovoort, enzovoort. Kun je in plaats daarvan een gekoppelde server en enkele weergaven maken die ervoor zorgen dat de gegevens in de ene database realtime toegankelijk zijn vanuit de andere?

Vertel ons meer over uw vereisten en waarom u dit moet doen.

Bijwerken

Als je de handmatige updateroute volgt, houd er dan rekening mee dat je de invoeg-, update- en verwijderbewerkingen van een tijdsperiode niet massaal kunt toepassen. Je moet ze een voor een toepassen, in volgorde . Als u in plaats daarvan werkt met huidige staat in plaats van tussentijdse gegevensbewerkingen, dan kunt u alle rijen tegelijk uitvoeren. Ik zal je het MERGE-voorbeeld laten zien, niet het geschiedenis-afspelen.

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;

Misschien vindt u het beter om de hele tabel te pushen en de samenvoegbewerking op de doelserver uit te voeren.

De vergrendelingshints die ik bij de eerste vraag heb ingevoerd, zijn belangrijk als u een consistente momentopname wilt hebben. Als je daar niet om geeft, verwijder dan de vergrendelingstips.

Als u merkt dat updates op de gekoppelde server traag zijn, duw dan de hele tabel in één stuk naar een tijdelijke staging-tabel op de externe server en voer de SAMENVOEGEN in een script volledig op de externe server uit.