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