SQL-Server-Abfrageoptimierung für Dynamics ERP

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

Dynamics 365 Business Central Wave 2

Dynamics 365 Business Central 2020 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 2020 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 2020 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 2020 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 2020 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 2020 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 lausigen 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

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

Performance Probleme in Dynamics NAV

Performance Probleme in Dynamics NAV

 

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

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

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

Ich fände es gut!

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

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


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


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





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


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


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

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

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


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

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


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


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

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

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

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


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


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



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

Es ist zu komplex!

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

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

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


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

 

Olav Treffurt