Updateerbare abonnementen - Voor transactionele replicatie

Van toepassing op:SQL Server

Transactionele replicatie ondersteunt updates bij abonnees via bijgewerkte abonnementen en peer-to-peer-replicatie. Hier volgen de twee typen updatable abonnementen:

• Direct bijwerken. De uitgever en abonnee moeten zijn verbonden om gegevens bij te werken bij de abonnee.

• Bijwerken in wachtrij De uitgever en de abonnee hoeven niet met elkaar verbonden te zijn om gegevens bij de abonnee bij te werken. Je kunt data bijwerken terwijl de abonnee of Publisher offline is.

Wanneer je gegevens bijwerkt bij een abonnee, gaat de update eerst naar de Publisher en daarna naar andere abonnees. Als je direct bijwerken gebruikt, worden de wijzigingen onmiddellijk doorgevoerd via het tweefasencommitprotocol. Als je een queue-update gebruikt, gaan de wijzigingen in een wachtrij. De in de wachtrij staande transacties gaan asynchroon naar de Publisher wanneer netwerkverbinding beschikbaar is. Omdat de updates asynchroon naar de Publisher gaan, kan dezelfde data worden bijgewerkt door de Publisher of door een andere abonnee en kunnen conflicten optreden bij het toepassen van de updates. Het systeem detecteert en lost conflicten op volgens een conflictoplossingsbeleid dat je hebt ingesteld bij het maken van de publicatie.

Als u een transactionele publicatie maakt met bijwerkbare abonnementen in de wizard Nieuwe publicatie, zijn zowel direct bijwerken als bijwerken in de wachtrij ingeschakeld. Als u een publicatie met opgeslagen procedures maakt, kunt u een of beide opties inschakelen. Wanneer u een abonnement op de publicatie maakt, geeft u op welke updatemodus moet worden gebruikt. U kunt zo nodig schakelen tussen updatemodi. Zie de volgende sectie 'Schakelen tussen updatemodi' voor meer informatie.

Om updateerbare abonnementen voor transactionele publicaties mogelijk te maken, zie Updates van abonnementen voor transactionele publicaties inschakelen.

Om updateerbare abonnementen te maken voor transactionele publicaties, zie Create an Updateable Subscription to a Transactional Publication (Management Studio).

Wisselen tussen updatemodi

Wanneer je updateerbare abonnementen gebruikt, kun je één updatemodus voor een abonnement specificeren en overschakelen naar de andere modus als de applicatie dat vereist. Je kunt bijvoorbeeld specificeren dat een abonnement direct wordt bijgewerkt, maar overschakelt op updates in de wachtrij als een systeemstoring leidt tot verlies van netwerkverbinding.

Als je overschakelt van directe update naar wachtrij-update, kun je pas terugschakelen naar directe updates als de Subscriber en Publisher verbonden zijn en de Queue Reader Agent alle wachtende berichten in de wachtrij toepast op de Publisher.

Schakelen tussen updatemodi

Om tussen updatemodi te wisselen, schakel je publicatie en abonnement in voor beide updatemodi, en wissel je indien nodig tussen deze modi. Zie voor meer informatie
Schakelen tussen updatemodi voor een updatable transactioneel abonnement.

Overwegingen bij het gebruik van update-bare abonnementen

• Nadat je een publicatie hebt ingesteld voor het bijwerken van abonnementen of voor abonnementsupdates in de wachtrij, kun je deze optie voor de publicatie niet uitschakelen (hoewel abonnementen hiervan geen gebruik hoeven te maken). Om de optie uit te schakelen, verwijder je de publicatie en maak je een nieuwe aan.

• Het opnieuw publiceren van data wordt niet ondersteund.

• Replicatie voegt de msrepl_tran_version-kolom toe aan gepubliceerde tabellen voor traceringsdoeleinden. Vanwege deze extra kolom kun je een kolomlijst opnemen in alle INSERT verklaringen.

• Om schemawijzigingen aan te brengen in een tabel in een publicatie die het bijwerken van abonnementen ondersteunt, stop je alle activiteit op de tabel bij de Publisher en Subscribers, en versprei je openstaande datawijzigingen naar alle knooppunten voordat je schemawijzigingen aanbrengt. Dit proces zorgt ervoor dat openstaande transacties niet conflicteren met de lopende schemawijziging. Nadat de schemawijzigingen naar alle knooppunten zijn doorgegeven, kan de activiteit op de gepubliceerde tabellen worden hervat. Zie Een replicatietopologie onderbreken (Programmeren van replicatie in Transact-SQL) voor meer informatie.

• Om tussen updatemodi te schakelen, moet de Queue Reader Agent minstens één keer draaien nadat het abonnement is geïnitialiseerd (standaard draait de Queue Reader Agent continu).

• Als de abonneedatabase horizontaal is gepartitioneerd en er zijn rijen in de partitie die bestaan bij de abonnee maar niet bij de Publisher, kan de abonnee de bestaande rijen niet bijwerken. Als u deze rijen probeert bij te werken, wordt een fout geretourneerd. Verwijder de rijen uit de tabel en voeg ze dan toe bij de Publisher.

• Transactionele replicatie met in de wachtrij updateerbare abonnees kan trage prestaties ervaren wanneer unieke gefilterde indexen worden gebruikt. Als er een conflict optreedt in een artikel met unieke gefilterde indexen, leidt conflictoplossing tot extra verwijderingen en invoegingen bij de abonnee voor de rijen die niet onder de unieke gefilterde index vallen.

Updates bij de abonnee

• Updates bij de Abonnee worden doorgegeven aan de Publisher, zelfs als een abonnement is verlopen of inactief is. Zorg ervoor dat je dergelijke abonnementen stopt of opnieuw initialiseert.

• Als je TIMESTAMP- of IDENTITY-kolommen gebruikt en deze repliceert als hun onderliggende gegevenstypen, werk de waarden in deze kolommen dan niet bij op de Subscriber.

• Abonnees kunnen geen tekst-, ntext- of afbeeldingswaarden bijwerken of invoegen omdat replicatie-wijzigingstrackers niet kunnen lezen uit de ingevoegde of verwijderde tabellen. Evenzo kunnen abonnees geen tekst- of afbeeldingswaarden bijwerken of invoegen door WRITETEXT of UPDATETEXT te gebruiken, omdat de Publisher de gegevens overschrijft. In plaats daarvan kun je de tekst- en afbeeldingskolommen in een aparte tabel partitioneren en beide tabellen binnen een transactie aanpassen.

  Om grote objecten bij een abonnee bij te werken, gebruik je de datatypes varchar(max),nvarchar(max) en varbinary(max) in plaats van respectievelijk tekst-, ntext- en afbeeldingsdatatypes .

• Updates van unieke sleutels (inclusief primaire sleutels) die duplicaten genereren, zoals een update van het formulier UPDATE <column> SET <column> =<column>+1, zijn niet toegestaan en worden afgewezen vanwege een uniciteitsschending. Set-updates die bij de Abonnee zijn aangebracht, worden via replicatie doorgegeven als afzonderlijke UPDATE-instructies voor elke getroffen rij.

• Als de abonneedatabase horizontaal is gepartitioneerd en de partitie bevat rijen die bestaan bij de abonnee maar niet bij de Publisher, kan de abonnee de reeds bestaande rijen niet bijwerken. Als u deze rijen probeert bij te werken, wordt een fout geretourneerd. Verwijder en voeg deze rijen opnieuw in.

Door de gebruiker gedefinieerde triggers

• Als de applicatie triggers vereist bij de abonnee, definieer dan de triggers met de NOT FOR REPLICATION optie bij de Publisher en Subscriber. Deze optie zorgt ervoor dat alleen triggers worden geactiveerd voor de oorspronkelijke datawijziging, maar niet wanneer replicatie de wijziging voortplant.

  Zorg ervoor dat de door de gebruiker gedefinieerde trigger niet afgaat wanneer de replicatietrigger de tabel bijwerkt. Roep de procedure sp_check_for_sync_trigger aan in het lichaam van de door de gebruiker gedefinieerde trigger. Zie sp_check_for_sync_trigger (Transact-SQL) voor meer informatie.

Direct bijwerken

• Voor directe updates van abonnementen worden wijzigingen bij de Subscriber doorgegeven aan de Publisher en worden ze toegepast via de Microsoft Distributed Transaction Coordinator (MS DTC). Zorg ervoor dat MS DTC is geïnstalleerd en geconfigureerd bij publisher en abonnee. Zie de Windows-documentatie voor meer informatie.

• De triggers die onmiddellijke updates van abonnementen gebruiken, vereisen een verbinding met de Publisher om wijzigingen te repliceren.

• Als de publicatie het direct bijwerken van abonnementen toestaat en een artikel in de publicatie een kolomfilter heeft, kun je niet-nulbare kolommen niet filteren zonder standaardinstellingen.

Update in wachtrij

• Je kunt tabellen die zijn opgenomen in een merge-publicatie niet publiceren als onderdeel van een transactionele publicatie die wachtrij-updates van abonnementen mogelijk maakt.

• Werk de kolommen van de primaire sleutel niet bij bij het gebruik van wachtrij-updates, omdat de primaire sleutel dient als recordlocator voor alle zoekopdrachten. Wanneer het conflictoplossingsbeleid staat op Subscriber Wins, wees dan voorzichtig met het bijwerken van primaire sleutels. Als zowel de Publisher als de Subscriber de primaire sleutel bijwerken, resulteert het resultaat in twee rijen met verschillende primaire sleutels.

• Voor kolommen van het datatype SQL_VARIANT: wanneer gegevens worden ingevoegd of bijgewerkt bij de abonnee, wijst de Queue Reader Agent deze op de volgende manier toe wanneer hij gegevens van de abonnee naar de wachtrij kopieert:

  • BIGINT,DECIMAL, NUMERIC,MONEY en SMALLMONEY worden overeengebracht met NUMERIC.

  • BINARY en VARBINARY worden gekoppeld aan VARBINARY-gegevens .

Conflictdetectie en -oplossing

• Voor het Subscriber Wins-conflictbeleid: conflictoplossing ondersteunt geen updates van primaire sleutelkolommen.

• Replicatie lost conflicten niet op door het falen van vreemde sleutelconstrainten:

  • Als je geen conflicten verwacht en de data goed gepartitioneerd is (abonnees werken niet dezelfde rijen bij), gebruik dan foreign key-beperkingen op de Publisher en Subscribers.

  • Als je conflicten verwacht: gebruik dan geen foreign key-beperkingen bij de Publisher of Subscriber als je "Subscriber wins" conflictoplossing gebruikt. Gebruik geen vreemde sleutelbeperkingen bij de abonnee als je "Publisher wins" conflictoplossing gebruikt.

Verwante inhoud

• Peer-to-Peer - transactionele replicatie
• Transactionele replicatie
• Gegevens en databaseobjecten publiceren
• Abonneren op publicaties