Daten werden nicht an Abonnenten übermittelt

Wenn es dazu kommt, dass Daten nicht an Abonnenten übermittelt werden, gibt es dafür zwei generelle Gründe:

  • Die Daten werden – aufgrund einer Filterung, eines Agentproblems oder eines anderen Replikationsfehlers – nicht übernommen.

  • Die Daten werden nach der Bereitstellung auf dem Abonnenten gelöscht.

Erklärung

Wenn Daten nicht an Abonnenten übermittelt werden, sind dafür die folgenden Ursachen denkbar:

  • Die Tabelle wird gefiltert, und es sind keine Änderungen vorhanden, die an den betreffenden Abonnenten übermittelt werden müssten.

  • Einer oder mehrere der Agents werden nicht ausgeführt oder sind aufgrund eines Fehlers nicht verfügbar.

  • Ein Transaktionsabonnement wurde ohne Momentaufnahme initialisiert, und seit dem Erstellen der Veröffentlichung ist es auf dem Verleger zu Änderungen gekommen.

  • Die Replikation der Ausführung der gespeicherten Prozedur für eine Transaktionsveröffentlichung führt auf dem Abonnenten zu unterschiedlichen Ergebnissen.

  • Die von einem Transaktionsartikel verwendete gespeicherte Prozedur INSERT enthält eine Bedingung, die nicht erfüllt ist.

  • Die Daten wurden von einem Benutzer, einem Replikationsskript oder einer anderen Anwendung gelöscht.

  • Die Daten wurden von einem Trigger gelöscht, oder ein Trigger enthält eine ROLLBACK-Anweisung.

Benutzeraktion

Bevor Sie versuchen herauszufinden, warum die Daten nicht an Abonnenten übermittelt wurden, sollten Sie durch Validierung oder mithilfe des Hilfsprogramms tablediff überprüfen, ob Zeilen fehlen:

  • Wenn der Verteilungs-Agent oder der Merge-Agent ausgeführt werden kann, stellen Sie fest, ob Daten fehlen, indem Sie eine binäre Prüfsummenüberprüfung ausführen. Sie können auch eine Zeilenanzahlüberprüfung verwenden, bei dieser Methode werden aber Unterschiede im Inhalt der Daten nicht aufgedeckt. Weitere Informationen finden Sie unter Überprüfen von replizierten Daten.

  • Wenn der Verteilungs-Agent oder der Merge-Agent nicht ausgeführt werden kann, stellen Sie fest, ob Daten fehlen, indem Sie das Hilfsprogramm tablediff ausführen. Informationen zum Verwenden dieses Hilfsprogramms bei replizierten Tabellen finden Sie unter Vorgehensweise: Überprüfen replizierter Tabellen auf Unterschiede (Replikationsprogrammierung).

Ermitteln der Ursache für das Fehlen von Daten

Mit den folgenden Aktionen können Sie den im Abschnitt zur Erläuterung angegebenen Ursachen auf den Grund gehen:

  • Die Tabelle wird gefiltert, und es sind keine Änderungen vorhanden, die an den betreffenden Abonnenten übermittelt werden müssten.

    Möglicherweise wurden die auf dem Abonnenten fehlenden Zeilen nicht repliziert, weil sie nicht den Filterkriterien für die Veröffentlichung entsprechen. Alle Replikationstypen unterstützen statische Filter, und bei der Mergereplikation werden darüber hinaus auch parametrisierte Filter und Joinfilter unterstützt. Weitere Informationen finden Sie unter Filtern von veröffentlichten Daten. Wenn einer oder mehrere der Artikel in der Veröffentlichung herausgefiltert werden, führen Sie die folgenden Schritte durch, und überprüfen Sie den Wert der Filterklausel:

    Bestimmen Sie anhand der Filterklausel, ob unter den fehlenden Zeilen solche sind, die den Filterkriterien entsprechen. Dazu könnten Sie z. B. die Filterklausel gegen die Tabelle auf dem Verleger ausführen, um so festzustellen, ob die zurückgegebenen Daten mit den Daten auf dem Abonnenten übereinstimmen.

  • Einer oder mehrere der Agents werden nicht ausgeführt oder sind aufgrund eines Fehlers nicht verfügbar:

  • Ein Transaktionsabonnement wurde ohne Momentaufnahme initialisiert, und seit dem Erstellen der Veröffentlichung ist es auf dem Verleger zu Änderungen gekommen:

    • Wenn Sie für eine Veröffentlichung festgelegt haben, dass sie von einer Sicherung aus initialisiert werden soll, werden Änderungen an den veröffentlichten Tabellen im Veröffentlichungsdatenbankprotokoll ab dem Zeitpunkt verfolgt, ab dem die Veröffentlichung erstellt ist. Bei der Initialisierung eines Abonnements werden ausstehende Änderungen so lange an den Abonnenten übermittelt, so lange sie in der Verteilungsdatenbank noch verfügbar sind.

    • Beim Initialisieren eines Abonnements mithilfe der replication support only-Option müssen Sie oder Ihre Anwendung – im Gegensatz zum Initialisieren aus einer Sicherung – sicherstellen, dass die Daten und das Schema ordnungsgemäß synchronisiert sind, wenn das Abonnement hinzugefügt wird. Wenn es zwischen dem Zeitpunkt, zu dem die Daten und das Schema auf den Abonnenten kopiert wurden, und dem Zeitpunkt, zu dem das Abonnement hinzugefügt wird, z. B. auf dem Verleger zu einer Aktivität gekommen ist, kann es passieren, dass Änderungen, die sich aus dieser Aktivität ergeben, nicht auf den Abonnenten repliziert werden.

    Weitere Informationen finden Sie unter Initialisieren eines Transaktionsabonnements ohne Snapshot.

  • Die Replikation der Ausführung der gespeicherten Prozedur für eine Transaktionsveröffentlichung führt auf dem Abonnenten zu unterschiedlichen Ergebnissen.

    Wenn Sie die Ausführung einer gespeicherten Prozedur replizieren, wird die Prozedurdefinition beim Initialisieren des Abonnements auf den Abonnenten repliziert. Wird die Prozedur auf dem Verleger ausgeführt, führt die Replikation die entsprechende Prozedur auf dem Abonnenten aus. Weitere Informationen finden Sie unter Veröffentlichen der Ausführung von gespeicherten Prozeduren in der Transaktionsreplikation.

    Wenn die gespeicherte Prozedur eine andere Aktion auf dem Abonnenten ausführt oder auf der Basis anderer Daten als der Daten auf dem Verleger agiert, kann es zu Nichtkonvergenz kommen. Stellen Sie sich z. B. eine Prozedur vor, die eine Berechnung vornimmt und die dann die auf dieser Berechnung basierenden Daten einfügt. Wenn der Abonnent so gefiltert wird, dass die Berechnung auf dem Abonnenten auf der Grundlage anderer Daten erfolgt, kann das auf dem Abonnenten eingefügte Ergebnis abweichen, oder die berechneten Daten werden überhaupt nicht eingefügt.

  • Die von einem Transaktionsartikel verwendete gespeicherte Prozedur INSERT enthält eine Bedingung, die nicht erfüllt ist.

    Bei der Transaktionsreplikation wird zur Weiterleitung von Änderungen an die Abonnenten standardmäßig ein Satz gespeicherter Prozeduren verwendet. Sie können diese Prozeduren auch anpassen und auf diese Weise die für Ihre Anwendung erforderliche Geschäftslogik integrieren. Weitere Informationen finden Sie unter Angeben der Weitergabemethode für Änderungen bei Transaktionsartikeln. Wenn die gespeicherte Prozedur INSERT in ihrer Logik eine Bedingung enthält, die nicht erfüllt wird, erfolgt keine Einfügung. Stellen Sie sich z. B. eine Prozedur vor, die dahingehend angepasst wurde, dass zunächst in einer Tabelle (Tabelle A) auf dem Abonnenten ein bestimmter Wert geprüft werden muss, bevor eine Einfügung in einer anderen Tabelle (Tabelle B) erfolgen darf. Wenn der entsprechende Wert in Tabelle A nicht verfügbar ist, weil ein Fehler aufgetreten ist oder weil die Daten noch nicht in diese Tabelle repliziert wurden, fehlt die erwartete Zeile in Tabelle B.

  • Die Daten wurden von einem Benutzer, einem Replikationsskript oder einer anderen Anwendung gelöscht:

    • Wenn Benutzer Daten auf dem Abonnenten löschen können dürfen, verwenden Sie die Mergereplikation, die Transaktionsreplikation mit aktualisierbaren Abonnements oder die Peer-zu-Peer-Transaktionsreplikation. Löschungen werden an den Verleger weitergegeben, sodass die Daten auf dem Verleger und dem Abonnenten letztendlich übereinstimmen. Weitere Informationen finden Sie unter Mergereplikation (Übersicht) und Veröffentlichungstypen der Transaktionsreplikation.

    • Wenn die Benutzer keine Daten auf dem Abonnenten löschen können sollen, erstellen Sie für jede Tabelle einen Trigger, der das Wort ROLLBACK enthält, und verwenden Sie die Option NOT FOR REPLICATION (dadurch wird verhindert, dass der Trigger ausgelöst wird, wenn ein Replikations-Agent eine Operation ausführt). Beispiel:

      USE AdventureWorks2008R2;
      GO
      CREATE TRIGGER prevent_user_dml
      ON Person.Address
      FOR INSERT, UPDATE, DELETE
      NOT FOR REPLICATION
      AS
      ROLLBACK;
      

      Weitere Informationen finden Sie unter CREATE TRIGGER (Transact-SQL) und Steuern von Einschränkungen, Identitäten und Triggern mithilfe von NOT FOR REPLICATION.

    • Die Replikation ermöglicht es Ihnen, Skripts vor und nach dem Anwenden der Momentaufnahme und während der Synchronisierung auszuführen. Mithilfe der @pre_snapshot_script- und @post_snapshot_script-Parameter von sp_addpublication und sp_addmergepublication können Sie angeben, ob die Skripts vor oder nach dem Anwenden der Momentaufnahme ausgeführt werden sollen. Weitere Informationen finden Sie unter Ausführen von Skripts vor und nach dem Anwenden des Snapshots. Die gespeicherte Prozedur sp_addscriptexec ermöglicht die Ausführung eines Skripts während des Synchronisierungsprozesses. Weitere Informationen finden Sie unter Vorgehensweise: Ausführen von Skripts während der Synchronisierung (Replikationsprogrammierung mit Transact-SQL).

      Diese Skripts werden typischerweise für Verwaltungsaufgaben verwendet, wie z. B. für das Hinzufügen von Benutzernamen auf dem Abonnenten. Wenn die Skripts zum Löschen von Daten auf einem Abonnenten verwendet werden, der als schreibgeschützt zu behandeln ist, muss der Administrator sicherstellen, dass keine Nichtkonvergenz entsteht.

  • Die Daten wurden von einem Trigger gelöscht, oder ein Trigger enthält eine ROLLBACK-Anweisung.

    Trigger auf dem Abonnenten müssen ordnungsgemäß verwaltet werden, damit sie nicht zu Nichtkonvergenz oder zu anderen Problemen führen:

    • Trigger dürfen nur zu Datenänderungen auf einem Abonnenten führen, wenn Sie die Mergereplikation, die Transaktionsreplikation mit aktualisierbaren Abonnements oder die Peer-zu-Peer-Transaktionsreplikation verwenden. Weitere Informationen finden Sie unter Mergereplikation (Übersicht) und Veröffentlichungstypen der Transaktionsreplikation.

    • In vielen Fällen sollten Trigger die Option NOT FOR REPLICATION verwenden. Wenn ein Trigger eine ROLLBACK-Anweisung enthält und der Trigger nicht die Option NOT FOR REPLICATION verwendet, kann es passieren, dass Zeilen, die auf einen Abonnenten repliziert wurden, nicht angewendet werden.

    • Bei der Transaktionsreplikation sind zusätzliche Überlegungen zur XACT_ABORT-Einstellung und zum Verwenden der COMMIT- und ROLLBACK-Anweisungen in einem Trigger anzustellen. Weitere Informationen dazu finden Sie im Abschnitt zu den Triggern unter Überlegungen zur Transaktionsreplikation.

Siehe auch

Konzepte