UPDATE-instructies kunnen worden gerepliceerd als DELETE/INSERT-paren

In dit artikel wordt beschreven dat Update-instructies kunnen worden gerepliceerd als DELETE/INSERT-paren.

Originele productversie: SQL Server
Oorspronkelijk KB-nummer: 238254

Samenvatting

Als een kolom die deel uitmaakt van een unieke beperking wordt bijgewerkt, implementeert SQL Server de update als een 'uitgestelde update', wat betekent als een paar DELETE/INSERT bewerkingen. Deze 'uitgestelde update' zorgt ervoor dat replicatie een paar DELETE/INSERT instructies naar de abonnees verzendt. Er zijn ook andere situaties die een uitgestelde update kunnen veroorzaken. Daarom moet elke bedrijfslogica die u implementeert in uw UPDATE triggers of aangepaste opgeslagen procedures bij de abonnee, ook worden opgenomen in de DELETE/INSERT triggers of aangepaste opgeslagen procedures.

Meer informatie

Het standaardgedrag in transactionele replicatie is het gebruik van de INSERTopgeslagen UPDATEprocedures en DELETE aangepaste opgeslagen procedures om wijzigingen toe te passen bij de abonnees.

INSERT instructies die bij Publisher worden gedaan, worden toegepast op abonnees via een INSERT opgeslagen procedureaanroep. Op dezelfde manier wordt een DELETE instructie toegepast via een DELETE opgeslagen procedure-aanroep.

Wanneer een UPDATE instructie echter wordt uitgevoerd als een 'uitgestelde update', plaatst de logboeklezeragent een paar opgeslagen procedureaanroepen in de distributiedatabase die moet worden toegepast op de abonnees in plaats van DELETE/INSERT een opgeslagen procedureaanroep bijwerken. Stel dat u een publicatietabel hebt met de naam , met de volgende TABLE1drie kolommen:

• col1 int
• col2 int
• col3 varchar(30)

De enige unieke beperking TABLE1 is gedefinieerd col1 via een primaire-sleutelbeperking. Stel dat u één record hebt (1,1,'Dallas').

Wanneer u deze code uitvoert:

UPDATE TABLE1 set col1 = 3 where col3 = 'Dallas'

De UPDATE instructie wordt door SQL Server geïmplementeerd als een paarINSERTDELETE/instructies sinds u bijwerktcol1, waarvoor een unieke index is gedefinieerd. De logboeklezer plaatst dus een paar DELETE/INSERT aanroepen in de distributiedatabase. Dit kan van invloed zijn op elke bedrijfslogica die aanwezig is in de triggers of aangepaste opgeslagen procedures bij de abonnee. U moet de aanvullende bedrijfslogica opnemen in DELETE en INSERT triggers of opgeslagen procedures opnemen om deze situatie af te handelen.

Als u liever updates van één rij repliceert als UPDATE instructies in plaats van DELETE parenINSERT, kunt u Trace Flag 8207 inschakelen.

Als u bovendien een horizontaal filter in uw publicatie gebruikt en als de bijgewerkte rij niet voldoet aan een filtervoorwaarde, wordt alleen een DELETE procedureaanroep naar de abonnees verzonden. Als de bijgewerkte rij eerder niet aan de filtervoorwaarde voldoet, maar voldoet aan de voorwaarde na de update, wordt alleen de INSERT procedureaanroep verzonden via het replicatieproces.

In het voorgaande voorbeeld wordt ervan uitgegaan dat u ook een horizontaal filter hebt gedefinieerd op TABLE1: where col3 = 'Dallas'. Als u deze code uitvoert:

UPDATE table1 set col3 = 'New York' where col1 = 3

De logboeklezeragent plaatst alleen een DELETE opgeslagen procedureoproep die moet worden toegepast op de abonnees, omdat de bijgewerkte rij niet voldoet aan de horizontale filtercriteria.

Als u deze code nu uitvoert:

UPDATE table1 set col3 = 'Dallas' where col1 = 3

De logboeklezer genereert alleen de INSERT opgeslagen procedureaanroep, omdat de rij niet eerder aan de filtervoorwaarde voldoet.

Hoewel er een UPDATE bewerking is uitgevoerd bij Publisher, worden alleen de juiste opdrachten toegepast op de abonnee.