Inzicht in de verwerkingsvolgorde van het artikel Replicatie samenvoegen

In dit artikel wordt uitgelegd hoe u de verwerkingsvolgorde van samenvoegingsreplicatie-artikelen begrijpt.

Originele productversie: SQL Server
Origineel KB-nummer: 307356

Samenvatting

De samenvoegagent volgt een specifieke set regels die bepalen in welke volgorde het samenvoegproces wijzigingen toepast op artikelen tijdens het synchronisatieproces.

In dit artikel wordt beschreven waarom de order voor het verwerken van artikelen belangrijk is.

Meer informatie

Er zijn twee belangrijke redenen waarom de volgorde voor het verwerken van artikelen belangrijk is:

• In veel gevallen moet de samenvoegagent wijzigingen in artikelen die deelnemen aan declaratieve referentiële integriteit (DRI)-beperkingen in een specifieke volgorde verwerken om optimale prestaties te bereiken. Zo niet, dan moet de samenvoegagent mogelijk DML-bewerkingen (Data Manipulation Language) opnieuw proberen in een onjuiste volgorde (dat wil gezegd, probeer een onderliggende rij in te voegen vóór die van de bovenliggende rij).

• Voor toepassingen die gebruikmaken van triggers om referentiële integriteit te behouden, moet de samenvoegagent wijzigingen in een specifieke volgorde verzenden. Als de samenvoegagent wijzigingen in een onjuiste volgorde verzendt, wordt de wijziging waarschijnlijk teruggedraaid door de trigger en wordt de wijziging niet doorgegeven in de replicatietopologie.

Opmerking

De samenvoegagent kan de evaluatie van foreign key-beperkingen en uitvoering van gebruikerstriggers omzeilen wanneer SQL DML-wijzigingsbewerkingen worden toegepast op een partnerreplica. Hiervoor moeten de beperking REFERERENDE SLEUTEL en de gebruikerstrigger, of beide, zijn gemaakt met de optie NIET VOOR REPLICATIE . In beide gevallen wordt bij het samenvoegproces ervan uitgegaan dat SQL Server de bedrijfslogica met succes heeft geëvalueerd wanneer de oorspronkelijke door de gebruiker geïnitieerde wijziging op het object wordt uitgevoerd en dat deze voorwaarden niet opnieuw hoeven te worden geëvalueerd wanneer de gegevens worden gerepliceerd naar de partnerreplica. Het primaire voordeel van het gebruik van NOT FOR REPLICATION op deze manier is verbeterde prestaties. Zie het onderwerp NIET VOOR REPLICATIE in SQL Server 2000 Books Online voor meer informatie over de optie NIET VOOR REPLICATIE en hoe u deze op de juiste manier kunt gebruiken.

Om de twee redenen die eerder zijn vermeld, is de volgorde waarin de samenvoegagent wijzigingen aan een partnerreplica levert belangrijk.

Voordat u begint met een bespreking van de volgorde voor het verwerken van artikelen, is het belangrijk om kennis te hebben van twee belangrijke concepten. De twee belangrijkste concepten zijn als volgt:

• Een bijnaam van een artikel.

• Een generatie.

Hier volgt een beschrijving van de twee concepten.

• Bijnamen van artikel

  Een bijnaam is een geheel getal dat de samenvoegagent gebruikt om een artikel (een SQL Server tabel) te identificeren om replicatie samen te voegen. Tijdens het instellen van de samenvoegbewerking wordt een bijnaam van een artikel toegewezen wanneer het artikel wordt toegevoegd aan een samenvoegpublicatie. Als een artikel deelneemt aan DRI-beperkingen, probeert het installatieproces voor samenvoegen een artikelnaam te genereren die gedefinieerde DRI-beperkingen weerspiegelt. Het samenvoegproces wijst tabellen waarnaar wordt verwezen door een FOREIGN KEY-beperking (een bovenliggende) een kleinere bijnaam toe dan die van de tabel waarnaar wordt verwezen (de onderliggende tabel of de tabel waarvoor de beperking REFERERENDE SLEUTEL is gedefinieerd).

  Als een tabel niet deelneemt aan dri-beperkingen, wijst het samenvoegingsproces de bijnaam toe op basis van de volgorde waarin het artikel aan de publicatie wordt toegevoegd (in oplopende volgorde).

• Generatie

Een generatie is een geheel getal dat door de samenvoegagent wordt gebruikt om een logische groep wijzigingen in een bepaald artikel bij te houden. Alle wijzigingen in een bepaald artikel op een bepaalde replica tussen samenvoegsynchronisaties zijn gekoppeld aan dezelfde generatie. Telkens wanneer de samenvoegagent wordt uitgevoerd, wordt de bestaande open generatie gesloten en wordt er een nieuwe generatie geopend waaraan de volgende set wijzigingen kan worden gekoppeld.

INSERT's, UPDATes en VERWIJDERINGen verwerken

De samenvoegagent partitioneert de artikelen voor een bepaalde publicatie in twee afzonderlijke groepen:

• De samenvoegagent plaatst artikelen die niet betrokken zijn bij joinfilterrelaties en die niet via DRI zijn gerelateerd aan artikelen die betrokken zijn bij joinfilters in één groep.

• De samenvoegagent plaatst artikelen die expliciet betrokken zijn bij joinfilterrelaties en artikelen met betrekking tot het samenvoegen van filterartikelen via DRI in een tweede afzonderlijke groep.

De samenvoegagent voegt elk artikel dat is gedefinieerd aan de publicatie toe aan slechts één van de voorgaande groepen.

De samenvoegagent gebruikt de groepen om de algehele verwerkingsvolgorde van UPDATEs, INSERTsen DELETEs te bepalen voor alle artikelen die voor de publicatie zijn gedefinieerd.

In elk van de twee respectieve groepen verwerkt INSERTs de samenvoegagent en UPDATEs in oplopende volgorde van de bijnaam van het artikel en in DELETEs aflopende volgorde van de bijnaam van het artikel. Eerst verwerkt de samenvoegagent alles DELETEs in hun geheel in een bepaalde groep, gevolgd door UPDATEs en INSERTs (ook in een bepaalde groep). Conceptueel voegt de samenvoegagent de twee bovengenoemde groepen aan elkaar toe (niet samengevoegd) in de eerder vermelde volgorde. De samenvoegagent begint met de verwerking DELETEs voor de eerste groep en breidt vervolgens de verwerking uit DELETE naar de tweede groep en de rest van de wijzigingen voor de twee groepen worden parallel verwerkt. Hoewel de samenvoegagent de verwerkingsvolgorde van artikelen in elke respectieve groep onderhoudt, houdt de samenvoegagent geen strikte verwerkingsvolgorde voor artikelen in de twee respectieve groepen. Als zodanig is het in het geval van een INSERT of UPDATEmogelijk dat wijzigingen van de eerste groep met een hogere artikelnaam vóór die van de tweede groep met een lagere bijnaam aankomen. De omgekeerde situatie kan ook optreden voor een DELETE. Beide gedragingen zijn standaard.

Mogelijke effecten van het genereren van batches op de order voor het verwerken van artikelen

Zoals eerder vermeld, kunt u met een generatie wijzigingen (INSERTs, UPDATEs en DELETEs) die zich voordoen voor een bepaald artikel op een bepaalde replica tussen synchronisatiesessies logisch groepeert. Uiteindelijk werkt de samenvoegagent met generaties wanneer deze bepaalt welke wijzigingen moeten worden uitgewisseld tussen twee replica's. De samenvoegagent onderhandelt over een algemene generatie op de volgende punten in het synchronisatieproces:

• Voordat wijzigingen van de abonnee naar de uitgever worden geüpload.

• Voordat wijzigingen worden gedownload van de uitgever naar de abonnee.

De samenvoegagent gebruikt deze algemene generatie als uitgangspunt bij het inventariseren van de generaties die moeten worden verzonden naar een partnerreplica tijdens de upload- en downloadfase van de samenvoegsynchronisatie.

De samenvoegagent verwerkt generaties in batches, ook wel generatiebatches genoemd. Standaard worden 100 generaties opgenomen in elke generatiebatch die de samenvoegagent uploadt naar de uitgever van de abonnee of downloadt naar de abonnee van de uitgever. De batchgrootte voor het genereren kan worden geconfigureerd via de -UploadGenerationsPerBatch parameters en de -DownloadGenerationsPerBatch samenvoegagent of via het profiel Van de samenvoegagent. In het standaard geval, als er meer dan 100 generaties zijn die u moet uitwisselen (dat wil gezegd, downloaden en uploaden, of beide) tussen een uitgever (of een heruitgever) en een abonnee, verwerkt de Samenvoegagent batches van meerdere generaties. Het aantal batches is afhankelijk van het aantal generaties dat de samenvoegagent moet uitwisselen en de generaties per batch-instellingen die van kracht zijn voor een bepaalde samenvoegsessie.

In een situatie waarin batches van meerdere generatie worden uitgewisseld, kan de samenvoegagent gerelateerde bovenliggende en onderliggende wijzigingen splitsen over twee afzonderlijke generatiebatches. Als dat het geval is, kan de samenvoegagent een onderliggende wijziging in een generatiebatch leveren vóór de generatiebatch die de gekoppelde bovenliggende wijziging bevat. In hiërarchische samenvoegtopologieën die gebruikmaken van heruitgevers, is er een zeldzame situatie waarin het splitsen van bovenliggende en onderliggende wijzigingen tussen generatiebatches kan leiden tot niet-convergentie. Zie het volgende artikel voor meer informatie over niet-convergentie:

Niet-convergentie wanneer SQL Server onderliggende en bovenliggende generaties in afzonderlijke generatiebatches verwerkt.

U kunt de -UploadGenerationsPerBatch-DownloadGenerationsPerBatch parameters en die eerder zijn besproken verhogen om te voorkomen dat bovenliggende en onderliggende wijzigingen worden gesplitst tussen generatiebatches.

De verwerkingsvolgorde van het artikel wordt onderhouden in een bepaalde generatiebatch volgens de eerder besproken regels. De samenvoegagent kan de verwerkingsvolgorde van artikelen echter niet bijhouden voor generatiebatches.