Schlagwort: Dynamics Business Central

Business Central Performance Tool

Posted on | by InfoMaster

Business Central Performance Tool. Mit dem Business Central Performance Tool V8 Search XE können Sie die Leistung, Analysieren und die Performance Ihrer Dynamics Business Central oder NAV Lösung steigern.

Ein typisches Problem in der Dynamics Welt…

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

Sollten Sie eine Dynamics Business Central Version 18 oder höher benutzen empfehlen wir Ihnen diesen Artikel Business Central Tabellensperren live sehen

 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 Dynamics NAV 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 bietet zwei Möglichkeiten Ereignisdaten aus Business Central / NAV zu sammeln.

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 das Business Central Performance Tool 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 /Business Central 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

SQL-Server-Abfrageoptimierung für Dynamics ERP

Posted on | by InfoMaster

SQL-Server-Abfrageoptimierung für Dynamics ERP

SQL-Server-Abfrageoptimierung für Dynamics ERP

1. Warum sollte man eine SQL-Server-Abfrageoptimierung für Dynamics ERP Systeme wie Business Central oder NAV durchführen?

In den letzten Jahren hat man unglaubliche Verbesserungen in vielen Bereichen der Datenbank Server gesehen:

  • Datenbankoptimierer verbessern sich ständig und finden Wege, um Abfragen anpassungsfähiger zu machen und Bereiche mit schlechter Optimierung zu überwinden.
  • Die Speichergeschwindigkeit hat sich aufgrund der Fortschritte sowohl bei der Speichertechnologie als auch bei der Netzwerkbandbreite massiv erhöht, CPUs sind viel schneller geworden und die Preise für Speicher sind dramatisch gesunken.

Dennoch gibt es immer noch Fachleute (wie uns), die ihren Lebensunterhalt mit der Abstimmung von Abfragen verdienen und andere darin schulen, Abfragen zu optimieren. Dieser Prozess beinhaltet das Auffinden bestimmter langsamer Abfragen (Long Durations), die für die Leistung von Dynamics Business Central oder NAV entscheidend sind. Diese „langsamen SQL-Abfragen“ können durch das Vornehmen strategischer Änderungen, sei es im Code, der Datenbankstruktur, der NAV Server Instanz Konfiguration oder etwas anderem entstehen. Optimierungen sind oft notwendig, um sicherzustellen, dass diese spezifischen SQL-Abfragen konsistent mit einer bestimmten Geschwindigkeit ausgeführt werden oder einem geforderten Leistungsstandard entsprechen.
Aber warum also SQL-Server-Abfrageoptimierung trotz der ganzen Verbesserungen?

Ganz einfach:

  • Auch die Datenmengen nehmen dramatisch zu
  • Auch die Erwartungen der Kunden/Benutzer an Leistung/Geschwindigkeit von Anwendungen wie Dynamics Business Central sind gestiegen
  • Kunden/Benutzer erwarten, dass sie jetzt nicht auf Ergebnisse warten müssen – sie möchten sofort den aktuellen Status sehen

2. Wer sollte die SQL-Abfrageoptimierung durchführen?

Die SQL-Abfrageoptimierung erfolgt durch:

  • Datenbankadministratoren
  • C/AL oder AL Entwickler, die sich auf Performance oder speziell auf Datenbanken spezialisiert haben

Full-Stack-Entwickler für AL und C/AL führen im Allgemeinen keine Abfrageoptimierung durch, es sei denn, sie haben ein bestimmtes Interesse oder Berufserfahrung. Dies ist eher eine Spezialisierung als eine „schnelle Lernaufgabe“, daher haben die meisten Full-Stack-Entwickler einfach keine Zeit und müssen eine spezialisiertere Person beauftragen, die ihnen hilft. Teams, die keinen leicht verfügbaren Spezialisten haben, können in regelmäßigen Abständen Berater wie uns das DynamicsProject Team hinzuziehen, die dabei helfen.

Es gibt auch viele Datenbankadministratoren, die SQL-Datenbanken verwalten, bei denen nur „grundlegende“ Verfügbarkeit und Leistung erforderlich sind. Diese SQL-Datenbanken werden von kostenbewussten Unternehmen verwendet, die nicht jede Datenbank wie ein „Rennauto“ tunen müssen: Die meisten ihrer SQL-Datenbanken werden von internen Benutzern verwendet, die es gewohnt sind, die Dynamics ERP Leistung und Geschwindigkeit mäßig ist.

3. Welche Fähigkeiten sind bei der SQL-Abfrageoptimierung erforderlich?

Die meisten von uns sind kein Zauberer bei TSQL, aber viele DBAs sind ziemlich gut im Abfragetuning geworden (z.B. durch unsere V8 Performance Workshops).

Eine sehr unwissenschaftliche Schätzung, welche Fähigkeiten jemanden bei der Abfrageoptimierung ausmachen:

40% – die Zeit, das Interesse und die Ressourcen (einschließlich eines Netzwerks von Personen, die gefragt werden müssen), um ein umfassendes Profil von „Leistungsinformationen“ zu erstellen – dies sind Muster, die sich nicht gut optimieren lassen, Randbedingungen, bei denen die Leistung schlecht wird, Verständnis von Trace Flags und Konfiguration auf TSQL.

30% – Interesse und Fähigkeit zu erfahren, wie die Datenbank-Engine Abfragen mithilfe von Indizes und anderen Ressourcen optimiert und verarbeitet und was sich auf die Parallelität auswirkt, wenn mehrere Abfragen gleichzeitig gegen eine Live-Datenbank ausgeführt werden

10% – Verständnis der TSQL-Sprache und verschiedene Möglichkeiten zum Umschreiben einer Abfrage in Verbindung mit der AL oder C/AL Programmierung von Dynamics, um eine bestimmte Ergebnismenge zu erzeugen. Diese Funktioniert aller Dings oft nur mit Datenbank-DevOps.

Was ist Datenbank-DevOps?
Beginnen wir mit der Definition von DevOps. DevOps ist eine Reihe von Praktiken, die Softwareentwicklung (dev!) und IT-Betrieb (ops!) mit dem Ziel kombinieren, mehr Funktionen, Fixes und Updates schneller bereitzustellen, in Übereinstimmung mit den Geschäftszielen. Database DevOps wendet dieselben Prinzipien an und stellt sicher, dass der AL oder C/AL Datenbankcode im selben Prozess wie der Entwicklungscode enthalten ist.

Database DevOps hilft Teams, den Anwendungsentwicklungs- und -freigabeprozess weiter zu identifizieren und zu rationalisieren, indem ein bekannter Engpass behoben wird: Änderungen des AL oder C/AL Dynamics Source Codes.

4. SQL-Abfrageoptimierungstools und ihre Zusammenarbeit
4.1 Ausführungspläne

Wie die SQL-Abfrage aus Dynamics Business Central hinter den Kulissen ausgeführt wird.

  • „Geschätzte“ Ausführungspläne zeigen die Entscheidungen, die der Optimierer zum Ausführen der Abfrage getroffen hat, einschließlich der geschätzten Anzahl von Zeilen, die durch die verschiedenen Teile des Plans fließen werden
  • „Tatsächliche“ Ausführungspläne sind geschätzte Pläne, die mit Laufzeitstatistiken aktualisiert werden, z. B. wie viele Zeilen den Plan durchlaufen haben. Wenn der Plan „adaptiv“ ist, enthält er einige Informationen darüber, welche Optionen gewählt wurden
4.2 Abfragespeicher

SQL-Server 2016+, alle Editionen

  • Diese Funktion verfolgt Ausführungspläne und aggregierte Laufzeit Metriken (Dauer, CPU-Auslastung) zusammen mit aggregierten Wartestatistiken
  • Dies hat auch die Möglichkeit, Pläne „einzufrieren“
  • Abfragespeicherinformationen werden mit der Datenbank selbst wiederhergestellt, sodass sie bei Bedarf zwischen Umgebungen gemeinsam genutzt werden können.
4.3 Dynamische Verwaltungsansichten und Leistungsindikatoren (DMV)
  • Diese helfen, die Engpässe der gesamten Instanz während der langsamen Leistung zu verstehen
  • Beispiel: Gesamtwartestatistik für die Instanz und Metriken zur Speicherlatenz während der Zeit, in der die Abfragen schlecht ausgeführt wurden, können helfen zu erklären, ob die Abfrage wirklich optimiert werden muss
  • Bei der Abfrageoptimierung sind häufig Rückrufe für die „Workload-Optimierung“ erforderlich.
  • SQL-Ablaufverfolgung und erweiterte Ereignisablaufverfolgungen (bei erweiterten Ereignissen handelt es sich um ein Lightweight-System zur Leistungsüberwachung, um Daten zu sammeln und bilden die Grundlage von V8 Search XE)
  • Der „Alte“ SQL Profiler ist für die Abfrageoptimierung im „live“ Betrieb schwierig zu verwenden, da sie Ihre Arbeitslast leicht verlangsamen und Leistungsprobleme beim Tracing verursachen.
  • Ausführungspläne (Filtern hilft in diesem Fall nicht, die Pläne werden alle untersucht / gesammelt und der Filter wird zu spät angewendet)
  • Wartestatistiken (Filtern kann hier helfen, aber die gesammelten Daten sind so massiv, dass man sehr vorsichtig sein muss – und auch das Sortieren und Abfragen der gesammelten Daten ist recht umständlich
  • „Business Central Server Trace Events“ Es gibt zwei Ereignis-Trace-Anbieter, die verschiedene Trace-Ereignisse im Ereignisprotokoll veröffentlichen: Microsoft-DynamicsNAV-Server und Microsoft-DynamicsNAV-Common. Der Microsoft-DynamicsNAV-Common-Anbieter ist ausschließlich für Telemetrie-Trace-Ereignisse vorgesehen. Alle anderen Ereignisse verwenden Microsoft-Dynamics NAV-Server. In der Regel müssen Sie den Ereignis-Trace-Anbieter in dem von Ihnen verwendeten Überwachungstool (z.B. V8 Search XE) angeben.
  • „SQL-Trace-Ereignisse“ verfolgen einen bestimmten Satz von SQL-Anweisungen, die von der Business Central Server-Instanz gegen die Business Central-Datenbank auf SQL-Server ausgeführt werden.

5. Schwierige Probleme – Streit um Ressourcen

Es ist schwer vorherzusagen, wie SQL-Abfragen in einem Live-Workload miteinander interagieren

Gemeinsam genutzte Ressourcen:
  • Arbeitsspeicher für Abfragen – eine bestimmte Menge an Arbeitsspeicher muss für Sortierungen/Verknüpfungen/Verschieben von Daten in einer Abfrage zugewiesen werden. Viele gleichzeitig ausgeführte Abfragen, die viel Arbeitsspeicher benötigen, können dabei zu Problemen führen. (Manchmal gehen die Abfragen davon aus, dass sie viel mehr von diesem Speicher benötigen, als sie benötigen, und er muss optimiert werden – dies wird den Benutzern außerhalb eines Live-Workloads wahrscheinlich nicht bewusst sein)
  • Die Anzahl der Abfragen, die Änderungen vornehmen, und der Ansatz zum Sperren sind außerhalb einer Live-Workload schwer vorherzusagen (Änderungen in Abfrageplänen können zu Blockierungen führen, wenn sie vorher nicht vorhanden waren)
Änderungen der Serverressourcen – sogar Verbesserungen – können zu Blockierungen führen, wenn sie vorher nicht vorhanden waren
  • Beispiel: Der Wechsel zu einem neuen Server mit mehr Arbeitsspeicher und schnelleren CPUs führte zu einer Zunahme der Wartezeiten für Sperren, da die Wartezeiten im Speicher verringert und die Ausführung von Abfragen beschleunigt wurde.

6. Ist eine Prüfung in der „Live“ SQL-Datenbank erforderlich?

Ja. Ein Beispiel dafür ist Parallelität.

Das Optimieren des Parallelitätsgrads für eine Workload und für bestimmte Abfragen in dieser Workload ist in der Regel ziemlich hardwarespezifisch, und Sie benötigen eine Live-Umgebung.

Workload- „Replays“ sind im Toolkit von SQL-Servern verfügbar, aber sie sind:

  • Nur Wiederholungen – Sie können die Aktivität nicht sinnvoll „verstärken“ (das 10-malige Löschen derselben Zeilen ist nicht dasselbe wie das 10-malige Löschen verschiedener Zeilen)
  • Zeitaufwändig einzurichten

7. Automatisierte SQL-Server-Abfrageoptimierung: Verlauf und Entwicklung
7.1 Automatisierte Plankorrektur

SQL-Server 2017+, Enterprise Edition

  • Aufgebaut auf dem Abfragespeicher
  • Erkennt SQL Abfragen, die manchmal schnell und manchmal langsam sind
  • Kann Änderungen nur empfehlen, wenn gewünscht und eingerichtet
  • Kann Pläne einfrieren, testen, ob es hilft und entsprechend reagieren (Das Einfrieren ist als vorübergehende Lösung gedacht – es wird empfohlen, dass ein Benutzer die Abfrage zur Optimierung als längerfristige Lösung auswertet)
  • Sehr gute Funktion zur Identifizierung von Parameter-Sniffing
7.2 Intelligente Abfrageverarbeitung
  • „Intelligente Abfrageverarbeitung“ (Intelligent Query Processing, IQP) wurden in den letzten Versionen von SQL-Server veröffentlicht
  • Mehrere dieser Features beheben häufige Probleme bei der Abfrageoptimierung in SQL-Server
  • Mehr Informationen: Intelligente Abfrageverarbeitung in SQL-Datenbanken

8. Häufige Fehler und Fallstricke bei der SQL-Server-Abfrageoptimierung
  • Fehlende Verbindung zwischen DBAs und Dynamics Entwicklungsteams
  • Mangelnde Kenntnis der Ausführungspläne im Team
  • Mangelndes Verständnis von SQL-Server-Isolationsstufen und „optimistischen“ Optionen
  • Mangelnde Kenntnis wie von Dynamics AL oder C/AL Programmierung auf dem SQL Server umgesetzt wird

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