Hochtempdb-Festplatten-E / A während der Zusammenführungsreplikation von BLOBs

Mit einer Zusammenführungspublikation zum Replizieren von BLOBs (Typ image) wurde eine sehr hohe Tempdb-Festplatten-E / A für meine Datengröße erhalten. Die Veröffentlichung ist nur zum Herunterladen und enthält keine Filter.

Hohe Festplatten-E / A werden durch Synchronisation verursacht (wenn keine Abonnenten synchronisieren, ist alles in Ordnung), die stark mit der Anzahl der Abonnenten korreliert. Es passiert auch dann, wenn zwischen den Synchronisierungen keine Daten bei Publisher geändert werden, und das stört mich.

• Größe der replizierten Tabelle: 7 MB (Gesamtzahl der Zeilen beträgt ca. 100)
• Tempdb-E / A: ~ 30 MB / s zum Schreiben (Protokoll- und Datendateien)
• Anzahl der Teilnehmer: etwas mehr als 100, die alle 30 Minuten synchronisiert werden (mehr oder weniger gleichmäßig).
• Die Aufbewahrungsfrist beträgt 14 Tage

Verwenden von SQL Server 2008 bei Publisher, SQL Server 2005-2008R2 bei Abonnenten. Alle Abonnenten verwenden die Websynchronisation.

Darüber hinaus nimmt die Synchronisierung beim Teilnehmer viel Zeit in Anspruch, wobei mehrere Vorkommen replmerg.logwie folgt auftreten:

DatabaseReconciler, 2015/04/21 12:13:40.348, 3604, 25088,  S2,  
INFO: [WEBSYNC_PROTOCOL]  
Sending client ReconcilerPhase WebSyncReconcilerPhase_RegularDownload     

DatabaseReconciler, 2015/04/21 12:13:47.063, 3604, 25194,  S2,  
INFO: [WEBSYNC_PROTOCOL]  
Received server ReconcilerPhase WebSyncReconcilerPhase_LastRegularDownload

Versuchte Einstellung @stream_blob_columnsohne Wirkung ein- und ausschalten.

Die Frage ist: Ist es eine gute Idee, die Merge-Replikation zu verwenden, um diese Blobs an Abonnenten zu senden? Wir haben andere Veröffentlichungen (obwohl sie keine BLOB-Spalten haben) mit vielen Daten ohne Tempdb-Problem. Ist es ein SQL Server-Fehler oder ein schlechtes Setup?

Publisher und Distributor befinden sich in derselben Instanz, SQL Server 2008 SP4. Sie können sich nicht sicher sein, ob Abonnenten vorhanden sind. Einige von ihnen sind möglicherweise nicht auf dem neuesten Stand. Auf jeden Fall kann ich eine Testumgebung mit wenigen Abonnenten mit kontrollierten Versionen vorbereiten, wenn dies zu helfen scheint.

Bestätigt, dass übermäßige Tempdb-Nutzung durch die Ausführung von verursacht sys.sp_MSenumgenerations90. Überprüfte MSMerge_genhistoryTabelle, gefunden über 1,2 Millionen Datensätze, wobei pubidnull ist.

Fand dieses Gespräch mit dem Replikationsguru:

Ausgeführt sp_mergemetadataretentioncleanupohne Wirkung.

Es wurde eine Bemerkung zu einem Fall wie diesem gefunden (zu viele Zeilen MSmerge_genhistory), in dem das Löschen von Zeilen mit pubidnull und genstatus= 1 zur Korrektur der Replikation beitrug.

Gelöschte Zeilen, in denen pubidnull ist (was bedeutet, dass alle Abonnenten synchronisiert sind und nicht - werden im "manuellen Modus" neu initialisiert) und die Festplatten-E / A wieder normal ist!

Ich habe das Gefühl, dass diese Situation durch die Tatsache verursacht werden könnte, dass alle meine Abonnenten über WebSync anonym sind und die meisten von ihnen denselben Hostnamen haben. Ich werde versuchen zu überprüfen, ob der -hostnameSchlüssel hilft, Datensätze nicht zu multiplizieren MSmerge_genhistory.

Es gibt ein TechNet-Blog, in dem einige Probleme bei der Zusammenführungsreplikation mit Blobs auf einem Server mit SQL Server 2008 oder höher erläutert werden.

http://blogs.technet.com/b/claudia_silva/archive/2011/10/31/replication-watch-out-for-stream-blob-columns-when-setting-up-replication-on-your-sql- 2008-server.aspx

Beachten Sie, dass der Autor warnt, welche Einstellungen verwendet werden sollen, wenn SQL Server 2005-Clients vorhanden sind, wie Sie sie haben.

Ich hatte ein ähnliches Problem mit einem Kundenserver, dessen Ursache nicht gelöst werden konnte. Die hohe Menge an E / A verlangsamte den Speicher und betraf mehrere Systeme. Ich kann keine Lösung zur Lösung der Ursache selbst anbieten, aber es könnte sich um eine (vorübergehende) Option handeln, die das resultierende Problem löst und Ihnen mehr Zeit gibt, die Ursache zu identifizieren und zu lösen.

Wir haben das IO-Problem gelöst, während wir die Tempdb auf eine Ramdisk verschoben haben. In unserem Fall mussten wir schnell handeln, da andere Systeme aufgrund von Leistungsproblemen vorübergehend nicht mehr reagierten. Anstatt die Servereinstellung zu ändern, haben wir die Tempdb-Dateien auf die Ramdisk kopiert, eine Sicherungskopie der Originaldateien erstellt und diese durch Symlinks ersetzt. Die Ramdisk lädt ein Image, das die Tempdb-Dateien enthält. Die SQL-Dienste wurden verzögert, um sicherzustellen, dass die Ramdisk gestartet und das Image geladen wurde, bevor der SQL-Dienst gestartet wird. Die effektive Ausfallzeit für den Wechsel von Festplatte zu RAM dauerte weniger als eine Minute.

In unserem Fall haben wir die Leistung massiv verbessert und das Problem mit dem Speicher gelöst. Die Lösung funktioniert sehr gut für unsere Kunden und ist am Ende zu einer dauerhaften Lösung geworden.

Brent definiert, warum wir die tempDb-Datendatei erhöhen müssen. Sie können auf den folgenden Link verweisen

https://www.brentozar.com/blitz/tempdb-data-files/