Verbessern der Leistung der Mergereplikation

Gilt für:SQL Server

Im Anschluss an die in Verbessern der allgemeinen Replikationsleistungbeschriebenen Überlegungen zur allgemeinen Leistung sollten Sie sich Gedanken über die im Folgenden beschriebenen zusätzlichen Aspekte im Zusammenhang mit einer Mergereplikation machen.

Datenbankentwurf

  • Indizieren Sie Spalten, die in Zeilenfiltern und Joinfiltern verwendet werden.

    Erstellen Sie beim Verwenden eines Zeilenfilters für einen veröffentlichten Artikel einen Index für jede Spalte, die in der WHERE-Klausel des Filters verwendet wird. Ohne Index muss Microsoft SQL Server jede Zeile in der Tabelle lesen, um zu bestimmen, ob die Zeile in die Partition aufgenommen werden soll. Mit einem Index kann SQL Server schnell finden, welche Zeilen einbezogen werden sollen. Am schnellsten geht die Verarbeitung, wenn die Replikation die WHERE-Klausel des Filters vollständig allein aus dem Index auflösen kann.

    Außerdem sollten auch alle Spalten indiziert werden, die in Joinfiltern verwendet werden. Bei jeder Ausführung des Merge-Agents durchsucht dieser die Basistabelle, um festzustellen, welche Zeilen in einer übergeordneten Tabelle und welche Zeilen in verknüpften Tabellen in eine Partition aufzunehmen sind. Das Erstellen eines Indexes für die verknüpften Spalten vermeidet, dass SQL Server jede Zeile in der Tabelle jedes Mal liest, wenn die Merge-Agent ausgeführt wird.

    Weitere Informationen zur Filterung finden Sie unter Filtern von veröffentlichten Daten für die Mergereplikation.

  • Überlegen Sie, ob Sie Tabellen, die LOB-Datentypen (Large Object) enthalten, übernormalisieren sollten.

    Bei der Synchronisierung muss der Merge-Agent möglicherweise die gesamte Datenzeile von einem Verleger oder Abonnenten lesen und übertragen. Falls die Zeile Spalten enthält, die LOBs verwenden, kann dieser Vorgang eine zusätzliche Speicherbelegung erfordern und die Leistung beeinträchtigen, auch wenn diese Spalten gar nicht aktualisiert wurden. Um die Wahrscheinlichkeit einer solchen Leistungsbeeinträchtigung zu verringern, sollten Sie LOB-Spalten in einer separaten Tabelle mit einer 1:1-Beziehung zu den restlichen Zeilendaten speichern. Die Datentypen text, ntextund image sind als veraltet markiert. Wenn Sie LOBs verwenden, sollten Sie auf die Datentypen varchar(max), nvarchar(max)und varbinary(max)zurückgreifen.

Veröffentlichungsentwurf

  • Verwenden Sie eine Publikationskompatibilitätsebene von 90RTM (SQL Server 2005 (9.x) oder einer höheren Version.

    Wenn mindestens eine Abonnenten eine andere Version von SQL Server verwenden, geben Sie an, dass die Publikation nur SQL Server 2005 (9.x) oder eine höhere Version unterstützen muss. Auf diese Weise kommt die Veröffentlichung in den Genuss der neuen Funktionen und Leistungsoptimierungen.

  • Verwenden Sie geeignete Einstellungen für die Beibehaltungsdauer der Veröffentlichung.

    Die Beibehaltungsdauer der Veröffentlichung (also die Zeit, nach deren Ablauf das Abonnement wieder synchronisiert werden muss) bestimmt, wie lange die Nachverfolgungsmetadaten gespeichert werden. Ein hoher Wert kann sich negativ auf die Speicher- und Verarbeitungsleistung auswirken. Weitere Informationen zum Festlegen der Beibehaltungsdauer der Veröffentlichung finden Sie unter Subscription Expiration and Deactivation.

  • Verwenden Sie herunterladbare Artikel lediglich in Tabellen, die ausschließlich auf dem Verleger geändert werden. Weitere Informationen finden Sie unter Optimieren der Leistung der Mergereplikation durch nur herunterladbare Artikel.

Filterentwurf und -verwendung

  • Gestalten Sie Zeilenfilterklauseln nicht zu komplex.

    Je weniger komplex die Filterkriterien sind, desto höher ist die Leistung des Merge-Agents beim Auswerten von Zeilenänderungen, die an Abonnenten gesendet werden sollen. Vermeiden Sie untergeordnete SELECT-Anweisungen innerhalb von Mergezeilenfilter-Klauseln. Verwenden Sie stattdessen Joinfilter, die im Allgemeinen effizienter sind, wenn Daten in einer Tabelle auf der Basis der Zeilenfilterklausel in einer anderen Tabelle partitioniert werden sollen. Weitere Informationen zur Filterung finden Sie unter Filtern von veröffentlichten Daten für die Mergereplikation.

  • Verwenden Sie vorausberechnete Partitionen mit parametrisierten Filtern (diese Funktion wird standardmäßig verwendet). Weitere Informationen finden Sie unter Optimieren Parametrisierter Filter-Leistung mit Vorausberechneten Partitionen .

    Vorausberechnete Partitionen setzen dem Filterverhalten bestimmte Grenzen. Wenn Ihre Anwendung mit diesen Grenzen nicht zurecht kommt, legen Sie für die keep_partition_changes -Option Truefest. Dies führt zu einer Leistungssteigerung. Weitere Informationen zu parametrisierten Zeilenfiltern finden Sie unter Parametrisierte Zeilenfilter.

  • Verwenden Sie bei Daten, die zwar gefiltert, nicht aber von mehreren Benutzer genutzt werden sollen, Partitionen, die sich nicht überlappen.

    Die Replikation kann die Leistung bei Daten optimieren, die sich nicht in mehreren Partitionen befinden bzw. an mehrere Abonnements gesendet werden. Weitere Informationen zu parametrisierten Zeilenfiltern finden Sie unter Parametrisierte Zeilenfilter.

  • Erstellen Sie keine komplexen Joinfilterhierarchien.

    Joinfilter mit fünf oder mehr Tabellen können die Leistung der Mergeverarbeitung deutlich beeinträchtigen. Sie sollten daher bei der Generierung von Joinfiltern mit fünf oder mehr Tabellen andere Lösungen in Betracht ziehen:

    • Vermeiden Sie das Filtern von Tabellen, bei denen es sich in erster Linie um Nachschlagetabellen, kleinere Tabellen und Tabellen handelt, die nicht geändert werden. Nehmen Sie diese Tabellen vollständig in die Veröffentlichung auf. Joinfilter sollten nur zwischen Tabellen verwendet werden, die zwischen Abonnenten partitioniert werden müssen. Weitere Informationen finden Sie unter Join Filters.

    • Überlegen Sie, ob es nicht möglich ist, den Datenbankentwurf zu denormalisieren oder eine Zuordnungstabelle zu verwenden, wenn ein Join viele Tabellen enthält. Wenn ein Vertriebsmitarbeiter z. B. nur die Daten für seine eigenen Kunden benötigt, für die Zuordnung eines Kunden zu einem Vertriebsmitarbeiter aber sechs Joins notwendig sind, können Sie der Kundentabelle eine Spalte hinzufügen, aus der der jeweilige Vertriebsmitarbeiter hervorgeht. Die Angaben zum Vertriebsmitarbeiter sind zwar redundant, der Aufwand der Denormalisierung der Tabellen wird aber möglicherweise durch die Leistungssteigerungen bei der Replikationspartitionierung wieder wettgemacht.

    • Entwerfen Sie Ihre Anwendung mit Sorgfalt, um die Leistung vorausberechneter Partitionen zu verbessern, wenn in Batches vieles Datenänderungen enthalten sind. Stellen Sie sicher, dass die Änderungen an der übergeordneten Tabelle in einem Joinfilter vor den entsprechenden Änderungen in den untergeordneten Tabellen vorgenommen werden.

  • Legen Sie, wenn es die Logik zulässt, für die join_unique_key -Option 1 fest.

    Mit dem Wert 1 geben Sie an, dass die Beziehung zwischen der untergeordneten und der übergeordneten Tabelle in einem Joinfilter 1:1 oder 1:n ist. Legen Sie für diesen Parameter aber nur dann 1 fest, wenn die verknüpfte Spalte in der untergeordneten Tabelle eine Einschränkung besitzt, die die Eindeutigkeit sicherstellt. Wenn für den Parameter fälschlicherweise 1 festgelegt wird, kann es zu einer Nichtkonvergenz der Daten kommen. Weitere Informationen finden Sie unter Join Filters.

  • Vermeiden Sie bei Verwendung vorausberechneter Partitionen das Ausführen von Batches mit vielen Änderungen.

    Wenn der Merge-Agent ausgeführt wird, nachdem Sie einen Batch mit vielen Datenänderungen ausführen, wird der große Batch vom Agent in kleinere Batches unterteilt. Während dieser Zeit werden andere Merge-Agent-Prozesse möglicherweise blockiert. Reduzieren Sie die Anzahl der Änderungen in einem Batch, und führen Sie den Merge-Agent zwischen Batches aus. Wenn dies nicht möglich ist, erhöhen Sie den Wert von generation_leveling_threshold für die Veröffentlichung.

Überlegungen zu Abonnements

  • Staffeln Sie die Zeitpläne für die Synchronisierung der Abonnements.

    Wenn viele Abonnenten eine Synchronisierung mit einem Verleger ausführen, sollten Sie die Zeitpläne so staffeln, dass die Merge-Agents zu unterschiedlichen Zeiten ausgeführt werden. Weitere Informationen finden Sie unter Angeben von Synchronisierungszeitplänen.

Merge-Agentparameter

Informationen zum Merge-Agent und seinen Parametern finden Sie unter Replication Merge Agent.

  • Aktualisieren Sie alle Abonnenten für Pullabonnements auf SQL Server 2005 (9.x) oder eine höhere Version.

    Das Upgrade des Abonnenten auf SQL Server 2005 (9.x) oder eine höhere Version aktualisiert die Merge-Agent, die von den Abonnements bei diesem Abonnenten verwendet werden. Um viele der neuen Features und Leistungsoptimierungen zu nutzen, ist die Merge-Agent von SQL Server 2005 (9.x) oder einer höheren Version erforderlich.

  • Wenn ein Abonnement über eine schnelle Verbindung synchronisiert wird und vom Verleger und vom Abonnenten Änderungen gesendet werden, verwenden Sie für den Merge-Agent den –ParallelUploadDownload -Parameter.

    SQL Server 2005 (9.x) hat einen neuen Merge-Agent Parameter eingeführt: –ParallelUploadDownload. Wenn Sie diesen Parameter verwenden, kann der Merge-Agent gleichzeitig sowohl die Änderungen, die auf den Verleger hochgeladen werden, als auch die Änderungen verarbeiten, die auf den Abonnenten heruntergeladen werden. Dieses Verhalten erweist sich in Umgebungen mit hohem Volumen als nützlich, die eine hohe Netzwerkbandbreite besitzen. Agentparameter können in den Agentprofilen und in der Befehlszeile angegeben werden. Weitere Informationen finden Sie unter:

  • Möglicherweise ist es ratsam, den Wert des -MakeGenerationInterval -Parameters zu erhöhen, insbesondere dann, wenn die Synchronisierung mehr Uploads von Abonnenten als Downloads an Abonnenten beinhaltet.

  • Beim Synchronisieren von Datenzeilen mit einer umfangreichen Datenmenge, z. B. Zeilen mit LOB-Spalten, kann die Websynchronisierung eine zusätzliche Speicherbelegung erfordern und die Leistung beeinträchtigen. Diese Situation tritt ein, wenn der Merge-Agent eine XML-Nachricht generiert, die zu viele Datenzeilen mit großen Datenmengen enthält. Wenn der Merge-Agent zu viele Ressourcen während der Websynchronisierung verbraucht, verringern Sie die in einer einzelnen Nachricht gesendete Anzahl der Zeilen mithilfe einer der folgenden Möglichkeiten:

    • Verwenden Sie für den Merge-Agent das Agentprofil für langsame Links. Weitere Informationen finden Sie unter Replication Agent Profiles.

    • Verringern Sie die - DownloadGenerationsPerBatch - und - UploadGenerationsPerBatch -Parameter für den Merge-Agent auf einen Wert von 10 oder weniger. Der Standardwert für diese Parameter beträgt 50.

Überlegungen zu Momentaufnahmen

  • Erstellen Sie in großen Tabellen eine ROWGUIDCOL-Spalte, bevor Sie die Anfangsmomentaufnahme generieren.

    Bei der Mergereplikation benötigt jede veröffentlichte Tabelle eine ROWGUIDCOL-Spalte. Falls keine ROWGUIDCOL-Spalte in der Tabelle enthalten ist, bevor der Momentaufnahme-Agent die Anfangsmomentaufnahmedateien erstellt, muss der Agent zunächst die ROWGUIDCOL-Spalte hinzufügen und auffüllen. Im Sinne einer Leistungssteigerung bei der Generierung von Momentaufnahmen während der Mergereplikation sollten Sie daher vor dem Veröffentlichen für jede Tabelle eine ROWGUIDCOL-Spalte erstellen. Die Spalte kann einen beliebigen Namen aufweisen (der Momentaufnahme-Agent verwendet standardmäßigrowguid ), muss jedoch die folgenden Datentypmerkmale besitzen:

    • Der Datentyp muss UNIQUEIDENTIFIER sein.

    • Der Standardwert muss NEWSEQUENTIALID() oder NEWID() lauten. NEWSEQUENTIALID() ermöglicht eine höhere Leistung beim Ausführen und Nachverfolgen von Änderungen und wird daher empfohlen.

    • Die ROWGUIDCOL-Eigenschaft muss festgelegt werden.

    • Die Spalte muss über einen eindeutigen Index verfügen.

  • Generieren Sie vorab Momentaufnahmen, und/oder ermöglichen Sie es den Abonnenten, beim ersten Synchronisieren die Momentaufnahmegenerierung und -anwendung anzufordern.

    Verwenden Sie eine oder beide dieser Optionen, um Momentaufnahmen für Veröffentlichungen bereitzustellen, die parametrisierte Filter verwenden. Wenn Sie keine dieser beiden Optionen angeben, werden die Abonnements mit einer Reihe von SELECT- und INSERT-Anweisungen statt mit dem bcp -Hilfsprogramm initialisiert, wodurch sich der Prozess deutlich verlangsamt. Weitere Informationen finden Sie unter Snapshots for Merge Publications with Parameterized Filters.

Überlegungen zur Wartung und Überwachung

  • Indizieren Sie die Systemtabellen für die Mergereplikation von Zeit zu Zeit neu.

    Als Teil der Wartung für die Mergereplikation überprüfen Sie gelegentlich die Vergrößerung der Systemtabellen, die mit der Mergereplikation verbunden sind: MSmerge_contents, MSmerge_genhistory, MSmerge_tombstone, MSmerge_current_partition_mappingsund MSmerge_past_partition_mappings. Führen Sie eine regelmäßige Neuindizierung dieser Tabellen durch. Weitere Informationen finden Sie unter Neuorganisieren und Neuerstellen von Indizes.

  • Überwachen Sie mithilfe der Registerkarte Synchronisierungsverlauf im Replikationsmonitor die Synchronisierungsleistung.

    Bei Mergereplikationen zeigt der Replikationsmonitor auf der Registerkarte Synchronisierungsverlauf detaillierte Statistiken für alle Artikel an, die während einer Synchronisierung verarbeitet werden. So lässt sich diesen Statistiken z. B. die Länge der einzelnen Verarbeitungsphasen (Hochladen von Änderungen, Herunterladen von Änderungen usw.) entnehmen. Auf diese Weise können Sie besser die Tabellen identifizieren, die zu einer Verlangsamung führen, und Sie können hier auch hervorragend Leistungsprobleme im Zusammenhang mit Mergeabonnements diagnostizieren. Weitere Informationen zum Anzeigen detaillierten Statistiken finden Sie unter View Information and Perform Tasks using Replication Monitor (Anzeigen von Informationen und Ausführen von Aufgaben mit dem Replikationsmonitor).