BLOG

Identifizieren von Tabellensperren in Dynamics NAV

Identifizieren von Tabellensperren in Dynamics NAV

Dynamics NAV Blocking Message


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.

V8 Search XE Ereignisverfolgung

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

Dynamics 365 BC SQL Server-Leistung

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

Dynamics 365 Business Central Wave 2

Dynamics 365 Business Central 2020 Release Wave 2 ist die erste Version, die die klassische Entwicklungsumgebung (auch als C/SIDE bezeichnet) nicht enthält. Mit dem Release Wave 2 von 2020 greifen Benutzer über den Browser, die Windows 10-Desktop-App, mobile Apps auf Android und iOS oder in Outlook auf Dynamics 365 Business Central zu.

Dynamics 365 Business Central 2020 Release Wave 2

Microsoft beschleunigt seine Investitionen in Geschwindigkeits- und Produktivitätsfunktionen für das moderne Browser-Erlebnis und erreicht damit einen wichtigen Meilenstein bei der Umwandlung in ein erstklassiges Desktop-Erlebnis für neue und erfahrene Dynamics Benutzer. Die modernen Clients unterstützen jetzt so viele Produktivitätsfunktionen, dass der ältere Dynamics NAV Windows-Client für Dynamics 365 Business Central künftig nicht mehr verfügbar ist. Der ältere Dynamics NAV-Client wird in früheren Versionen entsprechend dem Support-Lebenszyklus weiterhin unterstützt.

Stärkung der unabhängigen Software-Anbieter (ISV)

Indessen bietet das Release Wave 2-Update für 2019 eine Reihe von Funktionen, die die ISV-Entwicklung (Independent Software Vendor) für neue Lösungen vereinfachen und insbesondere die Migration vom Quellcode-Anpassungsmodell von Dynamics NAV zu Dynamics 365 Business Central optimieren sollen. Darüber hinaus wird sich Microsoft darauf konzentrieren, den Weg für unabhängige Software-Anbieter (ISVs) zu optimieren, um ihre Lösungen – und damit auch ihre Kunden – online zu Dynamics 365 Business Central zu bringen.

Moderne Entwicklertools

Die moderne Entwicklungsumgebung, die auf Visual Studio Code mit Azure DevOps und einer AL-Sprache basiert, unterstützt jetzt die Entwicklung großer Apps. Daher wird C/SIDE für Dynamics 365 Business Central in Zukunft eingestellt. Deswegen haben wir uns und unsere Performance Analyse Tool “V8 Search XE”auf die neue Situation eingestellt. Trotzdem wird sich im Bereich der Performance Optimierung von Dynamics 365 BC Wave 2 und SQL Server einiges verändern.

 So arbeiten Sie mit Leistungsproblem in Dynamics 365 Business Central 2020 Release Wave 2 zukünftig…

Was tun Sie, wenn sich Benutzer beschweren, dass “es langsam ist” in der neuen modernen Browser Umgebung? In diesem Abschnitt möchten wir einen Fehlerbehebungsprozess beschreiben, der Ihnen dabei helfen kann, die Hauptursache des Problems zu finden.
Bevor Sie mit der Lösung eines Leistungsoptimierungsproblems beginnen, ist es häufig hilfreich, “langsam” zu definieren und zu quantifizieren. Versuchen sie, akzeptable Werte für die Ausführungszeit von “langsamen” Vorgängen mit BC Benutzern auszuhandeln. Dies wird manchmal als “Festlegen einer Basislinie” bezeichnet.

Um ein Leistungsproblem zu lösen, werden häufig folgende Iterationen durchgeführt:

  • Messen Sie die Systemleistung und erfassen Sie Leistungsdaten vom SQL Server und den Dynamics 365 BC Servern
  • Suchen Sie einen Engpass
  • Beseitigen Sie den Engpass

und fahren Sie fort, bis die “langsamen” Operationen mit der festgelegten Basislinie vergleichbar sind.

Überwachung und Analyse der Telemetrie Business Central 2020 Release Wave 2 und höher.

Business Central sendet Telemetriedaten für verschiedene Aktivitäten und Operationen. V8 Search XE sammelt die Telemetriedaten für Business Central On-Premises über die V8 Services. Das heißt die Daten werden zentral für alle Server in der V8 Datenbank gespeichert.
Durch die Überwachung der Telemetrie erhalten Sie einen Überblick über die Aktivitäten und den allgemeinen Gesundheitszustand ihres Dynamics Systems. Es hilft Ihnen, Probleme zu diagnostizieren und Vorgänge zu analysieren, die sich auf die Leistung auswirken.

Der folgende Artikel kann Ihnen helfen, mehr zu diesem Thema zu finden:
Monitoring and Analyzing Telemetry Business Central | Microsoft Docs

Fazit:

Microsoft hat unserer Meinung nach viele neue Features im Bereich Performance Optimierung für Dynamics Business Central 2020 Release Wave 2 zur Verfügung gestellt. Andererseits werden auch sich auch Systembetreuer und Administratoren genauso wie C/AL-Entwickler/-innen mit der AL Programmierung befassen müssen. Wir stimmen der weitverbreiteten Meinung zu, dass wir die Dynamics Business Central / NAV onPremise Versionen noch einige Zeit mit der C/AL Programmiersprache unseren Spaß haben dürfen. Natürlich spielt das Know-how über die älteren NAV / BC Versionen für einen ERP Entwickler und Administratoren auch in Zukunft eine entscheidende Rolle.
Dinge ändern sich aber manchmal auch sehr schnell.

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

Optimieren der SQL Server Leistung mit Dynamics 365 Business Central on-Prem

Optimieren der SQL Server Leistung mit Dynamics 365 Business Central on-Prem und Dynamics NAV (alle Vorgängerversionen). Es gibt so viele Faktoren, die zu Leistungsproblemen in der SQL-Welt beitragen, dass es geradezu verwirrend sein kann, wo man überhaupt anfangen soll.

Wenn die Dynamics Anwendung und die zugehörige SQL Datenbanken wächst, ändern sich die Dinge. Zeilen werden geändert, das Schema wird aktualisiert und häufig verlangsamen sich die Dinge. Diese Leistungsschwächen können plötzlich oder zeitweise auftreten, aber es ist wichtig zu wissen, wie man Leistungsprobleme unterscheidet, damit man das einzelne Problem beheben kann.

Der Beitrag befasst sich mit einigen Schritten, die Sie ausführen sollten, wenn sich Ihre SQL Datenbank seltsam verhält. Damit Sie genau diagnostizieren können, was falsch läuft, und sich darauf konzentrieren, die Dinge zu beschleunigen. Optimieren der SQL Server Leistung mit Dynamics 365 Business Central sollte möglichst mit der Überprüfung der SQL Server Konfiguration starten.


Ist es die Datenbank? Oder der Server?

Wenn Sie Zugriff auf den Server haben, können Sie ein Tool wie System Monitor oder Perfmon verwenden, um die Prozesse zu überprüfen, die auf dem Server selbst ausgeführt werden. Hohe Speichernutzung, hohe CPU-Auslastung und langsamer Netzwerkverkehr sind rote Fahnen, bei denen das Problem möglicherweise nicht die Datenbank selbst ist.

Es gibt viele andere Systemdiagnosetools z.B. V8 Search XE , die bei diesem Prozess helfen können. Eines davon sollte Sie jedoch zumindest in die richtige Richtung weisen, bevor Sie unzählige Stunden damit verbringen, Tabellen, Indizes und mehr zu betrachten.

SQL Server verfügt über ein hervorragendes Profiling-Tool, mit dem sowohl vorhandene Probleme behoben als auch langsam laufende Abfragen isoliert werden können. Der XEvent Profiler zeigt eine Liveansicht erweiterter Ereignisse an. Es ist auch eine fantastische Möglichkeit, zusätzliche Daten zu Ihrer Datenbank für Leistungsoptimierungszwecke abzurufen (z.B. zu sehen, welche Abfragen am häufigsten ausgeführt werden, Dinge wie Speicher- und CPU-Auslastung zu untersuchen, potenzielle Blöcke zu identifizieren usw.).

In V8 Search XE die Optimieren der SQL Server Leistung mit Dynamics 365 Business Central in mehrere Bereiche aufgeteilt.


SQL Server System Check
V8 Search XE SQL Optimierung
V8 Search XE SQL Optimierung

V8 Search XE ist unendlich nützlich und ein guter erster Schritt zur Diagnose einer schlechten Leistung (oder von Fehlern im Allgemeinen). Er ist sowohl in Entwicklungs- als auch in Produktionsumgebungen nützlich.

Standardmäßig sind alle Datenbanken in der SQL Server-Instanz für die verschiedenen datenbankspezifischen Prüfungen geeignet, und Sie können den optionalen Parameter verwenden, um diese Prüfungen auf bestimmte Datenbanken einzuschränken. Gültig ab SQL Server 2012 aufwärts.


Performs checks:
  • Processor
  • Memory
  • Pagefile
  • I/O
  • Server
  • Service Accounts
  • Instance
  • Database and tempDB
  • Performance
  • Indexes and Statistics
  • Naming Convention
  • Security
  • Maintenance and Monitoring

Diese verschiedenen leistungsbezogenen Abfragen können es wert sein, regelmäßig überprüft zu werden, um potenzielle Probleme zu finden, die im Laufe der Zeit auftreten können.


Den Täter gefunden? Finden Sie jetzt heraus, warum die Abfrage langsam ist.

Sobald Sie eine bestimmte Abfrage identifiziert haben, die in den Analyse-Ansichten im V8 Search XE “SQL Server Check” als langsam ausgeführt indentifiziert wurde, können Sie sich den Ausführungsplan anzeigen, um genau zu sehen, was SQL Server hinter den Kulissen tut. Sie können von einer bestimmten Abfrage aus einfach über, die Schaltfläche “Show Plan” in der Symbolleiste oder über das Menüband darauf zugreifen:

V8 Query Plan

Ausführungspläne können auf einfache Weise potenzielle Probleme im Zusammenhang mit der Indizierung aufdecken , die dazu führen, dass Ihre gesamte Tabelle gescannt wird, anstatt genau das zu suchen, was sie benötigt. Auf den ersten Blick mögen sie unglaublich komplex erscheinen (und sie können es auch sein), aber sobald Sie mit ihnen gearbeitet haben, lernen Sie, Muster zu identifizieren und was sie damit verbunden sind (z. B. zeigt die X-Operation einen fehlenden Index für eine Tabelle usw. an).


Ein paar Dinge, auf die Sie hier achten sollten:
  • Suchen Sie nach Warnungen – Warnungen wie “No Join Predicate” sollten sehr offensichtliche rote Fahnen sein, die Sie wahrscheinlich ansprechen müssen. Die meisten Warnungen sollten zumindest weitere Untersuchungen rechtfertigen.
  • Reihenfolge der Vorgänge (Kosten) – Betrachten Sie die teuersten Operationen und festzustellen , ob solche Bestellung machen Sinn. Verbraucht ein einfacher Join 90% der Rechenleistung für den gesamten Anruf? Wenn ja, könnte etwas falsch sein.
  • Scans vs. Seeks – Beides ist nicht unbedingt schlecht, aber wenn eines viel länger dauert als erwartet (eines davon), lohnt es sich wahrscheinlich festzustellen, ob ein Index fehlt (d.h. der SQL Server scannt die gesamte Tabelle, anstatt auf einen gut definierten Suchwert zu greifen).

Das Verständnis von Ausführungsplänen ist mit Erfahrung verbunden, und Sie müssen sich hoffentlich nicht zu häufig mit ihnen befassen. Aber wenn Sie dies tun, wissen Sie, dass sie ein wertvoller Verbündeter im Kampf gegen schlechte Leistungen sein können.


Untersuchen Sie mögliche schlechte / fehlende Indizes

SQL-Indizes sind das A und O für die Leistungsoptimierung in Ihrer Dynamics NAV SQL Datenbank. Sie können sich diese ähnlich wie die Indizes vorstellen, die Sie möglicherweise in einem Buch finden, da sie es SQL ermöglichen, zu “wissen”, wo sie nach bestimmten Daten suchen müssen, anstatt willkürlich Seite für Seite durchzublättern.

Es ist erwähnenswert, dass Indizes nicht “fehlerfrei” sind und wie bei den meisten Dingen, wenn Sie sie falsch verwenden, sie mehr schaden als nützen können (d.h. stellen Sie sich vor, Sie gehen auf eine Schnitzeljagd mit außergewöhnlich Wegen oder lausigen Hinweisen).

Eine großartige Sache ist, dass Sie diese Arbeit nicht immer selbst erledigen müssen. Leute wie wir, haben Tools wie V8 Search XE entwickelt, um Indizes basierend auf der Tabellennutzung zu empfehlen. Für die Optimieren der SQL Server Leistung mit Dynamics 365 Business Central on-Prem und Dynamics NAV von unschätzbaren Wert!


Statistiken

So wertvoll es auch sein kann, SQL-Abfragen zu optimieren, es ist erwähnenswert, dass SQL Server einige davon “gut” und andere “schlecht” selbst erledigt. Dies wird durch die Verwendung von Statistiken erreicht, indem getätigte Anrufe überwacht, Ausführungspläne zwischengespeichert und Beurteilungen darüber vorgenommen werden, wie ein bestimmter Anruf am besten ausgeführt werden könnte/sollte.
Beachten Sie, dass wir “gut oder schlechten” erwähnt haben und das ist beabsichtigt. Statistiken sind zwar unglaublich wertvoll, können aber auch Probleme verursachen, wenn sie nicht korrekt erfasst werden oder veraltet sind. In den meisten Szenarien müssen Sie sich wahrscheinlich nicht regelmäßig mit diesen befassen, aber es ist wichtig zu wissen, dass sie existieren.


Wie bei fast jeder Technologien ist es sehr unwahrscheinlich, dass nur eines dieser Elemente alle Ihre Leistungsprobleme mit SQL Servern und Dynamics 365 Business Central bzw. Dynamics NAV heilt. Betrachten Sie all dies als wertvolle Werkzeuge in Ihrem Arsenal zur Fehlerbehebung und verwenden Sie sie zusammen, wenn Probleme auftreten.


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

Fehlerbehebung bei Performance-Problemen


Die Fehlerbehebung bei Performance-Problemen mit Dynamics Business Central oder NAV mit SQL Servern ist schwierig.
Wir das Team von dynamicsproject.com machen uns ständig gedanken, wie wir V8 Search XE im Kampf gegen Performance-Probleme in Dynamics Business Central oder NAV verbessern können.

Extended Events (XE) ist ein großartiges Diagnosetool, das in SQL Server 2008 eingeführt wurde. Wir benutzen die Extended Events (XE) als Hauptbasis für die Datenanlyse in V8 Search XE. Der V8 XE Profiler ermöglicht es, per erweiterte Ereignisablaufverfolgungen auf allen Dynamics NAV Instanzen das “Full SQL Tracing” parallell ausführen, um Tabellensperren die auf jeder Instanzen auftreten kann “Live” zu erfassen.
Nach dem Einschalten der Ablaufverfolgung können in kürzster Zeit große Mengen mit den erweiterten Ereignisverfolgungsdaten erzeugt werden. V8 Search XE liest die XEL Dateien, die vom asynchronen Dateiziel für erweiterte Ereignisse erstellt wurden. Pro Zeile wird ein Ereignis im XML-Format zurückgegeben. Das Lesen großer Ergebnismengen kann unter umständen sehr lange dauern. Standard mäßig erstellt das V8_FullSQL_NAV_Trace Ereignis 5 Dateien a 1 GB. Bei 5 GB XEL-Daten (ca. 1 Milionen Datensätze im XML Format) konnte das Einlesen in die Datenbank Tabellen zu Analysezwecken, durch aus 45 Minuten und länger dauern.

Das ist eine lange Wartezeit, also haben wir und darüber nachgedacht, wie wir das Importieren schneller machen können.

Der neue V8 XE Loader.

Mit diesem Dienstprogramm von V8 Search XE (ab Version 2.4.5) können die Inhalte der V8_FullSQL_NAV_Trace*.xel erweiterter Ereignisdateien schnell in eine SQL-Server-Datenbank geladen. Die Grundidee hierbei ist, das Dienstprogramm mit einer Reihe von XEL-Dateien aus derselben Extended Event-Sitzung zu versorgen. Das Dienstprogramm liest die Ereignisse parallel in mehreren Threads. Diese Methode reduzierte die Zeit, die für die Verarbeitung einer einzelnen Datei benötigt wird um ein Zehnfaches. In unserem Test konnten wir die 5 GB XML Dateien in knapp 5 Minuten und hatten somit relativ schneller die komplette Transaktion inkl. C/AL Codes der Dynamics NAV/BC Sitzung, die für die Tabellensprerre auf dem SQL-Server verantwortlich wahr.


Diesen Art von C/AL Code sollten sie sehen, um eine Fehlerbehebung bei Performance-Problemen in Dynamics Business Central oder NAV durchführen zu können!


V8 XE Profiler Result
V8 XE Profiler Result


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

SQL Server Performance für Dynamics Business Central

SQL Server Performance für Dynamics Business Central. Dynamics NAV ist jetzt Business Central und dann kam irgendwann der Frust

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 phantasische 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 6 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.

 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 DynamicsNAV 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 speichert zwei Arten von Daten:

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 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 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

Dynamics NAV Job Queue – Performance Bremse Onlineshop?

Dynamics NAV Job Queue – Performance Bremse Onlineshop?

Dynamics NAV Job Queue – manchmal kann ein Programmierfehler in C/AL Code dazu führen, dass Benutzer aufgrund von Datenbank-Deadlocks Fehler bekommen.
Ein Datenbank-Deadlock kann auftreten, wenn zwei Sitzungen versuchen, die gleichen Daten zu aktualisieren, und Datenbanksperren in verschiedenen Aufträgen erfassen. Der SQL Server erkennt Deadlocks und löst sie auf, indem eine der Transaktionen zurückgesetzt wird. In den vergangenen Monaten, fiel uns immer wieder bei verschieden Kunden auf, dass eine hohe Anzahl von Deadlocks und Tabellensperren sehr oft in Verbindung mit der Verwendung der Aufgabenwarteschlange entstanden. Um einen Überblick zu bekommen, haben wir für einen Kunden auf Wunsch eine grafische Darstellung der NAV Aufgaben entwickelt. Diese Grafik wird für die Dynamics NAV “Job Queue” und die im SQL Server Agent definierten Jobs erstellt.

Diese Grafik zeigt die Aufgabenwarteschlange (Dynamics NAV “Job Queue”) des Kunden – jeder kleine Strich stellt eine Aufgabe mit der jeweiligen Dauer da!

Dynamics NAV Job Queue Timeline
Dynamics NAV Job Queue Timeline

Der SQL Server Agent erlaubt die Definition von Jobs, die aus (mehreren) Job Steps bestehen. Und das sieht dann so aus:

SQL Agent Job Queue Timeline
SQL Agent Job Queue Timeline

Gut zuerkennen ist, dass gewisse Aufgaben sich vom zeitlichen Ablauf eventuelle gegenseitig behindern.

Microsoft Dynamics NAV und E-Commerce ist in fast allen Unternehmen ein zentrales Thema. Anbieter versprechen durch 100% vollständige Integration mit Ihrem Microsoft Dynamics NAV-System. Dem Kunden stehen kundenspezifische Preisgestaltung, Produktspezifikationen, Lagerbestände und mehr direkt im Onlineshop zur Verfügung. Das funktioniert auch.

Aber was passiert, wenn z. B. die Anzahl der täglichen Bestellungen von genommen 100 auf 2000 anwachsen. Und Ihr Artikelstamm zehntausende von Artikeln beinhaltet? Wie lange braucht der “Dynamics NAV Web Services” für den Datenaustausch? Und werden die Daten vielleicht noch anderweitig verarbeitet (Buchungen, Lagerbestände abgleichen usw.). Wahrscheinlich laufen auch in Ihrer NAV “Job Queue” jede Menge Aufgaben. Sollten Sie Performance Probleme am SQL Server und in Ihrer Dynamics NAV Lösung haben, dann schauen sich Ihren SQL Server Agent und Ihrer NAV Aufgabenwarteschlange bitte genauer.

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

Olav Treffurt

Warum ist Dynamics NAV langsam Teil 2

Warum ist Dynamics NAV langsam Teil 2



Warum ist Dynamics NAV langsam Teil 2 – wir möchten noch einmal das Thema für Sie zur Sprache bringen. Die neue Sicht der Dinge.

Stellen Sie sich vor, einen erfahrenen Dynamics NAV Partner für das Thema Funktionalitäten und Anpassungen in Dynamics NAV zu haben, der weiß, dass er sich Ihr Vertrauen täglich erarbeiten muss. Einen Partner, der Ihre Bedürfnisse versteht, die passenden Lösungen plant, baut und implementiert.

Nach einiger Zeit läuft NAV oft sehr träge, und das ausgerechnet in zeitkritischen Situationen? Sie haben eine Menge investiert , um Ihr ERP System aufzubauen. Zeit, Geld und Ressourcen wurden eingesetzt, aber sobald Sie Artikelkarte in NAV aufrufen… sind Sie bereits genervt!
Warum – weil Sie eine gefühlte Ewigkeit warteten, bis die Daten sichtbar sind. Oder wichtige Informationen zu Bestellungen aus dem angebundenen Web Shop werden nicht zügig abgearbeitet… kommt Ihnen das bekannt vor?
Seit dem das NAV System “live” ist, funktioniert die Betreuung des ERP Systems durch den Partner vor Ort nur sehr …

Und was machen die meisten Dynamics NAV Verantwortlichen im Unternehmen?

Wenig bis Nichts. Sie sprechen mit dem NAV Partner. Der bekommt die Probleme aber auch nicht richtig in den Griff. Und jetzt? Auf die Suche nach einem neuen Dynamics NAV Partner machen? Nach dem “1-Klick-Programm” für NAV Probleme im Netz suchen?

Es gibt keine “One click alles wird gut Lösung” für NAV Probleme!!!



NAV Performance Optimierungs Tools gibt es leider nicht so viele auf dem Software Markt. Warum eigentlich? Ganz einfach – es ist ein undankbarer Job so etwas zu entwickeln. Trotzdem entwickeln wir mit unserer Kreativität und Leidenschaft für Sie neue Produkte.

Zum Beispiel unser neustes Tool V8 Search XE – Dynamics NAV und SQL Server Performance Anaylzer. Warum wieder so eine neue Mammutaufgabe?

“Weil wir es lieben… und ein bisschen irre sind!”

Seit dem Jahr 2012, mit Einführung Dynamics NAV 2013, haben wir voller Elan und Enthusiasmus eine Vision gehabt – Tools für Dynamics NAV und dem SQL Server zu entwickeln, die das Leben leichter machen sollen. Wir planten eine ganze Produktlinie Namens “Vision 8” . Die acht im Namen ist eigentlich gar keine “8” sonder ein Unendlichkeitszeichen “∞” (ließ sich beim schreiben schlecht darstellen).


Warum ist Dynamics NAV langsam Teil 2


Unternehmen sollen bei der Produktentwicklung die Bedürfnisse des Nutzers in den Mittelpunkt stellen. Im Idealfall empfindet der Nutzer das Produkt dadurch als nützlich und einfach zu bedienen.

Einfach machen: Das sagt sich so leicht. In Wirklichkeit ist Einfachheit oft die schwierigere Aufgabe.

Die Herausforderung liegt in der Funktionsvielfalt eines “NAV Performance Analyzer”

Dass die nutzerzentrierte Produktentwicklung gerade in den letzten Jahren in den Unternehmen immer wichtiger wird, liegt an der steigenden Komplexität der Produkte wie Dynamics NAV und dem SQL Server im Arbeitsalltag der Benutzer.

Je komplexer die IT-Infrastruktur, desto schwieriger ist es, diese hochperformant und sicher zu halten. Lässt sich Hochverfügbarkeit für die kritische Unternehmenssoftware wie Dynamics NAV überhaupt noch garantieren? Und welche Möglichkeiten gibt es, das komplexe Thema Performance Analyse zu vereinfachen?

Es gibt eine Vielzahl von Tools für die Leistungsüberwachung und -optimierung von SQL Servern. Kostenlose Monitoring-Tools mit Tipps, Tricks und Know-How bei Performance Problemen – alternativen zu teuren, großen und aufwändigen IT-Infrastruktur Monster Tools.

Egal ob kostenlos oder teuer; helfen Ihnen diese Tools bei Tabellensperren oder NAV Clients die nicht reagieren?

NEIN!

Was genau ist das V8 Search XE Tool und was macht es so besonders? Was unterscheidet V8 Search XE von anderen ähnlichen Diagnosetools – die es eigentlich nicht gibt; oder haben Sie eins im Internet gefunden?

Warum ist Dynamics NAV langsam Teil 2 – Fazit

Egal welchen Weg Sie wählen, sollten Sie am Ende Ihr Dynamics NAV System fit für die Zukunft machen…
Also warum nicht mit V8 Search XE

Gerne beantworten wir Ihnen persönlich weitergehende Fragen zu diesem Thema.

Siehe auch

https://www.dynamicsproject.com/allgemein/sql-server-performance-fuer-dynamics-business-central.html

Performance Probleme in Dynamics NAV

Performance Probleme in Dynamics NAV

 

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

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

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

Ich fände es gut!

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

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


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


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





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


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


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

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

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


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

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


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


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

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

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

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


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


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



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

Es ist zu komplex!

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

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

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


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

 

Olav Treffurt