Uppdaterbara prenumerationer – För transaktionell replikering

Gäller för:SQL Server

Transaktionsreplikering stöder uppdateringar hos prenumeranter via uppdaterbara prenumerationer och peer-to-peer-replikering. Följande är de två typerna av uppdaterbara prenumerationer:

• Omedelbar uppdatering. Utgivaren och prenumeranten måste vara anslutna för att uppdatera data hos prenumeranten.

• Köad uppdatering Utgivaren och prenumeranten behöver inte vara anslutna för att data ska kunna uppdateras hos prenumeranten. Du kan uppdatera data medan prenumeranten eller Publisher är offline.

När du uppdaterar data hos en prenumerant går uppdateringen först till Publisher och sedan till andra prenumeranter. Om du använder omedelbar uppdatering sker förändringarna omedelbart genom att använda tvåfas-commit-protokollet. Om du använder köad uppdatering hamnar ändringarna i en kö. De köade transaktionerna går asynkront till Publisher när nätverksanslutning är tillgänglig. Eftersom uppdateringarna går till Publisher asynkront kan samma data uppdateras av Publisher eller av en annan Subscriber och konflikter kan uppstå vid tillämpning av uppdateringarna. Systemet upptäcker och löser konflikter enligt en konfliktlösningspolicy som du sätter när du skapar publikationen.

Om du skapar en transaktionspublikation med uppdateringsbara prenumerationer i guiden Ny publikation aktiveras både omedelbar uppdatering och köuppdatering. Om du skapar en publikation med lagrade procedurer kan du aktivera ett eller båda alternativen. När du skapar en prenumeration på publikationen anger du vilket uppdateringsläge som ska användas. Du kan sedan växla mellan uppdateringslägen om det behövs. Mer information finns i följande avsnitt "Växla mellan uppdateringslägen".

För att aktivera uppdaterbara prenumerationer för transaktionspublikationer, se Aktivera uppdatering av prenumerationer för transaktionspublikationer.

För att skapa uppdaterbara prenumerationer för transaktionspublikationer, se Skapa en uppdaterbar prenumeration på en transaktionspublikation (Management Studio).

Byter mellan uppdateringslägen

När du använder updatablerbara prenumerationer kan du ange ett uppdateringsläge för en prenumeration och byta till det andra läget om applikationen kräver det. Till exempel kan du specificera att en prenumeration ska använda omedelbar uppdatering, men byta till köad uppdatering om ett systemfel leder till förlust av nätverksanslutning.

Om du växlar från omedelbar uppdatering till köad uppdatering kan du inte växla tillbaka till omedelbar uppdatering förrän prenumeranten och utgivaren har anslutits och Queue Reader Agent har tillämpat alla väntande meddelanden i kön på utgivaren.

Växla mellan uppdateringslägen

För att växla mellan uppdateringslägen, aktivera publikation och prenumeration för båda uppdateringslägena, och byt sedan mellan dem vid behov. Mer information finns i
Växla mellan uppdateringslägen för en uppdateringsbar transaktionsprenumeration.

Överväganden för att använda uppdaterbara prenumerationer

• Efter att du aktiverat en publikation för att uppdatera prenumerationer eller köat uppdaterade prenumerationer kan du inte inaktivera alternativet för publikationen (även om prenumerationer inte behöver använda det). För att inaktivera alternativet, radera publikationen och skapa en ny.

• Att publicera data igen stöds inte.

• Replikering lägger till kolumnen msrepl_tran_version i publicerade tabeller i spårningssyfte. På grund av denna extra kolumn, inkludera en kolumnlista i alla INSERT påståenden.

• För att göra schemaändringar i en tabell i en publikation som stödjer uppdatering av prenumerationer, stoppa all aktivitet i tabellen vid Publisher och Subscribers, och sprid väntande dataändringar till alla noder innan några schemaändringar göras. Denna process säkerställer att utestående transaktioner inte krockar med den väntande schemaändringen. Efter att schemaändringarna sprids till alla noder kan aktiviteten återupptas på de publicerade tabellerna. Mer information finns i Quiesce a Replication Topology (Replication Transact-SQL Programming).

• För att byta mellan uppdateringslägen måste Queue Reader Agent köras minst en gång efter att prenumerationen initierats (som standard körs Queue Reader Agent kontinuerligt).

• Om Subscriber-databasen är horisontellt partitionerad och det finns rader i partitionen som finns hos Subscriber men inte hos Publisher, kan Subscriber inte uppdatera de redan existerande raderna. Om du försöker uppdatera dessa rader returneras ett fel. Ta bort raderna från tabellen och lägg sedan till dem i Publisher.

• Transaktionell replikering med köade, uppdateringsbara prenumeranter kan ge försämrad prestanda när unika filtrerade index används. Om en konflikt uppstår på en artikel som har unika filtrerade index, medför konfliktlösningen extra borttagningar och infogningar på prenumeranten för de rader som inte omfattas av de unika filtrerade indexen.

Uppdateringar hos prenumeranten

• Uppdateringar hos Subscriber sprids till Publisher även om en prenumeration har gått ut eller är inaktiv. Se till att du avbryter eller ominitierar sådana prenumerationer.

• Om du använder TIMESTAMP eller IDENTITY kolumner och replikerar dem som deras basdatatyper, uppdatera inte värden i dessa kolumner hos Prenumeranten.

• Prenumeranter kan inte uppdatera eller infoga text-, ntext- eller bildvärden eftersom replikationsändringsspårningstriggers inte kan läsa från de insatta eller borttagna tabellerna. På samma sätt kan prenumeranter inte uppdatera eller infoga text- eller bildvärden genom att använda WRITETEXT eller UPDATETEXT eftersom Publisher skriver över datan. Istället kan du dela upp text - och bildkolumnerna i en separat tabell och ändra båda tabellerna inom en transaktion.

  För att uppdatera stora objekt hos en prenumerant, använd datatyperna varchar(max),nvarchar(max) och varbinary(max) istället för text-, ntext- och bilddatatyper , respektive.

• Uppdateringar av unika nycklar (inklusive primärnycklar) som genererar dubbletter, såsom en uppdatering av formuläret UPDATE <column> SET <column> =<column>+1, är inte tillåtna och avvisas på grund av ett unikhetsbrott. Uppsättningsbaserade uppdateringar som görs hos prenumeranten sprids via replikering som enskilda UPDATE-satser för varje rad som påverkas.

• Om Subscriber-databasen är partitionerad horisontellt och partitionen innehåller rader som finns hos Subscriber men inte hos Publisher, kan Subscriber inte uppdatera de redan existerande raderna. Om du försöker uppdatera dessa rader returneras ett fel. Ta bort och lägg in dessa rader igen.

Användardefinierade utlösare

• Om applikationen kräver utlösare på Subscriber definierar du utlösarna med alternativet NOT FOR REPLICATION på Publisher och Subscriber. Detta alternativ säkerställer att utlösare endast aktiveras för den ursprungliga dataändringen, men inte när replikering vidareför ändringen.

  Se till att den användardefinierade triggern inte aktiveras när replikationstriggern uppdaterar tabellen. Anropa proceduren sp_check_for_sync_trigger i den användardefinierade triggerns brödtext. Mer information finns i sp_check_for_sync_trigger (Transact-SQL).

Omedelbar uppdatering

• För omedelbar uppdatering av prenumerationer sprids ändringar på Subscriber till Publisher och tillämpas via Microsoft Distributed Transaction Coordinator (MS DTC). Kontrollera att MS DTC har installerats och konfigurerats i Publisher och Subscriber. Mer information finns i Windows-dokumentationen.

• De triggers som omedelbara uppdateringar av prenumerationer använder kräver en anslutning till Publisher för att replikera ändringar.

• Om publikationen tillåter omedelbar uppdatering av prenumerationer och en artikel i publikationen har ett kolumnfilter, kan du inte filtrera bort icke-nullbara kolumner utan standardinställningar.

Köad uppdatering

• Du kan inte publicera tabeller som ingår i en sammanslagningspublikation som en del av en transaktionell publikation som tillåter köad uppdatering av prenumerationer.

• Uppdatera inte primärnyckelkolumner när du använder köade uppdateringar, eftersom primärnyckeln fungerar som en identifierare för poster i alla frågor. När konfliktlösningspolicyn är inställd till att prenumeranten vinner, var försiktig när du uppdaterar primärnycklar. Om både Publisher och Subscriber uppdaterar primärnyckeln blir resultatet två rader med olika primärnycklar.

• För kolumner av datatyp SQL_VARIANT: när data infogas eller uppdateras hos prenumeranten, mappar Queue Reader Agent den på följande sätt när den kopierar data från prenumeranten till kön:

  • BIGINT, DECIMAL, NUMERIC, MONEY och SMALLMONEY motsvarar NUMERIC.

  • BINARY och VARBINARY mappas till data av typen VARBINARY.

Konfliktupptäckt och lösning

• För Subscriber Wins-konfliktpolicyn: konfliktlösning stöder inte uppdateringar av primärnyckelkolumner.

• Replikering löser inte konflikter på grund av fel på främmande nyckelbegränsningar:

  • Om du inte förväntar dig konflikter och data är väl partitionerad (prenumeranter uppdaterar inte samma rader), använd främmande nyckelbegränsningar på Publisher och prenumeranter.

  • Om du förväntar dig konflikter: använd inte främmande nyckelbegränsningar hos Publisher eller Subscriber om du använder konfliktlösning som "Subscriber wins". Använd inte främmande nyckelbegränsningar vid prenumeranten om du använder konfliktlösning som "Publisher wins".

Relaterat innehåll

• Peer-to-Peer - transaktionell replikering
• Transaktionsreplikering
• Publicera data och databasobjekt
• Prenumerera på publikationer