replikering mellem to tabeller med forskellige navne og som har forskellige kolonnenavne. Er det muligt at oprette en sådan replikation

Tilsyneladende er svaret:"Når du definerer artiklen, bliver du nødt til at indstille @vertical_partition parameter til sand, og tilføj derefter de kolonner, du ønsker med sp_articlecolumn ."

Men jeg er nødt til at spørge, hvorfor du gør dette. Replikering i mit sind er ikke et generelt værktøj til at flytte data rundt mellem i modsætning til databaser, men til at holde to identiske databaser synkroniseret.

Andre brainstorm ideer:

• Du kan oprette en ny kildetabel, der matcher destinationstabellen, og bruge en trigger til at holde kildetabellen synkroniseret.
• Skub kildetabellen intakt til destinationen, og lav FLÉNING i destinationsdatabasen.
• Replikering er måske ikke rigtig den rigtige løsning her. Hvad er de forretningsregler og -krav, der kræver, at dette skal gøres? Har du overvejet at bruge SSIS?
• Hvis der ER et behov for, at de to tabeller er i nøjagtig synkronisering hele tiden, hvad er så kanalen for ændringer af kildetabellen - et program? Det lyder næsten som om din applikation har brug for et nyt abstraktionsniveau, et dataskrivelag, der ved, hvordan man skriver til to kilder på samme tid.

At forsøge at holde data synkroniseret mellem to forskellige databaser kan være et problem. Der kan være alle mulige subtile problemer med raceforhold, mangel på distribuerede transaktioner (påvirker konsistens og respons på fejl), problemer med de løsninger, der er skabt for at håndtere ikke at have distribuerede transaktioner, og så videre og så videre. Kan du i stedet oprette en linket server og nogle visninger, der faktisk gør dataene i den ene database tilgået i realtid fra den anden?

Fortæl os venligst mere om dine krav, og hvorfor du skal gøre dette.

Opdater

Hvis du går den manuelle opdateringsrute, bemærk, at du ikke kan anvende en tidsperiodes indsættelses-, opdaterings- og sletningshandlinger i massevis. Du skal anvende dem én ad gangen i rækkefølge . Hvis du i stedet arbejder med aktuel tilstand i stedet for mellemliggende dataoperationer, så kan du udføre alle rækker på én gang. Jeg vil vise dig MERGE-eksemplet, ikke historie-afspilningseksemplet.

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 kan finde det bedre at skubbe hele tabellen og udføre fletteoperationen på destinationsserveren.

De låsetips, jeg satte i den første forespørgsel, er vigtige, hvis du skal have et konsistent øjebliksbillede. Hvis du er ligeglad med det, så tag låsetipsene ud.

Hvis du opdager, at opdateringer på tværs af den linkede server er langsomme, så skub hele tabellen i ét stykke til en midlertidig iscenesættelsestabel på fjernserveren, og lav FLÉNING i et script helt på fjernserveren.