BC25 TristateLocking - Slow Performance

Hallo zusammen,

wir haben bei einem unserer Kunden unter BC25 (BC25.1 / BC25.4) massive Probleme beim "Export" von Daten. Genannt sei hier einmal ein Lohnexport und ein Datevexport
-> beides 3rd Party Module (Haveldata / Sievers).
Der DTV-Export dauert ewig und 3 Tage (keine Ahnung wie lange wirklich, nach 12h hab ich dann den NST gekillt), vom Lohnexport will ich gar nicht anfangen.
Unter BC23 liefen beide Exporte fix.
Die Einstellungen an den NSTs (BC23 zu BC25) sind im Grunde ident.
Fragt mich nicht, wie ich darauf gekommen bin, aber unter BC25 hab ich mal das TriStateLocking deaktiviert -> schon ging es wesentlich schneller....(30mins < 12h)
Also lag der Verdacht nahe, dass TriState unter BC25 irgenwas kaputt macht, denn unter BC23 war es auch an, lief aber ja fix.

Aktivieren wir über die Funktionsverwaltung "Funktion: Legacy-Sperrschema in AL aktivieren" für alle Benutzer, dann geht der Export auch fix (Tristate am NST wieder an) -> also alles wie erwartet

Wir haben dann DB mal auf nen anderen Server geschoben, dort wieder TriState im NST (docker) auf default => true gelassen => schwubbs, auch schnell (30mins) ==> Hinweis: in der DB war noch kein Export ausgeführt <<<--- Theorie kaputt :(
Hier muss aber gesagt werden, dass der Server da auch massiv viel Ressourcen hat.

Okay, dann haben wir die Funktion halt auch mal am Testserver angeschaltet -> Export in 7mins durch, wobei der SQL-Server ja sicher noch was im Cache etc hatte, vom Export davor.

Hat jemand ähnliche Erfahrungen gesammelt, oder kann irgendwas dazu sagen?

Edit: erwähnenswert wäre, dass RCSI an der DB nicht aktiviert ist (auf keiner der getesteten) -> ich gehe daher davon aus, dass dies mein Performancekiller ist.
Der Umstand, dass es auf dem Testserver so fix lief, wird hoffentlich damit einhergehen, dass das Teil halt wirklich overpowered ist.

Hi, ich habe ein ähnliches Problem mit BC25. Manche Prozesse dauern 5-6 Fache von der Zeit als in der älteren Version. Habt ihr die endgültige Ursache gefunden? Mit dem EnableTriStateLocking habe ich bereits auch experimentiert, hat aber nicht den gewünschten Ergebnis gebracht.
Vielen Dank für deine Antwort.
Irina

Hi Irina,

leider nicht wirklich. Wir hatten wirklich nur massive Probleme beim Export von Daten (viele viele Daten). Für diesen Zweck hatte ich dann einen eigenen NST für den Export erstellt, auf dem EnableTriStateLocking auf false steht.
Die Prod-Dienste haben TriState alle aktiviert.
Auch wurde RSCI auf der DB aktiviert (eventuell geht der Export nun auch flott, aber wir brauchten damals die Daten recht schnell, daher wurde das nicht weiter verfolgt).

Wichtig für die Perf-Analyse bei dir wäre die Art der Prozesse, die länger dauern.

Auf welchem CU stehst du? Sind die Stände zu vorher gleich - sprich es wurde nix an der Abarbeitung der Prozesse im Code geändert - nicht mal eine einzige Zeile oder ein Zeichen?

Weiterhin empfehle ich jedoch auch wirklich aktiv TriStateLocking + RSCI anzuschalten, das bringt schon was.

Hi Stephan,

bei meinem Kunden ist die Erstellung der Zahlungslastschriften und die Zahlung Dateien aktuell ein großes Problem. (OPPLUS Lösung). Dabei handelt sich auch um relativ große Datenmengen von etwa 250.000 Lastschriften.
Was ich gemerkt habe das die Schleifen mit FINDSET(TRUE) und der gesetzten Option EnableTriStateLocking, extrem langsam sind.. wirklich extrem: update von 3 Datensätzen in 2 Sekunden.. bei 250.000 kann man ja hochrechnen. Ich habe die Option deaktiviert, darauf hin ist es etwas schneller geworden. Aber trotzdem kein Vergleich für BC14. Probleme im Code kann ich ausschließen, da ich einen ganz einfachen Test geschrieben hatte (FINDSET(TRUE) Schleife und Update von einen einzigen boolean Wert der betroffenen OPpLUS TAbelle ), der genauso lange dauert.. Dagegen FINDSET mit (False,False) läuft einigermaßen schnell.. Ich werde die Option nochmal auf dem NTS aktivieren und für ALLE User. Danach teste ich erneut..

Danke Dir für deine Unterstützung!
Irina

ah, ihr habt von BC14 auf BC25 migriert - blöde Frage: wann?
laufen die Wartungsjobs für die Datenbank? sprich Index rebuild bzw. reorganize?


Vielleicht nochmal kurz zur Erläuterung:
Im Client: "Funktion: Legacy-Sperrschema in AL aktivieren" ---> deaktiviert TristateLocking, egal was am NST eingestellt ist - sprich es greift das alte Sperrschema (wie vor BC23).
---> damit liefen unsere Exporte flott, aber wir wollten ja TristateLocking an haben -> also via Client "Funktion: Legacy-Sperrschema in AL aktivieren" auf nein und am NST greift dann Tristatelocking (sofern aktiv)

Meine Empfehlung wäre hier erstmal, einen separaten Dienst aufzusetzen, bei dem TriState generell aus ist und dann damit den Export testen.
Der normale Dienst, hat TriState an und somit profitieren die User dann auch vom besseren Sperrverhalten.

Wichtig wäre auch, dem SQL-Server genügend Ram und CPU zu futtern zu geben :) und die NSTs brauchen sicher auch.

Bei schlechter Performance kann auch die Analyse mit Missing indexes in Business Central databases weiterhelfen.

Hi nochmal,



Ich habe beides aktiviert TRIStar und Read Committed Snapshot, aber es hat nicht geholfen.
Ich habe so eine Vermutung dass wenn man bei FINDSET die Parameter (TRUE,FALSE) oder (TRUE,TRUE) mitgibt führt es dazu dass die Feature übersteuert wird.. Und noch zusätzlich zu einem (ganz komischen Verhalten führt).. sieht man im SQL Trace, es werden immer relative viele Datensätze immer in Blöcken gelesen um nur einen davon upzudaten und noch zusätzlich wird die gesamte Tabelle gesperrt, sodass nicht mal Select TOP(50) auf die Tabelle möglich ist.

Grüße,
Irina

naja, das 1. true ist ja eben für den Lock gedacht -> das true sagt ja "hey, ich will Daten ändern" - damit wird gelockt.

das 2. true ist deprecated - würde mir die frage stellen, warum das noch verwendet wird o_O

Bei altem Quellcode aus BC 14 alle Schleifen möglichst mit SetLoadFields versehen, um sich auf die tatsächlich benötigten Felder des Datensatzes zu beschränken, die Technik war in BC 14 noch nicht vorhanden und kam erst in BC 17.
Using partial records

Der zweite Parameter UpdateKey bei FindSet ist seit BC 22 auf "deprecated" und sollte entfernt werden.
viewtopic.php?f=7&t=2026&hilit=+updatekey#p149724

Hallo

Bei altem Quellcode aus BC 14 alle Schleifen möglichst mit SetLoadFields versehen, um sich auf die tatsächlich benötigten Felder des Datensatzes zu beschränken, die Technik war in BC 14 noch nicht vorhanden und kam erst in BC 17.

So Pauschal wie du das hier jetzt sagst, würde ich das nicht unterschreiben. An der falschen Stelle kann SetLoadFields auch ein Performance-Problem verursachen.
Warum:
Nut SetLoadFields soll dafür sorgen, das nur die benötigten Felder geladen werden. Das an sich wäre ja schön, hat aber ein paar Haken.

• Auch ein SetLoadFields, verhindert nicht, das der SQL-Server die kompletten Datensätze von der Festplatte liest, da der SQL-Server immer nur komplette Pages liest, in dem sich ein oder mehr komplette Records befinden
• Lädst du nur ein paar Felder, kann es sein, dass wenn du in deiner Schleife noch einmal den kompletten Datensatz benötigst, das BC die Datensätze noch einmal lesen muss, du also sogar die doppelte Anzahl Zugriffe hast

Gruß Fiddi

An der falschen Stelle kann SetLoadFields auch ein Performance-Problem verursachen.

Bei Read-only innerhalb der Schleife sind mir keine Nachteile bekannt, sofern man keine Felder vergisst, die man benötigt. Die sonstigen Einschränkungen stehen im verlinkten Artikel unter Usage Guidelines. Die Technik wurde ja u.a. wegen der schlechten Performance bei mehreren Tableextensions an einer Tabelle notwendig, seit die alle ab BC 23 in einer Companion Table zusammengeführt wurden, ist der Performancegewinn zwar geringer geworden, aber immer noch vorhanden.

Hallo zusammen,

vielen Dank für Zahlreiche Anmerkungen und Posts. Ich habe mittlerweile alle Problemstellen gefunden, hauptsächlich lag es tatsächlich an den Stellen mit Setfilter auf FlowFields, an den fehlenden Indexen für Tabellen Extensions, und

Ich würde gern den "alten" Code optimieren und auch an einigen Stellen SETLOADFIELDS benutzen, ( da stimme ich KOWA zu, bei den Großen Tabellen bringt es deutliche Verbesserungen).. Nun leider ist es aber so, dass der Code zum dem Partner Modul gehört ( in dem Fall OPPLUS ) und man selbst diesen nicht optimieren kann.. Gerade in den Schleifen SETLOADFIELDS ergänzen, falsche Filter entfernen.. dafür gibt es einfach keine Events...

Viele Grüße,
Irina

Hallo Irina,
ich habe bei einem Kunden auch das Problem dass die Ausgleichsfindung (In Erw. Zahlungseingang importieren) in OPplus nach einem BC Update deutlich langsamer geworden ist (allerdings BC 22.18). Wenn du das mit Continia klärst wäre ich vermutlich auch froh...