Schlagwort: Microsoft SQL Server

Kleine Artikel mit Tipps und Tricks für Microsoft SQL Server.

SQL-Server-Abfrageoptimierung für Dynamics ERP

Posted on | by InfoMaster

SQL-Server-Abfrageoptimierung für Dynamics ERP

SQL-Server-Abfrageoptimierung für Dynamics ERP

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

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

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

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

Ganz einfach:

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

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

Die SQL-Abfrageoptimierung erfolgt durch:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SQL-Server 2016+, alle Editionen

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

5. Schwierige Probleme – Streit um Ressourcen

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

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

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

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

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

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

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

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

SQL-Server 2017+, Enterprise Edition

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

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

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

SQL Server Buffer Cache

Posted on | by InfoMaster

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

Dynamics 365 BC SQL Server-Leistung

Posted on | by InfoMaster

Dynamics 365 BC SQL Server-Leistung

Dynamics 365 BC SQL Server-Leistung – worauf sollten Sie bei einem Überwachungstool achten? Was ist erforderlich?

Ein Überwachungstool / Analyse-Tool wie z.B. V8 Search XE muss Ihnen ein Verständnis der häufig komplexen Leistungsmuster vermitteln, die SQL Datenbanken unter Last aufweisen. Damit Sie vorhersagen können, wie Sie mit der Erweiterung bzw. Vergrößerung der Datenbank umgehen werden. Es muss uns auch helfen, die Symptome von Stress zu erkennen und zu handeln, bevor sie zu Problemen werden. Das Tool sollte aufzeigen, was in Ihrer Datenbank passiert ist, als ein zeitweise auftretendes Problem auftrat und die Dynamics 365 BC SQL Server-Leistung spürbar beeinflusste.

Es gibt drei gute Gründe, die Leistung einer Datenbank zu überwachen und zu optimieren:

  • Chronische Leistungsprobleme: Wenn eine Datenbank langsam und konsistent reagiert, wird oft davon ausgegangen, dass Ihr System mehr Ressourcen oder eine andere Technologie benötigen. Der Kauf von „mehr Metall“ oder die Erhöhung Ihrer Cloud-Ressourcen ist teuer, wenn die vollen Kosten berücksichtigt werden. Ebenso steigen die Kosten einer neuen Technologie schnell an, sobald Lizenzen und die Schulung der Mitarbeiter berücksichtigt werden. Solche Investitionen mögen als logische Lösung erscheinen, aber ohne die Ursache für das langsame Verhalten von Dynamics 365 BC/ NAV untersuchen zu können, sind sie sinnlos. Sie müssen wissen, warum Ihre Dynamics Lösung langsam läuft und was das Problem verursacht, bevor Sie davon ausgehen können, dass ein Upgrade die Antwort ist. Das Beheben einiger unerwünschter Abfragen kann zu einer überraschend schnellen Verjüngung einer müden Datenbank führen und diese unnötigen Kosten und Verzögerungen vermeiden.

  • Zeitweise auftretende Leistungsprobleme: Wenn eine Dynamics 365 Business Central SQL Server Datenbank ein zeitweiliges Problem aufweist, ist es einfacher zu lösen, wenn Ihnen Daten zur Verfügung stehen, wann und unter welchen Umständen dies geschieht. Wenn Sie eine historische Aufzeichnung der zuverlässigsten Leistungsindikatoren oder Metriken haben, können Sie die Aktivitäten über verschiedene Zeiträume hinweg vergleichen, und es ist dann viel einfacher, das Problem schneller zu finden und zu beheben.

  • Akute Leistungsprobleme: Wenn Sie die Leistung Ihrer Dynamics SQL Datenbank nicht überwachen, verlassen Sie sich tatsächlich darauf, dass sich Ihre Benutzer beschweren, wenn die Datenbank zu langsam ist, um ihre Arbeit zu erledigen. Dies ist keine gute Idee, da nur wenige Unternehmen etwas tolerieren, das Ihr Geschäft behindert.

Mit der Verantwortung Dynamics 365 BC/NAV Server ist es möglich, SQL Server-eigenen Tools zu verwenden, um die Diagnosedaten zu erfassen, die Sie benötigen, um besorgniserregende Änderungen oder Trends zu erkennen. Sofern die Person, die für die erste Beantwortung von Leistungsproblemen verantwortlich ist, nicht weiß, wo sie nachforschen muss, ist die in SQL Server verfügbare Informationsmenge kaum mehr als eine Ablenkung. Die Schwierigkeit besteht häufig darin, die für Ihre Systemlandschaft notwendigen Informationen aus den zahlreichen Server-Metriken zu finden, die auf Ressourcenkonflikte, Fehlerbedingungen und Engpässe auf dem SQL Server hinweisen können.

Infolgedessen sollten Sie ein Überwachungstool einsetzen, dass Sie darauf hinweist, dass mit der SQL Server-Datenbanken etwas nicht richtig ist und gerade genug Informationen mit der Warnung bereitstellt. Sobald die Art des Problems hinreichend verstanden ist, können Sie bei Bedarf verschiedene zusätzliche Leistungsmetriken verwenden, die im SQL Server und den Dynamics NAV Servern verfügbar sind.

Anzeichen für mögliche Leistungsprobleme

Es gibt verschiedene Trends, die Sie vor Leistungsproblemen warnen. Zu den wichtigeren gehören:

  • Die aktuelle Leistung ist ungewöhnlich langsam.
  • Der Server steht unter hohem Prozessordruck.
  • Es gibt mehr Vorfälle als üblich mit Blockierungen, Deadlocks und lang laufenden Abfragen
  • Es gibt eine zunehmende Anzahl von Wartezeiten bestimmter Arten
  • Die Leistung verschlechtert sich erheblich, als man mit zunehmender Datenbankgröße erwarten würde
  • Der Speicherbedarf und der für die Protokollierung erforderliche Speicherplatz nehmen rapide zu

Diagnosedaten sammeln

Sowohl Windows Server, Dynamics NAV Server als auch SQL Server verfügen über integrierte Leistungstools, und wir haben mit V8 Search XE ein Tool, um Probleme mit der Leistung zu beheben. Einige dieser Tools bieten allgemeine Metriken, während andere sehr spezifische Bedingungen überprüfen sollen, die eine Theorie darüber bestätigen können, was ein Problem verursacht. Ist die Ursache für eine lang laufende Abfrage (Long Duration) beispielsweise ein fehlender Index, eine schlechte Abfragelogik wie ein „Non-SARGable-Abfrage-Filter“? Sie können erweiterte Ereignisse (XEvents), Perfmon, DMVs (Dynamic Management Views) und Traces verwenden, um diese Daten bereitzustellen.

Wenn Leistungsprobleme bestehen bleiben, nachdem die Datenbankadministratoren auf das Problem aufmerksam gemacht wurden, können Sie mit V8 Search XE wahrscheinlich die Hauptursache finden. Wenn das Problem jedoch vorübergehend und zeitweise auftritt, kann es sehr schwierig werden, da die von Ihnen benötigten Details verschwunden sind. Bis das Problem gemeldet wird, ist es zu spät und sie müssen warten, bis es erneut Auftritt.

Datenbankadministratoren benötigen ein Tool wie V8 Search XE, das die erforderlichen Diagnosedaten kontinuierlich in regelmäßigen Abständen sammelt, damit sie Probleme schnell beheben können, unabhängig davon, wann sie auftreten. Ein effektives Überwachungssystem muss auf jedem SQL Server funktionieren, um alle Punkte in der gesamten Serverlandschaft zu verbinden.

Anforderungen an die Leistungsüberwachung

Es gibt eine Reihe von Möglichkeiten, wie Sie mit Ihrem Überwachungstool Leistungsprobleme anhand der gesammelten Diagnosedaten identifizieren und diagnostizieren können. Hier können Sie nur einige der offensichtlicheren Möglichkeiten behandeln.

Verbinden Sie Server-Stressbedingungen schnell mit ihrer Ursache

Angenommen, Dynamics Benutzer melden eine langsame Datenbankleistung, und Ihr Überwachungstool zeigt an, dass die CPU-Auslastung „hoch“ ist. Bedeutet dies, dass „Prozessordruck“ das Leistungsproblem verursacht? Es hängt davon ab, ob! Wenn der Server ausgelastet ist, sollten Ihre Prozessoren hart arbeiten, um alle Anfragen der Benutzer zu verarbeiten! Ein gutes Überwachungstool hilft Ihnen dabei, diese eine Metrik schnell mit anderen zu korrelieren, die den CPU-Druck bestätigen (oder ausschließen) und mit den spezifischen Abfragen, die zum Zeitpunkt des Problems ausgeführt werden.

Ist die CPU nur deshalb ausgelastet, weil der Server ausgelastet ist? Ist die Anzahl der Verbindungen oder die Anzahl der Benutzeranforderungen pro Sekunde höher als normal? Sie können nur sicher wissen, ob Ihr Überwachungstool für jede dieser Metriken eine Basislinie hat. Mit anderen Worten, wenn Sie damit schnell aktuelle Werte mit Werten für dieselben Metriken gestern zur gleichen Zeit oder zur gleichen Zeit in den letzten Tagen oder Wochen vergleichen können.

Geht die CPU-Erhöhung mit einer signifikanten Verlängerung der Zeit einher, die Benutzerprozesse nur damit verbringen, auf die CPU zu warten? Diese häufigen Signalwartezeiten können zusammen mit einer hohen CPU-Auslastung auf einen CPU-Druck hinweisen. Auch hier benötigen Sie eine Basislinie für Signalwartezeiten, um dies festzustellen, und Ihr Überwachungstool sollte es sehr einfach machen, bei Bedarf eine Metrik zum Sammeln dieser Daten hinzuzufügen.

Ihre Leistungsmetrik-Baselines zeigen möglicherweise, dass der CPU-Druck in der letzten Woche eines jeden Monats normal ist. An diesem Punkt der Leistungsuntersuchung möchten Sie den Server-Stresszustand, ob hohe CPU-, Speicher- oder I/O-Auslastung (oder alle drei), direkt mit lang laufenden Abfragen in diesem Zeitraum verbinden. Eine übermäßige CPU-Auslastung wird häufig durch lang andauernde, komplexe Abfragen verursacht, die einfach viel Rechenleistung erfordern. Schlecht abgestimmte T-SQL-Anweisungen und schlecht gestaltete Indizes können zu einer hohen Belastung aller Ressourcen führen.

Gibt es Möglichkeiten, den Druck durch die Optimierung dieser Abfragen oder der Datenbankindizes zu verringern? Wenn nicht, können Sie Schritte unternehmen, um die CPU-Zuordnung für diesen Zeitraum zu optimieren. Wenn es sich beispielsweise um Cloud-basierte Server handelt, können Sie diese elastisch erweitern, um mehr Prozessoren zu verwenden, und so die Leistung Ihrer wichtigen Berichtsabfragen optimieren?

Ohne die Tools, mit denen festgestellt werden kann, ob die Engpässe durch schlecht geschriebene Abfragen oder fehlende Indizes verursacht werden, besteht die Versuchung, die Anzahl der Kerne zu erhöhen. Mithilfe eines Überwachungstools kann häufig eine kleine Anzahl von Abfragen gefunden werden, die die meisten Engpässe verursachen. Sobald diese Abfragen identifiziert sind, müssen nur noch die Abfragen und Indizes optimiert werden.

Server-Wartezeiten analysieren

Warten Sie im Statistikbereich mit dem leistungsstarken Tool, um den größten Engpass auf Ihren SQL-Servern festzustellen. Jedes Mal, wenn eine Anforderung zum Warten gezwungen wird, zeichnet SQL Server die Länge der Wartezeit und die Ursache der Wartezeit (den Wartetyp) auf, die im Allgemeinen die Ressource angibt, auf die die Anforderung gewartet hat, die sie jedoch nicht abrufen konnte. Wartezeiten können beispielsweise mit Parallelität, I/O Langsamkeit oder Sperrung zusammenhängen. Dies wird als Gesamtaggregatwerte angegeben, die seit dem letzten Neustart des Servers erfasst wurden. DBAs überprüfen normalerweise Wartezeiten, um die Belastungen auf dem Server zu verstehen.

Auch hier bedeutet das Wissen, dass eine bestimmte Wartezeitmetrik „hoch“ ist, kein Problem für sich. Ihr Überwachungstool muss Ihnen dabei helfen, diese mit anderen Metriken zu korrelieren und diese Wartezeiten zu analysieren, um die tatsächlichen Abfragen zu finden, die von ihnen betroffen sind:

Ein gutes Überwachungstool meldet auch die häufigsten Wartezeiten über einen bestimmten Zeitraum, sodass der DBA Trends oder Ausreißer leicht erkennen kann.

Nehmen wir an, Sie beobachten hohe CXPACKET Wartezeiten. Ist das ein Problem? Diese Art des Wartens tritt immer dann auf, wenn Abfragen auf mehreren Prozessoren parallel ausgeführt werden. Eine häufige Fehldiagnose bei sehr hohen CXPACKET Wartezeiten besteht darin, dass die parallele Arbeitslast das Festplatten-I/O-Subsystem überlastet. Überprüfen Sie jedoch zunächst die von diesen Wartezeiten betroffenen Abfragen. Wenn es sich um ein OLTP-System wie Dynamics 365 BC oder NAV handelt, bei dem Transaktionen kurz und schnell sein sollten, sollten Sie die Abfragen untersuchen, für die parallele Pläne vorliegen, und nach Optimierungsmöglichkeiten suchen. In ähnlicher Weise können übermäßige I/O-Wartezeiten beispielsweise einfach ein Zeichen dafür sein, dass eine große Tabelle wiederholt gescannt wird und dass ein Index die Abfrage unterstützen kann.

Schnelle Fehlerbehebung in Echtzeit

So proaktiv ein DBA sein möchte, um Probleme zu lösen, bevor sie zu echten Problemen werden, spielt das Überwachungstool immer eine wichtige Rolle bei der Lösung von Echtzeit-Leistungsproblemen.

Wenn auf einem wichtigen Business-Server derzeit schwerwiegende Leistungsprobleme auftreten, sollten Sie sehr schnell wissen, welche Verbindungen und Sitzungen betroffen sind und welche Aktivitäten auf dem Server stattfinden. Eine Möglichkeit, wie ein professionelles Überwachungstool wirklich helfen kann, besteht darin, nicht nur übermäßiges „Blockieren“ zu erkennen oder beispielsweise zu melden, dass ein Deadlock aufgetreten ist, sondern innerhalb der Warnung auch eine Liste der aktiven Prozesse und einige einfache Visualisierungen des Blockierens bereitzustellen oder Deadlocking-Kette. Das folgende Bild zeigt eine Blockierungskette:

Das Blockieren in SQL Server ist wie eine Kreuzung im Stau. Die Abfrage im Herzen des Problems wirkt sich auf andere Abfragen aus und lässt sie warten, bis die Problemabfrage ausgeführt oder beendet wurde. Häufige Ursachen sind übermäßige I/O aufgrund von Scans für große Tabellen oder Transaktionen, die nach Fehlern offen bleiben. Um das Problem kurzfristig zu lösen, muss die fehlerhafte Abfrage gefunden und möglicherweise die Verbindung unterbrochen werden. Ein gutes Überwachungstool, wie V8 Search XE identifiziert die Ursache der Blockierung, damit geeignete Maßnahmen ergriffen werden können.

Ein Deadlock ist eine kreisförmige Verriegelungskette, da jede Verarbeitung der Blockierungskette auf einen oder mehrere andere Prozesse in derselben Blockierungskette wartet, sodass keiner abgeschlossen werden kann. Dies ist eine schwerwiegende Fehlerbedingung, die SQL Server durch Beenden und Zurücksetzen eines der Prozesse behebt. Der DBA muss sofort nachforschen, um herauszufinden, was den Deadlock verursacht hat, und Maßnahmen ergreifen, um ein erneutes Auftreten zu verhindern.

Vorher und Nachher: ​​Baselines

Eine weitere wichtige Verwendung der von uns gesammelten Überwachungsdaten ist die Erstellung visueller Basislinien. Dies hilft dem DBA zu verstehen, ob sich die Leistung in bestimmten Zeiträumen vorhersehbar verschlechtert oder ob die aktuelle Leistung des Servers typisch oder ungewöhnlich ist. Sie können auch auf Änderungen achten, wenn die Daten wachsen oder das System mit der Zeit geschäftiger wird.

Wie oft hören wir: „Dynamics NAV war gestern langsam“ oder „Es war schneller, bevor wir das Upgrade veröffentlicht haben“ oder „NAV ist gerade langsam“? Um diese Behauptungen zu validieren und die Ursache herauszufinden, benötigen wir Ressourcenverbrauchsdaten von gestern, um sie mit heute vergleichen zu können.

Vielleicht können Sie jedoch feststellen, dass die CPU-Auslastung dieser Prozessors jetzt höher ist als letzte Woche. Ist das ein beunruhigender Trend? Zur Unterstützung möglicher Optimierungsbemühungen müssen Sie feststellen, ob Sie das sehen, was als normales Verhalten beschrieben werden kann. Oder Sie sehen tatsächlich einen Trend, der zu Druck auf diese Ressource führt. Sofern Sie keine Maßnahmen ergreifen, wie Suche nach Möglichkeiten, die Last in diesen geschäftigen Zeiten besser auf die verfügbaren Prozessoren zu verteilen.

Fazit

SQL Datenbanken sind äußerst komplex, noch bevor Sie versuchen, ihr Verhalten unter Last im Produktionsbetrieb zu verstehen. Sie brauchen dieses Verständnis der Leistung, um vorhersagen zu können, wie Sie mit Expansion oder Skaleneffekt umgehen werden. Sie müssen verhindern, dass Stresssymptome zu Problemen werden, die sich auf den Service auswirken. Sie brauchen die Informationen, die es Ihnen ermöglichen, intelligente Entscheidungen über das Hosting zu treffen. Sie müssen auch verstehen, was in der Dynamics 365 BC/NAV SQL Datenbank passiert ist, als ein zeitweise auftretendes Problem auftrat.

Alle RDBMS verfügen über Diagnosetools. Sie werden jedoch am besten verwendet, nachdem die allgemeine Natur und der Kontext eines Leistungsproblems verstanden wurden. Insbesondere, wenn die Zeit knapp ist und Probleme behoben werden müssen, bevor sich die Benutzer beschweren. Mit zunehmender Arbeitsbelastung des Betriebspersonals lohnt es sich, über ein System zu verfügen, das die Dynamics 365 Business Central / NAV System im Auge behält und Warnungen ausgibt, wenn eine Kombination von Metriken einen beunruhigenden Trend zeigt.

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

Posted on | by InfoMaster

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

ASYNC_NETWORK_IO Dynamics NAV

Posted on | by InfoMaster

ASYNC_NETWORK_IO Dynamics NAV

 

Der ASYNC_NETWORK_IO Wartetyp des SQL Servers gehört zu jenen Wartetypen, die sehr oft von DBAs im Aktivitätsmonitor gesehen werden. Beunruhigend ist es, wenn hohe Werte im Monitoring auftauchen, da dieser Wartetyp mit am schwierigsten zu beheben ist. Vor allem in Verbindung mit Dynamics NAV.

Der ursprüngliche Name des „ASYNC_NETWORK_IO“ Wartetyp stammt aus der Zeit der langsamen Ethernet-Geschwindigkeiten von 10 Mbit/s und 100 Mbit/s, die bis Mitte der 2000er Jahre häufig verwendet wurden.

In den meisten Fällen beziehen sich die hohen Werte für diesen Wartetyp nicht tatsächlich auf Netzwerkprobleme (das ist sehr seltener Fall), vor allem mit den sehr schnellen Ethernet-Geschwindigkeiten von 40 Gigabit oder 100 Gigabit Geschwindigkeit.

Übermäßige ASYNC_NETWORK_IO Werte können unter zwei Szenarien auftreten:

Die Sitzung muss darauf warten, dass z. B. der Dynamics NAV RTC Client die von SQL Server empfangenen Daten verarbeitet, und dann das Signal an den SQL Server zu senden, dass der Client neue Daten für die Verarbeitung akzeptiert. Dies ist ein allgemeines Szenario, das schlechtes Anwendungsdesign widerspiegeln kann, und ist die häufigste Ursache für übermäßige „ASYNC_NETWORK_IO“ Warte-Typ-Werte.

Oder die Netzwerk-Bandbreite ist ausgereizt. Ein verstopftes Ethernet ist Verantwortlich für die langsame Datenübertragung. Dadurch wird die Effizienz der Anwendung stark beeinträchtigt.


Ein Problem mit der Client-Anwendung (z. B. Dynamics NAV RTC)


Der häufigste Grund für hohe Werte des „ASYNC_NETWORK_IO“ Wartetyp ist, dass die Anwendung die Daten, die aus SQL Server schnell genug kommen, nicht verarbeiten kann. Wenn von der Anwendung eine große Datenergebnismenge anfordert, wird eine langsame Datenverarbeitung dazu führen, dass sich der Datenspeicher füllt, wodurch verhindert wird, das SQL Server neue Daten an den Client senden kann.

„Row by Agonizing Row“ (RBAR) Verarbeitung (Dynamics NAV = „REPEAT … UNTIL NEXT …“) ist oft die Ursache für ein solches Verhalten und hohe ASYNC_NETWORK_IO Warte Typ Werte. In der RBAR-Anwendungsprogrammierung wird jeweils nur eine Zeile aus der von SQL Server gesendeten Ergebnismenge verarbeitet. In einem solchen Szenario wird die komplette Ergebnismenge, die für die Verarbeitung verfügbar ist, zwischengespeichert und dann wird SQL Server benachrichtigt, dass der Datensatz „verarbeitet“ wurde. Dies ermöglicht es SQL Server, einen neuen Datensatz zu senden, während die Anwendung die Daten aus dem zwischengespeicherten Ergebnissatz verarbeitet.


 

Was tun, wenn hohe „ASYNC_NETWORK_IO“ Warte-Typ-Werte auf dem SQL Server auftreten?


Erste Möglichkeit -> Sie sprechen mit uns.

Bei der Untersuchung der übermäßigen ASYNC_NETWORK_IO Warte-Typ-Werte sollte folgendes überprüft werden:

Stellen Sie sicher, dass für die Clientanwendung entsprechende Sichten erstellt werden, dass die Datenfilterung von der SQL Server-Instanz durchgeführt wird und dadurch eine deutlich geringere Datenmenge an die Clientanwendung gesendet wird. Überprüfen Sie, ob es die Möglichkeit gibt, den angeforderten Datensatz in einer Weise zu reduzieren, um die Datenfilterung auf dem SQL Server direkt durchzuführen.

Im Falle von Einzel- oder Ad-Hock-Abfragen ist sicherzustellen, dass eine WHERE-Klausel (NAV = SETFILTER…, SETRANGE…) überall dort hinzugefügt wird, wo es möglich ist und dass die Abfrage ordnungsgemäß optimiert ist, um den angeforderten Datensatz nur auf die erforderlichen Daten zu beschränken.

Die Verwendung einer berechneten Spalte, die mit einer benutzerdefinierten Funktion (in NAV „FlowFields“) mit einer großen Datenbank definiert ist, ist ein weiterer häufiger Grund für die hohen ASYNC_NETWORK_IO Warte-Typ-Werte aufgrund von RBAR.

Um den den Client mit einer nicht optimalen Abfrage der Datenmenge eingrenzen zu können, sollten Sie im SQL Server die DMV [sys].[dm_exec_sessions] abfragen und dort überprüfen, welcher Task „suspended“ ist und dessen wait_status „ASYNC_NETWORK_IO“ ist.

Wenn die oben beschriebenen Punkte in Koordination mit den Anwendungsentwicklern abgearbeitet sind und der SQL Server immer noch hohe ASYNC_NETWORK_IO Warte-Typ-Werte anzeigt, dann ist es Zeit, zu prüfen, ob das Netzwerk ein solches Verhalten verursacht. Es gibt verschiedene Ursachen, durch die Einschränkung des physischen Netzwerkes, Fehlfunktionen oder einfach wegen falscher Netzwerkeinrichtungen. Folgendes sollte sorgfältig überprüft werden, um das Netzwerk die verursachten ASYNC_NETWORK_IO Wartezeiten zu beheben.


Probleme mit dem Netzwerk?

Überprüfen Sie die Netzwerkbandbreite zwischen dem SQL Server und dem NAV Client. Langsame Netzwerkadapter mit Bandbreite, die nicht der geschätzten Menge an Daten entspricht, die auf der Client-Seite verarbeitet werden sollen, sind oft der Grund für hohe ASYNC_NETWORK_IO Wartezeiten. In vielen Netzwerken sind oft noch 100 Mbit/s Adapter vorhanden. Diese Adapter können oft nicht auf die Anforderungen moderner SQL Server-Datenbanken und die damit verbunde Menge der verarbeiteten Daten antworten. Sogar mit der Umstellung auf 1 Gigabit-Adapter bleiben viele System noch unter den Anforderungen aktueller SQL Serverdatenbanken. 10 Gigabit Netzwerkadaptern werden als das Minimum für die meisten Umgebungen betrachtet, während 100 Gigabit bis 400 Gigabits größen sind, auf die viele Unternehmen in naher Zukunft wechseln werden, wenn sie das nicht schon gemacht haben!

Stellen Sie sicher, dass alle Netzwerk-Komponenten zwischen der SQL Server Instanz und dem Client, z. B. Router, Switches, Kabel ordnungsgemäß konfiguriert sind, voll funktionsfähig und der benötigten Bandbreite entsprechend.

Überprüfen Sie die Batch-Anfragen(SQL Server Performance Counter „Batch Requests“) des SQL Servers. Dieser Performance Counter repräsentiert die Anzahl der SQL-Anweisungen, die pro Sekunde auf dem Server ausgeführt werden. Unserer Meinung nach ist dies eine der besten Metriken für Performanceinformation die, der SQL Server liefert. Allerdings sollte diese Metrik nicht alleine betrachtet werden. Es ist notwendig, die Metrik „Batch Requests“ mit anderen Metriken (insbesondere CPU-Auslastung) zu korrelieren, um einen Gesamteindruck der Leistung Ihres Servers zu erhalten. Server mit Batch-Requests pro Sekunde größer als 1.000 werden als „busy“ betrachtet. Der Wert könnte stark von der tatsächlichen Systemkonfiguration, dem Aktivitätsniveau und der Anzahl der verarbeiteten Transaktionen abhänge

Achten Sie auf den SQL Server Performance Counter „Batch Requests“. Überprüfen Sie die „Batch Requests“ Zählerwerte, da dies auch ein Grund für die hohe ASYNC_NETWORK_IO im Aktivitätsmonitor sein können. Das Ziel ist es, die größte Anzahl von Batch-Anfragen zu erreichen, während die Ressourcen wie CPU, Disk und Speicher niedrig sein sollten.
Öffnen Sie den Windows „Perfmon“ oder einem Third-Party Monitoring Tool (z. B. V8 NAV SQL Studio) und fügen Sie diesen Zähler hinzu. Dieser Zähler befindet sich im Leistungsmonitor unter SQLServer: SQL Statistics: Batch Requests / sec.

Überprüfen Sie die NIC-Bandbreitenauslastung.

Die Netzwerknutzung ist über folgende Formel einfach zu berechnen:

Netzwerkauslastung% = ((Gesamtbytes\Sekunde * 8) / aktuelle Bandbreite) * 100

Sollte das Monitoring regelmäßig Werte größer als 60 % aufweisen, ist eine Umstellung auf einen schnelleren Netzwerkadapter / Netzwerkbandbreite sehr ratsam, um sicherzustellen, dass bei der Datenverarbeitung genügend Bandbreite zugewiesen werden kann.

Stellen Sie sicher, dass Auto-Negotiate der Netzwerkkarte die Netzwerkbandbreite richtig erkennt.

Um die aktuelle Geschwindigkeit aller aktiven Netzwerkverbindungen zu überprüfen, verwenden Sie den folgenden CLI-Befehl:

wmic NIC where NetEnabled=true get Name, Speed

Für den Fall, dass die Auto-Negotiation für einen bestimmten Adapter nicht die richtige Netzwerk-Geschwindigkeit auswählt wurde, ist es möglich, die NIC-Geschwindigkeit in der NIS-Eigenschaften manuell einzurichten.




Wie „busy“ ist Ihr SQL Server und Ihre Dynamics NAV Server?

Sie sind noch kein Kunde? Wir unterstützen Sie.
Mit dem richtigen Dynamics Project Plan können Sie Ihre Lösung optimal einsetzen und dafür sorgen, dass Ihr System nicht nur gut funktioniert, sondern stets die bestmögliche Performance bietet.

Haben Sie Fragen zu Netzwerkkomponenten? Unser Partner Netram Memory GmbH hilft Ihnen gerne weiter.


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

 

Warum ist Dynamics NAV langsam

Posted on | by InfoMaster

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

Neuer Blog für Dynamics NAV und Microsoft SQL Server

Posted on | by InfoMaster

Neuer Blog für Dynamics NAV und Microsoft SQL Server

 

Herzlich Willkommen bei DynamicsProject.com!
Viel Vergnügen auf unserem neuen Blog.

 

Neuer Blog für Dynamics NAV und Microsoft SQL Server. Da die Themen Performance-Optimierung und C/AL Programmierung für Dynamics NAV und Microsoft SQL Server sehr abwechslungs- und facettenreich sind, bieten wir Ihnen ab heute in regelmäßigen Abständen kurze Artikel an, mit denen Sie tiefer in die Materie einsteigen können. Gleichzeitig dient der Blog dazu, Ihnen einen ersten Eindruck zu verschaffen, was Sie von dem Dynamics Project Team erwarten können.

 

Sie können uns jederzeit Fragen zu den Artikeln stellen und wir freuen uns über jede Anmerkung und Feedback!

 

Wir wünschen Ihnen und uns viel Erfolg

Ihr Team von DynamicsProject.com