Konflikterkennung und -lösung bei der Mergereplikation

Beim Erstellen eines Abonnements geben Sie an, ob es sich um ein Push- oder ein Pullabonnement, ein Client- oder ein Serverabonnement (in früheren Versionen von Microsoft SQL Server als lokales bzw. globales Abonnement bezeichnet) handeln soll. Wenn das Abonnement einmal erstellt ist, können Sie den Typ nicht mehr ändern.

Ein Abonnement mit einem zugewiesenen Priority-Wert (von 0,00 bis 99,99) wird als Serverabonnement bezeichnet; ein Abonnement, das den Priority-Wert des Verlegers verwendet, wird als Clientabonnement bezeichnet. Abonnenten, die über ein Serverabonnement verfügen, können selbst Daten auf anderen Abonnenten veröffentlichen. In der folgenden Tabelle werden die Hauptunterschiede und Verwendungsweisen der einzelnen Abonnententypen zusammengefasst.

Wird eine Zeile in einem Clientabonnement geändert, wird der Änderung erst dann eine Priorität zugewiesen, wenn das Abonnement synchronisiert wird. Während der Synchronisierung werden den Änderungen des Abonnenten die Priorität des Verlegers zugewiesen und behalten diese Priorität bei späteren Synchronisierungen bei. In gewisser Weise nimmt der Verleger die Urheberschaft der Änderung an. Diese Verhaltensweise ermöglicht dem ersten Abonnenten das Synchronisieren mit dem Verleger sowie den Gewinn bei späteren Zeilen- oder Spaltenänderungskonflikten mit anderen Abonnenten.

Wenn Sie eine Zeile in einem Serverabonnement ändern, wird die Abonnementpriorität für die Änderung in den Metadaten gespeichert. Dieser Priority-Wert wird mit der geänderten Zeile während der Zusammenführung mit Änderungen auf anderen Abonnenten übertragen. Dadurch wird sichergestellt, dass eine Änderung durch ein Abonnement höherer Priorität nicht gegen eine spätere Änderung durch ein Abonnement niedrigerer Priorität verliert.

Ein Abonnement darf keinen expliziten höheren Priority-Wert als sein Verleger besitzen. In einer Mergereplikationstopologie besitzt der Verleger der obersten Ebene immer einen expliziten Priority-Wert von 100,00. Alle Abonnenten der Veröffentlichung müssen eine niedrigere Priorität aufweisen. In einer Wiederveröffentlichungstopologie:

• Wenn der Abonnent Daten neu veröffentlicht, muss das Abonnement vom Typ Server sein und einen niedrigeren Priority-Wert als der Verleger über dem Abonnenten besitzen.

• Wenn der Abonnent keine Daten neu veröffentlicht (weil er sich auf der Blattebene der Wiederveröffentlichungsstruktur befindet), muss das Abonnement vom Typ Client sein.

Weitere Informationen zu Serverabonnements finden Sie unter Beispiel für die Lösung von Mergekonflikten auf der Basis des Abonnementtyps und der zugewiesenen Prioritäten.

Verzögerte Konfliktbenachrichtigung

Ob eine Datenänderung als Konflikt eingestuft wird, ist von dem Konfliktnachverfolgungstyp abhängig, den Sie für die einzelnen Artikel festlegen: Zeilenebene, Spaltenebene oder logische Datensätze. Weitere Informationen zur Nachverfolgung auf der Ebene des logischen Datensatzes finden Sie unter Ermitteln und Lösen von Konflikten in logischen Datensätzen.

Wenn Konflikte auf der Zeilenebene erkannt werden, werden Änderungen an den entsprechenden Zeilen als Konflikt eingestuft, unabhängig davon, ob die Änderungen an derselben Spalte vorgenommen werden. Nehmen Sie beispielsweise an, es wird eine Änderung an der address-Spalte einer Zeile auf dem Verleger und eine zweite Änderung an der phone number-Spalte (in derselben Tabelle) in der entsprechenden Zeile auf dem Abonnenten vorgenommen. Bei der Nachverfolgung auf Zeilenebene wird ein Konflikt erkannt, da Änderungen an derselben Zeile vorgenommen wurden. Bei der Nachverfolgung auf Spaltenebene wird kein Konflikt erkannt, da Änderungen zwar an derselben Zeile, jedoch in verschiedenen Spalten vorgenommen wurden.

Bei der Nachverfolgung auf Zeilenebene wie auch auf Spaltenebene ist die Konfliktlösung dieselbe: die gesamte Zeile wird mit den Daten des Konfliktgewinners überschrieben. Bei der Nachverfolgung auf der Ebene des logischen Datensatzes ist die Konfliktlösung von der Artikeleigenschaft logical_record_level_conflict_resolution abhängig.

Die Anwendungssemantik bestimmt in der Regel, welche Nachverfolgungsoption verwendet werden soll. Wenn Sie z. B. Kundendaten aktualisieren, die in der Regel gleichzeitig eingegeben werden, wie beispielsweise Adresse und Telefonnummer, empfiehlt es sich, die Nachverfolgung auf Zeilenebene auszuwählen. Wird in dieser Situation die Nachverfolgung auf Spaltenebene ausgewählt, werden Änderungen der Kundenadresse an einem Standort und der Kundentelefonnummer am anderen Standort nicht als Konflikt erkannt. Die Daten werden bei der Synchronisierung zusammengeführt, und der Fehler wird übersehen. In anderen Situationen kann sich das Aktualisieren einzelner Spalten von verschiedenen Standorten als logischste Wahl erweisen. Zwei Standorte haben z. B. Zugriff auf verschiedene Typen von statistischen Informationen zu einem Kunden, wie z. B. Höhe des Einkommens und Gesamtbetrag der Kreditkartenkäufe. Durch das Auswählen der Nachverfolgung auf Spaltenebene wird sichergestellt, dass an beiden Standorten statistische Daten für verschiedene Spalten eingegeben werden können, ohne unnötige Konflikte zu generieren.

Hinweis

Wenn für Ihre Anwendung die Nachverfolgung auf Spaltenebene nicht erforderlich ist, empfiehlt es sich, die Standardeinstellung Nachverfolgung auf Zeilenebene zu verwenden, da diese in der Regel eine höhere Synchronisierungsleistung erzielt. Wenn das Protokollieren auf Zeilenebene verwendet wird, darf die Basistabelle maximal 1.024 Spalten enthalten. Aus den Spalten muss jedoch der Artikel gefiltert werden, sodass maximal 246 Spalten veröffentlicht werden. Wenn das Protokollieren auf Spaltenebene verwendet wird, darf die Basistabelle maximal 246 Spalten enthalten.

Der Merge-Agent erkennt UPDATE/UPDATE-Konflikte, wenn eine UPDATE-Anweisung für eine Zeile, bzw. Spalte, oder für einen logischen Datensatz auf einem Knoten mit einem anderen UPDATE für dieselbe Zeile auf einem anderen Knoten in Konflikt steht. In diesem Fall sendet der Standardkonfliktlöser die gewinnende Version der Zeile an den verlierenden Knoten und protokolliert die Version der verlierenden Zeile in der Konflikttabelle des Artikels.

Der Merge-Agent erkennt UPDATE/DELETE-Konflikte, wenn aktualisierte Daten auf einem Knoten mit gelöschten Daten auf einem anderen in Konflikt stehen. In diesem Fall aktualisiert der Merge-Agent zunächst die eine Zeile; wenn er jedoch am Zielort nach dieser Zeile sucht, kann er sie nicht finden, da sie gelöscht wurde. Ist der Gewinner der Knoten, der die Zeile aktualisiert hat, wird das Löschen der Zeile auf dem verlierenden Knoten ignoriert und die aktualisierte Zeile an den Verlierer gesendet. Der Merge-Agent protokolliert die Informationen zu der verlierenden Version der Zeile in der MSmerge_conflicts_info-Tabelle.

Der Merge-Agent löst diese Konflikte aus, wenn bestimmte Änderungen nicht angewendet werden können. In der Regel tritt dies aufgrund von Unterschieden in den Einschränkungsdefinitionen des Verlegers und des Abonnenten sowie der Verwendung der Eigenschaft NOT FOR REPLICATION (NFR) mit der Einschränkung auf. Beispiele:

• Ein Fremdschlüsselkonflikt auf dem Abonnenten kann auftreten, wenn die Einschränkung seitens des Abonnenten nicht als NFR gekennzeichnet ist.

• Unterschiede in den Einschränkungen zwischen Verleger und Abonnenten, wenn die Eigenschaften nicht als NFR gekennzeichnet sind.

• Nichtverfügbarkeit von abhängigen Objekten beim Abonnenten. Wenn Sie beispielsweise eine Sicht veröffentlichen, die der Sicht zugrunde liegende Tabelle jedoch nicht, tritt ein Fehler auf, wenn Sie versuchen, beim Abonnenten über diese Sicht eine INSERT-Anweisung durchzuführen.

• Verknüpfungsfilterlogik bei einer Veröffentlichung ohne Übereinstimmung des Primärschlüssels und der Fremdschlüsseleinschränkungen. Konflikte können auftreten, wenn das relationale SQL Server-Datenbankmodul versucht, eine Einschränkung zu berücksichtigen, der Merge-Agent jedoch die Verknüpfungsfilterdefinition zwischen den Artikeln berücksichtigt. Der Merge-Agent kann dann die Änderung aufgrund der Einschränkungen auf Tabellenebene nicht auf dem Zielknoten anwenden, sodass ein Konflikt entsteht.

• Konflikte aufgrund von Verletzungen des eindeutigen Indexes, eindeutiger Einschränkungen oder des Primärschlüssels können auftreten, wenn Identitätsspalten für den Artikel definiert sind und keine automatische Identitätsverwaltung verwendet wird. Dies kann problematisch werden, wenn zwei Abonnenten denselben Identitätswert für eine neu eingefügte Zeile verwenden. Weitere Informationen zur Identitätsbereichsverwaltung finden Sie unter Replizieren von Identitätsspalten.

• Konflikte, wenn der Merge-Agent aufgrund von Triggerlogik keine Zeilen in die Zieltabelle einfügen kann. Wenn beim Abonnenten beispielsweise ein UPDATE-Trigger vorhanden ist, der nicht als NFR gekennzeichnet ist und in seiner Logik ein ROLLBACK aufweist, gibt der Trigger im Fall eines Fehlers ein ROLLBACK für die Transaktion aus. Dies führt dazu, dass der Merge-Agent einen fehlerhaften Änderungskonflikt erkennt.