Dynamics 365 Business Central Wave 2

Dynamics 365 Business Central 2019 Release Wave 2 ist die erste Version, die die klassische Entwicklungsumgebung (auch als C/SIDE bezeichnet) nicht enthält. Mit dem Release Wave 2 von 2019 greifen Benutzer über den Browser, die Windows 10-Desktop-App, mobile Apps auf Android und iOS oder in Outlook auf Dynamics 365 Business Central zu.

Dynamics 365 Business Central 2019 Release Wave 2

Microsoft beschleunigt seine Investitionen in Geschwindigkeits- und Produktivitätsfunktionen für das moderne Browser-Erlebnis und erreicht damit einen wichtigen Meilenstein bei der Umwandlung in ein erstklassiges Desktop-Erlebnis für neue und erfahrene Dynamics Benutzer. Die modernen Clients unterstützen jetzt so viele Produktivitätsfunktionen, dass der ältere Dynamics NAV Windows-Client für Dynamics 365 Business Central künftig nicht mehr verfügbar ist. Der ältere Dynamics NAV-Client wird in früheren Versionen entsprechend dem Support-Lebenszyklus weiterhin unterstützt.

Stärkung der unabhängigen Software-Anbieter (ISV)

Indessen bietet das Release Wave 2-Update für 2019 eine Reihe von Funktionen, die die ISV-Entwicklung (Independent Software Vendor) für neue Lösungen vereinfachen und insbesondere die Migration vom Quellcode-Anpassungsmodell von Dynamics NAV zu Dynamics 365 Business Central optimieren sollen. Darüber hinaus wird sich Microsoft darauf konzentrieren, den Weg für unabhängige Software-Anbieter (ISVs) zu optimieren, um ihre Lösungen – und damit auch ihre Kunden – online zu Dynamics 365 Business Central zu bringen.

Moderne Entwicklertools

Die moderne Entwicklungsumgebung, die auf Visual Studio Code mit Azure DevOps und einer AL-Sprache basiert, unterstützt jetzt die Entwicklung großer Apps. Daher wird C/SIDE für Dynamics 365 Business Central in Zukunft eingestellt. Deswegen haben wir uns und unsere Performance Analyse Tool “V8 Search XE”auf die neue Situation eingestellt. Trotzdem wird sich im Bereich der Performance Optimierung von Dynamics 365 BC Wave 2 und SQL Server einiges verändern.

 So arbeiten Sie mit Leistungsproblem in Dynamics 365 Business Central 2019 Release Wave 2 zukünftig…

Was tun Sie, wenn sich Benutzer beschweren, dass “es langsam ist” in der neuen modernen Browser Umgebung? In diesem Abschnitt möchten wir einen Fehlerbehebungsprozess beschreiben, der Ihnen dabei helfen kann, die Hauptursache des Problems zu finden.
Bevor Sie mit der Lösung eines Leistungsoptimierungsproblems beginnen, ist es häufig hilfreich, “langsam” zu definieren und zu quantifizieren. Versuchen sie, akzeptable Werte für die Ausführungszeit von “langsamen” Vorgängen mit BC Benutzern auszuhandeln. Dies wird manchmal als “Festlegen einer Basislinie” bezeichnet.

Um ein Leistungsproblem zu lösen, werden häufig folgende Iterationen durchgeführt:

  • Messen Sie die Systemleistung und erfassen Sie Leistungsdaten vom SQL Server und den Dynamics 365 BC Servern
  • Suchen Sie einen Engpass
  • Beseitigen Sie den Engpass

und fahren Sie fort, bis die “langsamen” Operationen mit der festgelegten Basislinie vergleichbar sind.

Überwachung und Analyse der Telemetrie Business Central 2019 Release Wave 2 und höher.

Business Central sendet Telemetriedaten für verschiedene Aktivitäten und Operationen. V8 Search XE sammelt die Telemetriedaten für Business Central On-Premises über die V8 Services. Das heißt die Daten werden zentral für alle Server in der V8 Datenbank gespeichert.
Durch die Überwachung der Telemetrie erhalten Sie einen Überblick über die Aktivitäten und den allgemeinen Gesundheitszustand ihres Dynamics Systems. Es hilft Ihnen, Probleme zu diagnostizieren und Vorgänge zu analysieren, die sich auf die Leistung auswirken.

Der folgende Artikel kann Ihnen helfen, mehr zu diesem Thema zu finden:
Monitoring and Analyzing Telemetry Business Central | Microsoft Docs

Fazit:

Microsoft hat unserer Meinung nach viele neue Features im Bereich Performance Optimierung für Dynamics Business Central 2019 Release Wave 2 zur Verfügung gestellt. Andererseits werden auch sich auch Systembetreuer und Administratoren genauso wie C/AL-Entwickler/-innen mit der AL Programmierung befassen müssen. Wir stimmen der weitverbreiteten Meinung zu, dass wir die Dynamics Business Central / NAV onPremise Versionen noch einige Zeit mit der C/AL Programmiersprache unseren Spaß haben dürfen. Natürlich spielt das Know-how über die älteren NAV / BC Versionen für einen ERP Entwickler und Administratoren auch in Zukunft eine entscheidende Rolle.
Dinge ändern sich aber manchmal auch sehr schnell.

Gerne beantworten wir Ihnen persönlich weitergehende Fragen zu diesem Thema.
Ihr dynamicsproject.com Team

Optimieren der SQL Server Leistung mit Dynamics 365 Business Central on-Prem

Optimieren der SQL Server Leistung mit Dynamics 365 Business Central on-Prem und Dynamics NAV (alle Vorgängerversionen). Es gibt so viele Faktoren, die zu Leistungsproblemen in der SQL-Welt beitragen, dass es geradezu verwirrend sein kann, wo man überhaupt anfangen soll.

Wenn die Dynamics Anwendung und die zugehörige SQL Datenbanken wächst, ändern sich die Dinge. Zeilen werden geändert, das Schema wird aktualisiert und häufig verlangsamen sich die Dinge. Diese Leistungsschwächen können plötzlich oder zeitweise auftreten, aber es ist wichtig zu wissen, wie man Leistungsprobleme unterscheidet, damit man das einzelne Problem beheben kann.

Der Beitrag befasst sich mit einigen Schritten, die Sie ausführen sollten, wenn sich Ihre SQL Datenbank seltsam verhält. Damit Sie genau diagnostizieren können, was falsch läuft, und sich darauf konzentrieren, die Dinge zu beschleunigen. Optimieren der SQL Server Leistung mit Dynamics 365 Business Central sollte möglichst mit der Überprüfung der SQL Server Konfiguration starten.


Ist es die Datenbank? Oder der Server?

Wenn Sie Zugriff auf den Server haben, können Sie ein Tool wie System Monitor oder Perfmon verwenden, um die Prozesse zu überprüfen, die auf dem Server selbst ausgeführt werden. Hohe Speichernutzung, hohe CPU-Auslastung und langsamer Netzwerkverkehr sind rote Fahnen, bei denen das Problem möglicherweise nicht die Datenbank selbst ist.

Es gibt viele andere Systemdiagnosetools z.B. V8 Search XE , die bei diesem Prozess helfen können. Eines davon sollte Sie jedoch zumindest in die richtige Richtung weisen, bevor Sie unzählige Stunden damit verbringen, Tabellen, Indizes und mehr zu betrachten.

SQL Server verfügt über ein hervorragendes Profiling-Tool, mit dem sowohl vorhandene Probleme behoben als auch langsam laufende Abfragen isoliert werden können. Der XEvent Profiler zeigt eine Liveansicht erweiterter Ereignisse an. Es ist auch eine fantastische Möglichkeit, zusätzliche Daten zu Ihrer Datenbank für Leistungsoptimierungszwecke abzurufen (z.B. zu sehen, welche Abfragen am häufigsten ausgeführt werden, Dinge wie Speicher- und CPU-Auslastung zu untersuchen, potenzielle Blöcke zu identifizieren usw.).

In V8 Search XE die Optimieren der SQL Server Leistung mit Dynamics 365 Business Central in mehrere Bereiche aufgeteilt.


SQL Server System Check
V8 Search XE SQL Optimierung
V8 Search XE SQL Optimierung

V8 Search XE ist unendlich nützlich und ein guter erster Schritt zur Diagnose einer schlechten Leistung (oder von Fehlern im Allgemeinen). Er ist sowohl in Entwicklungs- als auch in Produktionsumgebungen nützlich.

Standardmäßig sind alle Datenbanken in der SQL Server-Instanz für die verschiedenen datenbankspezifischen Prüfungen geeignet, und Sie können den optionalen Parameter verwenden, um diese Prüfungen auf bestimmte Datenbanken einzuschränken. Gültig ab SQL Server 2012 aufwärts.


Performs checks:
  • Processor
  • Memory
  • Pagefile
  • I/O
  • Server
  • Service Accounts
  • Instance
  • Database and tempDB
  • Performance
  • Indexes and Statistics
  • Naming Convention
  • Security
  • Maintenance and Monitoring

Diese verschiedenen leistungsbezogenen Abfragen können es wert sein, regelmäßig überprüft zu werden, um potenzielle Probleme zu finden, die im Laufe der Zeit auftreten können.


Den Täter gefunden? Finden Sie jetzt heraus, warum die Abfrage langsam ist.

Sobald Sie eine bestimmte Abfrage identifiziert haben, die in den Analyse-Ansichten im V8 Search XE “SQL Server Check” als langsam ausgeführt indentifiziert wurde, können Sie sich den Ausführungsplan anzeigen, um genau zu sehen, was SQL Server hinter den Kulissen tut. Sie können von einer bestimmten Abfrage aus einfach über, die Schaltfläche “Show Plan” in der Symbolleiste oder über das Menüband darauf zugreifen:

V8 Query Plan

Ausführungspläne können auf einfache Weise potenzielle Probleme im Zusammenhang mit der Indizierung aufdecken , die dazu führen, dass Ihre gesamte Tabelle gescannt wird, anstatt genau das zu suchen, was sie benötigt. Auf den ersten Blick mögen sie unglaublich komplex erscheinen (und sie können es auch sein), aber sobald Sie mit ihnen gearbeitet haben, lernen Sie, Muster zu identifizieren und was sie damit verbunden sind (z. B. zeigt die X-Operation einen fehlenden Index für eine Tabelle usw. an).


Ein paar Dinge, auf die Sie hier achten sollten:
  • Suchen Sie nach Warnungen – Warnungen wie “No Join Predicate” sollten sehr offensichtliche rote Fahnen sein, die Sie wahrscheinlich ansprechen müssen. Die meisten Warnungen sollten zumindest weitere Untersuchungen rechtfertigen.
  • Reihenfolge der Vorgänge (Kosten) – Betrachten Sie die teuersten Operationen und festzustellen , ob solche Bestellung machen Sinn. Verbraucht ein einfacher Join 90% der Rechenleistung für den gesamten Anruf? Wenn ja, könnte etwas falsch sein.
  • Scans vs. Seeks – Beides ist nicht unbedingt schlecht, aber wenn eines viel länger dauert als erwartet (eines davon), lohnt es sich wahrscheinlich festzustellen, ob ein Index fehlt (d.h. der SQL Server scannt die gesamte Tabelle, anstatt auf einen gut definierten Suchwert zu greifen).

Das Verständnis von Ausführungsplänen ist mit Erfahrung verbunden, und Sie müssen sich hoffentlich nicht zu häufig mit ihnen befassen. Aber wenn Sie dies tun, wissen Sie, dass sie ein wertvoller Verbündeter im Kampf gegen schlechte Leistungen sein können.


Untersuchen Sie mögliche schlechte / fehlende Indizes

SQL-Indizes sind das A und O für die Leistungsoptimierung in Ihrer Dynamics NAV SQL Datenbank. Sie können sich diese ähnlich wie die Indizes vorstellen, die Sie möglicherweise in einem Buch finden, da sie es SQL ermöglichen, zu “wissen”, wo sie nach bestimmten Daten suchen müssen, anstatt willkürlich Seite für Seite durchzublättern.

Es ist erwähnenswert, dass Indizes nicht “fehlerfrei” sind und wie bei den meisten Dingen, wenn Sie sie falsch verwenden, sie mehr schaden als nützen können (d.h. stellen Sie sich vor, Sie gehen auf eine Schnitzeljagd mit außergewöhnlich Wegen oder beschissenen Hinweisen).

Eine großartige Sache ist, dass Sie diese Arbeit nicht immer selbst erledigen müssen. Leute wie wir, haben Tools wie V8 Search XE entwickelt, um Indizes basierend auf der Tabellennutzung zu empfehlen. Für die Optimieren der SQL Server Leistung mit Dynamics 365 Business Central on-Prem und Dynamics NAV von unschätzbaren Wert!


Statistiken

So wertvoll es auch sein kann, SQL-Abfragen zu optimieren, es ist erwähnenswert, dass SQL Server einige davon “gut” und andere “schlecht” selbst erledigt. Dies wird durch die Verwendung von Statistiken erreicht, indem getätigte Anrufe überwacht, Ausführungspläne zwischengespeichert und Beurteilungen darüber vorgenommen werden, wie ein bestimmter Anruf am besten ausgeführt werden könnte/sollte.
Beachten Sie, dass wir “gut oder schlechten” erwähnt haben und das ist beabsichtigt. Statistiken sind zwar unglaublich wertvoll, können aber auch Probleme verursachen, wenn sie nicht korrekt erfasst werden oder veraltet sind. In den meisten Szenarien müssen Sie sich wahrscheinlich nicht regelmäßig mit diesen befassen, aber es ist wichtig zu wissen, dass sie existieren.


Wie bei fast jeder Technologien ist es sehr unwahrscheinlich, dass nur eines dieser Elemente alle Ihre Leistungsprobleme mit SQL Servern und Dynamics 365 Business Central bzw. Dynamics NAV heilt. Betrachten Sie all dies als wertvolle Werkzeuge in Ihrem Arsenal zur Fehlerbehebung und verwenden Sie sie zusammen, wenn Probleme auftreten.


Gerne beantworten wir Ihnen persönlich weitergehende Fragen zu diesem Thema.
Ihr dynamicsproject.com Team

Fehlerbehebung bei Performance-Problemen


Die Fehlerbehebung bei Performance-Problemen mit Dynamics Business Central oder NAV mit SQL Servern ist schwierig.
Wir das Team von dynamicsproject.com machen uns ständig gedanken, wie wir V8 Search XE im Kampf gegen Performance-Probleme in Dynamics Business Central oder NAV verbessern können.

Extended Events (XE) ist ein großartiges Diagnosetool, das in SQL Server 2008 eingeführt wurde. Wir benutzen die Extended Events (XE) als Hauptbasis für die Datenanlyse in V8 Search XE. Der V8 XE Profiler ermöglicht es, per erweiterte Ereignisablaufverfolgungen auf allen Dynamics NAV Instanzen das “Full SQL Tracing” parallell ausführen, um Tabellensperren die auf jeder Instanzen auftreten kann “Live” zu erfassen.
Nach dem Einschalten der Ablaufverfolgung können in kürzster Zeit große Mengen mit den erweiterten Ereignisverfolgungsdaten erzeugt werden. V8 Search XE liest die XEL Dateien, die vom asynchronen Dateiziel für erweiterte Ereignisse erstellt wurden. Pro Zeile wird ein Ereignis im XML-Format zurückgegeben. Das Lesen großer Ergebnismengen kann unter umständen sehr lange dauern. Standard mäßig erstellt das V8_FullSQL_NAV_Trace Ereignis 5 Dateien a 1 GB. Bei 5 GB XEL-Daten (ca. 1 Milionen Datensätze im XML Format) konnte das Einlesen in die Datenbank Tabellen zu Analysezwecken, durch aus 45 Minuten und länger dauern.

Das ist eine lange Wartezeit, also haben wir und darüber nachgedacht, wie wir das Importieren schneller machen können.

Der neue V8 XE Loader.

Mit diesem Dienstprogramm von V8 Search XE (ab Version 2.4.5) können die Inhalte der V8_FullSQL_NAV_Trace*.xel erweiterter Ereignisdateien schnell in eine SQL-Server-Datenbank geladen. Die Grundidee hierbei ist, das Dienstprogramm mit einer Reihe von XEL-Dateien aus derselben Extended Event-Sitzung zu versorgen. Das Dienstprogramm liest die Ereignisse parallel in mehreren Threads. Diese Methode reduzierte die Zeit, die für die Verarbeitung einer einzelnen Datei benötigt wird um ein Zehnfaches. In unserem Test konnten wir die 5 GB XML Dateien in knapp 5 Minuten und hatten somit relativ schneller die komplette Transaktion inkl. C/AL Codes der Dynamics NAV/BC Sitzung, die für die Tabellensprerre auf dem SQL-Server verantwortlich wahr.


Diesen Art von C/AL Code sollten sie sehen, um eine Fehlerbehebung bei Performance-Problemen in Dynamics Business Central oder NAV durchführen zu können!


V8 XE Profiler Result
V8 XE Profiler Result


Gerne beantworten wir Ihnen persönlich weitergehende Fragen zu diesem Thema.
Ihr dynamicsproject.com Team

SQL Server Performance für Dynamics Business Central

SQL Server Performance für Dynamics Business Central. Dynamics NAV ist jetzt Business Central und dann kam irgendwann der Frust

Vor einiger Zeit hatten wir eine Anfrage zu den bekannten Problemen in Business Central / NAV. Die SQL Server Performance für Dynamics Business Central / NAV wäre auch nicht besser als die aktualisierte NAV Version 2013. Täglich viele Tabellensperren, frustrierte Benutzer und ein IT-Partner der etwas ratlos ist.

Unser Angebot, mit  V8 Care den “IST” Zustand des SQL Server und der Dynamics Business Central Lösung zu analysieren und die Engpässe der Datenbank zu sammeln. Getreu dem neuen Motto „Daten sind das Gold des 21. Jahrhunderts“.
Zu unserer Überraschung bekamen wir zur Antwort: “Daten zur Analyse der Dynamics Business Central Probleme seien genügend gesammelt worden.” Da der Interessent nicht über eigene IT-Experten im Unternehmen verfügte, nutzt er spezialisierte IT Dienstleister, die den SQL Server und Dynamics Business Central betreuen.
Zwar leben wir in einer Welt, in der Algorithmen in vielen Bereichen die Entscheidungen darüber treffen, was beim Eintreten eines bestimmten Ergebnisses oder dem Überschreiten einer Datengrenze zu passieren hat. Aber in ganz vielen Anwendungsszenarien ist und bleibt der Mensch die letzte Instanz.

Unsere Frage, was für Daten wurden gesammelt? Mit welchem SQL Server Monitoring Tool? Es gibt phantasische Real-Time SQL Server Monitoring Tools. Leider liefern die SQL Monitoring Tools keine Informationen zum Dynamics AL Code.

So ist bei der Überwachung von IT-Sicherheitssystemen letztendlich der IT-Admin oder Chief Security Officer derjenige, der die Entscheidungen trifft.

Aus diesem Grund möchten wir kurz auf die Möglichkeiten eingehen, die unser Analyse-Tool  V8 Search XE  bietet.

Das Problem:

Der SQL Server ist in der Lage, Anfragen von einer großen Anzahl gleichzeitiger Benutzer zu bearbeiten. Wenn SQL Server Anfragen von vielen Clients bearbeitet, besteht eine hohe Wahrscheinlichkeit, dass Konflikte auftreten, weil verschiedene Prozesse gleichzeitig Zugriff auf die selben Ressourcen anfordern. Ein Konflikt, bei dem ein Prozess darauf wartet, dass ein anderer Prozess eine Ressource freigibt, wird als Block bezeichnet. Obwohl sich in SQL Server ein blockierter Prozess normalerweise selbst auflöst, wenn der erste Prozess die Ressource freigibt, kann ein Prozess eine Transaktionssperre halten und sie nicht freigeben.

Unsere Lösung:

Um einen blockierten Prozess von Dynamics NAV / Business Central freizugeben, müssen wir zunächst feststellen, welcher Prozess der blockierende Prozess ist. Und dann, wenn möglich, den Sperrprozess von Dynamics NAV/BC analysieren und optimieren.
In V8 Search XE gibt es viele verschiedene Möglichkeiten, einen Blockierungs- und Entsperrungsprozess zu identifizieren, die unten aufgeführt sind:

1. SQL Server: Extended Events
2. SQL Server: Dynamic Management Views (DMV)
3. Windows Trace Events: SQL Trace Events
4. Business Central/NAV Server: C/AL tracing

 SQL Server: Extended Events

Das Ziel der durch V8 installierten Extended Events ist es, alle Informationen die von den Extended Events-Sitzungen gesammelt werden, in einer lesbarein Form darzustellen.
Die SQL-Abfragen, die den angegebenen Schwellenwert überschreiten (wir empfehlen mit 10 sekunden zu starten), werden in verschiedenen Extended Events-Sitzungen aufgezeichnet und gesammelt. Die SQL-Skripte werden als Grundlage für die Codeanalyse in V8 Search XE verwendet. Im V8 XE Profiler werden SQL-Abfragen bei ihrer Erstellung durch das Dynamics Business Central / NAV-Objekt aufgenommen.

V8 Extended Events sessions:
1. blocked_process -> Tabellensperren und Deadlocks
2. long_duration -> Lang laufende SQL-Abfragen in Business Central/NAV
3. V8_User_NAV_Trace -> Diese Sitzung ermöglicht die Anzeige von SQL-Abfragen für alle vom C/AL-Code ausgegebenen Anweisungen (Name des Windows-Benutzers mit der SPID des SQL Servers). Diese werden im V8 XE Profiler gespeichert und als Kommentare angezeigt.
/*
Get connection from the pool.
User: ComputerName\WindowsUsername
*/
4. V8_FullSQL_NAV_Trace -> Die Sitzung ermöglicht die Anzeige von SQL-Abfragen für alle vom C/AL-Code ausgegebenen Anweisungen. Diese werden als Kommentare für eine komplette Transaktion im V8 XE Profiler des SQL-Servers gesammelt und angezeigt.

 SQL Server: Dynamic Management Views (DMV)

“DMVs” sind in SQL Server eingebaute Abfragestrukturen, die Details über den Zustand und die Leistung von Servern und Datenbanken liefern. DMVs bieten einen gemeinsamen Mechanismus zum Extrahieren von “all things SQL” sowie von Leistungsdaten des Windows-Betriebssystems. Es gibt mehrere DMV-Kategorien, die Konfigurationsinformationen und Leistungsdaten zurückgeben.

 Windows Trace Events: SQL Trace Events

SQL Trace-Ereignisse verfolgen einen bestimmten Satz von SQL-Anweisungen, die von der Business Central Server-Instanz gegen die Business Central/NAV-Datenbank auf SQL Server ausgeführt werden.
Zu den gesammelten Ereignisdaten gehören: session ID, tenant ID, der Benutzer von Business Central/NAV und die SQL-Anweisung. Die Auflistung ist nur der SQL-Teil der Trace-Ereignisse von Business Central Server.

Wichtig!
Um diese Daten zu sammeln, benötigen Sie einen V8-Dienst pro Business Central Server-Instanz. Diese Funktion ist ab Version 6 der V8-Dienste verfügbar und erfordert das .NET Framework 4.7.2, das bei älteren Dynamics NAV nicht standardmäßig installiert ist.

Es besteht auch die Möglichkeit, einzelne Ereignis-IDs zu sammeln.

Die folgende Tabelle listet ein paar Dynamics SQL-Trace-Ereignisse auf. Zum Beispiel:

IDEvent (task/opcode)What is traced
1ExecuteScalar/StartSQL statements that query a database table and return a single field from a row in the query result.
2ExecuteScalar/StopSQL statements that query a database table and return a single field from a row in the query result.
3ExecuteNonQuery/StartSQL statements that return a number of rows from a database table
4ExecuteNonQuery/StopSQL statements that return a number of rows from a database table
5ExecuteReader/StartSQL statements that return a set of rows from a database table.

So sehen die SQL-Trace-Ereignis Daten aus, die in der SQL-Tabelle “V8 ETW Log Viewer” in der V8 Search XE-Datenbank gespeichert werden.

 Business Central/NAV Server: C/AL tracing

Seit der Version Microsoft Dynamics NAV 2013 verfügt der Server über eine Funktion, die es Ihnen ermöglicht, den AL-Aufrufstapel für SQL-Befehle anzuzeigen. Full SQL Trace aktiviert / deaktiviert das Tracing für alle neuen und bestehenden Sitzungen pro Dynamics Server-Instanz.

Damit können Sie SQL-Abfragen für alle von der AL ausgegebenen Anweisungen anzeigen. Alle SQL-Anweisungen zwischen aufeinander folgenden Kommentaren entsprechen der AL-Anweisung ab dem ersten Kommentar.
Diese Kommentare entsprechen den Ereignissen, wenn die Verbindung abgerufen und an die Microsoft DynamicsNAV Server-Verbindungsabfrage zurückgegeben wird. Diese Kommentare werden benötigt, um SQL-Abfrageprobleme von verschiedenen Clients auf derselben SQL-Verbindung zu trennen. Die SQL-Anweisung, die mit diesen Kommentaren übereinstimmt, wird von Microsoft Dynamics NAV Server ausgegeben, aber nicht von AL. Kommentare, die nur den Benutzernamen enthalten, entsprechen ebenfalls SQL-Anweisungen, die von Microsoft Dynamics NAV Server, aber nicht von Dyanmics AL Code ausgegeben werden.

Beispielsweise führt Microsoft Dynamics NAV Server Abfragen aus, um berechnete Felder zu berechnen, die in den Faktenfeldern angezeigt werden. Diese Arten von Kommentaren sind erforderlich, da Microsoft Dynamics NAV Server möglicherweise eine SQL-Abfrage ausführt, ohne dass eine erneute Verbindung zum Pool hergestellt wird, und sie nicht von Dynamics AL stammen.

Wichtig! Um diese Daten zu sammeln, benötigen Sie einen V8-Dienst pro Business Central Server-Instanz.

Daten sammeln und analysieren
V8 Search XE speichert zwei Arten von Daten:

1. Nach dem der SQL-Trace erfasst wurde, werden die Daten in der SQL-Tabelle gespeichert. Der Trace wurde in der Tabelle “V8 XEvents Full SQL Trace” in der V8 Search XE-Datenbank gespeichert.

2. Der vollständige AL-Programmiercode der jeweiligen Objekte. Die Daten sind in der Tabelle “V8 Performance Profiler” in der V8 Search XE-Datenbank gespeichert.

Mit dem Modul “V8-Quellcode-Suche” können Sie Ihre gesamte Dynamics NAV/BC-Codebasis durchsuchen, um die Stellen zu finden, an denen bestimmte Codeelemente referenziert werden.

Fazit
Diese speziellen Daten, sind mit einem Real-Time SQL Server Monitoring Tool nur sehr schwer zu erfassen. Sie müssen alle im Business Central Server-Instanz parallel überwachen.

V8 Search XE soll allen Administratoren und Entwicklern, die eine ERP-Lösung von Dynamics NAV/BC unterstützen, die Möglichkeit geben, eine Aussage über die Schwächen der von Dynamics Dynamics Business Central / NAV generierten SQL-Befehle zu treffen und diese zu dokumentieren.

Es zahlt sich auf jeden Fall aus, die Dynamics NAV Performance von einem Dritten mal checken zu lassen um herauszufinden, in welchem Zustand das ERP System und der SQL Server sich befindet.
Danach kann man überlegen, welche Optionen man für die weitere Vorgehensweise dann hat, die SQL Server Performance für Dynamics Business Central zu verbessern.

Gerne beantworten wir Ihnen persönlich weitergehende Fragen zu diesem Thema.
Ihr dynamicsproject.com Team

Warum ist Dynamics NAV langsam Teil 2

Warum ist Dynamics NAV langsam Teil 2



Warum ist Dynamics NAV langsam Teil 2 – wir möchten noch einmal das Thema für Sie zur Sprache bringen. Die neue Sicht der Dinge.

Stellen Sie sich vor, einen erfahrenen Dynamics NAV Partner für das Thema Funktionalitäten und Anpassungen in Dynamics NAV zu haben, der weiß, dass er sich Ihr Vertrauen täglich erarbeiten muss. Einen Partner, der Ihre Bedürfnisse versteht, die passenden Lösungen plant, baut und implementiert.

Nach einiger Zeit läuft NAV oft sehr träge, und das ausgerechnet in zeitkritischen Situationen? Sie haben eine Menge investiert , um Ihr ERP System aufzubauen. Zeit, Geld und Ressourcen wurden eingesetzt, aber sobald Sie Artikelkarte in NAV aufrufen… sind Sie bereits genervt!
Warum – weil Sie eine gefühlte Ewigkeit warteten, bis die Daten sichtbar sind. Oder wichtige Informationen zu Bestellungen aus dem angebundenen Web Shop werden nicht zügig abgearbeitet… kommt Ihnen das bekannt vor?
Seit dem das NAV System “live” ist, funktioniert die Betreuung des ERP Systems durch den Partner vor Ort nur sehr …

Und was machen die meisten Dynamics NAV Verantwortlichen im Unternehmen?

Wenig bis Nichts. Sie sprechen mit dem NAV Partner. Der bekommt die Probleme aber auch nicht richtig in den Griff. Und jetzt? Auf die Suche nach einem neuen Dynamics NAV Partner machen? Nach dem “1-Klick-Programm” für NAV Probleme im Netz suchen?

Es gibt keine “One click alles wird gut Lösung” für NAV Probleme!!!



NAV Performance Optimierungs Tools gibt es leider nicht so viele auf dem Software Markt. Warum eigentlich? Ganz einfach – es ist ein undankbarer Job so etwas zu entwickeln. Trotzdem entwickeln wir mit unserer Kreativität und Leidenschaft für Sie neue Produkte.

Zum Beispiel unser neustes Tool V8 Search XE – Dynamics NAV und SQL Server Performance Anaylzer. Warum wieder so eine neue Mammutaufgabe?

“Weil wir es lieben… und ein bisschen irre sind!”

Seit dem Jahr 2012, mit Einführung Dynamics NAV 2013, haben wir voller Elan und Enthusiasmus eine Vision gehabt – Tools für Dynamics NAV und dem SQL Server zu entwickeln, die das Leben leichter machen sollen. Wir planten eine ganze Produktlinie Namens “Vision 8” . Die acht im Namen ist eigentlich gar keine “8” sonder ein Unendlichkeitszeichen “∞” (ließ sich beim schreiben schlecht darstellen).


Warum ist Dynamics NAV langsam Teil 2


Unternehmen sollen bei der Produktentwicklung die Bedürfnisse des Nutzers in den Mittelpunkt stellen. Im Idealfall empfindet der Nutzer das Produkt dadurch als nützlich und einfach zu bedienen.

Einfach machen: Das sagt sich so leicht. In Wirklichkeit ist Einfachheit oft die schwierigere Aufgabe.

Die Herausforderung liegt in der Funktionsvielfalt eines “NAV Performance Analyzer”

Dass die nutzerzentrierte Produktentwicklung gerade in den letzten Jahren in den Unternehmen immer wichtiger wird, liegt an der steigenden Komplexität der Produkte wie Dynamics NAV und dem SQL Server im Arbeitsalltag der Benutzer.

Je komplexer die IT-Infrastruktur, desto schwieriger ist es, diese hochperformant und sicher zu halten. Lässt sich Hochverfügbarkeit für die kritische Unternehmenssoftware wie Dynamics NAV überhaupt noch garantieren? Und welche Möglichkeiten gibt es, das komplexe Thema Performance Analyse zu vereinfachen?

Es gibt eine Vielzahl von Tools für die Leistungsüberwachung und -optimierung von SQL Servern. Kostenlose Monitoring-Tools mit Tipps, Tricks und Know-How bei Performance Problemen – alternativen zu teuren, großen und aufwändigen IT-Infrastruktur Monster Tools.

Egal ob kostenlos oder teuer; helfen Ihnen diese Tools bei Tabellensperren oder NAV Clients die nicht reagieren?

NEIN!

Was genau ist das V8 Search XE Tool und was macht es so besonders? Was unterscheidet V8 Search XE von anderen ähnlichen Diagnosetools – die es eigentlich nicht gibt; oder haben Sie eins im Internet gefunden?

Warum ist Dynamics NAV langsam Teil 2 – Fazit

Egal welchen Weg Sie wählen, sollten Sie am Ende Ihr Dynamics NAV System fit für die Zukunft machen…
Also warum nicht mit V8 Search XE

Gerne beantworten wir Ihnen persönlich weitergehende Fragen zu diesem Thema.

Siehe auch

https://www.dynamicsproject.com/allgemein/sql-server-performance-fuer-dynamics-business-central.html

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

 

Support-Anrufe – Tabelle gesperrt?

Support-Anrufe: Welcher Microsoft Dynamics NAV Benutzer hat eine Tabelle gesperrt?

 

Viele von Ihnen kennen die Support-Anrufe von verzweifelten Kunden oder Kollegen, die etwa so klingen: “Hilfe! Niemand kann etwas Buchen!”
“Alles, was wir bekommen, ist eine Nachricht, dass die Tabelle Artikelposten von einem anderen Benutzer gesperrt ist!”


“Find the NAV Session ID that holds the blocking lock” – gerne, aber wie?


Bis NAV 2009R2 war die Sitzungs-ID in der NAV-Sessions-Liste dasselbe wie die SQL Server SPID. Beginnend mit Microsoft Dynamics NAV 2013, entspricht die Sitzungs-ID nicht mehr den SQL SPID.


Der SQL Server erkennt, dass eine Blockierung durch das NAV Service Tier entsteht mit der SPID XXX und als User wird der Netzwerkdienst angezeigt. AAAAAAHHH!!!”
Und welcher NAV Benutzer verursacht das Problem? Wen soll man anrufen, den Netzwerkdienst??


Dem Anschein nach ist der „Leidensdruck” noch nicht hoch genug, dass sich Dynamics NAV Benutzer/Kunden von Dynamics NAV 2013 oder höher bei Ihren Microsoft Dynamics-Partner über diesen unbefriedigende bzw. nicht vorhandene Problemlösung beschweren.


Immer wieder Fragen mich meine Kollegen, Kunden und sogar Microsoft Dynamics-Partner nach einer Lösung.


Unsere erste Lösung der V8 NAV SQL Monitor – leider nicht ganz optimal für NAV Service Tiere auf verschieden Computern.


Basierend auf unserer ersten Idee, haben wir aus einer Windows-Applikation einen Windows-Service entwickelt. Damit ist das Problem der NAV Service Tiere auf verschiedenen Maschinen gelöst (guter Tipp von einem NAV Entwickler Kollegen).
Alle Informationen lassen in einer SQL Server Datenbank zusammenfassen. Somit kann die NAV Session ID, User Name und SQL SPID in einer SQL Sicht anzeigt werden. Damit stehen alle Analyse Möglichkeiten des SQL Server in Bezug auf Deadlocks, Blocking Process und vieles mehr für jeden Dynamics NAV Benutzer zur Verfügung.

[URIS id=2921]



Die Performance Optimierung in Dynamics NAV kann beginnen, da man jeden NAV Benutzer gezielt ansprechen kann, was er gerade in Dynamics NAV macht und warum die anderen Benutzer gesperrt werden!


Let’s have big fun!


Kleiner Hinweis:

Die Dynamics NAV Benutzer können in den seltensten Fällen etwas für das Sperren der Tabellen. In 95% der Fälle ist der Dynamics NAV C/AL Source Code die Ursache – nicht der NAV Benutzer!


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.



Ihr Nutzen: weniger Support-Anrufe!

 


Unser Workshop-Angebot – V8 Performance Management Pack


  • 3 Tage Vor-Ort- oder Onlineanalyse / Software installation durch/mit einen Mitarbeiter unseres Dynamics Project Teams
  • Installation, Konfiguration und Verwaltung von V8 NAV SQL Monitor
  • Konzept zur weiteren Vorgehensweise mit Detail-Anweisungen zur Dynamics NAV und SQL Server Optimierung


 

Features | SQL Server | Dynamics NAV


  • Echtzeit-System SQL-und Performance-Daten
  • Datenbank- und Protokolldateigröße
  • Sperren und Latches | Pufferverwaltungsstatistiken
  • Arbeitsspeicher | Festplattenleistung
  • Identifizierung von aufwändigen SQL Abfragen anhand von CPU-Zeit und durchschnittlicher Dauer
  • Aktive Benutzerverbindungen
  • Datenprotokollierung als CSV Datei – Datenerfassungsintervall konfigurierbar
  • Nutzung des neuen Features von Microsoft Dynamics NAV 2013 / 2015 / 2016 zur Analyse der C/AL-Aufrufliste für SQL-Befehle
  • Ermittlung welche SQL-Anweisungen aus der selektierten Session des NAV-Client generiert wurden
  • Analyse kostspieligster C/AL Aufrufe in Bezug auf die SQL Performance
  • Sichtbarkeit der Metadaten aller Objekte aus der NAV 2013 / 2015 / 2016 Objekt-Metadatentabelle
  • C/AL Source Code Compare and Merge Tool
  • C/AL Compare Html Documentation
  • Dynamics NAV Object Store incl. Function “Where Used?””
  • XE Explorer für SQL Server Extended Events
  • SQL Live Monitor
  • Html SQL Server Dokumenter
  • Vergleichen von Datenbankschemas
  • Transact-SQL-Editor
  • PowerShell Editor
  • SQL System Health Reports


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 Performance Counters

Dynamics NAV Performance Counters

Dynamics NAV Performance Counters und die SQL Server integrierten Performance Counter sind starke Werkzeuge, um Fehlern in der Systemkonfiguration und Flaschenhälsen auf die Schliche zu kommen.

 

Wir möchen Ihnen die bedeutendsten dieser Leistungsmesser in der NAV Systemumgebung (Dynamics NAV Performance Counters / SQL Server Performance Counters) vorstellen.

 

Ein NAV System performant zu halten (möglichst ohne Sperren), ist die wichtigste und zugleich schwierigste Aufgabe eines Systemverantwortlichen. Besonders zeitraubend sind die Probleme, deren Ursache tief in der NAV / SQL Server Architektur liegen, oftmals nicht auf den ersten Blick ersichtlich sind. Um den Problemen auf die Schliche zu kommen, ist es sehr hilfreich, die Engpässe und Flaschenhälse des Systems zu kennen und zu lokalisieren.
Genau an diesem Punkt setzen die Dynamics NAV und SQL Server Performance Counter an. Auf den ersten Blick verliert man aufgrund der schieren Masse der verschiedenen Zähler die Übersicht. Die Dynamics NAV Leistungsindikatoren (Data Collector Set) geben Auskunft darüber, wie gut der Microsoft Dynamics NAV Server arbeitet. Durch die Verwendung der V8 NAV SQL Studio Monitoring-Tools können Sie die Daten der Leistungsindikatoren der Komponenten wie Service Tier, Speicher, physischen Datenträger und SQL Server usw. überwachen, um evtl. Optimierungen der Leistung vorzunehmen.

 

 

1. Dynamics NAV Performance Counters

 

Es gibt mehrere Gründe, warum eine Werte der Leistungsindikaturen des SQL Server in Verbindung mit der Dynamics NAV Serverinstanz hoch sein können. Vielleicht gibt es in Ihrer NAV Lösung nicht optimalen Code, der zu viele SQL-Aufrufe verursacht. Es ist auch möglich, dass Ihre Daten oder die Metadaten Cacheeinstellungen zu niedrig eingestellt sind.
Es gibt 2 Dynamics NAV Performance Counters, die dieses Problem aufzeigen:

 

#CategoryCounterBeschreibungStatus
1Data and caching% Primary key cache hit rateProzentsatz der Treffer im Primärschlüssel-Cache, im Vergleich zu den Gesamtanforderungen im Primärschlüssel-Cache.>90%
2Data and caching% Result set cache hit rateProzentsatz von Treffern der Ergebnismenge im Cache, im Vergleich zu den Gesamtanforderungen an den Ergebnismengen-Cache.>90%

Die Primärschlüssel Cache-Trefferrate sollte über 90% betragen; ansonsten könnte der Cache der Dynamics NAV Serverinstanz zu klein sein.

 

Data Cache Size (CustomSettings.config)

 

Sollten Sie feststellen, dass der “Data Cache” der Dynamics NAV Serverinstanz zu klein ist, können Sie den Wert in dieser Einstellung anpassen:

 

<add key=”DataCacheSize” value=”9″ />

 

Bei der Ausführung eines „Single Tenant“-NAV System der Defaultwert von 9 ist wahrscheinlich gut.

Hier die Werte zum Verändern des „Data Cache Size“:

ValueMemory
9 (default)512Mb
101Gb
112Gb
124Gb
138Gb
1416Gb
1532Gb

 

Metadata Provider Cache Size

 

<add key=”MetadataProviderCacheSize” value=”150″ />

 

Den “Metadata Provider Cache Size” des Microsoft Dynamics NAV-Service-Tier sollten Sie nur erhöhen, wenn Sie eine starke Last des Arbeitspeicher über die Performance Counter feststellen.

 

 

2. Windows und SQL Server Performance Counters

 

Hier ist unser Vorschlag der wichtigsten Leistungsindikatoren die Sie überprüfen sollten:

 

#CategoryCounterBeschreibungStatus
1Memory/Buffer ManagerBuffer Cache Hit RatioAngabe des Prozentsatzes der Datenseiten, die im SQL Server-Speicher vorhanden ist, ohne Zugriff auf die Fetsplatte. Ein Wert kleiner als 90% ist ein deutliches Zeichen für Speicherproblem (SQL Server-RAM erhöhen).>= 90%
2CPU/ Processor% User TimeDer Leistungsindikator “% User Time” entspricht dem Prozentsatz der Zeit, die der Prozessor mit der Ausführung von Benutzer Prozessen wie dem SQL Server verbringt.=< 70%
3DiskAvg. Disk Sec/ReadDie durchschnittliche Zeit in Millisekunden für jedes Lesen auf der Festplatte: > 20 gilt als sehr schlecht, < 20 gut, < 12 sehr gut und < 8 optimal=< 20MS
4DiskAvg. Disk Sec/WriteDie durchschnittliche Zeit in Millisekunden für jedes Schreiben auf der Festplatte: > 20 gilt als sehr schlecht, < 20 gut, < 12 sehr gut und < 8 optimal.Dieser Indikator unterscheidet sich deutlich von dem Leistungsindikator “cached writes” wo: > 4 schlecht, < 4 gut, < 2 sehr gut, < 1 optimal ist.=< 20MS
5LocksAvg. Wait Time (in ms)Die durchschnittliche Länge der Wartezeit (in Millisekunden) für jede Sperranforderung, die nicht sofort erfüllt werden konnte.Eine durchschnittliche Wartezeit länger als 500ms deutet auf ein übermäßige blockieren hin.=< 500MS
6MemoryAvailable BytesNiedrige Werte für den “Available Bytes”-Leistungsindikator können ein Anzeichen sein, dass insgesamt zu wenig Arbeitsspeicher auf dem Computer vorhanden ist oder dass eine Anwendung wie Dynamics NAV keinen Arbeitsspeicher freigibt.>20MB
7MemoryPages/secEin hoher Wert für den “Pages/sec” Leistungsindikator kann auf eine überhöhte Auslagerungen hindeuten.< 50
8NetworkOutput Queue LengthDer Leistungsindikator Output Queue Length gibt die Länge der Ausgabepakete-Warteschlange in Paketen an.< 2
9SQL Server: Buffer ManagerOutput Queue LengthEin Wert von über 90 Prozent gibt an, dass mehr als 90 Prozent aller Datenanforderungen vom Datencache erfüllt wurden. Fügen Sie so lange Arbeitsspeicher hinzu, bis der Wert konstant über 90 Prozent liegt.>90
10SQL Server Access MethodsPage Splits/secAnzahl der Seitenteilungen pro Sekunde, die das Ergebnis eines Überlaufs von Indexseiten sind.1. Defragmentierung der SQL Server Indizes2. Überprüfen der Dynamics NAV C/AL-Keys0

 

 

Fazit:

Performance ist mit die wichtigste nichtfunktionale Anforderung, die an Dynamics NAV gestellt wird, besonders mit dem SQL Server. 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.

 

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

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