Sperren der Änderungsprotokollposten (Change Log Entry)

Seit dem Update von 2009 auf 2016 haben wir massive Probleme mit Sperren auf der Tabelle Änderungsprotokollposten.

Mithilfe von folgendem Artikel kann man das 2009er-Protokollverhalten wiederherstellen, das werden wir wahrscheinlich auch bald tun:
https://stoneridgesoftware.com/changes- ... -behavior/

Uns ist bei Tests aufgefallen, dass wenn bei einer Freigabe einer Einkaufsbestellung die Tabellen Purchase Header und Änderungsprotokollposten gesperrt sind, man zwar keine weitere Einkaufsbestellung freigeben kann (es erscheint eine "Änderungsprotokollposten gesperrt" - Meldung), aber man kann Artikel ändern, die während der o.g. Sperre ohne Probleme in die Änderungsprotokollposten schreiben. Ich dachte, wenn die Änderungsprotokollposten-Tabelle gesperrt ist, dürfte man keine anderen Dinge tun, die dort hineinschreiben? Der Primärschlüssel ist schließlich nur Lfd. Nr.

Nach dem Prüfen der Änderungsprotokollposten ist uns aufgefallen, dass wir eine Lücke bei der Lfd. Nr. in den Änderungsprotokollposten hatten dadurch - die Bestellfreigabe hatte die Ldf. Nr. ******2; der nächste Eintrag hatte die Nr. ******4. Scheinbar wäre ******3 unsere zweite Einkaufsbestellung-Freigabe gewesen, wenn das nicht gesperrt worden wäre.

Wilde Vermutung: ist es evtl. so, dass zur Unterscheidung, was in den Änderungsprotokollposten gesperrt worden ist, nicht die Lfd. Nr. entscheidend ist, sondern evtl. der zweite Schlüssel (Table No.,Primary Key Field 1 Value) zur RowLock-Unterscheidung verwendet wird? Aber warum?

Weiß jemand evtl. eine ausführliche Beschreibung des Sperrverhaltens von NAV? Meine Sicht auf das Thema wird alle paar Monate über den Haufen geworfen durch solche Phänomene wie oben beschrieben.

Zuletzt geändert von InfoWissler am 24. Mai 2017 14:52, insgesamt 1-mal geändert.

Hallo,

ihr habt hoffentlich keine genialen Auswerteprogramme oder andere Tools, die evtl. auf SQL-Ebene irgendwelche genialen Informationen aus dem Protokoll holen wollen, oder gar das Protokoll klein halten wollen?

Gruß Fiddi

1) Es gibt externen Zugriff darauf, der war auch mal sperrend, aber jetzt nicht mehr.

2) Wir sichern jede Nacht alte Einträge in eine andere DB und löschen die alten Einträge.

3) Es gibt einen SQL-Job, der alle 5 Minuten da rein schreibt auf Basis der in den letzten 5 Minuten erzeugten Reservierungsposten. (Der hat aber nichts mit der o.g. Lücke zu tun)

4) Wir haben auf SQL-Ebene über Storage - Mange Compression die Komprimierung für die Change Log Entry aktiviert


zu 1) und 3) das wollen wir auf jeden Fall abschaffen. Ich weiß nicht, wer auf diese dolle Idee gekommen ist

zu 4) wir hatten sowohl vorher als auch nachher große Sperr-Probleme. Wobei die Komprimierung für das viele Schreiben wohl auch eher nachteilig ist, ich weiß nicht, warum wir das gemacht haben.


Ich hatte mich im ersten Post verschrieben; ich dachte, dass man keine Änderungen im Änderungsprotokoll vornehmen können dürfte (also keinen Artikel bearbeiten während die Freigabe einer Einkaufsbestellung die Änderungsprotokollposten sperrt).

Dachte ich es mir doch.

Das Changelog ist ein Problem und immer Performance- anfällig, und da es im Echtbetrieb schon mal den halben genutzten Speicherplatz (oder mehr) belegt, sollte man sich da möglichst raus halten. Man sollte eher im Gegenteil für Auswertungen ein eigenes Änderungsprotokoll schreiben (mit weniger Informationen).

Ein nicht ganz ungefährliches Thema ist auch noch die Verwendung mehrerer Servictiers, die auch noch miteinander synchronisiert werden müssen (und manchmal Ärger machen, siehe Ereignisprotokoll) (evtl. mal alles auf einen Servicetier legen (testweise))

Wie sieht es denn mit de Pflege der SQL- Datenbankstatistiken bzw. insbesondere der Optimierung des Änderungsprokollschlüssels.

Wir haben 6 ServiceTiers für Anwender (wir haben 240 User) und 9 ServiceTiers für Jobs. Alles auf eins ist da glaube ich keine Option. Wenn natürlich die Synchronisierung der ServiceTiers das grundlegende Problem ist - haben wir da irgendeine Chance, das anderweitig als Ursache zu identifizieren? Was steht denn in so einem Fall in der Ereignisanzeige?

Wir lassen alle drei Wochen am Wochenende Skripte zur SQL-Optimierung von Jörg Stryk laufen. Dabei findet auch Indexoptimierung statt. Was da im Einzelnen passiert, da hat niemand von uns Aktien drin.

Alles auf eins ist da glaube ich keine Option

Da muss ich dir recht geben

Aber mit der richtigen Maschine (viele Cores und viel RAM) käme das auf eine Versuch an. Wenn alle Tiers auf einer Physik laufen (sei es als mehrere VMs auf einer Blechkiste oder alle Tiers auf einem Rechner) würde ich das trotzdem mal versuchen. Denn das reduziert auf alle Fälle den Synchronisationsaufwand.
Ach ja, und dann scheint es da noch das Problem zu geben, wenn die Server als VMs nicht auf einem phys. Rechner laufen, dass die Performace dann einbricht

Uff, NAV macht micht manchmal echt fertig mit den ganzen Performance-Macken.

Bis jetzt habe ich daher eher mehr Fragen als weniger.

Noch offen sind:
1) Ist es normal, dass ich Artikel ändern kann, wenn durch einen Einkaufskopf die Änderungsprotokollposten gesperrt sind?
2) Ist eine Lücke (Entry No_ nicht immer fortlaufend) in den Änderungsprotokollposten normal?
5) Macht es Sinn, das Changelog auf Vor-2013-Funktionalität umzustellen?

Neu sind:
3) Kann man herausfinden, ob wir Synchronisierungsprobleme haben?
4) Meinst du, es könnte auch sein, dass wir die Server als VMs auf VMs laufen haben könnten? Muss ich mal nachfragen, das ist bei uns extern gehostet

Vielen Dank schonmal! :)

Meinst du, es könnte auch sein, dass wir die Server als VMs auf VMs laufen haben könnten? Muss ich mal nachfragen, das ist bei uns extern gehostet

Ich meinte, ob die Servicetiers alle auf einer physikalischen Maschine laufen. Es macht in meinen Augen nur dann Sinn mehrere Servictiers zu benutzen, wenn Sie sich die physikalischen Ressourcen (Prozessor, Speicher, Platte, Netzwerk) nicht mit anderen auf dem gleichen Rechner teilen müssen. (mal abgesehen, es aus Strukturgründen notwendig, z.B. Jobqueue o. Webservice, die man schon mal neu starten können sollte, wenn Sie sich aufgehängt haben, ohne den Betrieb zu stoppen)

Ein Computer (physikalischer Rechner) hat eine endliche Rechenleistung. Da macht es keinen Sinn diese Rechenleistung auf möglichst viele VMs oder Servicetiers zu verteilen, um Ihn noch mit zusätzlichem Verwaltungsaufwand (Windows, Servicetier- Synchronisation) zu beschäftigen.

Gruß Fiddi

Ah ok, jetzt hab ichs verstanden, danke :) Wenn eh schon alle ServiceTiers auf dieselben CPUs, denselben Ram zugreifen, bringt Performance-technisch die Teilung nix.

Hat jemand evtl. noch Tipps zu den Fragen 1-3 und 5?

)1) Ist es normal, dass ich Artikel ändern kann, wenn durch einen Einkaufskopf die Änderungsprotokollposten gesperrt sind?

Die Änderungsprotokolle sollten eigentlich nicht so lange gesperrt sein, das es zu Probleme führt.

2) Ist eine Lücke (Entry No_ nicht immer fortlaufend) in den Änderungsprotokollposten normal?

Das kann möglich sein, da das Schlüsselfeld ein Autoincrement- Feld ist. d.h. die nächste Nummer wird unwiderruflich beim Einfügen ermittelt und erhöht, egal ob die Transaktion gut geht (Datensatz bleibt erhalten) oder ein Rollback (Datensatz wird wieder gelöscht) wg. eines Fehlers durchgeführt wird.

5) Macht es Sinn, das Changelog auf Vor-2013-Funktionalität umzustellen?

Das kommt darauf an, wofür du das Log benutzen willst.
Willst du alles wissen, was passiert mit deinen Datensätzen, dann eher nein. Möchtest du nur wissen, was die Anwender angestellt haben, dann evtl. ja, wenn es überhaupt möglich ist.

3) Kann man herausfinden, ob wir Synchronisierungsprobleme haben?

Da bin ich im Moment überfragt. Evtl. kann man da mit dem SQL-Server- Management- Studio (SQL-Server- Monitor, Ablaufverfolgung) was ausrichten.

Vielen Dank!

"Die Änderungsprotokolle sollten eigentlich nicht so lange gesperrt sein, das es zu Probleme führt." verstehe ich allerdings nicht. Wenn ich umfangreichen Code habe, der einfach lange braucht und ich zwischendurch meinetwegen noch Sperren auf anderen Tabellen habe, die sich zwar bis zum Timeout wieder auflösen, aber ich in Summe schon eine Minute brauche und direkt in der ersten Transaktion ist eine Tabelle betroffen, die im Änderungsprotokoll eingerichtet ist, dann ist die Tabelle doch die komplette Minute gesperrt bis zum Abschluss des Codes und damit aller Transaktionen, oder nicht?