Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op:
SQL Server
Opmerking
Deze functie wordt verwijderd in een toekomstige versie van SQL Server. Vermijd het gebruik van deze functie in nieuwe ontwikkelwerkzaamheden en plan om toepassingen te wijzigen die momenteel gebruikmaken van deze functie.
Standaard verwerkt Merge Replication gegevenswijzigingen rij voor rij. In veel gevallen is deze aanpak geschikt, maar voor sommige toepassingen is het essentieel dat gerelateerde rijen als een eenheid worden verwerkt. De functie logische records van Merge Replication stelt je in staat een relatie te definiëren tussen gerelateerde rijen in verschillende tabellen zodat de rijen als een eenheid worden verwerkt.
Opmerking
Je kunt de functie voor logische records alleen gebruiken of in combinatie met join-filters. Zie Join Filters voor meer informatie over joinfilters. Als u logische records wilt gebruiken, moet het compatibiliteitsniveau van de publicatie ten minste 90RTM zijn.
Houd rekening met deze drie gerelateerde tabellen:
De tabel Klanten is de bovenliggende tabel in deze relatie en heeft een primaire sleutelkolom CustID. De tabel Orders heeft een primaire sleutelkolom OrderID, met een foreign key-beperking op de kolom CustID die verwijst naar de kolom CustID in de tabel Customers. Op dezelfde manier heeft de tabel OrderItems een primaire sleutelkolom OrderItemID, met een foreign key-beperking op de kolom OrderID die verwijst naar de kolom OrderID in de tabel Orders.
In dit voorbeeld bestaat een logische record uit alle rijen in de tabel Orders die zijn gerelateerd aan één CustID-waarde en alle rijen in de tabel OrderItems die zijn gerelateerd aan die rijen in de tabel Orders . In dit diagram ziet u alle rijen in de drie tabellen die zich in de logische record voor Customer2 bevinden:
Als u een logische recordrelatie tussen artikelen wilt definiëren, raadpleegt u Een logische recordrelatie tussen samenvoegtabelartikelen definiëren.
Voordelen van logische gegevens
De functie logische records heeft twee primaire voordelen:
Toepassing van gegevenswijzigingen als een eenheid.
De detectie en oplossing van conflicten tegelijk op meerdere rijen uit meerdere tabellen.
De toepassing van veranderingen als een eenheid
Als mergeverwerking wordt onderbroken, zoals bij een verbroken verbinding, rolt het proces de gedeeltelijk voltooide set van gerelateerde gerepliceerde wijzigingen terug als logische records worden gebruikt. Denk bijvoorbeeld aan het geval dat een abonnee een nieuwe order toevoegt met OrderID = 6 en twee nieuwe rijen in de tabel OrderItems met OrderItemID = 10 en OrderItemID = 11 voor OrderID = 6.
Als het replicatieproces wordt onderbroken nadat de Orders-rij voor OrderID = 6 voltooid is, maar voordat de OrderItems 10 en 11 compleet zijn en logische records niet worden gebruikt, is de OrderTotal-waarde voor OrderID = 6 niet consistent met de som van de OrderAmount-waarden voor de OrderItems-rijen . Als logische records worden gebruikt, wordt de Orders-rij voor OrderID = 6 pas gecommitteerd nadat de gerelateerde OrderItems-wijzigingen zijn gerepliceerd.
In een ander scenario, als logische records worden gebruikt en iemand vraagt tabellen op terwijl het mergeproces wijzigingen toepast, ziet de gebruiker de gedeeltelijk gerepliceerde wijzigingen pas als ze allemaal compleet zijn. Bijvoorbeeld, het replicatieproces uploadt de Orders-rij voor OrderID = 6, maar een gebruiker raadpleegt de tabellen voordat het replicatieproces de OrderItems-rijen repliceert; de OrderTotal-waarde is niet hetzelfde als de som van de OrderAmount-waarden . Als logische records worden gebruikt, is de Orders-rij pas zichtbaar als de OrderItems-rijen compleet zijn en de transactie als eenheid wordt gecommend.
De toepassing van conflictafhandeling op meer dan één tabel
Beschouw het geval waarin twee abonnees de voorgaande dataset hebben:
Een gebruiker bij de eerste abonnee wijzigt de OrderAmount van OrderItemID 5 van 100 tot 150 en de OrderTotal van OrderID 3 van 200 in 250.
Een gebruiker bij de tweede abonnee wijzigt de OrderAmount van OrderItemID 6 van 25 tot 125 en de OrderTotal van OrderID 3 van 200 tot 300.
Als deze wijzigingen worden gerepliceerd zonder gebruik te maken van logische records, resulteren de verschillende OrderTotal-waarden in een conflict en wordt er slechts één gerepliceerd. Maar de niet-conflicterende wijzigingen in de OrderItems-tabel worden zonder conflict gerepliceerd, waardoor de uiteindelijke OrderTotal-waarden in een inconsistente staat blijven ten opzichte van de OrderItems-rijen . Als logische records in dit scenario worden gebruikt, wordt de wijziging in OrderItems die gekoppeld is aan de verandering in de verloren Order-tabel ook teruggedraaid, en is de uiteindelijke OrderTotal-waarde een nauwkeurige samenvatting van de OrderItems-rijen .
Zie Conflicten in logische records detecteren en oplossen voor meer informatie over opties met betrekking tot conflictdetectie en -oplossing met logische records.
Overwegingen bij het gebruik van logische records
Houd rekening met de volgende overwegingen bij het gebruik van logische records.
Algemene overwegingen
Houd het aantal tabellen in een logisch record zo laag mogelijk. Gebruik vijf tafels of minder.
Logische records kunnen geen kolommen met een van de volgende datatypen refereren:
varchar(max) en nvarchar(max)
varbinary(max)
tekst en ntekst
image
XML
UDT
Je kunt vreemde sleutelrelaties niet definiëren in gepubliceerde tabellen door de CASCADE-optie te gebruiken. Zie CREATE TABLE (Transact-SQL) en ALTER TABLE (Transact-SQL) voor meer informatie.
Je kunt geen kolommen updaten die in de logische relatieclausule worden gebruikt.
Aangepaste conflictoplossing met business logic handlers of custom resolvers wordt niet ondersteund voor artikelen die in een logisch record zijn opgenomen.
Als je logische records gebruikt in een publicatie die geparametriseerde filters bevat, moet je elke abonnee initialiseren met een snapshot voor zijn partitie. Als je een abonnee initialiseert via een andere methode, faalt de Merge Agent. Zie Momentopnamen voor het samenvoegen van publicaties met geparameteriseerde filters voor meer informatie.
Conflicten die logische records betreffen, verschijnen niet in Conflict Viewer. Als u informatie over deze conflicten wilt weergeven, gebruikt u opgeslagen replicatieprocedures. Voor meer informatie, zie Conflictinformatie weergeven voor samenvoegpublicaties (Replicatie Transact-SQL Programmeren).
Publicatie-instellingen
De publicatie moet een compatibiliteitsniveau van 90RTM of hoger hebben. Zie voor meer informatie het gedeelte "Publicatiecompatibiliteitsniveau" van Replicatie Achterwaarts Compatibiliteit.
De publicatie moet de systeemeigen momentopnamemodus gebruiken. Deze modus is standaard, tenzij je repliceert naar SQL Server Compact, die geen logische records ondersteunt.
De publicatie kan geen websynchronisatie toestaan. Voor meer informatie over websynchronisatie, zie Websynchronisatie voor samenvoegreplicatie.
Om logische records te gebruiken op een gefilterde publicatie:
Je moet ook vooraf berekende partities gebruiken. De vereisten van vooraf samengestelde partities zijn ook van toepassing op logische records. Zie Geparameteriseerde filterprestaties optimaliseren met vooraf samengestelde partities voor meer informatie.
Je kunt geen niet-overlappende geparametriseerde filters gebruiken. Zie de sectie 'Partitieopties instellen' van Geparameteriseerde rijfilters voor meer informatie.
Als de publicatie joinfilters gebruikt, moet je de join unique key-eigenschap op true zetten voor alle joinfilters die betrokken zijn bij logische recordrelaties. Zie Join-filters voor meer informatie.
Relaties tussen tabellen
Tabellen die zijn gerelateerd via logische records moeten een primaire-sleutel/vreemde-sleutelrelatie hebben.
Je kunt de optie NOT FOR REPLICATION niet instellen voor foreign key-beperkingen.
Onderliggende tabellen kunnen slechts één bovenliggende tabel hebben.
Een database die lessen en studenten bijhoudt kan bijvoorbeeld een ontwerp hebben dat vergelijkbaar is met:
Je kunt geen logisch record gebruiken om de drie tabellen in deze relatie weer te geven, omdat de rijen in ClassMembers niet aan één enkele primaire sleutelrij zijn gekoppeld. De tabellen Klassen en ClassMembers kunnen nog steeds een logische record vormen, net als de tabellen ClassMembers en Studenten, maar niet alle drie.
De publicatie kan geen circulaire joinfilterrelaties bevatten.
Met het voorbeeld van de tabellen Klanten, Orders en OrderItems, kun je geen logische records gebruiken als de Orders-tabel ook een vreemde sleutel-beperking heeft die verwijst naar de OrderItems-tabel .
Gevolgen voor de prestaties van logische records
De logische registratiefunctie brengt een prestatiekosten met zich mee. Als je geen logische records gebruikt, kan de replicatieagent alle wijzigingen voor een bepaald artikel tegelijk verwerken. Omdat de wijzigingen rij voor rij worden toegepast, zijn de vereisten voor het toepassen van de wijzigingen minimaal voor het vergrendelen en de transactielogboeken.
Als je logische records gebruikt, moet de Merge Agent de wijzigingen voor elk gehele logisch record samen verwerken. Dit proces beïnvloedt de tijd die de Merge Agent nodig heeft om de rijen te repliceren. Omdat de agent een afzonderlijke transactie voor elk logisch record opent, kunnen de vergrendelingsvereisten toenemen.