Performanceprobs nach technischem Update

Hallo!

nach der Durchführungen eines technischen Update von NAV 2.65 DE (Native DB) auf NAV 2009 R2 (SQl Server) haben wir desöftern sehr große Performanceprobleme. Z. B. beim Rechnungs buchen (>60 sec). Ich mal mal den Client Monitor mit laufen lassen und folgende Schwerpunkte ausgemacht:

Beim ausführen des COMMIT; braucht er die meiste Zeit. Was genau geht da bei ausführen des Befehls auf dem SQL-Server vor? Und kann man das beschleunigen?

Was auch lange dauert ist das Laden der Tabelle Objects obwohl es beim buchen öfters verwendet wird. Wird das nicht im Zwischenspeicher gehalten?

Also mir ist klar das die alte Programmierung sich nicht mit dem SQL-Server verträgt. Ich bin auch dabei die Keys mit den Filtern anzupassen und auch find('-') mit Findfirst zu ersetzen. Aber bei den oben genannten Punkten weis ich nicht was ich da programmiertechnisch verbessern kann.

Auf wunsch kann ich auch gern auszüge aus dem Client Monitor Protokoll posten

Gruß
t000bi

ich bin dabei....auch find('-') mit Findfirst zu ersetzen.

So einfach ist das nicht. Das muss mal FINDSET (mit den richtigen Parametern!) werden, mal FINDFIRST und mal so bleiben (je nach Einsatz und Datensatzanzahl) siehe hier.

Hmmm ... leider ist das Thema NAV/SQL Performance SEHR umfangreich - es gibt zig Gründe für Probleme, aber auch ebenso viele Lösungen ...

Am besten mal das Forum nach "SQL Performance" durchsuchen; Du findest sicher einige Tipps und Empfehlungen!

Das mit dem COMMIT ist vermutlich (?) so:
Ab NAV 5.0 SP1 verwendet NAV sog. "Buffered Inserts"; d.h. ein INSERT wird nicht mehr unmittelbar ausgeführt, sondern eben "gepuffert". Der tatsächliche INSERT erfolgt erst, wenn ...
... auf den DS wieder zugeriffen werden soll.
... ein COMMIT erfolgt.

Werden sehr VIELE Datensätze in einer Transaktion erzeugt, dann kann so ein COMMIT tatsächlich das von Dir beschriebene Problem erzeugen, weil dann eben am "Schluß" alle zig DS soz. "am Stück" geschrieben werden ...

Umgehen kann man sowas z.B. durch:

Code:

IF [Record.]INSERT THEN;

Das impliziert ein Lesen des eben angelegten DS, d.h. der INSERT wird sofort ausgeführt.

Aaaaaber: eine Verzögerung beim COMMIT kann auch physikalische Probleme haben, z.B. im Zusammenhang mit SQL Checkpoints, etc..

Wie gesagt, das müsste man mal näher untersuchen.