none
Merge-Replikation mit FILESTREAM-Spalten - Konflikttabelle RRS feed

  • Frage

  • Hallo zusammen,

    ich bin heute über ein Problem gestolpert, das nur auf Tabellen mit Filestream-Spalten auftritt.

    Wenn ich solch eine Tabelle als Artikel in der Merge-Replikation habe, dann erstellt SQL Server eine Konflikttabelle, die anders aussieht als bei denen ohne FILESTREAM-Spalte. Bei letzteren gibt es keinen Primary Key, sondern nur einen zusammengesetzten Schlüssel bestehend aus dem Primary Key der Artikeltabelle und der Spalte data_source_origin. Macht ja auch Sinn - denn nur so können Konflikte aus unterschiedlichen Abonnennten gespeichert werden. 

    Für den Artikel mit FILESTREAM-Spalte hingegen erstellt die Merge-Replikation auf der zugehörigen Konflikt-Tabelle einen Unique Key auf der Rowguid-Spalte der Ausgangstabelle. Muss ja auch, denn die Regeln für eine Tabelle mit Filestream-Spalten besagen, dass es einen UK auf der ROWGUID-Spalte geben muss - und letztlich entspricht die Konflikt-Tabelle ja der Ausgangstabelle. Die Spalte data_source_origin findet hier hingegen keine Verwendung, was zur Folge hat, dass auf dem Verleger nur ein konfliktierender Abonnent protokolliert werden kann. Kommt ein zweiter mit einer Änderung auf dem gleichen Datensatz, kommt es zur Schlüsselverletzung auf dem UK der Konflikttabelle und der ganze Synchronisationsvorgang schlägt fehl bis der Konflikt manuell aufgelöst bzw. aus der Konflikttabelle entfernt worden ist.

    Jetzt könnte man versuchen als Workaround die Tabelle zu droppen und mit eine UK auf ROWGUIDCOL und data_source_origin neu zu erstellen - geht aber auch nicht, weil data_source_origin NULLABLE ist. 

    Der Hintergrund ist auch klar - unter der ROWGUIDCOL (oder dem UK?) werden die Dateien im FILESTREAM abgelegt - gäbe es zwei mit gleichem Schlüssel, würden die Dateien sich überschreiben.

    Hat jemand hierzu schon mal eine Lösung gesehen oder gibt es hierzu vielleicht einen Bugreport bei Microsoft? Ich bekomme das Verhalten in allen Versionen von 2012-2017 - also ein durchaus altes "Feature".


    Freitag, 9. Oktober 2020 10:24

Alle Antworten

  • Hallo,

    ein bisschen was zu dem Thema ist unter FILESTREAM-Kompatibilität mit anderen SQL Server-Features => Merge Replikation zu lesen.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Freitag, 9. Oktober 2020 10:38
  • Ja, aber leider nichts zu dem konkreten Problem. Da steht nur das, was ich oben eh schon erwähnt habe.
    Freitag, 9. Oktober 2020 10:57
  • das Problem ist nicht lösbar. Last update wins wäre die einzige Lösung, aber der Distributor macht standardmäßiog eine Gewichtung (pubisher 50% Subscriber 25%) nach dem entschieden wird wer Recht hat. Das muß man in "last update wins" ändern... notfalls mit Triggern am Distributor.


    Konflikte gibts weil ein und dieselbe Datei am Share des Publishers und am Share des Subscribers geändert wurde, und die Merge Replikation weiß ja nicht was richtig ist. Und wer Unsinn im Kopf hat für die Konflitkauflösung, den bestraft eine gestoppte Replikation. Diese sammelt dann zwar noch Deltas für 2 Wochen, aber der Merge danach kostet dann echt viel Zeit.

    Normalerweise geht das auf einem echten Windows Fileshare nicht da Dateien exclusiv zum Schreiben geöffnet werden, aber wenn ein und dieselbe Datei auf beiden Enden geändert wird, nun ja Pech gehabt. Was soll dabei am Ende herauskommen?

    Sowas über mehrere Standorte verteilt kann nur Sharepoint oder DFSR oder Teams, ansonsten hast du mit der manuelle Auflösung von Mergekonflitken bei DAteien eine Jobgarantie bis zur Rente. 

    Meiner Meinung nach ist das eine falsche Erwartungshaltung an die Replikation. Die Merge Replikation des MS SQL Servers hat standardmäßig ein Delay von 2 Minuten: bei einem Zyklus von einer Minuten gelangt ein Delta nach 60 Sekudnen auf den Distributor und nach weiteren 60 Sekunden auf den oder die Subscriber.

    Und last but not least, der SQL SErver kann seit 2014 Always On, schaut euch das mal an... schneller, besser, moderne, man braucht bei einer 2-Server-Konstellation keinen Distributor mehr, man kann Read Replikas und Multi Master für Schreibzugriffe haben... und nehmt bitte DFSR, das nimmt einem die Behanldlung von Merge Konflikten ab, die man ansosnten bei Filestream hat



    IT architect - Terminal servers, virtualizations, SQL servers, file servers, WAN networks and closely related to software devleopment (8 years + experience in VB, C++ and script langugaes), MCP for SQL server and CCAA for Xenapp 6.5


    • Bearbeitet Al Hasoob Freitag, 23. Oktober 2020 07:57
    Freitag, 23. Oktober 2020 07:56