Dynamics NAV Job Queue – Performance Bremse Onlineshop?

Dynamics NAV Job Queue – Performance Bremse Onlineshop?

Dynamics NAV Job Queue – manchmal kann ein Programmierfehler in C/AL Code dazu führen, dass Benutzer aufgrund von Datenbank-Deadlocks Fehler bekommen.
Ein Datenbank-Deadlock kann auftreten, wenn zwei Sitzungen versuchen, die gleichen Daten zu aktualisieren, und Datenbanksperren in verschiedenen Aufträgen erfassen. Der SQL Server erkennt Deadlocks und löst sie auf, indem eine der Transaktionen zurückgesetzt wird. In den vergangenen Monaten, fiel uns immer wieder bei verschieden Kunden auf, dass eine hohe Anzahl von Deadlocks und Tabellensperren sehr oft in Verbindung mit der Verwendung der Aufgabenwarteschlange entstanden. Um einen Überblick zu bekommen, haben wir für einen Kunden auf Wunsch eine grafische Darstellung der NAV Aufgaben entwickelt. Diese Grafik wird für die Dynamics NAV „Job Queue“ und die im SQL Server Agent definierten Jobs erstellt.

Diese Grafik zeigt die Aufgabenwarteschlange (Dynamics NAV „Job Queue“) des Kunden – jeder kleine Strich stellt eine Aufgabe mit der jeweiligen Dauer da!

Dynamics NAV Job Queue Timeline
Dynamics NAV Job Queue Timeline

Der SQL Server Agent erlaubt die Definition von Jobs, die aus (mehreren) Job Steps bestehen. Und das sieht dann so aus:

SQL Agent Job Queue Timeline
SQL Agent Job Queue Timeline

Gut zuerkennen ist, dass gewisse Aufgaben sich vom zeitlichen Ablauf eventuelle gegenseitig behindern.

Microsoft Dynamics NAV und E-Commerce ist in fast allen Unternehmen ein zentrales Thema. Anbieter versprechen durch 100% vollständige Integration mit Ihrem Microsoft Dynamics NAV-System. Dem Kunden stehen kundenspezifische Preisgestaltung, Produktspezifikationen, Lagerbestände und mehr direkt im Onlineshop zur Verfügung. Das funktioniert auch.

Aber was passiert, wenn z. B. die Anzahl der täglichen Bestellungen von genommen 100 auf 2000 anwachsen. Und Ihr Artikelstamm zehntausende von Artikeln beinhaltet? Wie lange braucht der „Dynamics NAV Web Services“ für den Datenaustausch? Und werden die Daten vielleicht noch anderweitig verarbeitet (Buchungen, Lagerbestände abgleichen usw.). Wahrscheinlich laufen auch in Ihrer NAV „Job Queue“ jede Menge Aufgaben. Sollten Sie Performance Probleme am SQL Server und in Ihrer Dynamics NAV Lösung haben, dann schauen sich Ihren SQL Server Agent und Ihrer NAV Aufgabenwarteschlange bitte genauer.

Gerne beantworte ich Ihnen persönlich weitergehende Fragen zu diesem Thema. Kontaktieren Sie mich einfach über unser Kontaktformular oder per E-Mail an info@dynamicsproject.com!

Olav Treffurt

Bad Smells in Dynamics NAV

Bad Smells


Unter Bad Smells, kurz Smell (deutsch ‚[schlechter] Geruch‘) oder deutsch übelriechender Code versteht man in der Programmierung ein Konstrukt, das eine Überarbeitung des Programm-Quelltextes nahelegt (Quelle Wikipedia).


Kurzum bei Bad Smells geht es nicht um Programmfehler! Vielmehr handelt es sich um funktionierenden Programmcode, der schlecht strukturiert ist. Demzufolge nicht optimal auf die Daten des SQL Servers zugreift und sie verarbeitet.
Das größte Problem liegt darin, dass der Code für den Programmierer schwer verständlich ist. So können sich bei Korrekturen und Erweiterungen häufig wieder neue Fehler einschleichen. Code-Smell kann auch auf ein tieferes Problem hinweisen, das in der schlechten Struktur verborgen liegt. Oft wird diese Problem erst durch eine Überarbeitung erkannt.



Bad Smells existieren in jedem Softwaresystem (auch bei uns!)


Bad Smells entstehen aus verschiedenen Gründen. Sei es beispielsweise durch Anforderungen an das NAV System und somit Geschäftsregeln oder Berechnungen zu verändern. Manchmal auch wegen schlechter Abstimmung in einem Entwicklerteam. Infolgedessen geschieht es schnell, das z. B. duplizierter Quellcode entsteht.
Jeder Programmierer kennt zudem das Problem, dass häufig unter Zeitdruck gearbeitet wird und dadurch nicht alle Anforderungen oder Erweiterungen gut durchdacht und getestet werden.

Beim Thema Variablen- und Funktionsnamen im C/AL Code verwenden, haben wir in den bei der Analyse von Performance Problemen in Dynamics NAV interessante Variationen entdeckt.

Hier ein kleines Beispiel:

Genauer gesagt haben mit V8 Search ein SQL Statements analysiert, dass von Dynamics NAV erstellt wurden. Diese Abfrage führt eventuelle zu Blockaden, Deadlocks oder brauchen einfach nur lange bei der Ausführung (Long Duration).


TSQL:

SELECT „timestamp“
,“Document Type“
,“Document No_“

FROM „Datenbank“.dbo.“Mandant$Sales Line“ WITH (READUNCOMMITTED)
WHERE (
„Document Type“ = @0
AND „Document No_“ = @1
)
ORDER BY „Document Type“ ASC
,“Document No_“ ASC


Die Abfrage benutzt einen gruppierten Index mit eindeutigen Spalten. Die Antwortzeit des SQL Skripts ist Top und Logical Reads optimal.

Demzufolge begibt man sich auf die Suche der verwendeten SQL Tabelle „Sales Line“ (Record 37) im Dynamics NAV C/AL Code. Bei der NAV Lösung unseres Kunden mit über 8.000 NAV Objekten und über 6,5 Mio. Zeilen C/AL Code eine echte Herausforderung.

Das Ergebnis wie oft die Tabelle „Sales Line“ (Record 37) in gesamten Code als Record benutzt wird lag bei 10.626 mal.
Und jetzt kommt der eigentlich Punkt des Themas – die verwendeten Variablennamen für den Record 37.


Bad Smells in Dynamics NAV
Bad Smells



Mit V8 Search hatten wir das Ergebnis in ca. 2 Sekunden.

Hier das Ergebnis:


SalesLine
SalesOrderLine
Loc_SalesLine
SalesLine2
OldSalesLine
locSalesLine
l_SalesLine
TempSalesLine
SalesLine3
SalesLine_loc
p_SalesLine
NewSalesLine
ToSalesOrderLine
CompSalesLine
TotalSalesLine
TotalSalesLineLCY
ATOSalesLine
SL_loc
l_SalesLineRec
v_SalesLine
Verkaufszeile_loc
RentalLine2
RentalLine
RentalOrderLine
TempSalesLines
SalesLineInvoice
OrderLine
SalesLine5
SalesLineForQuoteDetails_Loc
AVZ
VKZ_loc
verkzeile_loc
lSalesLine
TotalsSalesLine
FilterSalesLine
SalesLineToUpdate
ToSalesLine
PreviousSalesLine
SalesLines_loc
xSalesLine
SalesLineACY
JobTaskSalesLine
GlobalSalesLine
l_Salesline2
SalesLineBackup
ItemChargeSalesLine
ItemJnlLine2
PrepmtSalesLine
NewTotalSalesLine
BlanketOrderSalesLine
xBlanketOrderSalesLine
SalesOrderLine2
SalesOrderInvLine2
SalesLineToPost
TempPrepmtSalesLine
SalesInvoiceLine
CombinedSalesLine
TotalSalesLineLCY2
HasATOShippedNotInvoiced
ItemLedgEntryNotInvoiced
SalesLineForCharge
SlsLine
SL
SalesLine2_loc
SalesQuoteLine
OrderSalesLine
AttachedToSalesLine
SalesLine_loc2
pSalesLine
FromSalesLine
InvRoundingSalesLine
SalesLines
SalesLineOld
NewSalesLineLCY
SelectedSalesLine
SalesLineRec
BlanketSalesLine
TempSalesLine2
ToSalesInvLine
FromSalesHeader
ToSalesLine2
FromSalesLine2
FromSalesLineBuf
EmptyToSalesLine
ToAssemblyLine
TempFromAsmLine
ToSalesHeader
p_doclineno
SourceRefNo
retSalesLine
recSalesLIne
SalesLineMach_loc
VZ
LSalesLine1
FoundSalesLine
Rec
ActRec
NewRec
SalesLine4
CurrentSalesLine
pItemChargeSalesLine
tmpSalesLine
OldRentalLine
crMemoLine_loc
Loc_SalesLineFrom
Loc_SalesLineTo
PAR_SalesLine
AngebotsZeilen
SalLine
loc_SalesQuoteLines
xRec
VKZeile
SalesLineCharge
SalesLine1
SalesLineSplit
SalesLineReturn
Amount
DummySalesLine
ReturnSalesLine
OriginalSalesLine
DestinationSalesLine
ItemSalesLine
SalesLineBlanket
SalesLineOrder
SalesLineBoAfterCrM
RefSalesLine
InvDiscAmountEditable
SalesLineDest
CalcMethod
SalesHeader
WithDemandSalesLine
SalesLineItem
SalesLineBC
SalesLineNM
SalesLineRestored
SalesLineWithNegativeQuantity
SalesLineItemCharge
SalesLineRetOrder
SalesLineApplyTo
Factor
FirstSalesLine
SecondSalesLine
ReferenceSalesLine
InvoiceSalesLine
QuoteSalesLine
TestSalesLine
InvoiceLine
LastLine
wlRecSalesLine
ForSalesLine
CalcSalesLine
SynchronizingSalesLine
vkZeile2_loc
recSL
recTmp
recTmp2
recNew
LocOrderLines
LocReturnLines
CurrSalesLine
Verkaufszeile
PAR_SalesLines
BlanketSalesOrderLine



Nicht schlecht oder.
Die Benennung ist schwierig, aber es gibt eine einfache Möglichkeit, sicherzustellen, dass die Variablen- und Funktionsnamen mindestens von annehmbarer Qualität sind. Solange den Namen eine Art von Informationen hinzufügt, die der Rest des Codes nicht vermittelt, wird es für andere Entwickler einfacher, Ihren Code zu lesen. Der Grund, warum Benennung so wichtig ist, ist, dass Namen eine allgemeine Vorstellung davon geben können, was der C/AL Code ausführt. Mit anderen Worten ein guter Name kann Ihnen in Sekunden helfen, zu verstehen, was der C/AL Code oder das TSQL Statement tut.


Gerne beantworte ich Ihnen persönlich weitergehende Fragen zu diesem Thema. Kontaktieren Sie mich einfach über unser Kontaktformular oder per E-Mail an info@dynamicsproject.com!


Olav Treffurt

NAV Performance

Um eine Dynamics NAV Performance Verbesserung mit SQL Servern zu erreichen, ist es wichtig, die Ursachen statt Symptome der Probleme zu behandeln.




Dynamics NAV Performance Verbesserung | Das leidige Thema Dynamics NAV Performance und wie kann man sie verbessern? Und wer kümmert sich um dieses unbeliebte Thema? Gehören Sie auch dazu? Aber was ist das eigentlich? Was steckt dahinter, wenn von schlechter Performance die Rede ist?

Im Allgemeinen ist damit die Leistung des Computers gemeint bzw. die Zusammenarbeit von Hardware und Software, wie z. B. dem SQL Server und Dynamics NAV. Soll heißen um eine gute Performance zu erreichen sollten Hardware und Software aufeinander abgestimmt sein.

Nicht immer ist der SQL Server als Software Schuld an einer schlechten Performance. In 90 Prozent aller Fälle, die wir untersucht haben, sind Dynamics NAV Applikationen die Ursache, welche den SQL Server in die Knie zwingt. Besonders NAV Lösungen mit kundenindividuellen Eigenentwicklungen, Funktionserweiterungen und AddOns von Drittanbietern haben oft ein Fehlverhalten. Es können aber auch Mobile Datenerfassung für Dynamics NAV oder die Software für Backups Schuld an einer schlechten Performance sein.



Viele SQL Server Monitoring Tools bieten laut Herstellern in Form von Reports und KPI-Dashboards die Lösung für SQL Tunnig an. Im Internet gibt es viele Seiten und Ressourcen, die sich mit der Performanceoptimierung des SQL Servers auseinander setzten. Auch wir finden immer wieder gute Tipps und Anregungen von „SQL Performance Experten“. Oft helfen viele Informationen nur bedingt bei dem komplexen Thema NAV Performance weiter. Auch die Dynamics NAV „Super Tool Seite“ – mibuso kann nur bedingt Lösungen bieten.

Systemverwalter und Administratoren befinden sich gerade in kleinen und mittleren Firmen häufig in der Situation, dass sie als „Mädchen für alles“ agieren müssen. Einerseits sollen sie sich um das „teure ERP System“ kümmern, andererseits haben sie oft nicht die Zeit, die Werkzeuge und manchmal auch nicht Kenntnis (nicht böse gemeint!). Mit anderen Worten ein Problem, das sie so nicht lösen werden. Je nachdem, wie groß die Probleme sind, kann man sie aussitzen oder etwas dagegen unternehmen.

Vorausgesetzt sie entschließen sich doch etwas zu unternehmen, seien sich darüber im Klaren, das wird nicht preiswert! Spätesten ab hier steigen 80 % der Verantwortlichen aus. Wir kennen keine kostenlosen Werkzeuge, die Sie effizient bei Problemen mit der NAV Performance unterstützen.



Allen anderen empfehlen wir das Lesen der anderen Dynamics Project Blogs. Zugegeben SQL Abfragen zu analysieren ist echt schwer. Und noch die Ursache im Dynamics C/AL Code zu finden, ist aus unserer Sicht die größte Herausforderung. Oft werden die Ursachen nicht richtig erkannt und zusätzliche Hardware soll den Engpass beseitigen. Ob das immer funktioniert?

Nichtsdestotrotz gift es auch Lösungen wie unsere V8 Tools zur Dynamics NAV Performance Verbesserung mit SQL Servern. Wir beschäftigen uns seit Jahren mit dem Thema NAV Performance. Der Einsatz einer fertigen Lösung spart ihnen meist viel Zeit und Ressourcen. Die Entwicklung einer eigenen Lösung kann sehr aufwendig sein.

Bevor sie sich auf die Suche nach der verlorenen Performance machen, noch ein Wort zur V8 Methodik. Sie können nicht auf gut Glück an ihren SQL Server Instanzen oder Dynamics NAV Servern etwas ändern und hoffen, dass die Dynamics NAV Performance der Clients danach schneller werden.



Abbildung 1 zeigt den Optimierungsprozess, den wir mit den verschiedenen V8 Tools verfolgen:


Wo geht die Performance verloren?

Es gibt vier Schichten, die Sie einzelnen mit Hilfe der V8 Tools betrachten und untersuchen können:

  • Hardware =V8 Search
  • Physikalischen Datenbankstruktur = V8 Search
  • Logische Datenbankstruktur / Datenmodellierung =V8 Search / V8 Monitor
  • Datenbankzugriff Dynamics NAV = V8 Search



Sie haben die Wahl – Dynamics NAV Performance Verbesserung selber machen mit den V8 Software Paketen oder als DynamicsProject – V8 Performance Service!


Alles, was Sie brauchen, an einem Ort – DynamicsProject.com!


Gerne beantworte ich Ihnen persönlich weitergehende Fragen zu diesem Thema. Kontaktieren Sie mich einfach über unser Kontaktformular oder per E-Mail an info@dynamicsproject.com!

Olav Treffurt

Performance Probleme in Dynamics NAV

Performance Probleme in Dynamics NAV

 

Performance Probleme in Dynamics NAV ist auch unter NAV 2017 und dem SQL Server 2016 immer noch ein Thema.

Vor einigen Tagen habe ich eine neue virtuelle Maschine mit Dynamics NAV und dem SQL Server 2016 aufgesetzt, um ein Performance Troubleshooting mit dem „Query Store“ (Abfragespeicher) zu testen.

Ich bin ein leidenschaftlicher SQL Server Datenbankarchitekt, Software Engineer und ein Dynamics NAV Performance Troubleshooter. Kann ich mich in Zukunft nach einem anderen Betätigungsfeld umsehen, da ihnen nun der SQL Server 2016 mit dem sogenannten Abfragespeicher („Query Store“) ein Troubleshooting Tool in die Hand liefert, mit dem sie selbstständig Ausführungspläne „Plan Regressions“ analysieren und schlussendlich beheben können. Werden auch die teilweise hochpreisigen Performanceüberwachungstools von Drittherstellern, wenn sie es nicht schon sind, überflüssig?

Ich fände es gut!

Klar, unser Team lebt teilweise von den Problemen anderer mit Dynamics NAV und dem SQL Server. Sehr oft werde ich bei verschiedenen Dynamics NAV und SQL Server Blocking Problemen kontaktiert, um diese mit den „Vision 8 Tools“ effizient zu lösen. Sehe ich den „neuen“ Kollegen als Gefahr oder als Bereicherung für die Dynamics NAV Welt an?

Ich möchte ihnen das neue SQL Server Tool kurz vorstellen und ein wenig zeigen, wie gut bzw. schlecht es seinen Job macht.


Um was handelt es sich dabei bei dem neuen Feature „SQL Server Query Store“?


Mit dem neuen Feature SQL Server Query Store lassen sich Informationen zur Ausführung von Abfragen auf z. B. Dynamics NAV Datenbank aufzeichnen. Somit sind z. B. auch nach einem Neustart des SQL Server Dienstes die verwendeten Ausführungspläne noch verfügbar. Die Ausführungspläne können zusammen mit Statistiken (wichtig für Performance Optimierung) zur Ausführung der Abfrage über vorgefertigte Reports komfortabel analysiert werden.





Ich sehe den „SQL Server Query Store“ als eine großartige Ressource und Ergänzung für Performance Tuning. Allerdings sollten sie die neue Möglichkeit der Performance Optimierung sorgfältig verwenden!


Was können sie tun, wenn immer wieder Performance Probleme in Dynamics NAV auftauchen?


Die meisten meiner Kunden haben komplexe Prozesse in ihrem Dynamics NAV abgebildet, die die Leistung beeinträchtigen, wobei das größte Problem dann Sperren, Deadlocks und Timeouts sind.

Während die Dimensionierung des NAV-Servers gut eingerichtet ist, sind im Bereich der SQL Server-Dimensionierung, Einrichtung, proaktive Überwachung, vorbeugende Wartung und Optimierung sehr oft nicht vorhanden. Die „SQL Server HW und SW Plattform“ ist ein sehr wichtiger Aspekt, wenn es um die richtige Leistung von NAV geht. Die Lösung könnte so einfach sein wie das Hinzufügen von RAM oder das Ändern von Festplatten.

Allerdings sobald alle diese Schritte durchgeführt wurden, sind Leistungsprobleme im stark individualisierten Dynamics NAV Lösungen immer noch wahrscheinlich.


In diesem Zusammenhang empfehle ich ihnen unsere „Vision 8 Performance Packs“.

Leider kommt man oft um ein Redesign für NAV (Pages, Berichte usw.), Datenarchivierung, Re-Codierung spezifischer Anwendungsbereiche nicht drum rum, um eine optimale NAV-Leistung zu erreichen.


Toller Hinweis…, aber wo fängt man und welche Tools helfen „Bad Code“ zu finden?


Aus meiner Sicht werden viele wichtige Tools im Bereich Performance Optimierung ab dem SQL Server 2012 mit liefert z. B. DTA (Database Tuning Advisor), Extended Events, Hypothetical Indexes, Performance Counters, SQLDiag (Sammeln von Diagnoseinformationen), SQLIO (Disk Subsystem Benchmark Tool) u.v.m.

Ab dem SQL Server 2014 SP 2 gibt es den neuen Kollegen „Query Store“, DBCC CLONEDATABASE (Kopie einer Datenbank nur mit Schema und Statistiken), In-Memory OLTP (Arbeitsspeicheroptimierung) usw.

Aber auch Dynamics NAV bietet eine Menge Tools und Funktion um Performance zu messen und zu optimieren z. B. „FULL SQL Trace“, „Data Collector Set“ für Microsoft Dynamics NAV „trace event data“ oder Dynamics NAV „Performance Counters“.

Leider können diese Tools nur einen Anhaltspunkt auf suboptimalen C/AL Code in Dynamics NAV liefern.


Aber im welchem Dynamics NAV Objekt ist der „bad“ C/AL Code?


Mit dieser Frage, beschäftige ich mich seit dem Jahr 2012 mit dem erscheinen von Dynamics NAV 2013. Aus diesem Grund habe ich von 2013 bis 2016 das „V8 NAV SQL Studio“ entwickelt. Für mein Team und mich ist bis heute das V8 Studio im Bereich Dynamics NAV, das „NAV Tool“, wenn es um C/AL Code und NAV Objekte geht. Von 2014 bis Sommer 2016 hatten wir das V8 Studio der „Dynamics NAV Welt“ angeboten – allerdings mit mäßigem Erfolg!



Woran lag es, dass NAV Entwickler, Administratoren, Dynamics-NAV-Berater oder Projekt Manager nicht damit arbeiten wollten?

Es ist zu komplex!

Ein guter Kollege sagte zu mir, dass er oft auch unter Zeitdruck im Daily Business steht und keine Möglichkeit hat sich mit diesem Thema zu beschäftigen.

Okay. Also habe ich das Tool vom Markt genommen und aus Teilen des V8 Studios ein neues Tool entwickelt – den „V8 NAV SQL Monitor“.

Ich bin mir sicher, mit der richtigen Beratung (natürlich durch mich) und dem Einsatz der richtigen Kombination der vorhandenen Tools, finden sie ihren „bad“ C/AL Code und minimieren Performance Probleme in Dynamics NAV!


Gerne beantworte ich Ihnen persönlich weitergehende Fragen zu diesem Thema. Kontaktieren Sie mich einfach über unser Kontaktformular oder per E-Mail an info@dynamicsproject.com!

 

Olav Treffurt