none
Mergereplikation SQL Server 2005 langsam RRS feed

  • Allgemeine Diskussion

  • Habe hier 4 SQL Server 2005 (an verschiedenen Standorten)

    1 Verleger u. 3 Abonnenten

    Was mir in letzter Zeit auffällt ist, das zu bestimmten Zeiten die Mergereplikation sehr langsam ist.

    Aktuell habe ich gerade 100 Änderungen vom Verleger an den Abonnenten mit einer Laufzeit von über 30 Minuten.

    Das kommt mir sehr lange vor.

    Gruß

    Volker

    Donnerstag, 19. Juli 2012 09:42

Alle Antworten

  • hallo Volker

    pruef mal die Definition der Spalte rowguid welche bei merge replication als key benutzt wird.

    was ist der Default Constraint ? ist es "newid()" oder "newsequentialid()" ? und hat es einen Index auf dieser Spalte?

    wenn kein Index darauf existiert, so muss der SQL Server dann die ganze Tabelle durchsuchen um den richtigen Record zu finden und ihn upzudaten. falls newid als Defaultconstraint benutzt wird, so fragmentiert der Index extrem und es werden sehr viele I/O erzeugt welche wiederum die Performance reduziert.


    Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.

    Donnerstag, 19. Juli 2012 09:50
  • Danke Daniel,

    Ich habe das mal für die Tabellen mit den meisten Datensätzen überprüft.

    ...

    [rowguid] [uniqueidentifier] ROWGUIDCOL NOT NULL,

    ...

    ALTER TABLE [dbo].[Disposition] ADD CONSTRAINT [MSmerge_df_rowguid_3807E88375EA48E386B1D2CB080B4DF6] DEFAULT (newsequentialid()) FOR [rowguid]

    ...

    CREATE UNIQUE NONCLUSTERED INDEX [MSmerge_index_1806629479] ON [dbo].[Disposition]
    (
    [rowguid] ASC
    )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
    GO

    Das finde ich bei allen Tabellen die repliziert werden.

    Gruß

    Volker

    Donnerstag, 19. Juli 2012 12:05
  • wie sieht es mit der Fragmentierung dieses Indexes aus ?

    laeuft der SQL Server unter Volllast wenn Du feststellst, dass die Merge Replikation langsam laeuft ?

    wieviel Resourcen stehen den an den Merge Replikation beteiligten SQL Server zur Verfuegung?


    Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.

    Freitag, 20. Juli 2012 15:20
  • Sorry, das ich mich heute erst melde.

    Habe heute und gestern, die Performance auf den beteiligten Systemen geprüft.

    Die idlen eigentlich alle so vor sich hin (CPU-Last jeweils unter 10%) 

    Speicherauslastung bis zu 70% (jeweils 4GB Hauptspeicher) und ausreichend Festplattenkapazität (jeweils > 20 GB).

    Evtl liegt es doch an der Verbindung der Server zueinander, das kann ich nicht ganz ausschliessen)

    Fragmentierung des Indexes? So adhoc finde ich das nicht wie ich das prüfe.

    Gruß

    Volker

    Dienstag, 24. Juli 2012 09:07
  • Fragmentierung des Indexes? So adhoc finde ich das nicht wie ich das prüfe.

    hallo Volker

    via GUI (SSMS) kannst Du die Fragmentierung auf 2 Arten einfach bestimmen:

    - Reports -> Index Physical Stats

    - Index anklicken, Eigenschaftsdialog, Storage oder Fragmentation


    Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.

    Dienstag, 24. Juli 2012 10:58
  • So,

    das mit der Fragmentierung habe ich herausgefunden, und auch wie man dann die Indexe neu organisiert.

    Teilweise hatte ich bei den zu replizierenden Tabellen, über 70% durchschnittliche Fragmentierung (oO).

    Nun, das habe ich behoben

    Nur ...

    ein Standort bereitet immer noch Kopfschmerzen, weil dort die Replizierung übel langsam ist. Aber nach all den Optimierung im DB-Bereich denke ich das es tats. an der Leitung liegt (geringer Upload), weil die anderen Standorte, die gleichen Daten repliziert bekommen, und wesentlich früher damit durch sind.

    Bis dahin

    Volker

    Mittwoch, 25. Juli 2012 13:19