Business Central Performance

Business Central Performance Analyse – neue Features zur Überwachung und Optimierung.

Die neuen Möglichkeiten helfen Ihnen, die Leistung von Business Central zu verstehen und zu verbessern. Da sich die Dinge zwischen den veröffentlichten Dynamics Business Central Versionen ändern, ist es wichtig, sich über die neuen Features für die Business Central Performance-Analyse zu informieren.

Je nach Art der Dynamics BC Anwendung (Azure Dienste oder On-Premises) stehen auch hier unterschiedliche Möglichkeiten der Business Central Performance Analyse zur Verfügung.
Eine Business Central On-Premises Installation besteht normalerweise aus den folgenden Komponenten, die zur Verbesserung der Leistung optimiert werden können:

  • Client
  • Web Server
  • Server (Service-Tier)
  • SQL Database
  • SQL Server

Tools und Funktionen zur Leistungsüberwachung der Business Central Performance

Hier ist eine kleine Übersicht der Tools und Funktion bei Leistungsproblemen für sie interessant sein könnten:

  • Azure Application Insights (Business Central 2019, Wave 2 und höher)
    Azure Application Insights ist ein in Azure gehosteter Dienst, der Telemetriedaten zur Analyse und Präsentation sammelt.
    Unabhängig davon, ob Sie Business Central online oder vor Ort ausführen.
    Read more…

  • Telemetriedaten
    Business Central sendet Telemetriedaten für verschiedene Aktivitäten und Vorgänge in Umgebungen und Apps/Erweiterungen.
    (Als AL-Entwickler können Sie benutzerdefinierte Telemetrienachrichten direkt aus AL erstellen, indem Sie die Features Telemetry-Codeeinheit in der Systemanwendung oder die LogMessage-Methode verwenden.)
    Read more…

  • Performance-Toolkit (Business Central 2022, Wave 1 und höher)
    Mit dem Business Central Performance Toolkit können Sie die Leistung zwischen verschiedenen Builds Ihrer Lösung verfolgen und vergleichen.
    Wenn Sie die Umgebungstelemetrie aktiviert haben, erhalten Sie Signale zu Performance, Toolkit-Ausführungen und -Szenarien.
    Read more…

  • Business Central Server-Trace-Ereignisse (Ablaufverfolgungsereignisse)
    Es gibt zwei Ereignisablaufverfolgungsanbieter, die unterschiedliche Ablaufverfolgungsereignisse im Ereignisprotokoll veröffentlichen: Microsoft-DynamicsNAV-Server und Microsoft-DynamicsNAV-Common. Der „Microsoft-DynamicsNAV-Common“ Provider ist ausschließlich für Telemetrie-Ablaufverfolgungsereignisse vorgesehen. Alle anderen Events nutzen den „Microsoft-DynamicsNAV-Server“ Provider.
    Read more…

  • SQL Server Extended Events (Leistungsüberwachungstool)
    SQL Server Extended Events ist ein Leistungsüberwachungstool, das dabei hilft, die Aktionen der Datenbank-Engine zu sammeln und zu überwachen, um Probleme in SQL Server zu diagnostizieren.
    Erweiterte SQL Server-Ereignisse wirken sich nicht wie der Profiler auf die Leistung des SQL Servers aus und bieten außerdem zahlreiche Ereignisse, die bei der Fehlerbehebung bei der Abfrageleistung und anderen Problemen helfen. Um Deadlock-Probleme zu lösen, kann dies die erste Option sein, und unserer Meinung nach muss es auch die erste Option sein. Auch Busissnes Central nutzt die Extended Events, um Deadlock-Probleme aufzuzeichnen.
    Read more…

Wir nutzen einige Möglichkeiten in Kombination der Leistungsüberwachung mit unserem Analysetool V8 Search XE, da wir so allen Kunden bei Problemen wie Deadlocks, Tabellensperren und allgemein schlechter Performance helfen können. Bei der Business Central Ablaufverfolgungsereignis Methode zum Beispiel ist es egal, ob sie ein Dynamics NAV oder eine Business Central nutzen.

Business Central Server-Trace-Ereignisse

Für jedes „Trace Event“ gibt es mehrere Arten von Ablaufverfolgungsereignissen, darunter: Windows-Ereignisanzeige, SQL-Ablaufverfolgungen, Dienstaufrufe, AL-Funktionsaufrufe und Telemetrie.
Aktivieren sie die Ereignisprotokollierung im Windows-Anwendungsprotokoll (EnableApplicationChannelLog). Standardmäßig ist diese Funktion aktiviert.

Business Central Performance - Windows-Anwendungsprotokoll aktivieren.

Viele von ihnen denken jetzt: Wir schauen oft in das Windows-Protokoll. Aber das hilft uns nicht wirklich. Stimmt!

Wahrscheinlich sehen oft folgende Informationen im Windows-Ereignisprotokoll.

Business Central Performance Tool

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

Business Central Tabellensperren live sehen

Business Central Tabellensperren „live“ sehen – das ist seit Jahren im wieder das Thema in der Performance Optimierung von Microsoft Dynamics Business Central. Seit der Version 18 von Dynamics Business Central hat Microsoft in diesem Bereich neue Informationen über den Verursacher von Tabellensperren bereitgestellt. Diese neuen Informationen ermöglichen es Administrator und Systembetreuern, die richtigen Schritte einzuleiten, um den Kollegen der AL Programmierung im eigenen Haus oder bei den Partnern die Stelle im AL-Code zuliefern, die Probleme verursacht.

V8 Search XE (Version 4) bietet nun allen Dynamics Business Central der Version 18 oder höher die Möglichkeit Tabellensperren „live“ zusehen. Die Möglichkeit, Sperren in Tabellen zu identifizieren, ist auch für ältere Dynamics NAV / Business Central möglich. Allerdings sind die Informationen über den Verursacher der Tabellensperre abzurufen, nur über einen erweiterten Workflow in V8 Search XE möglich.

Business Central Tabellensperren „Live“ sehen – welche Informationen liefern die neuen Dynamics Business Central Versionen?

Die Datenbanksperre steuert den gleichzeitigen Zugriff mehrerer Benutzer auf dieselben Daten. Um eine Transaktion gegen andere Transaktionen zu schützen, die dieselben Daten ändern, sperrt die erste Transaktion die Daten. Die Sperre bleibt bestehen, bis die Transaktion abgeschlossen ist.

Benutzer können für den Abschluss von Transaktionen mit den gesperrten Daten gesperrt werden. Sie erhalten in der Regel eine Meldung, die den Sperrzustand anzeigt.

Was sieht der Administrator oder Systembetreuer?

Wahrscheinlich benutzen die meisten IT Abteilungen ein Monitoring Tool, um möglich Engpässe oder Bottlenecks auf dem SQL Server in Verbindung mit Business Central zu identifizieren.
So zeigt Ihnen zum Beispiel der Aktivitätsmonitor im SQL Server Management Studio so eine Tabellensperre an.

Mit diesen Informationen kann kein Programmierer für Dynamics Business Central etwas anfangen. Aber wie soll man solche Probleme lösen?

Was sieht der Administrator oder Systembetreuer mit V8 Search XE?

Sie erhalten die gleichen Informationen wie im Aktivitätsmonitor, wenn eine Tabellensperre auftritt. Sehen zum Beispiel in unserem Beispiel, das SPID 54 von SPID 55 geblockt wird. Sie die den Waitype und die Wairesource des SQL Server. Die Art der in Informationen werden ihnen von fast allen Monitoring Tools als Basisinformation zur Verfügung gestellt und viele, viele weitere Details zum SQL Server verhalten zur Transaktion.


Was Ihnen aber die SQL Server Monitoring Tools nicht liefern, sind die Informationen zur Transaktion aus der Dynamics Server. Und hier kommen die neuen Informationen der Version 18 oder höher von Dynamics Business Central zum Vorschein. Der V8 Search XE Performance Analyzer bietet die Möglichkeit, diese Informationen „live“ abzurufen!


Sie haben nun endlich die Verbindung zur Datenbanksperre auf dem SQL-Server und in Echtzeit, welches Dynamics AL Objekt das Problem verursacht hat.

Sie sehen in diesen Informationen die SPID die im SQL-Server das „Blocking“ verursacht hat. Mit diesen Informationen sollten Administratoren / Systembetreuer und die AL Programmierer gemeinsam viele Probleme der Dynamics Benutzer lösen können und somit ein Performance optimiertes Dynamics Business Central System dem Unternehmen zur Verfügung stellen.

V8 Search XE bietet eine viel Zahl von integrierten Performance Tools für SQL Server und Dynamics Business Central / NAV. Mit V8 Search XE werden sie ihr Dynamics Business Central System zur Performance höchst Leistung optimieren.

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

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

SQL Server Buffer Cache


SQL Server Buffer Cache

Was ist der SQL Server Buffer Cache und wie wirkt er sich auf die Leistung z.B. von Microsoft Dynamics ERP Systemen aus.

In SQL Servern ist der „Buffer Cache“ der Speicher, mit dem Anwendungen wie Dynamics 365 Business Central häufig aufgerufene Daten schnell abfragen kann. Wenn Daten in eine SQL Server-Datenbank geschrieben oder aus dieser gelesen werden, kopiert der Buffer Manager sie in den „Buffer Cache“ (auch als Pufferpool – Pufferspeicher eines Datenbankmanagementsystems bezeichnet). Wenn Pufferpool voll ist, werden ältere oder weniger häufig verwendete Datenseiten („Data Pages“) auf die Festplatte verschoben.

Warum sollten Sie den Buffer Cache überwachen?

Die Speichernutzung kann einen erheblichen Einfluss auf die Leistung haben. Wenn nicht genügend Speicher vorhanden ist, werden Datenseiten häufig aus dem Puffercache gelöscht. Dies verlangsamt Abfragen, da SQL Server auf die Festplatte gehen muss, um die Datenseite zu finden. Danach muss der Server die Datenseite im Puffercache wiederherstellen und dann die Seite lesen, bevor das Abfrageergebniss zurückgegeben werden kann.

Es gibt viele Gründe, warum Abfragen langsam ausgeführt werden. Wenn Sie jedoch Speicherprobleme ausschließen möchten, schauen Sie sich an, was im Puffercache vor sich geht. Ein Blick hinein zeigt, welche Datenbank, Tabelle oder welcher Index den Speicher belastet und Druck auf den Puffer ausübt.

Verwenden Sie die folgende SQL Abfrage, um festzustellen, welche Datenbank den meisten Speicher belegt (bei einem Dynamics 365 Business Central System sollte dies immer die „Live“ Datenbank sein):

SELECT CASE database_id
		WHEN 32767
			THEN 'ResourceDb'
		ELSE db_name(database_id)
		END AS database_name
	,COUNT(1) / 128 AS megabytes_in_cache
FROM sys.dm_os_buffer_descriptors
GROUP BY DB_NAME(database_id)
	,database_id
ORDER BY megabytes_in_cache DESC;

Führen Sie diese Abfrage in der Datenbank aus, die Sie untersuchen möchten, um die Tabelle oder den Index zu identifizieren, die bzw. der den meisten Speicher belegt.

USE [your database]

SELECT COUNT(1) / 128 AS megabytes_in_cache
	,name
	,index_id
FROM sys.dm_os_buffer_descriptors AS bd
INNER JOIN (
	SELECT object_name(object_id) AS name
		,index_id
		,allocation_unit_id
	FROM sys.allocation_units AS au
	INNER JOIN sys.partitions AS p ON au.container_id = p.hobt_id
		AND (
			au.type = 1
			OR au.type = 3
			)
	
	UNION ALL
	
	SELECT object_name(object_id) AS name
		,index_id
		,allocation_unit_id
	FROM sys.allocation_units AS au
	INNER JOIN sys.partitions AS p ON au.container_id = p.partition_id
		AND au.type = 2
	) AS obj ON bd.allocation_unit_id = obj.allocation_unit_id
WHERE database_id = DB_ID()
GROUP BY name
	,index_id
ORDER BY megabytes_in_cache DESC;

Verwalten Sie den Speicher mit Metriken

Obwohl es hilfreich ist, Datenbanken und Indizes auf Überbeanspruchung des Speichers zu überprüfen, ist die Verfolgung von Puffer-Cache-Metriken der beste Weg, um Leistungsprobleme zu identifizieren und zu beheben.

Hier sind die fünf wichtigsten zu überwachenden Metriken, um speicherbezogene Leistungsprobleme (SQL Server Buffer Cache) zu verbessern:

1. Buffer Cache Hit Ratio (Puffer-Cache-Trefferquote)


  • Diese Metrik zeigt, wie SQL Server den Puffercache verwendet
  • Die Trefferquote gibt den Prozentsatz der Seitenanforderungen an, die von Datenseiten aus dem Puffercache ausgeführt wurden, im Vergleich zu allen Datenseitenanforderungen
  • Seiten, die nicht im Puffercache gefunden werden, werden von der Festplatte gelesen, was viel langsamer ist
  • Das ideale Puffer-Cache-Verhältnis beträgt 100 (d.h. der SQL Server liest alle Seiten aus dem Puffer-Cache und keine von der Festplatte)
  • Der empfohlene Puffer-Cache-Wert ist größer als 90

2. Page Life Expectancy (PLE – Lebenserwartung der Seite)


  • Die Seitenlebenserwartung misst, wie lange (in Sekunden) eine Datenseite im Puffercache verbleibt
  • Je länger die PLE ist, desto besser ist die Chance, dass SQL Server die Seiten aus dem Puffercache liest und nicht auf die Festplatte gehen muss
  • Wenn nicht genügend Speicher vorhanden ist, werden Datenseiten häufiger aus dem Puffercache gelöscht, um Speicherplatz für neue Seiten freizugeben
  • In der Vergangenheit betrug ein „normaler“ PLE-Wert 300 Sekunden, wenn Systeme viel weniger Speicher hatten als Heutzutage
  • Für neuere SQL Server wird folgende Formel verwendet, um „gute“ PLE zu bestimmen: Seitenlebensdauer = 300 Sekunden für jeweils 4 GB RAM auf Ihrem Server
  • Die PLE sollte stabil bleiben, wenn er über die Zeit überwacht wird
  • Schnelle, häufige Abnahmen weisen auf Speicherprobleme hin
  • Ein Abfall von mehr als 50% sollte sofort untersucht werden

3. Page reads / Sec. (Serverebene)


  • Diese Metrik zeigt an, wie viele physische Lesevorgänge (d.h. Lesevorgänge von der Festplatte) in einer Sekunde in allen Datenbanken einer Instanz aufgetreten sind
  • Physische Lesevorgänge sind teuer und langsam
  • Verringern Sie physische Lesevorgänge, indem Sie einen größeren Datencache, intelligente Indizes und effizientere Abfragen verwenden oder das Datenbankdesign ändern
  • Der empfohlene Wert liegt unter 90
  • Ein Wert über 90 weist auf unzureichende Speicher- und Indizierungsprobleme hin

4. Page Writes/Sec


  • Diese Metrik gibt an, wie oft Seiten in einer Sekunde auf Serverebene auf die Festplatte geschrieben wurden
  • Der empfohlene Wert liegt unter 90

5. Pages Input/Sec and Pages Output/Sec (Memory Counters)


  • Seiteneingabe / Sek. Ist die Anzahl der Seiten, die pro Sekunde von der Festplatte eingelegt werden
  • Die Seitenausgabe / Sek. Ist die Anzahl der Seiten, die pro Sekunde auf die Festplatte geschrieben werden, um Platz im Puffercache zu schaffen
  • Seiten / Sek. Ist die Summe aus Seiteneingabe / Sek. Und Seitenausgabe / Sek
  • Wenn der Wert für Seiten / Sek. durchweg mehr als 50 beträgt, sind zusätzliche Untersuchungen erforderlich

In V8 Search XE finden die eine Abfrage zur Messung des SQL Server Buffer Cache unter:

V8 Search SQL Server Buffer Cache Navi

V8 Search SQL Server Buffer Cache

Ein fehlerfreier SQL Server Buffer Cache ist eine wichtige Komponente bei der Optimierung der SQL Server-Abfragegeschwindigkeit. Obwohl Speicherprobleme nur einer von mehreren Faktoren sind, die die Abfrageantworten verlangsamen können, sind sie relativ einfach zu identifizieren und zu beheben.
Das Verfolgen dieser fünf Schlüsselmetriken kann Ihnen dabei helfen, Datenseiten länger im Pufferpool zu halten, sodass SQL Server keine Zeit mit der Suche auf der Festplatte verschwenden muss, bevor Abfrageergebnisse zurückgegeben werden.

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

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