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:
Statischer Filter für Momentaufnahme- und Transaktionsveröffentlichungen: die von sp_helparticle (Transact-SQL) zurückgegebene filter_clause-Spalte.
Statischer Filter oder parametrisierter Filter für Mergeveröffentlichungen: die von sp_helpmergearticle (Transact-SQL) zurückgegebene subset_filterclause-Spalte.
Joinfilter für Mergeveröffentlichungen: die von sp_helpmergefilter (Transact-SQL) zurückgegebene join_filterclause-Spalte.
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:
Wenn Sie ein Abonnement initialisieren, stellen Sie sicher, dass die Momentaufnahme mit dem Verteilungs-Agent oder dem Merge-Agent erst nach Abschluss des Momentaufnahme-Agents für die Veröffentlichung angewendet wird. Anderenfalls wird folgende Fehlermeldung ausgegeben: "Die Anfangsmomentaufnahme für die '%s'-Veröffentlichung ist noch nicht verfügbar."
Bei einer Transaktionsreplikation müssen Sie sicherstellen, dass der Verteilungs-Agent und der Protokolllese-Agent ausgeführt werden. Bei einer Mergereplikation muss der Merge-Agent ausgeführt werden. Informationen zum Starten dieser Agents finden Sie unter Vorgehensweise: Starten und Beenden eines Replikations-Agents (SQL Server Management Studio) und Ausführbare Konzepte für die Programmierung von Replikations-Agents.
Wenn ein Agent aufgrund eines Fehlers beendet wird, rufen Sie die Fehlerdetails für diesen Agent auf, um die Ursache für den Fehler herauszufinden. Informationen dazu, wie Sie die Fehlerdetails für den Momentaufnahme-Agent und den Protokolllese-Agent aufrufen können, finden Sie unter Vorgehensweise: Anzeigen von Informationen und Ausführen von Aufgaben für die einer Veröffentlichung zugeordneten Agents (Replikationsmonitor). Informationen zum Verteilungs-Agent und zum Merge-Agent finden Sie unter Vorgehensweise: Anzeigen von Informationen und Ausführen von Aufgaben für die einem Abonnement zugeordneten Agents (Replikationsmonitor). Wenn der Fehler weiterhin auftritt, erhöhen Sie den Protokolliergrad des Agents, und geben Sie eine Ausgabedatei für das Protokoll an. Je nach Zusammenhang, in dem der Fehler auftritt, finden Sie hier möglicherweise die Schritte, die zum Fehler führen, und/oder weitere Fehlermeldungen. Weitere Informationen finden Sie unter Replikations-Agents (Problembehandlung).
Die Nichtübermittlung von Daten ist häufig auf Probleme bei den Berechtigungen und Einschränkungsverletzungen zurückzuführen. Weitere Informationen zu Fragen im Zusammenhang mit Berechtigungen finden Sie unter Datenreplikation aufgrund von Sicherheitsproblemen nicht möglich. Einschränkungsverletzungen führen dazu, dass Zeilen auf dem Abonnenten nicht eingefügt werden.
Bei einer Transaktionsreplikation werden Einschränkungsverletzungen als Fehler behandelt. Sie führen dazu, dass der Verteilungs-Agent die Synchronisierung beendet. (Informationen zum Übergehen dieser Fehler finden Sie unter Überspringen von Fehlern in der Transaktionsreplikation.) Bei einer Mergereplikation werden Einschränkungsverletzungen als Konflikte behandelt. Diese Konflikte werden zwar protokolliert, führen aber nicht dazu, dass der Merge-Agent die Synchronisierung beendet. Bei beiden Replikationstypen können Einschränkungsverletzungen zu Nichtkonvergenz führen, wenn eine an einem Knoten erfolgte Einfügung, Aktualisierung oder Löschung nicht auch an einem anderen Knoten erfolgt.
Beim Veröffentlichen einer Tabelle wird durch die Standardschemaoptionen angegeben, dass FOREIGN KEY- und CHECK-Einschränkungen in der Abonnementdatenbank mit dem Optionssatz NOT FOR REPLICATION zu erstellen sind. Wenn Ihre Anwendung andere Einstellungen für die Einschränkungen verlangt, ändern Sie die Schemaoptionen entsprechend. Weitere Informationen finden Sie unter Vorgehensweise: Angeben von Schemaoptionen (SQL Server Management Studio) und Vorgehensweise: Angeben von Schemaoptionen (Replikationsprogrammierung mit Transact-SQL).
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.