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

ASYNC_NETWORK_IO Dynamics NAV

ASYNC_NETWORK_IO Dynamics NAV

 

Der ASYNC_NETWORK_IO Wartetyp des SQL Servers gehört zu jenen Wartetypen, die sehr oft von DBAs im Aktivitätsmonitor gesehen werden. Beunruhigend ist es, wenn hohe Werte im Monitoring auftauchen, da dieser Wartetyp mit am schwierigsten zu beheben ist. Vor allem in Verbindung mit Dynamics NAV.

Der ursprüngliche Name des „ASYNC_NETWORK_IO“ Wartetyp stammt aus der Zeit der langsamen Ethernet-Geschwindigkeiten von 10 Mbit/s und 100 Mbit/s, die bis Mitte der 2000er Jahre häufig verwendet wurden.

In den meisten Fällen beziehen sich die hohen Werte für diesen Wartetyp nicht tatsächlich auf Netzwerkprobleme (das ist sehr seltener Fall), vor allem mit den sehr schnellen Ethernet-Geschwindigkeiten von 40 Gigabit oder 100 Gigabit Geschwindigkeit.

Übermäßige ASYNC_NETWORK_IO Werte können unter zwei Szenarien auftreten:

Die Sitzung muss darauf warten, dass z. B. der Dynamics NAV RTC Client die von SQL Server empfangenen Daten verarbeitet, und dann das Signal an den SQL Server zu senden, dass der Client neue Daten für die Verarbeitung akzeptiert. Dies ist ein allgemeines Szenario, das schlechtes Anwendungsdesign widerspiegeln kann, und ist die häufigste Ursache für übermäßige „ASYNC_NETWORK_IO“ Warte-Typ-Werte.

Oder die Netzwerk-Bandbreite ist ausgereizt. Ein verstopftes Ethernet ist Verantwortlich für die langsame Datenübertragung. Dadurch wird die Effizienz der Anwendung stark beeinträchtigt.


Ein Problem mit der Client-Anwendung (z. B. Dynamics NAV RTC)


Der häufigste Grund für hohe Werte des „ASYNC_NETWORK_IO“ Wartetyp ist, dass die Anwendung die Daten, die aus SQL Server schnell genug kommen, nicht verarbeiten kann. Wenn von der Anwendung eine große Datenergebnismenge anfordert, wird eine langsame Datenverarbeitung dazu führen, dass sich der Datenspeicher füllt, wodurch verhindert wird, das SQL Server neue Daten an den Client senden kann.

„Row by Agonizing Row“ (RBAR) Verarbeitung (Dynamics NAV = „REPEAT … UNTIL NEXT …“) ist oft die Ursache für ein solches Verhalten und hohe ASYNC_NETWORK_IO Warte Typ Werte. In der RBAR-Anwendungsprogrammierung wird jeweils nur eine Zeile aus der von SQL Server gesendeten Ergebnismenge verarbeitet. In einem solchen Szenario wird die komplette Ergebnismenge, die für die Verarbeitung verfügbar ist, zwischengespeichert und dann wird SQL Server benachrichtigt, dass der Datensatz „verarbeitet“ wurde. Dies ermöglicht es SQL Server, einen neuen Datensatz zu senden, während die Anwendung die Daten aus dem zwischengespeicherten Ergebnissatz verarbeitet.


 

Was tun, wenn hohe „ASYNC_NETWORK_IO“ Warte-Typ-Werte auf dem SQL Server auftreten?


Erste Möglichkeit -> Sie sprechen mit uns.

Bei der Untersuchung der übermäßigen ASYNC_NETWORK_IO Warte-Typ-Werte sollte folgendes überprüft werden:

Stellen Sie sicher, dass für die Clientanwendung entsprechende Sichten erstellt werden, dass die Datenfilterung von der SQL Server-Instanz durchgeführt wird und dadurch eine deutlich geringere Datenmenge an die Clientanwendung gesendet wird. Überprüfen Sie, ob es die Möglichkeit gibt, den angeforderten Datensatz in einer Weise zu reduzieren, um die Datenfilterung auf dem SQL Server direkt durchzuführen.

Im Falle von Einzel- oder Ad-Hock-Abfragen ist sicherzustellen, dass eine WHERE-Klausel (NAV = SETFILTER…, SETRANGE…) überall dort hinzugefügt wird, wo es möglich ist und dass die Abfrage ordnungsgemäß optimiert ist, um den angeforderten Datensatz nur auf die erforderlichen Daten zu beschränken.

Die Verwendung einer berechneten Spalte, die mit einer benutzerdefinierten Funktion (in NAV „FlowFields“) mit einer großen Datenbank definiert ist, ist ein weiterer häufiger Grund für die hohen ASYNC_NETWORK_IO Warte-Typ-Werte aufgrund von RBAR.

Um den den Client mit einer nicht optimalen Abfrage der Datenmenge eingrenzen zu können, sollten Sie im SQL Server die DMV [sys].[dm_exec_sessions] abfragen und dort überprüfen, welcher Task „suspended“ ist und dessen wait_status „ASYNC_NETWORK_IO“ ist.

Wenn die oben beschriebenen Punkte in Koordination mit den Anwendungsentwicklern abgearbeitet sind und der SQL Server immer noch hohe ASYNC_NETWORK_IO Warte-Typ-Werte anzeigt, dann ist es Zeit, zu prüfen, ob das Netzwerk ein solches Verhalten verursacht. Es gibt verschiedene Ursachen, durch die Einschränkung des physischen Netzwerkes, Fehlfunktionen oder einfach wegen falscher Netzwerkeinrichtungen. Folgendes sollte sorgfältig überprüft werden, um das Netzwerk die verursachten ASYNC_NETWORK_IO Wartezeiten zu beheben.


Probleme mit dem Netzwerk?

Überprüfen Sie die Netzwerkbandbreite zwischen dem SQL Server und dem NAV Client. Langsame Netzwerkadapter mit Bandbreite, die nicht der geschätzten Menge an Daten entspricht, die auf der Client-Seite verarbeitet werden sollen, sind oft der Grund für hohe ASYNC_NETWORK_IO Wartezeiten. In vielen Netzwerken sind oft noch 100 Mbit/s Adapter vorhanden. Diese Adapter können oft nicht auf die Anforderungen moderner SQL Server-Datenbanken und die damit verbunde Menge der verarbeiteten Daten antworten. Sogar mit der Umstellung auf 1 Gigabit-Adapter bleiben viele System noch unter den Anforderungen aktueller SQL Serverdatenbanken. 10 Gigabit Netzwerkadaptern werden als das Minimum für die meisten Umgebungen betrachtet, während 100 Gigabit bis 400 Gigabits größen sind, auf die viele Unternehmen in naher Zukunft wechseln werden, wenn sie das nicht schon gemacht haben!

Stellen Sie sicher, dass alle Netzwerk-Komponenten zwischen der SQL Server Instanz und dem Client, z. B. Router, Switches, Kabel ordnungsgemäß konfiguriert sind, voll funktionsfähig und der benötigten Bandbreite entsprechend.

Überprüfen Sie die Batch-Anfragen(SQL Server Performance Counter „Batch Requests“) des SQL Servers. Dieser Performance Counter repräsentiert die Anzahl der SQL-Anweisungen, die pro Sekunde auf dem Server ausgeführt werden. Unserer Meinung nach ist dies eine der besten Metriken für Performanceinformation die, der SQL Server liefert. Allerdings sollte diese Metrik nicht alleine betrachtet werden. Es ist notwendig, die Metrik „Batch Requests“ mit anderen Metriken (insbesondere CPU-Auslastung) zu korrelieren, um einen Gesamteindruck der Leistung Ihres Servers zu erhalten. Server mit Batch-Requests pro Sekunde größer als 1.000 werden als „busy“ betrachtet. Der Wert könnte stark von der tatsächlichen Systemkonfiguration, dem Aktivitätsniveau und der Anzahl der verarbeiteten Transaktionen abhänge

Achten Sie auf den SQL Server Performance Counter „Batch Requests“. Überprüfen Sie die „Batch Requests“ Zählerwerte, da dies auch ein Grund für die hohe ASYNC_NETWORK_IO im Aktivitätsmonitor sein können. Das Ziel ist es, die größte Anzahl von Batch-Anfragen zu erreichen, während die Ressourcen wie CPU, Disk und Speicher niedrig sein sollten.
Öffnen Sie den Windows „Perfmon“ oder einem Third-Party Monitoring Tool (z. B. V8 NAV SQL Studio) und fügen Sie diesen Zähler hinzu. Dieser Zähler befindet sich im Leistungsmonitor unter SQLServer: SQL Statistics: Batch Requests / sec.

Überprüfen Sie die NIC-Bandbreitenauslastung.

Die Netzwerknutzung ist über folgende Formel einfach zu berechnen:

Netzwerkauslastung% = ((Gesamtbytes\Sekunde * 8) / aktuelle Bandbreite) * 100

Sollte das Monitoring regelmäßig Werte größer als 60 % aufweisen, ist eine Umstellung auf einen schnelleren Netzwerkadapter / Netzwerkbandbreite sehr ratsam, um sicherzustellen, dass bei der Datenverarbeitung genügend Bandbreite zugewiesen werden kann.

Stellen Sie sicher, dass Auto-Negotiate der Netzwerkkarte die Netzwerkbandbreite richtig erkennt.

Um die aktuelle Geschwindigkeit aller aktiven Netzwerkverbindungen zu überprüfen, verwenden Sie den folgenden CLI-Befehl:

wmic NIC where NetEnabled=true get Name, Speed

Für den Fall, dass die Auto-Negotiation für einen bestimmten Adapter nicht die richtige Netzwerk-Geschwindigkeit auswählt wurde, ist es möglich, die NIC-Geschwindigkeit in der NIS-Eigenschaften manuell einzurichten.




Wie „busy“ ist Ihr SQL Server und Ihre Dynamics NAV Server?

Sie sind noch kein Kunde? Wir unterstützen Sie.
Mit dem richtigen Dynamics Project Plan können Sie Ihre Lösung optimal einsetzen und dafür sorgen, dass Ihr System nicht nur gut funktioniert, sondern stets die bestmögliche Performance bietet.

Haben Sie Fragen zu Netzwerkkomponenten? Unser Partner Netram Memory GmbH hilft Ihnen gerne weiter.


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

 

Ihr Team von DynamicsProject.com

 

Dynamics NAV und SQL Server Optimierung

Dynamics NAV und SQL Server Optimierung


Dynamics NAV und SQL Server Optimierung. In unserem Blog möchten Ihnen unsere Experten in den nächsten Wochen einen Überblick über die Optimierungsmöglichkeiten Ihrer Dynamics NAV Lösung und des dazu gehörigen SQL Servers vermitteln. Wenn es um die Optimierung geht, ist die Auswahl an Werkzeugen vielfältig. Eine richtige Entscheidung zu treffen, welche Tools die geeigneten sind, ist nicht einfach.

 

Wir möchten Ihnen mit Hilfe unseres V8 NAV SQL Studio die einzelnen Schritte für die vorliegende Aufgabenstellung der System Optimierung darlegen, da wir seit vielen Jahren in beiden Welten zuhause sind (MS SQL Server und Dynamics NAV). Unser Analyseweg geht von der Gesamtansicht in die Detailansicht: von der Hardware über die SQL Server Konfiguration bis zur NAV C/AL Programmierung. Sie lernen die einzelnen Module des V8 NAV SQL Studio kennen wie z. B.

 

  • V8 Live Monitor (Performance Counter) für den SQL Server und das Dynamics NAV Service Tier
  •  

  • V8 SQL Profiler
  •  

  • V8 Full Event Tracing für Windows (ETW)
  •  

  • Tipps zur Optimierung von SQL-Server-Indizes

 

[URIS id=2638]

 

Die einzelnen Blogs vermitteln Ihnen die notwendigen Kenntnisse, um im Dynamics NAV C/AL Code programmierten Routinen zu bewerten und die durch den C/AL Code generierten SQL-Abfragen zu verbessern, sowie die damit verbundenen Antwortzeiten des SQL Servers zu verkürzen. Es wird systematisch erläutert, wie die Abfrageperformance gemessen und optimiert werden kann.

Das V8 NAV SQL Studio bietet mehrere Tools, mit denen man die Performance überwachen, einstellen und optimieren kann. In einem Blog werden wir uns damit beschäftigen, wie man die V8 SQL-Servertools nutzen kann um den Einsatz von Indizes zu optimieren.

Die Dynamics NAV Leistungsindikatoren (Data Collector Set) geben Auskunft darüber, wie gut der Microsoft Dynamics NAV Server arbeitet. Durch die Verwendung der V8 Monitoring-Tools können Sie die Daten der Leistungsindikatoren der Komponenten wie z. B. NAV Service Tier, Speicher, physischen Datenträger und SQL Server überwachen, um evtl. Optimierungen der Leistung vorzunehmen.

 

Sie können uns jederzeit Fragen zu den Artikeln stellen und wir freuen uns über jede Anmerkung und Feedback!

 

Ihr Team von DynamicsProject.com

Warum ist Dynamics NAV langsam

Warum ist Dynamics NAV langsam?


Warum ist Dynamics NAV langsam? Im Laufe der Jahre sind wir bei DynamicsProject.com oft Unternehmen um Hilfe gebeten worden, da das Dynamics NAV System aus irgendeinem Grund immer langsam wurde. Sehr oft bei Unternehmen die eine Dynamics NAV Datenbank Größe über 50 GB haben.

 

Grundsätzlich sind die neuen Dynamics NAV Versionen und die Microsoft SQL Datenbank-Server gut aufeinander abgestimmt. Das Dynamics NAV Standardsystem („Dreischicht-Architektur“) arbeitet tadellos mit SQL Server zusammen. Aber wer arbeitet schon mit dem Dynamics NAV Standard?

 

Nun stellt sich die Frage, wo die Performance verloren geht. Wir bei Dynamics Project unterscheiden bei unseren Performanceanalysen zwischen Infrastruktur- und Anwendungs-Engpässen.

 

 

1. Die Infrastruktur

 

Die Infrastruktur ist schuld, wenn das System träge reagiert. Entweder ist der Server zu langsam oder das Netzwerk ist überlastet. Das ist die Wahrnehmung der meisten Dynamics NAV User. Leider ist das auch sehr oft auch die erste Aussage der Dynamics NAV Consultants gegeben über dem Kunden.

 

Die Lösung muss sein, entweder das Verbessern der Komponenten oder das Austauschen der Hardware. Oft können große Verbesserungen durch die Modernisierung der Infrastruktur vorgenommen werden. Allerdings gibt es noch andere Möglichkeit, die oft übersehen wird, nämlich die Anwendung.

 

2. Die Anwendung

 

Für die meister Dynamics NAV Anwender ist der RTC oder Classic Client nur eine geheimnisvolle Sache, die geschieht, wenn der Benutzer mit dem Computer interagiert. Die Geschwindigkeit dieser Anwendung wird oft nur im Zusammenhang mit der Leistung der aktuellen Workstation, Server oder Netzwerk gesehen. Diese Annahme könnte nicht weiter von der Wahrheit entfernt sein. Eine schlecht programmierte Dynamics NAV Anpassung kann noch viel schlimmer Auswirkungen haben, als jedes Performance-Problem der Hardware.

 

Unsere Empfehlung:

Sehen Ihr Dynamics NAV und Microsoft SQL Server immer als eine Einheit. Leider wird der Microsoft SQL Server oft nur als „Daten“ Behälter angesehen und dem entsprechend nicht ausreichend im ERP-Gesamtkonzept berücksichtigt.

 

Was können Sie tun?

Je nach Einsatzzweck kann der Microsoft SQL Server sehr komplex erscheinen. Und wenn es um Leistungsoptimierung mit Dynamics NAV geht, wissen viele DBAs einfach nicht, wo sie anfangen sollen. Leistungsoptimierung ist definitiv einer der Bereiche, wo Erfahrung ein guter Lehrer ist.
Aber irgendwo müssen jeder Datenbankverantwortliche beginnen Erfahrungen zu sammeln.

 

Wir möchten Ihnen hier ein paar generelle Anregungen zum SQL Server Performance-Tuning geben. Hierbei handelt es um einfache Dinge der Leistungsoptimierung für den SQL Server.

 

1. Identifizierung problematischer SQL Abfragen

 

In einer bestimmten SQL Server-Instanz gibt es vermutlich 7 bis 10 Dynamics NAV Abfragen, die für ca. 80 bis 90 Prozent der schlechten Performance verantwortlich sind, die im SQL Monitoring (z.B. Ablaufverfolgung mit dem SQL Server Profiler) im Laufe des Tages zu sehen sind.
Wenn Sie diese „Problem“ Abfragen identifizieren können, dass bei Dynamics NAV nicht ganz so einfach ist, haben Sie eine gute Ausgangsbasis, um die Beeinflussung auf die Gesamtleistung Ihres Servers zu optimieren.

 

Einrichten einer Blocked Process Report-Ereignisklasse (SQL Server Extended Events)

 

Die Blocked Process Report-Ereignisklasse zeigt an, dass ein Task länger als die angegebene Zeitspanne blockiert wurde. Diese Ereignisklasse schließt keine Systemtasks oder Tasks ein, die auf Ressourcen warten, für die keine Deadlocks erkannt werden können. Wir benutzen die SQL Server Extended Events um z.B. Sperren von Dynamics NAV zu analysieren.

 

2. Suchen Sie nach Datenträgerengpässen I/O

 

Die Auflistung der I/O-bezogenen Datenbank-Management-Objekte (DMOs) hilft ihnen bei Untersuchung, wenn Daten geschrieben und vom Datenträger gelesen werden. I/O Engpässe sind mit die wichtigsten Gründe, warum die Leistung des SQL Server leidet. Wenn Sie feststellen, dass viele physische I/O-Engpässe auftreten, sollte der Schritt sein, die Ursache aller Abfragen mit höhen physischen I/O sind zu finden, bevor Sie mehr Hardware hinzuzufügen.

 

Sie haben relativ einfache Methoden zur Verfügung, um festzustellen, ob Sie I/O Probleme haben:

  • sys.dm_exec_query_stats – Gibt die Aggregatleistungsstatistik für zwischengespeicherte Abfragepläne im SQL Server zurück.

  • sys.dm_exec_connections – Gibt Informationen über die zu dieser SQL Server-Instanz hergestellten Verbindungen zurück.

  • sys.dm_exec_sessions – Ist eine Sicht des Serverbereichs mit Informationen zu allen aktiven Benutzerverbindungen und internen Tasks. Sie können hiermit die aktuelle Systemlast anzeigen sowie eine relevante Sitzung ermitteln.

  • sys.dm_os_workers – Gibt eine Zeile für jeden Arbeitsthread im System zurück.

 

3. Indexverwendung

 

Die sys.dm_db_index_operational_stats DMF (Dynamic Management Function) ist eine oft vernachlässigte Quelle von Informationen. Sie kann Ihnen wertvolle Informationen über den benutzten Index einer Tabelle geben. Durch die Nutzung dieser DMF, können Sie alle Arten von Informationen entschlüsseln, nicht nur welche Indizes, sondern auch wie sie verwendet werden.

 

Fazit:

Inzwischen werden Sie bemerkt haben, dass einige dieser Themen größere Konzepte und Techniken erfordern, um in die Tiefe der Materie vorzudringen. Allerdings ist keines dieser Themen unlösbar für die DBAs.

 

Lesen Sie im zweiten Teil:

Warum ist Dynamics NAV langsam – Die neue Sicht der Dinge.


Sollte dieses oder ähnliche Themen Ihr Interesse geweckt haben, so würden wir uns über einen offenen Dialog mit Ihnen freuen.

 

Ihr Team von DynamicsProject.com

Back to Top

Neuer Blog für Dynamics NAV und Microsoft SQL Server

Neuer Blog für Dynamics NAV und Microsoft SQL Server

 

Herzlich Willkommen bei DynamicsProject.com!
Viel Vergnügen auf unserem neuen Blog.

 

Neuer Blog für Dynamics NAV und Microsoft SQL Server. Da die Themen Performance-Optimierung und C/AL Programmierung für Dynamics NAV und Microsoft SQL Server sehr abwechslungs- und facettenreich sind, bieten wir Ihnen ab heute in regelmäßigen Abständen kurze Artikel an, mit denen Sie tiefer in die Materie einsteigen können. Gleichzeitig dient der Blog dazu, Ihnen einen ersten Eindruck zu verschaffen, was Sie von dem Dynamics Project Team erwarten können.

 

Sie können uns jederzeit Fragen zu den Artikeln stellen und wir freuen uns über jede Anmerkung und Feedback!

 

Wir wünschen Ihnen und uns viel Erfolg

Ihr Team von DynamicsProject.com