Freigeben über

  • Artikel

Verbessern der allgemeinen Replikationsleistung

Wenn Sie die Hinweise in diesem Thema beachten, können Sie die allgemeine Leistung aller Replikationstypen in der Anwendung und im Netzwerk verbessern.

Server und Netzwerk

  • Legen Sie das Minimum und das Maximum für den Arbeitsspeicher fest, der MicrosoftSQL Server Database Engine (Datenbankmodul) zugeordnet ist.

    Standardmäßig ändert Database Engine (Datenbankmodul) die Arbeitsspeicheranforderungen auf der Grundlage der verfügbaren Systemressourcen dynamisch. Wenn verhindert werden soll, dass während Replikationsaktivitäten nur wenig Arbeitsspeicher zur Verfügung steht, verwenden Sie die Option min server memory zum Festlegen des Minimums an Arbeitsspeicher. Um zu verhindern, dass das Betriebssystem Speicher auslagern muss, können Sie auch ein Maximum an Arbeitsspeicher mit der Option max server memory festlegen. Weitere Informationen finden Sie unter Serverarbeitsspeicher-Optionen.

  • Stellen Sie eine ordnungsgemäße Zuordnung der Datenbankdateien und Protokolldateien sicher. Verwenden Sie ein separates Laufwerk für das Transaktionsprotokoll für alle an der Replikation beteiligten Datenbanken.

    Sie können die Zeit verringern, die zum Schreiben von Transaktionen benötigt wird, indem Sie die Protokolldateien auf ein anderes Laufwerk schreiben als das, das zum Speichern der Datenbank verwendet wird. Dieses Laufwerk kann mithilfe eines RAID 1-Gerätes (Redundant Array of Inexpensive Disks) gespiegelt werden, wenn Fehlertoleranz erforderlich ist. Verwenden Sie RAID 0 oder 0+1 (je nach Bedarf an Fehlertoleranz) für andere Datenbankdateien. Dies wird empfohlen, unabhängig davon, ob die Replikation verwendet wird. Weitere Informationen finden Sie unter RAID-Stufen und SQL Server.

  • Fügen Sie gegebenenfalls Arbeitsspeicher für die Server hinzu, die für die Replikation verwendet werden, insbesondere für den Verteiler.

  • Verwenden Sie Computer mit mehreren Prozessoren.

    Replikations-Agents können von weiteren Prozessoren auf dem Server profitieren. Bei hoher CPU-Nutzung sollten Sie die Installation einer schnelleren CPU oder mehrerer CPUs in Betracht ziehen.

  • Verwenden Sie ein schnelles Netzwerk.

    Das Netzwerk kann besonders bei der Transaktionsreplikation einen erheblichen Leistungsengpass darstellen. Die Weitergabe von Änderungen an den Abonnenten kann deutlich beschleunigt werden, wenn Sie ein sehr schnelles Netzwerk mit 100 MBit/s oder mehr verwenden. Geben Sie bei einem langsamen Netzwerk geeignete Netzwerkeinstellungen und Agentparameter an. Weitere Informationen finden Sie unter Probleme aufgrund eines langsamen Netzwerks.

Datenbankentwurf

  • Beachten Sie die bewährten Methoden für den Datenbankentwurf.

    Eine Leistungsoptimierung wirkt sich auf eine replizierte Datenbank genauso vorteilhaft aus wie auf eine nicht replizierte Datenbank. Indizes sind auf dem Abonnenten jedoch mit Bedacht zu verwenden: die Primärschlüsselspalte auf dem Abonnenten sollte indiziert werden, doch weitere Indizes können sich auf die Leistung beim Einfügen, Aktualisieren und Löschen auswirken. Weitere Informationen zum Optimieren von Datenbanken finden Sie unter Optimieren von Datenbanken.

  • Legen Sie gegebenenfalls die Datenbankoption READ_COMMITTED_SNAPSHOT fest.

    Um Konflikte zwischen der Benutzeraktivität und der Aktivität des Replikations-Agents besser vermeiden zu können, legen Sie diese Option für die Veröffentlichungs- und Abonnementdatenbanken fest:

    ALTER DATABASE AdventureWorks
SET READ_COMMITTED_SNAPSHOT ON

    Weitere Informationen finden Sie unter ALTER DATABASE (Transact-SQL).

  • Gehen Sie bei der Anwendungslogik in Triggern mit Bedacht vor.

    Die Geschäftslogik in benutzerdefinierten Triggern auf dem Abonnenten kann die Replikation von Änderungen an den Abonnenten verlangsamen.

    Wenn Sie Trigger auf dem Abonnenten verwenden, finden Sie in den folgenden Themen weitere Informationen: Steuern von Einschränkungen, Identitäten und Triggern mithilfe von NOT FOR REPLICATION und Überlegungen zur Transaktionsreplikation. Wenn Sie zur Wahrung der referenziellen Integrität Trigger in Tabellen verwenden, die für die Mergereplikation veröffentlicht werden, geben Sie die Verarbeitungsreihenfolge der Tabellen an. Auf diese Weise reduzieren Sie die Zahl der Wiederholungsversuche für den Merge-Agent. Weitere Informationen finden Sie unter Angeben der Verarbeitungsreihenfolge von Mergeartikeln.

  • Schränken Sie die Verwendung des LOB-Datentyps (Large OBjects) ein.

    LOBs beanspruchen mehr Speicherplatz und Verarbeitungszeit als andere Spaltendatentypen. Verwenden Sie diese Spalten nur dann in Artikeln, wenn sie für die Anwendung erforderlich sind. Die Datentypen text, ntext und image sind als veraltet markiert. Falls Sie LOBs einschließen, sollten Sie jeweils die Datentypen varchar(max), nvarchar(max), varbinary(max) verwenden.

    Verwenden Sie für die Transaktionsreplikation das Verteilungs-Agentprofil Verteilungsprofil für das OLE DB-Streaming. Weitere Informationen finden Sie unter Replikations-Agent-Profile.

Veröffentlichungsentwurf

  • Veröffentlichen Sie nur die erforderlichen Daten.

    Da die Replikation problemlos eingerichtet werden kann, gibt es eine Tendenz, mehr Daten zu veröffentlichen, als tatsächlich erforderlich sind. Dies kann weitere Ressourcen innerhalb der Verteilungsdatenbanken und Snapshotdateien beanspruchen und den Durchsatz für erforderliche Dateien verringern. Sie sollten vermeiden, nicht benötigte Tabellen zu veröffentlichen, und in Betracht ziehen, Veröffentlichungen weniger häufig zu aktualisieren.

  • Minimieren Sie Konflikte über den Veröffentlichungsentwurf und das Anwendungsverhalten.

    Die folgenden Replikationstypen lassen Datenänderungen auf Abonnenten zu: Mergereplikation, Transaktionsreplikation mit aktualisierbaren Abonnements und Peer-to-Peer-Transaktionsreplikation. Die Mergereplikation und die Transaktionsreplikation mit aktualisierbaren Abonnements unterstützen Datenkonflikte, wenn eine bestimmte Zeile zwischen Synchronisierungen in mehreren Knoten aktualisiert wird. Die Peer-to-Peer-Replikation unterstützt keine Datenkonflikte; Datenänderungen müssen partitioniert werden. Unabhängig vom Typ der verwendeten Replikation wird empfohlen, Änderungen möglichst zu partitionieren, da dies den Verarbeitungsaufwand bei der Konflikterkennung und -lösung reduziert.

    Sie können Änderungen partitionieren, indem Sie Datenteilmengen auf jedem Abonnenten veröffentlichen, oder indem eine Anwendung Änderungen für eine bestimmte Zeile an einen bestimmten Knoten leitet:

    • Die Mergereplikation unterstützt das Veröffentlichen von Datenteilmengen, indem parametrisierte Filter mit einzelnen Veröffentlichungen verwendet werden. Weitere Informationen finden Sie unter Parametrisierte Zeilenfilter.

    • Die Transaktionsreplikation unterstützt das Veröffentlichen von Datenteilmengen, indem statische Filter mit mehreren Veröffentlichungen verwendet werden. Weitere Informationen finden Sie unter Filtern von veröffentlichten Daten.

  • Verwenden Sie Zeilenfilter mit Umsicht.

    Enthält eine Transaktionsveröffentlichung einen oder mehrere Artikel mit Zeilenfiltern, muss der Protokolllese-Agent beim Scannen des Transaktionsprotokolls die Filter auf jede Zeile anwenden, die von einer Aktualisierung der Tabelle betroffen sind. Das wirkt sich auf den Durchsatz des Protokolllese-Agents aus.

    In ähnlicher Form muss die Mergereplikation geänderte oder gelöschte Zeilen auswerten, um die Abonnenten zu ermitteln, die diese Zeilen erhalten sollten. Wenn Zeilenfilter eingesetzt werden, um die Daten zu reduzieren, die auf dem Abonnenten erforderlich sind, ist diese Verarbeitung komplexer und kann langsamer ablaufen als die Veröffentlichung aller Zeilen in einer Tabelle. Wägen Sie die Vor- und Nachteile zwischen geringeren Speicherplatzanforderungen auf jedem Abonnenten und der Notwendigkeit eines maximalen Durchsatzes sorgfältig ab. Weitere Informationen zu Filtern finden Sie unter Filtern von veröffentlichten Daten.

Überlegungen zu Abonnements

  • Verwenden Sie Pullabonnements, wenn sehr viele Abonnenten vorhanden sind.

    Der Verteilungs-Agent oder der Merge-Agent wird auf dem Verteiler für Pushabonnements und auf dem Abonnenten für Pullabonnements ausgeführt. Die Verwendung von Pullabonnements kann die Leistung verbessern, indem Verarbeitungsvorgänge des Agents auf die Abonnenten verlagert werden. Weitere Informationen finden Sie unter Abonnieren von Veröffentlichungen.

  • Initialisieren Sie gegebenenfalls das Abonnement erneut, wenn Abonnenten zu stark in Verzug geraten sind.

    Wenn umfangreiche Änderungen an Abonnenten gesendet werden müssen, kann die Neuinitialisierung mit einem neuen Snapshot schneller sein als das Verwenden der Replikation zum Verschieben der einzelnen Änderungen. Weitere Informationen finden Sie unter Erneutes Initialisieren eines Abonnements.

    Bei der Transaktionsreplikation zeigt der Replikationsmonitor folgende Informationen auf der Registerkarte Nicht verteilte Befehle an: die Anzahl der Transaktionen in der Verteilungsdatenbank, die noch nicht an einen Abonnenten verteilt wurden; und die geschätzte Zeit für das Verteilen dieser Transaktionen. Weitere Informationen finden Sie unter Vorgehensweise: Anzeigen von Informationen und Ausführen von Aufgaben für die einem Abonnement zugeordneten Agents (Replikationsmonitor).

Überlegungen zu Snapshots

  • Führen Sie den Snapshot-Agent nur bei Bedarf und außerhalb der Spitzenzeiten aus.

    Der Snapshot-Agent führt Massenkopieraktionen von Daten aus der veröffentlichten Tabelle auf dem Verleger in eine Datei im Snapshotordner auf dem Verteiler durch. Das Generieren eines Snapshots kann die Ressourcen stark beanspruchen und sollte möglichst außerhalb der Spitzenzeiten stattfinden.

  • Verwenden Sie einen Snapshot im systemeigenen Modus, sofern kein Snapshot im Zeichenmodus erforderlich ist.

    Verwenden Sie den Standardsnapshot im systemeigenen Modus für alle Abonnenten, ausgenommen Nicht-SQL Server-Abonnenten und Abonnenten mit SQL Server Compact 3.5 SP1, die einen Snapshot im Zeichenmodus erfordern.

  • Verwenden Sie einen einzigen Snapshotordner für eine Veröffentlichung.

    Beim Angeben der Veröffentlichungseigenschaften im Zusammenhang mit dem Snapshotspeicherort stehen Optionen zur Auswahl, um Snapshotdateien im Standardsnapshotordner, in einem alternativen Snapshotordner oder in beiden zu erstellen. Für das Erstellen von Snapshotdateien in beiden Speicherorten ist beim Ausführen des Snapshot-Agents zusätzlicher Datenträgerspeicher und Verarbeitungsaufwand erforderlich.

  • Speichern Sie den Snapshotordner auf einem lokalen Laufwerk des Verteilers, das nicht zum Speichern von Datenbank- oder Protokolldateien verwendet wird.

    Der Snapshot-Agent führt einen sequenziellen Schreibvorgang für die Daten im Snapshotordner aus. Durch das Speichern des Snapshotordners auf einem Laufwerk, das nicht für Datenbank- oder Protokolldateien verwendet wird, werden Konflikte bezüglich des Datenträgerzugriffs reduziert, und der Snapshotprozess wird schneller ausgeführt.

  • Wenn Sie die Abonnementdatenbank auf dem Abonnenten erstellen, sollten Sie das einfache oder das massenprotokollierte Wiederherstellungsmodell angeben. Dadurch werden die Masseneinfügungen während der Anwendung des Snapshots auf dem Abonnenten nur in geringem Umfang protokolliert. Nachdem der Snapshot auf die Abonnementdatenbank angewendet wurde, können Sie gegebenenfalls wieder zu einem anderen Wiederherstellungsmodell wechseln (replizierte Datenbanken unterstützen jedes Wiederherstellungsmodell). Weitere Informationen zur Auswahl des Wiederherstellungsmodells finden Sie unter Übersicht über Wiederherstellungsvorgänge (SQL Server).

  • Verwenden Sie bei Netzwerken mit niedrigen Bandbreiten gegebenenfalls den alternativen Snapshotordner und komprimierte Snapshots auf Wechselmedien.

    Das Komprimieren von Snapshotdateien im alternativen Snapshotordner kann den Speicherplatzbedarf von Snapshots reduzieren und das Übertragen der Snapshotdateien auf Wechselmedien vereinfachen.

    Komprimierte Snapshots können in einigen Fällen die Leistung beim Übertragen der Snapshotdateien im Netzwerk verbessern. Beim Komprimieren des Snapshots fällt jedoch zusätzlicher Verarbeitungsaufwand für den Snapshot-Agent an, wenn die Snapshotdateien erstellt werden, sowie für den Verteilungs-Agent oder den Merge-Agent, wenn die Snapshotdateien angewendet werden. Dies könnte das Erstellen von Snapshots verlangsamen und den Zeitaufwand für das Anwenden eines Snapshots in manchen Fällen erhöhen. Darüber hinaus kann das Übertragen komprimierter Snapshots bei einem Netzwerkausfall nicht wieder aufgenommen werden, weshalb sie sich nicht für unzuverlässige Netzwerke eignen. Wägen Sie die Vor- und Nachteile sorgfältig ab, wenn Sie komprimierte Snapshots in einem Netzwerk verwenden. Weitere Informationen finden Sie unter Alternative Speicherorte für Snapshotordner und Komprimierte Snapshots.

  • Initialisieren Sie ein Abonnement gegebenenfalls manuell.

    In einigen Szenarien, wenn z. B. große Anfangsdatasets eine Rolle spielen, ist es vorteilhafter, ein Abonnement statt mit einem Snapshot mit einer anderen Methode zu initialisieren. Weitere Informationen finden Sie unter Initialisieren eines Transaktionsabonnements ohne Snapshot und Initialisieren eines Mergeabonnements ohne Snapshot.

Agentparameter

  • Reduzieren Sie die Meldungsstufen von Replikations-Agents, außer während des ersten Testens, Überwachens oder Debuggens.

    Reduzieren Sie den –HistoryVerboseLevel-Parameter und den –OutputVerboseLevel-Parameter der Verteilungs-Agents oder Merge-Agents. Dadurch wird die Anzahl der neuen Zeilen reduziert, die zum Nachverfolgen des Verlaufs und der Ausgabe von Agents eingefügt werden. Stattdessen werden frühere Verlaufsmeldungen mit dem gleichen Status auf die neuen Verlaufsinformationen aktualisiert. Erhöhen Sie die Meldungsstufen für das Testen, Überwachen und Debuggen, sodass Sie so viele Informationen zur Agentaktivität erhalten wie möglich.

  • Verwenden Sie den –MaxBCPThreads-Parameter des Snapshot-Agents, Merge-Agents und Verteilungs-Agents (die Anzahl der angegebenen Threads sollte die Anzahl der Prozessoren des Computers nicht überschreiten). Mit diesem Parameter wird die Anzahl der Massenkopiervorgänge angegeben, die beim Erstellen und Anwenden des Snapshots parallel ausgeführt werden können.

  • Verwenden Sie den –UseInprocLoader-Parameter des Verteilungs-Agents und des Merge-Agents (dieser Parameter kann nicht verwendet werden, wenn veröffentlichte Tabellen XML-Spalten enthalten). Durch diesen Parameter verwendet der Agent beim Anwenden des Snapshots den BULK INSERT-Befehl.

Agentparameter können in Agentprofilen und in der Befehlszeile angegeben werden. Weitere Informationen finden Sie unter den folgenden Themen:

Siehe auch

Konzepte

Leistung (Replikation)