Transaktionsartiklar – Ange hur ändringar sprids

gäller för:SQL ServerAzure SQL Managed Instance

Med transaktionsreplikering kan du ange hur dataändringar sprids från utgivaren till prenumeranter. För varje publicerad tabell kan du ange ett av fyra sätt som varje åtgärd (INSERT, UPDATE eller DELETE) ska spridas till prenumeranten:

• Ange att transaktionsreplikering ska skrivas ut och därefter anropa en lagrad procedur för att sprida ändringar till Prenumeranter (standard).

• Ange att ändringen ska spridas med instruktionen INSERT, UPDATE eller DELETE (standardinställningen för icke-SQL Server-prenumeranter).

• Ange att en anpassad lagrad procedur ska användas.

• Ange att den här åtgärden inte ska utföras hos någon prenumerant. Transaktioner av den typen replikeras inte.

Som standard sprider transaktionsreplikering ändringar till Prenumeranter via en uppsättning lagrade procedurer som installeras på varje prenumerant. När en infogning, uppdatering eller borttagning sker i en tabell i Publisher översätts åtgärden till ett anrop till en lagrad procedur hos Prenumeranten. Den lagrade proceduren accepterar parametrar som mappar till kolumnerna i tabellen, vilket gör att dessa kolumner kan ändras i Prenumeranten.

Information om hur du anger spridningsmetoden för dataändringar till transaktionsartiklar finns i Ange spridningsmetod för dataändringar till transaktionsartiklar.

Standard- och anpassade lagrade procedurer

De tre procedurer som replikering skapar som standard för varje tabellartikel är:

• sp_MSins_<tabellnamn>, som hanterar infogningar.

• sp_MSupd_<tablename>, som hanterar uppdateringar.

• sp_MSdel_<tablename>, som hanterar borttagningar.

Det <tabellnamn> som används i proceduren beror på hur artikel lades till i publikationen och om prenumerationsdatabasen innehåller en tabell med samma namn men med en annan ägare.

Alla dessa procedurer kan ersättas med en anpassad procedur som du anger när du lägger till en artikel i en publikation. Anpassade procedurer används om ett program kräver anpassad logik, till exempel att infoga data i en granskningstabell när en rad uppdateras hos en prenumerant. Mer information om hur du anger anpassade lagrade procedurer finns i avsnitten ovan.

Om du anger standardreplikeringsprocedurer eller anpassade procedurer anger du även anropssyntax för varje procedur (replikering väljer standardvärden om du använder standardprocedurerna). Anropssyntaxen avgör strukturen för de parametrar som anges i proceduren och hur mycket information som skickas till prenumeranten med varje dataändring. Mer information finns i avsnittet "Anropa syntax för lagrade procedurer" i det här avsnittet.

Överväganden för att använda anpassade lagrade procedurer

Tänk på följande när du använder anpassade lagrade procedurer:

• Du måste ha stöd för logiken i den lagrade proceduren. Microsoft tillhandahåller inte stöd för anpassad logik.

• För att undvika konflikter med de transaktioner som används av replikering bör explicita transaktioner inte användas i anpassade procedurer.

• Schemat på Prenumeranten är vanligtvis identiskt med schemat i Publisher, men kan också vara en delmängd av Publisher-schemat om kolumnfiltrering används. Men om du behöver transformera schemat när data flyttas så att schemat på Prenumeranten inte är en delmängd av schemat i Publisher, är SQL Server 2019 Integration Services (SSIS) den rekommenderade lösningen. Mer information finns i SQL Server Integration Services.

• Om du gör schemaändringar i en publicerad tabell måste de anpassade procedurerna återskapas. Mer information finns i återskapa anpassade transaktionsprocedurer för att återspegla schemaändringar.

• Om du använder ett värde som är större än 1 för -SubscriptionStreams parametern för distributionsagenten måste du se till att uppdateringar av primärnyckelkolumner lyckas. Till exempel:

  update ... set pk = 2 where pk = 1 -- update 1  
  update ... set pk = 3 where pk = 2 -- update 2  
  

  Om distributionsagenten använder mer än en anslutning kan dessa två uppdateringar replikeras via olika anslutningar. Om uppdatering 1 tillämpas först är det inga problem. Om uppdatering 2 tillämpas först returnerar den "0 rader som påverkas" eftersom uppdatering 1 ännu inte har inträffat. Den här situationen hanteras i standardprocedurerna genom att skapa ett fel om inga rader påverkas vid en uppdatering:

  if @@rowcount = 0  
      if @@microsoftversion>0x07320000  
          exec sys.sp_MSreplraiserror 20598  
  

  Uppkomsten av felet tvingar distributionsagenten att försöka uppdatera igen över en enda anslutning, vilket lyckas. Anpassade lagrade procedurer måste innehålla liknande logik.

Anropssyntax för lagrade procedurer

Det finns fem alternativ för syntaxen som används för att anropa de procedurer som används av transaktionsreplikering:

• CALL-syntaxen. Kan användas för infogningar, uppdateringar och borttagningar. Som standard använder replikeringen den här syntaxen för infogningar och borttagningar.

• SCALL-syntax. Kan endast användas för uppdateringar. Som standard använder replikering den här syntaxen för uppdateringar.

• MCALL-syntax. Kan endast användas för uppdateringar.

• XCALL-syntax. Kan användas för uppdateringar och borttagningar.

• VCALL. Används för uppdaterbara prenumerationer. Endast intern användning.

Varje metod skiljer sig åt i mängden data som sprids till prenumeranten. SCALL skickar till exempel endast värden för de kolumner som faktiskt påverkas av en uppdatering. XCALL kräver däremot alla kolumner (oavsett om de påverkas av en uppdatering eller inte) och alla gamla datavärden för varje kolumn. I många fall är SCALL lämpligt för uppdateringar, men om programmet kräver alla datavärden under en uppdatering tillåter XCALL detta.

Anropssyntax

INSÄTT lagrade procedurer
Lagrade procedurer som hanterar INSERT-instruktioner får de infogade värdena för alla kolumner.

c1, c2, c3,... cn  

UPPDATERA lagrade procedurer
Lagrade procedurer som hanterar UPDATE-instruktioner skickas de uppdaterade värdena för alla kolumner som definieras i artikeln, följt av de ursprungliga värdena för primärnyckelkolumnerna (inga försök görs att avgöra vilka kolumner som har ändrats.):

c1, c2, c3,... cn, pkc1, pkc2, pkc3,... pkcn  

TA BORT lagrade procedurer
Lagrade procedurer som hanterar DELETE-instruktioner kommer att tilldelas värden för primärnyckelkolumnerna.

pkc1, pkc2, pkc3,... pkcn  

SCALL-syntax

UPPDATERA lagrade procedurer
Lagrade procedurer som hanterar UPDATE-instruktioner skickas endast de uppdaterade värdena för de kolumner som har ändrats, följt av de ursprungliga värdena för primärnyckelkolumnerna, följt av en bitmask (binary(n)) parameter som anger de ändrade kolumnerna. I följande exempel har kolumn 2 (c2) inte ändrats:

c1, , c3,... cn, pkc1, pkc2, pkc3,... pkcn, bitmask  

MCALL-syntax

UPPDATERA lagrade procedurer
Lagrade procedurer som hanterar UPDATE-instruktioner skickas de uppdaterade värdena för alla kolumner som definieras i artikeln, följt av de ursprungliga värdena för primärnyckelkolumnerna, följt av en bitmask (binary(n)) parameter som anger de ändrade kolumnerna:

c1, c2, c3,... cn, pkc1, pkc2, pkc3,... pkcn, bitmask  

XCALL-syntax

UPPDATERA lagrade procedurer i databasen
Lagrade procedurer som hanterar UPDATE-instruktioner får de ursprungliga värdena (förebild) för alla kolumner som definierats i artikeln, följt av de uppdaterade värdena (efterbild) för alla kolumner som definierats i artikeln.

old-c1, old-c2, old-c3,... old-cn, c1, c2, c3,... cn,  

TA BORT lagrade procedurer
Lagrade procedurer som hanterar DELETE-instruktioner skickas originalvärdena (före bilden) för alla kolumner som definierats i artikeln:

old-c1, old-c2, old-c3,... old-cn  

Not

När du använder XCALL förväntas före-bildvärdena för text och bild kolumner vara NULL.

Exempel

Följande procedurer är standardprocedurerna som skapats för Vendor Table i Adventure Works-exempeldatabasen.

--INSERT procedure using CALL syntax  
create procedure [sp_MSins_PurchasingVendor]   
  @c1 int,@c2 nvarchar(15),@c3 nvarchar(50),@c4 tinyint,@c5 bit,@c6 bit,@c7 nvarchar(1024),@c8 datetime  
as   
begin   
insert into [Purchasing].[Vendor]([VendorID]  
,[AccountNumber]  
,[Name]  
,[CreditRating]  
,[PreferredVendorStatus]  
,[ActiveFlag]  
,[PurchasingWebServiceURL]  
,[ModifiedDate])  
values (   
 @c1  
,@c2  
,@c3  
,@c4  
,@c5  
,@c6  
,@c7  
,@c8  
 )   
end  
go  
  
--UPDATE procedure using SCALL syntax  
create procedure [sp_MSupd_PurchasingVendor]   
 @c1 int = null,@c2 nvarchar(15) = null,@c3 nvarchar(50) = null,@c4 tinyint = null,@c5 bit = null,@c6 bit = null,@c7 nvarchar(1024) = null,@c8 datetime = null,@pkc1 int  
,@bitmap binary(2)  
as  
begin  
update [Purchasing].[Vendor] set   
 [AccountNumber] = case substring(@bitmap,1,1) & 2 when 2 then @c2 else [AccountNumber] end  
,[Name] = case substring(@bitmap,1,1) & 4 when 4 then @c3 else [Name] end  
,[CreditRating] = case substring(@bitmap,1,1) & 8 when 8 then @c4 else [CreditRating] end  
,[PreferredVendorStatus] = case substring(@bitmap,1,1) & 16 when 16 then @c5 else [PreferredVendorStatus] end  
,[ActiveFlag] = case substring(@bitmap,1,1) & 32 when 32 then @c6 else [ActiveFlag] end  
,[PurchasingWebServiceURL] = case substring(@bitmap,1,1) & 64 when 64 then @c7 else [PurchasingWebServiceURL] end  
,[ModifiedDate] = case substring(@bitmap,1,1) & 128 when 128 then @c8 else [ModifiedDate] end  
where [VendorID] = @pkc1  
if @@rowcount = 0  
    if @@microsoftversion>0x07320000  
        exec sp_MSreplraiserror 20598  
end  
go  
  
--DELETE procedure using CALL syntax  
create procedure [sp_MSdel_PurchasingVendor]   
  @pkc1 int  
as   
begin   
delete [Purchasing].[Vendor]  
where [VendorID] = @pkc1  
if @@rowcount = 0  
    if @@microsoftversion>0x07320000  
        exec sp_MSreplraiserror 20598  
end   
go  

Relaterat innehåll

• artikelalternativ för transaktionsreplikering