Freigeben über

  • Artikel

Überlegungen zur Transaktionsreplikation

Bei der Transaktionsreplikation sind mehrere Punkte zu berücksichtigen:

  • Transaktionsprotokollspeicher

  • Speicherplatz für die Verteilungsdatenbank

  • Primärschlüssel für jede veröffentlichte Tabelle

  • Trigger

  • LOB-Datentypen (Large Object)

  • Aktualisierbare Abonnements (sofern verwendet). Weitere Informationen zu den Überlegungen für aktualisierbare Abonnements finden Sie unter Aktualisierbare Abonnements für die Transaktionsreplikation.

Transaktionsprotokollspeicher

Für jede bei der Transaktionsreplikation veröffentlichte Datenbank sollten Sie sicherstellen, dass genügend Speicherplatz für das Transaktionsprotokoll zugeordnet wurde. Für das Transaktionsprotokoll einer veröffentlichten Datenbank ist möglicherweise mehr Speicherplatz erforderlich als für das Protokoll einer identischen nicht veröffentlichten Datenbank, da die Protokolldatensätze bis zum Verschieben in die Verteilungsdatenbank nicht abgeschnitten werden.

Falls die Verteilungsdatenbank nicht verfügbar ist oder der Protokolllese-Agent nicht ausgeführt wird, nimmt die Größe des Transaktionsprotokolls einer Veröffentlichungsdatenbank kontinuierlich zu. Das Protokoll kann nicht über die ältesten veröffentlichten Transaktionen hinaus abgeschnitten werden, die nicht in die Verteilungsdatenbank übernommen wurden. Es wird empfohlen, die Transaktionsprotokolldatei auf automatische Vergrößerung festzulegen, sodass das Protokoll diese Fälle unterstützt. Weitere Informationen finden Sie unter CREATE DATABASE (Transact-SQL) und ALTER DATABASE (Transact-SQL).

Es empfiehlt sich, für die Verteilungsdatenbank die Option sync with backup festzulegen, mit der das Abschneiden des Protokolls in der Veröffentlichungsdatenbank verzögert wird, bis die entsprechenden Transaktionen in der Verteilungsdatenbank gesichert wurden. Dies kann zu einem umfangreicheren Transaktionsprotokoll in der Veröffentlichungsdatenbank führen. Weitere Informationen zu dieser Option finden Sie unter Strategien zum Sichern und Wiederherstellen einer Snapshot- und Transaktionsreplikation.

Speicherplatz für die Verteilungsdatenbank

Stellen Sie sicher, dass genügend Speicherplatz für die replizierten Transaktionen in der Verteilungsdatenbank vorhanden ist:

  • Wenn Sie den Abonnenten die Snapshotdateien nicht umgehend zur Verfügung stellen (dies ist die Standardeinstellung), gilt Folgendes: Transaktionen werden so lange gespeichert, bis sie auf alle Abonnenten repliziert wurden oder bis die Beibehaltungsdauer erreicht wurde, je nachdem, welcher Vorgang kürzer ist.

  • Wenn Sie eine Transaktionsveröffentlichung erstellen und den Abonnenten die Snapshotdateien umgehend zur Verfügung stellen, gilt Folgendes: Transaktionen werden so lange gespeichert, bis sie auf alle Abonnenten repliziert wurden oder bis der Snapshot-Agent ausgeführt wird und einen neuen Snapshot erstellt, je nachdem, welcher Vorgang länger dauert. Wenn der Zeitraum, in dem der Snapshot-Agent ausgeführt wird, größer ist als die maximale Beibehaltungsdauer der Verteilung für die Veröffentlichung, werden Transaktionen aus der Verteilungsdatenbank entfernt, die älter als die Beibehaltungsdauer sind. Die maximale Beibehaltungsdauer beträgt standardmäßig 72 Stunden. Weitere Informationen finden Sie unter Abonnementablauf und -deaktivierung.

Obwohl das sofortige zur Verfügung stellen des Snapshots für die Abonnenten die Geschwindigkeit verbessert, mit der neue Abonnenten auf die Veröffentlichung zugreifen können, kann diese Option einen größeren Speicherplatzbereich für die Verteilungsdatenbank beanspruchen. Dies bedeutet auch, dass bei jedem Ausführen des Snapshot-Agents ein neuer Snapshot generiert wird. Wenn die Option nicht verwendet wird, wird ein neuer Snapshot nur generiert, wenn ein neues Abonnement vorhanden ist.

Primärschlüssel für jede veröffentlichte Tabelle

Alle veröffentlichten Tabellen in der Transaktionsreplikation müssen einen deklarierten Primärschlüssel enthalten. Vorhandene Tabellen können für die Veröffentlichung vorbereitet werden, indem ein Primärschlüssel über die Transact-SQL-Anweisung ALTER TABLE (Transact-SQL) hinzugefügt wird.

Trigger

Achten Sie bei der Verwendung von Triggern in einer Abonnementdatenbank auf folgende Probleme:

  • Standardmäßig ist bei der Ausführung von Triggern die XACT_ABORT-Einstellung auf ON festgelegt. Wenn durch eine Anweisung in einem Trigger ein Fehler verursacht wird, während der Verteilungs-Agent Änderungen auf dem Abonnenten anwendet, schlägt der gesamte Batch für die Änderungen fehl, nicht die jeweilige Anweisung. Bei der Transaktionsreplikation können mithilfe des -SkipErrors-Parameters des Verteilungs-Agents Anweisungen ausgelassen werden, die zu Fehlern führen. Wenn -SkipErrors bei aktivierter XACT_ABORT-Einstellung (ON) verwendet wird, wird der gesamte Batch für die Änderungen ausgelassen, wenn eine Anweisung zu einem Fehler führt. Wenn XACT_ABORT in Triggern nicht auf ON festgelegt sein muss, empfiehlt sich bei der Verwendung des -SkipErrors-Parameters die Einstellung OFF. Geben Sie zur Deaktivierung der Option SET XACT_ABORT OFF in der Triggerdefinition an. Weitere Informationen zu XACT_ABORT finden Sie unter SET XACT_ABORT (Transact-SQL). Weitere Informationen zum -SkipErrors-Parameter finden Sie unter Überspringen von Fehlern in der Transaktionsreplikation.

  • Es wird davon abgeraten, explizite Transaktionen in Trigger auf dem Abonnenten aufzunehmen. Bei Transaktionsreplikationen wird die Batchverarbeitung von Transaktionen angewendet, um die Anzahl der Netzwerkroundtrips zu reduzieren und so die Leistung zu steigern. Wenn auf dem Abonnenten Trigger hinzugefügt werden, die ROLLBACK-Anweisungen enthalten, können Transaktionsbatches abgebrochen und Serverfehler 266 ausgelöst werden (die Transaktionsanzahl nach EXECUTE zeigt an, dass eine COMMIT- oder ROLLBACK TRANSACTION-Anweisung fehlt. Vorherige Anzahl = %ld, aktuelle Anzahl = %ld.). Ein Batch kann Befehle aus mehreren Transaktionen enthalten oder Teil einer umfangreichen Transaktion auf dem Verleger sein, sodass durch das Ausführen eines Rollbacks für Transaktionen die Transaktionsintegrität gefährdet werden kann.

    Wenn Sie explizite Transaktionen aufnehmen, sollten Sie sicherstellen, dass alle COMMIT-Anweisungen in einem Trigger über entsprechende BEGIN TRANSACTION-Anweisungen verfügen. Eine COMMIT-Anweisung ohne zugehörige BEGIN TRANSACTION-Anweisung verursacht eine Nichttransaktionsanwendung von Zeilenänderungen auf dem Abonnenten. Darüber hinaus kann zu einem späteren Zeitpunkt ein Fehler auftreten, wenn der Verteilungs-Agent Serverfehler 266 erkennt und versucht, ein Rollback der Transaktion oder des Befehlsbatches auszuführen, um diese dann erneut anzuwenden. Wenn der Agent versucht, bereits angewendete Befehle anzuwenden, kommt es zu Fehlern aufgrund von doppelten Schlüsseln.

Weitere Informationen zu Triggern finden Sie unter Steuern von Einschränkungen, Identitäten und Triggern mithilfe von NOT FOR REPLICATION.

LOB-Datentypen (Large Object)

Die Transaktionsreplikation unterstützt die Veröffentlichung von LOBs und führt Teilaktualisierungen von LOB-Spalten aus: Wenn eine LOB-Spalte aktualisiert wird, wird nur das Datenfragment mit geänderten Daten anstelle der vollständigen Daten in der Spalte repliziert.

Beachten Sie folgende Parameter des Verteilungs-Agents, wenn eine veröffentlichte Tabelle LOBs enthält: -UseOledbStreaming, -OledbStreamThreshold und -PacketSize. Diese Parameter lassen sich am einfachsten mit dem Verteilungs-Agent-Profil namens Verteilungsprofil für das OLE DB-Streaming festlegen. Weitere Informationen finden Sie unter Replikations-Agent-Profile. Zusätzlich zu diesem vordefinierten Profil kann der Parameter in einem von Ihnen erstellten oder modifizierten Agentprofil oder in der Befehlszeile angegeben werden. Weitere Informationen finden Sie auf:

text-, ntext- und image-Datentypen

Der Replikationsvorgang für text-, ntext- und image-Datentypen in einer Transaktionsveröffentlichung ist von mehreren Überlegungen abhängig. Es wird empfohlen, jeweils die Datentypen varchar(max), nvarchar(max), varbinary(max) anstelle der Datentypen text, ntext und image zu verwenden.

Achten Sie auf Folgendes, wenn Sie text, ntext oder image verwenden:

  • WRITETEXT- und UPDATETEXT-Anweisungen sollten in explizite Transaktionen eingebunden sein.

  • Protokollierte Textoperationen können mithilfe von WRITETEXT und UPDATETEXT mit der Option WITH LOG für veröffentlichte Tabellen repliziert werden. Die WITH LOG-Option ist erforderlich, da die Transaktionsreplikation Änderungen im Transaktionsprotokoll verfolgt.

  • UPDATETEXT-Operationen können nur verwendet werden, wenn auf allen Abonnenten SQL Server ausgeführt wird. WRITETEXT-Operationen werden als UPDATE-Anweisungen repliziert, sodass sie auch mit Abonnenten verwendet werden können, auf denen nicht SQL Server ausgeführt wird.

  • Ein konfigurierbarer max text repl size-Parameter steuert die maximale Größe von text-, ntext-, varchar(max)-, nvarchar(max)- und image-Daten (in Bytes), die repliziert werden können. Dies ermöglicht die Unterstützung von ODBC-Treibern und OLE DB-Anbietern, von Anbietern für SQL Server Database Engine (Datenbankmodul), die keine großen Werte für diese Datentypen verarbeiten können, sowie die Unterstützung von Verteilern, deren Systemressourcen (virtueller Arbeitsspeicher) eingeschränkt sind. Wenn eine Spalte mit einem dieser Datentypen veröffentlicht wird und eine INSERT-, UPDATE-, WRITETEXT- oder UPDATETEXT-Operation ausgeführt wird, die den konfigurierten Grenzwert überschreitet, erzeugt die Operation einen Fehler.

    Beim Verwenden der gespeicherten Systemprozedur sp_configure (Transact-SQL) wird der max text repl size-Parameter festgelegt.

  • Beim Veröffentlichen von text-, ntext- und image-Spalten sollte der Textzeiger innerhalb derselben Transaktion abgerufen werden wie die UPDATETEXT- oder WRITETEXT-Operation (und mit Lesewiederholbarkeit). Sie sollten z. B. nicht den Textzeiger in einer Transaktion abrufen und dann in einer anderen verwenden. Er wurde möglicherweise verschoben und somit ungültig.

    Wenn der Textzeiger abgerufen wurde, sollten Sie außerdem keine Operationen ausführen, die den Standort des Textes ändern können, auf den der Textzeiger verweist (z. B. Aktualisieren des Primärschlüssels), bevor Sie die UPDATETEXT- oder WRITETEXT-Anweisung ausführen.

    Dies ist die empfohlene Vorgehensweise zum Verwenden der UPDATETEXT- und WRITETEXT-Operationen bei zu replizierenden Daten:

    1. Starten Sie die Transaktion.

    2. Rufen Sie den Textzeiger über die TEXTPTR()-Funktion mit der Isolationsstufe REPEATABLE READ ab.

    3. Verwenden Sie den des Textzeiger in der UPDATETEXT- oder WRITETEXT-Operation.

    4. Führen Sie einen Commit für die Transaktion aus.

      HinweisHinweis

      Wenn Sie den Textzeiger nicht in derselben Transaktion abrufen, sind zwar Änderungen auf dem Verleger zulässig, die Änderungen werden jedoch nicht auf den Abonnenten veröffentlicht.

    Beispiel:

    SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
BEGIN TRAN
DECLARE @mytextptr varbinary(16)
SELECT @mytextptr = textptr(Notes)
FROM Employees 
WHERE EmployeeID = '7'
IF @mytextptr IS NOT NULL 
BEGIN
UPDATETEXT Employees.Notes @mytextptr 0 NULL 'Terrific job this review period.'
-- Dummy update to fire trigger that will update metadata and ensure the update gets propagated to other Subscribers.
UPDATE Employees 
-- Set value equal to itself.
SET Notes = Notes
WHERE EmployeeID = '7' 
END
COMMIT TRAN 
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
HinweisHinweis

Dieses Beispiel basiert auf der Northwind-Datenbank, die nicht standardmäßig installiert wird. Informationen über das Installieren dieser Datenbank finden Sie in den Beispieldatenbanken Northwind und pubs im Microsoft-Download Center.

Eine wichtige Überlegung beim Anpassen der Größe von Abonnentendatenbanken besteht darin, dass der Textzeiger für replizierte text-, ntext- und image-Spalten für Abonnententabellen initialisiert werden muss, auch wenn diese nicht auf dem Verleger initialisiert wurden. Daher benötigt jede vom Verteilungstask zur Abonnententabelle hinzugefügte text-, ntext- und image-Spalte mindestens 43 Byte an Datenbankspeicher, auch wenn kein Inhalt vorhanden ist.