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...

Hallo zusammen,

vielleicht gehört das nicht direkt zum TriStateLocking aber durchaus zum SlowPerfomance:

Folgendes Scenario:
Feature: Use optimized text search in List ist deaktiviert.
Fulltext Search auf der Datenbank ist aktiviert.

Feature

1. Filter auf Entry No. setzen in der Tabelle Cust_ Ledger Entry.
2. SQL Server Statement dazu:

SELECT TOP (@0) "21"."timestamp","21"."Entry No_","21"."Customer No_","21"."Posting Date","21"."Document Type","21"."Document No_","21"."Description","21"."Customer Name","21"."Your Reference","21"."Currency Code","21"."Sales (LCY)","21"."Customer Posting Group","21"."Global Dimension 1 Code","21"."Global Dimension 2 Code","21"."Salesperson Code","21"."User ID","21"."Source Code","21"."On Hold","21"."Open","21"."Due Date","21"."Pmt_ Discount Date","21"."Original Pmt_ Disc_ Possible","21"."Closed by Entry No_","21"."Closed at Date","21"."Reason Code","21"."Bal_ Account Type","21"."Bal_ Account No_","21"."Document Date","21"."External Document No_","21"."Remaining Pmt_ Disc_ Possible","21"."Pmt_ Disc_ Tolerance Date","21"."Max_ Payment Tolerance","21"."IC Partner Code","21"."Reversed","21"."Reversed by Entry No_","21"."Reversed Entry No_","21"."Payment Method Code","21"."Recipient Bank Account","21"."Message to Recipient","21"."Exported to Payment File","21"."Dimension Set ID","21"."Direct Debit Mandate ID","21"."Dispute Status","21"."Promised Pay Date","21_ext"."OPP Pmt_ Import Entry No_$88cf5d4c-8afc-4a98-9cb7-212196c51d74","21_ext"."OPP Payback$88cf5d4c-8afc-4a98-9cb7-212196c51d74","21_ext"."OPP Mandate ID$88cf5d4c-8afc-4a98-9cb7-212196c51d74","21_ext"."OPP Installment Entry$88cf5d4c-8afc-4a98-9cb7-212196c51d74","21_ext"."Sepa Error Code$92c41f65-a7c7-4c3f-82e4-58aa649cfbfc","21_ext"."Transferred$92c41f65-a7c7-4c3f-82e4-58aa649cfbfc","21_ext"."Transferred from Entry No_$92c41f65-a7c7-4c3f-82e4-58aa649cfbfc","21_ext"."Entry No_ NAV 2009$92c41f65-a7c7-4c3f-82e4-58aa649cfbfc","21"."$systemId","21"."$systemCreatedAt","21"."$systemCreatedBy","21"."$systemModifiedAt","21"."$systemModifiedBy" FROM
"MSFBCTEST".dbo."MSF-FR$Cust_ Ledger Entry$437dbf0e-84ff-417a-965d-ed2bb9650972" "21" WITH(READUNCOMMITTED) JOIN "MSFBCTEST".dbo."MSF-FR$Cust_ Ledger Entry$437dbf0e-84ff-417a-965d-ed2bb9650972$ext" "21_ext" WITH(READUNCOMMITTED) ON ("21"."Entry No_" = "21_ext"."Entry No_")
WHERE ("21"."Entry No_"=@1 OR "21"."Description" COLLATE Latin1_General_100_CI_AI LIKE @2 OR "21"."Customer No_" COLLATE Latin1_General_100_CI_AI LIKE @3 OR "21"."Document Type"=@4 OR "21"."Document No_" COLLATE Latin1_General_100_CI_AI LIKE @5) ORDER BY "Entry No_" DESC OPTION(FAST 50)

3. In der Tabelle sind etwa 20 Millionen Einträge, Filter auf Entry No_ dauert etwa 10 Sekunden. Ich verstehe nicht warum auch beim Filter setzen, die Felder
"21"."Description" COLLATE Latin1_General_100_CI_AI LIKE @2 OR "21"."Customer No_" COLLATE Latin1_General_100_CI_AI LIKE @3 OR "21"."Document Type"=@4 OR "21"."Document No_" COLLATE Latin1_General_100_CI_AI LIKE @5) ORDER BY "Entry No_" DESC OPTION(FAST 50)
mitgefiltert werden? Ich hätte das beim Search erwartet aber nicht beim setzen der Filter auf das Feld direkt?

Hat jemand noch das Phänomen?

Danke und Grüße,
Irina

filterst du per Code, oder hast du die Table im Client offen und setzt da einfach nur den Filter?
Falls per Code, kannst du den vollständigen Code hier einstellen?

Nein ganz normal in der Page; was ganz unlogisch ist: auch das deaktivieren FullText Search auf der Datenbank und Dropen aller Search Indexe hilft nicht..

Hallo zusammen,

ich denke es werden grundsätzlich die Felder der DropDown List durchgesucht. In der Cust. Ledger Entry Tabelle sind es genau die die auch in der Where Clause automatisch ergänzt werden (abgesehen von Posting Date).

WHERE ("21"."Entry No_" = @1
OR "21"."Description" COLLATE Latin1_General_100_CI_AI LIKE @2
OR "21"."Customer No_" COLLATE Latin1_General_100_CI_AI LIKE @3
OR "21"."Document Type" = @4
OR "21"."Document No_" COLLATE Latin1_General_100_CI_AI LIKE @5)
ORDER BY "Entry No_" DESC OPTION(FAST 50)

Kann das bitte jemand verifizieren bzw. bestätigen? Das wäre sehr nett :). Im laufenden Betrieb dauert es ca. 50 Sekunden bis 2 Minuten und das ist extrem geduldaufreibend.

Gibt es die Möglichkeit die Standardspalte für Durchsuchen festlegen wie im alten Windows Client?

DANKE!

Die Cross Column Search kann soweit ich weiß nur über FilterGroups abgeschaltet werden (FilterGroup(0)).

https://learn.microsoft.com/en-us/dynam ... oup-method