Grundlegendes zur Verarbeitungsreihenfolge des Mergereplikationsartikels

  • Artikel

In diesem Artikel erfahren Sie, wie Sie die Verarbeitungsreihenfolge für Mergereplikationsartikel verstehen.

Ursprüngliche Produktversion: SQL Server
Ursprüngliche KB-Nummer: 307356

Zusammenfassung

Die Merge-Agent folgt einem bestimmten Satz von Regeln, die die Reihenfolge steuern, in der der Mergeprozess Änderungen während des Synchronisierungsprozesses auf Artikel anwendet.

In diesem Artikel wird erläutert, warum die Reihenfolge der Artikelverarbeitung wichtig ist.

Weitere Informationen

Es gibt zwei Hauptgründe, warum die Reihenfolge der Artikelverarbeitung wichtig ist:

  • In vielen Fällen muss die Merge-Agent Änderungen an Artikeln, die an Deklarativer Referenzieller Integrität (DRI)-Einschränkungen beteiligt sind, in einer bestimmten Reihenfolge verarbeiten, um eine optimale Leistung zu erzielen. Andernfalls muss die Merge-Agent möglicherweise dml-Vorgänge (Data Manipulation Language) wiederholen, die sie in einer falschen Reihenfolge versucht haben (d. a. versuchen Sie, eine untergeordnete Zeile vor der der übergeordneten Zeile einzufügen).

  • Anwendungen, die Trigger verwenden, um die referenzielle Integrität aufrechtzuerhalten, erfordern, dass die Merge-Agent Änderungen in einer bestimmten Reihenfolge senden. Wenn die Merge-Agent Änderungen in einer falschen Reihenfolge sendet, führt der Trigger höchstwahrscheinlich ein Rollback der Änderung durch, und die Änderung wird nicht in der gesamten Replikationstopologie weitergegeben.

Hinweis

Die Merge-Agent kann die Foreign KEY-Einschränkungsauswertung umgehen und die Ausführung durch Den Benutzer auslösen, wenn SQL DML-Änderungsvorgänge auf ein Partnerreplikat angewendet werden. Dazu müssen die FOREIGN KEY-Einschränkung und der Benutzertrigger oder beides mit der Option NOT FOR REPLICATION erstellt worden sein. In beiden Fällen wird beim Zusammenführungsprozess davon ausgegangen, dass SQL Server die Geschäftslogik erfolgreich ausgewertet hat, wenn die ursprüngliche vom Benutzer initiierte Änderung für das Objekt ausgeführt wird, und dass diese Bedingungen nicht neu ausgewertet werden müssen, wenn die Daten auf das Partnerreplikat repliziert werden. Der Hauptvorteil der Verwendung von NOT FOR REPLICATION auf diese Weise ist eine höhere Leistung. Weitere Informationen zur Option NOT FOR REPLICATION und zur entsprechenden Verwendung finden Sie im Thema NOT FOR REPLICATION in der SQL Server 2000-Onlinedokumentation.

Aus den beiden zuvor aufgeführten Gründen ist die Reihenfolge wichtig, in der die Merge-Agent Änderungen an ein Partnerreplikat übermittelt.

Bevor Sie mit einer Erläuterung der Artikelverarbeitungsreihenfolge beginnen, ist es wichtig, zwei wichtige Konzepte zu verstehen. Die beiden wichtigsten Konzepte sind wie folgt:

  • Ein Spitzname für Artikel.

  • Eine Generation.

Im Folgenden finden Sie eine Beschreibung der beiden Konzepte.

  • Spitznamen für Artikel

    Ein Spitzname ist ein ganzzahliger Wert, der vom Merge-Agent verwendet wird, um einen Artikel (eine SQL Server Tabelle) zum Zusammenführen der Replikation zu identifizieren. Der Mergeeinrichtungsprozess weist einen Artikelnamen zu, wenn der Artikel einer Mergeveröffentlichung hinzugefügt wird. Wenn ein Artikel an DRI-Einschränkungen teilnimmt, versucht der Mergeeinrichtungsprozess, einen Artikelnamen zu generieren, der definierte DRI-Einschränkungen widerspiegelt. Der Mergeprozess weist Tabellen, auf die durch eine FOREIGN KEY-Einschränkung (ein übergeordnetes Element) verwiesen wird, einen kleineren Artikelnamen zu als der der verweisenden Tabelle (die untergeordnete Tabelle oder die Tabelle, für die die FOREIGN KEY-Einschränkung definiert ist).

    Wenn eine Tabelle nicht an DRI-Einschränkungen teilnimmt, weist der Mergeeinrichtungsprozess den Artikelnamen basierend auf der Reihenfolge zu, in der der Artikel der Veröffentlichung hinzugefügt wird (in aufsteigender Reihenfolge).

  • Generation

Eine Generierung ist ein ganzzahliger Wert, den der Merge-Agent verwendet, um eine logische Gruppe von Änderungen an einem bestimmten Artikel nachzuverfolgen. Alle Änderungen, die an einem bestimmten Artikel an einem bestimmten Replikat zwischen Mergesynchronisierungen vorgenommen wurden, sind derselben Generation zugeordnet. Jedes Mal, wenn der Merge-Agent ausgeführt wird, schließt er die vorhandene offene Generation und öffnet dann eine neue Generation, der die nächsten Änderungen zugeordnet werden sollen.

Verarbeiten von INSERTs, UPDATEs und DELETEs

Die Merge-Agent partitioniert die Artikel für eine bestimmte Veröffentlichung in zwei unterschiedliche Gruppen:

  • Das Merge-Agent Artikel, die nicht an Joinfilterbeziehungen beteiligt sind und nicht über DRI verknüpft sind, mit Artikeln, die an Joinfiltern beteiligt sind, in einer Gruppe platziert.

  • Die Merge-Agent platziert Artikel, die explizit an Verknüpfungsfilterbeziehungen beteiligt sind, und Artikel, die sich auf Joinfilterartikel über DRI beziehen, in eine zweite separate Gruppe.

Die Merge-Agent fügt jeden der Veröffentlichung definierten Artikel nur einer der vorherigen Gruppen hinzu.

Die Merge-Agent verwendet die Gruppen, um die Gesamtverarbeitungsreihenfolge von UPDATEs, INSERTsund DELETEs für alle Artikel zu bestimmen, die für die Veröffentlichung definiert sind.

In jeder der beiden entsprechenden Gruppen verarbeitet INSERTs die Merge-Agent und UPDATEs in aufsteigender Reihenfolge des Spitznamens für Artikel und prozesse DELETEs in absteigender Reihenfolge des Spitznamens für Artikel. Erstens verarbeitet die Merge-Agent alle DELETEs vollständig in einer bestimmten Gruppe, gefolgt von UPDATEs und INSERTs (auch in einer bestimmten Gruppe). Konzeptionell fügt der Merge-Agent die beiden oben genannten Gruppen in der zuvor aufgeführten Reihenfolge aneinander an (nicht zusammengeführt). Die Merge-Agent beginnt mit der Verarbeitung DELETEs für die erste Gruppe und erweitert DELETE dann die Verarbeitung auf die zweite Gruppe, und die restlichen Änderungen für die beiden Gruppen werden parallel verarbeitet. Obwohl die Merge-Agent die Reihenfolge der Artikelverarbeitung in jeder jeweiligen Gruppe beibehält, behält die Merge-Agent keine strikte Artikelverarbeitungsreihenfolge für die beiden jeweiligen Gruppen bei. Daher ist es im Fall eines INSERT oder UPDATEmöglich, dass Änderungen aus der ersten Gruppe mit einem höheren Spitznamen vor denen aus der zweiten Gruppe mit einem niedrigeren Spitznamen eingehen können. Die umgekehrte Situation kann auch für ein DELETEauftreten. Beide Verhaltensweisen sind beabsichtigt.

Mögliche Auswirkungen der Generierungsbatchierung auf die Artikelverarbeitungsreihenfolge

Wie bereits erwähnt, können Sie mit einer Generation Änderungen (INSERTsund DELETEs) logisch gruppieren, UPDATEs die für einen bestimmten Artikel an einem bestimmten Replikat zwischen Synchronisierungssitzungen auftreten. Letztendlich funktioniert der Merge-Agent mit Generationen, wenn er bestimmt, welche Änderungen zwischen zwei Replikaten ausgetauscht werden müssen. Die Merge-Agent eine gemeinsame Generierung an den folgenden Punkten im Synchronisierungsprozess aushandelt:

  • Bevor änderungen vom Abonnenten an den Herausgeber hochgeladen werden.

  • Bevor änderungen vom Herausgeber auf den Abonnenten heruntergeladen werden.

Die Merge-Agent verwendet diese gemeinsame Generation als Ausgangspunkt beim Aufzählen der Generationen, die während der Upload- und Downloadphasen der Mergesynchronisierung an ein Partnerreplikat gesendet werden sollen.

Die Merge-Agent verarbeitet Generationen in Batches, die auch als Generierungsbatches bezeichnet werden. Standardmäßig sind 100 Generationen in jedem Generationsbatch enthalten, den der Merge-Agent vom Abonnenten auf den Verleger hochlädt oder vom Verleger auf den Abonnenten herunterlädt. Die Batchgröße der Generierung kann über die -UploadGenerationsPerBatch Parameter und -DownloadGenerationsPerBatch Merge-Agent oder über das Merge-Agent-Profil konfiguriert werden. Wenn Sie im Standardfall mehr als 100 Generationen zwischen einem Herausgeber (oder einem erneuten Herausgeber) und einem Abonnenten austauschen müssen (d. h. herunterladen und hochladen oder beides), verarbeitet der Merge-Agent Batches mit mehreren Generationen. Die Anzahl der Batches hängt von der Anzahl der Generationen ab, die der Merge-Agent austauschen muss, und den Für eine bestimmte Zusammenführungssitzung gültigen Einstellungen der Generationen pro Batch.

In einer Situation, in der Batches mit mehreren Generationen ausgetauscht werden, kann die Merge-Agent verwandte übergeordnete und untergeordnete Änderungen auf zwei separate Generierungsbatches aufteilen. Wenn dies der Fall ist, kann die Merge-Agent eine untergeordnete Änderung in einem Generierungsbatch vor dem Generierungsbatch übermitteln, der die zugeordnete übergeordnete Änderung enthält. In hierarchischen Mergetopologien, in denen erneute Herausgeber verwendet werden, gibt es eine seltene Situation, in der die Aufteilung von übergeordneten und untergeordneten Änderungen über Generierungsbatches hinweg zu Nichtkonvergenz führen kann. Weitere Informationen zur Nichtkonververzz finden Sie im folgenden Artikel:

Nichtkonververzung, wenn SQL Server untergeordnete und übergeordnete Generationen in separaten Generierungsbatches verarbeitet.

Sie können die zuvor erläuterten -UploadGenerationsPerBatch Parameter und -DownloadGenerationsPerBatch erhöhen, um zu vermeiden, dass übergeordnete und untergeordnete Änderungen auf Generierungsbatches aufgeteilt werden.

Die Artikelverarbeitungsreihenfolge wird in einem bestimmten Generationsbatch gemäß den zuvor erläuterten Regeln beibehalten. Die Merge-Agent kann jedoch nicht die Reihenfolge der Artikelverarbeitung über Generierungsbatches hinweg aufrechterhalten.