Performanceprobleme bei Merge-Replikation

Im Zuge einer Neueinrichtung einer Merge-Replikation auf einem Produktivsystem hatten wir auf der Abonnenten-Seite mit massiven Performance-Problemen zu kämpfen. Diese traten gefühlsmäßig immer dann auf, wenn die Replikation lief. Die CPU-Auslastung war sehr gering, aber die Datenträgerwarteschleife schoss teilweise auf 250!
Augenscheinlich war aber alles korrekt eingerichtet.

Um dem Problem auf die Schliche zu kommen, erwies sich die Systemtabelle dm_exec_query_stats als äußerst hilfreich. Hierüber kann man sich Ausführungsstatistiken der letzten Befehle abholen. Unter anderem werden hier CPU-Zeit, Lese- und Schreibzugriffe protokolliert.

SELECT TOP 5
    last_physical_reads,
    sql_handle,
    plan_handle
FROM sys.dm_exec_query_stats
ORDER BY last_physical_reads DESC

In den Spalten sql_handle und plan_handle werden zwei Handle zurückgeliefert über die man Zugriff auf das Kommando im Klartext sowie den Execution Plan bekommt.

Diese kann man sich mit den Systemfunktionen sys.dm_exec_sql_text und sys.dm_exec_text_query_plan zurückgeben lassen.
Ich führte also folgendes Statement aus

SELECT * FROM sys.dm_exec_sql_text(0x020000006D3E963947E734508EEE5BDFDA222AE4C2FE9432)

und bekam wie vermutet ein Replikationskommando zurück

SELECT TOP 100 mc.tablenick, mc.rowguid, mc.generation, mc.lineage, mc.colv1, t.*
FROM  [Shop].[dbo].[MSmerge_contents] mc, [Shop].[dbo].[OrderItemCondition] t WHERE
mc.generation = 45940 AND mc.tablenick = 26251010
AND mc.rowguid = t.rowguidcol
ORDER BY mc.tablenick, mc.rowguid

Ich führte das Kommando mit der Option “Include Actual Execution Plan” aus und bekam die Meldung, dass ein Index fehlt.

CREATE NONCLUSTERED INDEX [<name OF Missing INDEX, sysname,>]
ON [dbo].[OrderItemCondition] ([rowguid])

Tatsächlich fehlte ein Index auf der rowguid-Spalte, nach Anlegen dieses Index verringerte sich die Aktualisierungszeit der Replikation von rund 7 Minuten auf eine Minute. Die Datenträgerwarteschleife verhält sich seitdem auch ruhig und die Performanceeinbrüche existieren nicht mehr.
Normalerweise werden solche wichtigen Indizes von den Replikationstools automatisch angelegt. Warum das in diesem Fall nicht passiert ist kann ich nicht sagen, ich bin aber froh, das Problem gefunden und gelöst zu haben.

Stichworte | Tags

Database in SUSPECT-Modus

Nach einem Server-Neustart beglückte mich heute der SQL Server mit einer Meldung, dass eine Datenbank “suspect” sei. “Was ist das denn???”, fragte ich mich.
Nach ein wenig Recherche fand ich heraus, wann eine Datenbank als suspect markiert wird:

If one or more database files are not available.
If the entire database is not available.
If one or more database files are corrupted.
If a database resource is being held by the operating system.

Quelle: SQL Server Books Online

Da ich weder die Datenbank umbenannt noch Dateien gelöscht hatte, konnte der Status nur bedeuten, dass die Datenbank korrupt ist.
Zur Lösung des Problems kamen folgende Kommandos zum Einsatz:

1) Setzen der Datenbank in exklusiven Modus für Admin-Tätigkeit

ALTER DATABASE myDatabase SET Single_User

2) Setzen der Datenbank in Wartungsmodus

ALTER DATABAS myDatabase SET Emergency

3) Überprüfen der Datenbank Teil 1

DBCC CheckDB ('myDatabase ')

Hier erhält man eine Meldung, mit welchem Modus die Datenbank repariert werden kann

4) Überprüfen der Datenbank Teil 2

DBCC CheckDB ('myDatabase', REPAIR_ALLOW_DATA_LOSS)

5) Zurücksetzen der Datenbank in shared-Modus

ALTER DATABASE myDatabase SET Multi_User

Das hat das Problem bei mit gelöst. Zum Glück gingen trotz REPAIR_ALLOW_DATA_LOSS keine Daten verloren.

Stichworte | Tags

Fulltext Manager for SQL Express

If you missed the Storage node in the Object Explorer of your SSMS installation to manage your SQL Express fulltext catalogs, here is the solution!

Find below my new addin for both SSMS 2005 and SSMS 2008.

Once installed, you’ll find a new context menu entry when you select a database:

A click on the menu entry opens the management dialog:

Find the setup and sourcecode on my CodePlex project http://www.codeplex.com/FulltextManager.

Stichworte | Tags

Replikation hängt bei “uploading data changes”

Nachdem die Merge-Replikation bei einem unserer Kunden monatelang problemlos lief, ist sie plötzlich ausgefallen. Ein Blick ins Merge-Protokoll zeigte, dass sie nach dem Initialisieren im Status “uploading data changes to the Publisher” stehen geblieben ist. Einige Minuten später folgte dann ein Timeout. Als dieses Problem zum ersten Mal aufgetreten ist, half nur eine komplette Neuinitialisierung des Snapshots mit anschließenden Rebuild. Doch leider ist nach einigen Wochen dasselbe Problem wieder aufgetreten.

Nach längerer Recherche im Internet fand ich einen interessanten Thread über dieses Thema. Anscheinend ist wohl eine SP der Replikation fehlerhaft, was unter bestimmten Umständen zu einer Endlosschleife führt. Dieser Fehler bis zur SQL Server Version 9.0.3282 (Kumulatives Update-Paket 9) aber leider noch nicht behoben.

Ein Workaround besteht momentan im im Setzen des “generation_leveling_threshold” auf den Wert 0. Hierfür muss auf dem Subscriber folgendes Statement ausgeführt werden:

UPDATE sysmergepublications SET [generation_leveling_threshold] = 0

Laut Dokumentation soll der Wert “generation_leveling_threshold” eigentlich über die SP sp_changemergepublication gesetzt werden. Doch das hat in unserem Fall leider keinen Erfolg gebracht. Das korrekte Statement für sp_changemergepublication würde lauten:

EXEC sp_changemergepublication @publication = 'My Publication', @property = 'generation_leveling_threshold', @VALUE = '0'

Dieser Workaround hat in unserem Fall problemlos funktioniert und seid einigen Wochen läuft die Replikation wieder fehlerfrei. Ein großer Vorteil bei diesem Vorgehen ist, dass der Snapshot nicht neu erstellt werden muss und auch der Subscriber nicht erneut initialisiert werden muss. Nachdem man den Befehle ausgeführt hat läuft beim nächsten Abgleich alles wieder problemlos.

Stichworte | Tags

Weitere News und Artikel