INF: So zu verstehen, Merge Replication Artikel Verarbeitungsreihenfolge

Der Merge-Agent folgt auf einen bestimmten Satz von Regeln, die die Reihenfolge bestimmen, in der vom Mergeprozess Änderungen an Artikeln während des Synchronisierungsvorgangs anwendet.

Dieser Artikel beschreibt, warum die Verarbeitungsreihenfolge für Artikel wichtig ist.

Es gibt zwei Hauptgründe, warum die Verarbeitungsreihenfolge für Artikel wichtig ist:

• In vielen Fällen muss der Merge-Agent Änderungen an Artikeln verarbeiten, die Teilnahme von Einschränkungen der deklarativen referenziellen Integrität (DRI) in einer bestimmten Reihenfolge um eine optimale Leistung zu erreichen. Wenn nicht, der Merge-Agent (Data Manipulation Language, DML) Vorgänge zu wiederholen, haben möglicherweise versucht es in falscher Reihenfolge (die versuchen, ist, um eine untergeordnete Zeile vor der übergeordneten EINZUFÜGEN).
• Anwendungen, die Trigger, verwenden um die referenzielle Integrität zu erhalten, der Merge-Agent zum Senden von Änderungen in einer bestimmten Reihenfolge erfordern. Wenn der Merge-Agent Änderungen in falscher Reihenfolge sendet, der Trigger wird höchstwahrscheinlich Zurücknahme der Änderung und Weitergeben der Änderung nicht in der Replikationstopologie.

Beachten Sie, dass der Merge-Agent FOREIGN KEY-Einschränkung-Bewertung und Benutzer-Triggerausführung umgangen werden kann, wenn Sie SQL-DML angewendet wird ändern Operationen in einem Partner-Replikat. Damit dies geschieht müssen FOREIGN KEY-Einschränkung und die Benutzer-Trigger oder beides mit der Option NOT FOR REPLICATION erstellt wurden. In beiden Fällen wird der Mergeprozess davon ausgegangen, dass SQL Server die Geschäftslogik erfolgreich ausgewertet ist Wenn Sie die ursprüngliche Benutzer initiierte Änderung anhand des Objekts ausgeführt wird und dass es nicht diese Bedingungen neu zu bewerten, wenn Sie die Daten an das Partnerreplikat repliziert. Der Hauptvorteil der Verwendung von NOT FOR REPLICATION auf diese Weise ist die erhöhte Leistung. Weitere Informationen zu der Option NOT FOR REPLICATION und wie es angemessen verwendet finden Sie unter das Thema "Nicht für die Replikationsoption" in der Onlinedokumentation zu SQL Server 2000.

Für die zwei Gründe, die weiter oben aufgeführt wurden, unbedingt die Reihenfolge, in der der Merge-Agent Änderungen an einer Partner-Replikat übermittelt.

Vor Beginn einer Diskussion der Verarbeitungsreihenfolge Artikel, ist es wichtig, dass der zwei wichtigsten Konzepte vertraut sein. Die zwei wichtigsten Konzepte lauten wie folgt:

• Ein Artikel-Pseudonym.
  
• Eine Generation.

Es folgt eine Beschreibung der beiden Konzepte.

Verarbeitung von Einfügungen, Aktualisierungen und löscht

Der Merge-Agent Partitionen für eine bestimmte Veröffentlichung in zwei separate Gruppen Artikeln:

• Der Merge-Agent platziert Artikel, die alle Verknüpfungsbeziehungen-Filter nicht beteiligt sind, und nicht auf alle Artikel in einer Gruppe Verknüpfungsfilter beteiligt über DRI beziehen.
• Der Merge-Agent speichert Artikeln, die explizit beteiligt sind im Join Filter-Beziehungen und Artikeln im Zusammenhang mit der Filter-Artikeln über DRI in eine zweite distinct Gruppe beitreten.

Der Merge-Agent fügt jeder Artikel der Publikation nur auf eine der zuvor genannten Gruppen definiert.

Der Merge-Agent verwendet die Gruppen um zu bestimmen, die gesamte Bearbeitung der Bestellung von Aktualisierungen, Einfügungen und Löschungen für alle Artikel, die für die Publikation definiert.

In jedem der beiden entsprechenden Gruppen der Merge-Agent verarbeitet Einfügungen und Aktualisierungen in aufsteigender Reihenfolge der Artikel-Spitznamen, und Prozesse in absteigender Reihenfolge der Artikel-Pseudonym wird gelöscht. Erstens löscht den Merge-Agent-Prozesse, die alle in ihrer Gesamtheit in einer bestimmten Gruppe, gefolgt von Aktualisierungen und Einfügungen (auch in einer bestimmten Gruppe). Vom Konzept her, fügt der Merge-Agent die beiden genannten Gruppen mit einer anderen (nicht zusammengeführt) in der zuvor aufgeführten Reihenfolge. Der Merge-Agent beginnt mit der Verarbeitung von Löschungen für die erste Gruppe, und erweitert, Verarbeitung an die zweite Gruppe löschen und der Rest der Änderungen für die beiden Gruppen werden parallel verarbeitet. Obwohl der Merge-Agent Artikel Verarbeitungsreihenfolge in den jeweiligen Gruppen verwaltet werden, verwaltet der Merge-Agent keine strikte Artikel Verarbeitungsreihenfolge über die jeweiligen Gruppen. Im Falle einer INSERT- oder UPDATE ist es daher möglich, dass Änderungen aus der ersten Gruppe mit einem höheren Artikel Spitznamen voraus, von denen die zweite Gruppe mit einem niedrigeren Spitznamen eintreffen können. Die Situation umgekehrt kann auch bei einer DELETE auftreten. Diese Verhaltensweisen sind entwurfsbedingt.

Mögliche Auswirkungen der Batchverarbeitung auf Generation Artikel Verarbeitungsreihenfolge

Wie bereits erwähnt, können mit einer Generation Sie logisch Änderungen (Einfügungen, Aktualisierungen und Löschungen) gruppieren, die für einen bestimmten Artikel in einem bestimmten Replikat zwischen Synchronisationssitzungen auftreten. Letzten Endes der Merge-Agent arbeitet mit Generationen, wenn es, welche Änderungen ermittelt, Sie zwischen zwei Replikaten austauschen muss. Der Merge-Agent handelt es sich um eine gemeinsame Generation an den folgenden Punkten im Synchronisationsprozess:

• Bevor Sie Änderungen vom Abonnenten zum Verleger uploadet.
• Bevor Sie Änderungen vom Verleger auf den Abonnenten heruntergeladen.

Der Merge-Agent verwendet diese gemeinsamen Generation als Ausgangspunkt beim Aufzählen der Generationen zum Senden an einen Partner-Replikat während des Uploads und Downloadphasen der Mergesynchronisierung.

Der Merge-Agent verarbeitet Generierungen in Batches, die auch als Batches Generation bezeichnet. In der Standardeinstellung sind 100 Generierungen in jedem Batch Generation enthalten, die der Merge-Agent führt den Upload vom Abonnenten zum Verleger oder vom Verleger zum Abonnenten-downloads. Die Generierung von Batch-Größe ist konfigurierbar über die
-UploadGenerationsPerBatchund die-DownloadGenerationsPerBatchMerge-Agent-Parameter oder durch den Merge-Agent-profile. Im Standardfall, wenn mehr als 100 Generierungen vorhanden sind, Sie Exchange (d. h., Download und Upload oder beides) zwischen einem Verleger (oder einem Neuverleger müssen) und ein Abonnent, der Merge-Agent mehrere Generation Batches verarbeitet. Die Anzahl der Batches, hängt von der Anzahl der Generierungen, die der Merge-Agent wurde zum Austausch und die Generationen pro Batch Einstellungen in-Force für einen bestimmten Mergesitzung.

In einer Situation, in denen mehrere Generation Batches ausgetauscht werden, kann der Merge-Agent zugehörigen übergeordneten und untergeordneten Änderungen auf zwei separate Generation Stapel aufgeteilt. Wenn dies der Fall ist, darf der Merge-Agent eine untergeordneten-Änderung in einem Batch Generation voraus des Stapels Generation liefern, die die zugehörige übergeordnete Änderung enthält. In hierarchischen Merge-Topologien, die Re-publishers verwenden, ist eine seltene Situation, in dem die Aufteilung der über- und untergeordneten Änderungen auf Generation Batches zu non-Convergence führen kann. Weitere Informationen zu non-Convergence finden Sie im folgenden Artikel der Microsoft Knowledge Base:
Sie können erhöhen die-UploadGenerationsPerBatch
und die-DownloadGenerationsPerBatchum zu vermeiden, Aufteilung von übergeordneten und untergeordneten Änderungen auf Generation Batches zuvor beschriebenen Parametern.

Artikel Verarbeitungsreihenfolge wird in einem bestimmten Generierungsbatch besprochenen Vorschriften verwaltet. Der Merge-Agent kann nicht jedoch Artikel, die Bearbeitung der Bestellung über Generation Batches beibehalten.