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

Identifizieren von Tabellensperren in Dynamics NAV / Business Central

Identifizieren von Tabellensperren in Dynamics NAV


Das Identifizieren von Tabellensperren in Dynamics NAV hat sich seit Dynamics NAV 2013 gegenüber dem Navision Classic Client komplett geändert. Die Art und Weise, wie die Dynamics NAV Benutzer sich mit der SQL-Datenbank verbinden wurde durch den RTC Client neu strukturiert. Benutzer stellen eine Verbindung zu dem NAV-Service-Tier aus dem Windows-Client, Web-Client, Sharepoint-Client oder Web-Services her. Die neue sogenannte „Dreischicht-Architektur“ trennt Datenbank-, Server- und Client-Ebene voneinander.
Das Benutzerkonto, mit dem das NAV-Service-Tier ausgeführt wird, ist das Einzige, dass tatsächlich eine Verbindung zur SQL-Datenbank herstellt. Es gibt viele gute Gründe dafür:

  • Der Dynamics NAV Server verwendet eine ADO.NET-Schnittstelle, die eine Datenzugriffsschicht ist, die das SQL Server Connection-Pooling unterstützt. Dies vereinfacht die Bereitstellung der Microsoft Dynamics NAV-Drei-Schichten-Architektur für Einsätze, wo die drei Ebenen auf unterschiedlichen Computern installiert sind. Es wird das Windows Communication Framework (WCF) als Kommunikationsprotokoll verwendet.
  • Es verbessert die Sicherheit, da in der SQL Datenbank kein SQL Benutzer mit Anmeldename für jeden der benötigten NAV Anwender erstellt werden muss. Das Ergebnis, die Sicherheit ist einfacher, da somit keine Notwendigkeit für ein verbessertes Sicherheitsmodell zu früheren Versionen benötigt wird (Client-Server-Verbindung).

Tolle Dinge! Ein Nebeneffekt ist jedoch, dass es schwierig ist zu sehen, welche SQL Server Verbindung (SPID) einer NAV-Sitzung zu geordnet ist. Das ist ein Problem, wenn man versucht, einen Windowsbenutzer zu einer Tabellensperrung / Blockierungsproblem zu ermitteln.
In den Tagen des klassischen Clients, wo man die aktiven Datenbanksitzungen sehen konnte und Sperrinformation zusammen mit der Möglichkeit Sitzungen gegebenenfalls zu beenden, sind durch die neue Architektur leider Geschichte.

Da uns immer wieder Kunden auf das Problem des Identifizieren von Tabellensperren in Dynamics NAV ansprechen und ob wir nicht ein Tool oder eine Lösung für dieses Problem hätten, haben wir eine Lösung entwickelt. Unser erster Lösungsansatz war unser V8 NAV SQL Studio. Allerdings war die Architektur der Software bei der Installation von Dynamics NAV Service Tiere auf unterschiedlichen Computern, suboptimal.

Überwachen von Microsoft Dynamics NAV Server-Ereignissen:

Zum Bessern Verständnis möchten wir kurz einmal den Unterschied zwischen Locking, Blocking und Deadlocking für alle nicht SQL Server Spezialisten erklären. Locking (Sperren): Sperren sind ein Mechanismus, der von Microsoft   SQL Server zum Synchronisieren des gleichzeitigen Zugriffs auf die gleichen Daten durch mehrere Benutzer verwendet wird.
Bevor eine Transaktion eine Abhängigkeit für den aktuellen Status von Daten abruft, z.B. durch Lesen oder Ändern der Daten, muss sie sich selbst vor den Auswirkungen schützen, die sich ergeben können, wenn eine andere Transaktion die gleichen Daten ändert.

Blocking:

Ein BLOCKING tritt auf, wenn zwei Verbindungen gleichzeitig Zugriff auf das gleiche Datenelement benötigen und eine Verbindung blockiert wird, weil zu einem bestimmten Zeitpunkt nur eine Verbindung Zugriff haben kann.

In NAV erscheint dann diese Meldung:

Microsoft Dynamics NAV
—————————

Der Vorgang konnte nicht abgeschlossen werden, da ein Datensatz in der Tabelle ‚…‘ durch einen anderen Benutzer gesperrt wurde. Führen Sie die Aktion erneut aus.
—————————
OK
—————————

Deadlocks:

DEADLOCKS treten auf, wenn sich zwei Tasks dauerhaft gegenseitig blockieren, weil jeder der Tasks eine Sperre für eine Ressource aufrecht erhält, die von dem anderen Task benötigt wird.

Folglich kann Transaktion A nicht abgeschlossen werden, bis die Transaktion B abgeschlossen ist. Die Transaktion B ist aber durch Transaktion A blockiert.

In NAV erscheint dann diese Meldung:

Microsoft Dynamics NAV
—————————

Der Vorgang konnte nicht abgeschlossen werden, da ein Datensatz in der Tabelle ‚…‘ durch einen anderen Benutzer gesperrt wurde. Führen Sie die Aktion erneut aus.
—————————
OK
—————————

Das Sperren (Locking) ist ein integraler Bestandteil vom Microsoft SQL Server, um Parallelität und die physische Integrität jeder Transaktion sicherzustellen.
Blockierung ist schlecht, wenn eine Verbindung / Transaktion für eine lange Zeit unnötig wartet, und Deadlocking ist ein Phänomen, das niemals auftreten sollte.

V8 Search XE – Deadlocks und Blockings im Dynamics NAV Server erkennen und beheben.

Die Ereignisverfolgung im V8 Search XE liefert detaillierte Informationen über das, was auf dem Microsoft Dynamics NAV Server auftritt, wenn Benutzer mit Microsoft Dynamics NAV arbeiten und dabei Blocking oder Deadslocks entstehen. Alle Daten zu bestimmten Dynamics NAV Trace-Ereignissen werden in einer V8 SQL Server Datenbank erfasst. Dies kann Ihnen helfen, Probleme oder Zustände, die die Leistung von Dynamics NAV / SQL Server beeinträchtigen, zu identifizieren und zu analysieren.

Identifizieren von Tabellensperren in Dynamics NAV. Mit der V8 Search XE Ereignisverfolgung können Sie Microsoft Dynamics NAV Server dynamisch überwachen, ohne dass der Server oder die Microsoft Dynamics NAV-Clients neu gestartet werden müssen.

Sie können den V8 Search XE verwenden, um zum Beispiel folgenden Vorgänge auf Microsoft Dynamics NAV Server-Instanzen und dem SQL Server zu verfolgen:

  • Ausführung von SQL-Anweisungen von Microsoft Dynamics NAV Server.
  • Ausführung von NAV C/AL-Funktionen.
  • Ausführen von Microsoft Dynamics NAV-Berichten, Abfragen und XMLports.
  • Prozessnummer, Status, Sperren und Befehle (TSQL und C/AL bzw. AL), die die aktiven Benutzer ausführen.
  • Gesperrte Objekte sowie die Art der eingerichteten Sperren.
  • Vollständige Dynamics NAV SQL-Ablaufverfolgung eines sperrenden Prozess (SPID | DYNAMICS NAV USER)
  • Vollständige Dynamics NAV SQL-Ablaufverfolgung von aktiven Benutzen nach Gesamtwartezeit (SPID | WAITTIME)

Welcher Dynamics BC / NAV Windows User sperrt die Tabelle?

V8 Search XE Tutorial Video



Read more…

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

Back to Top