Identifizieren von Tabellensperren in Dynamics NAV / Business Central

Identifizieren von Tabellensperren in Dynamics NAV


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

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

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

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

Überwachen von Microsoft Dynamics NAV Server-Ereignissen:

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

Blocking:

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

In NAV erscheint dann diese Meldung:

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

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

Deadlocks:

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

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

In NAV erscheint dann diese Meldung:

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

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

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

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

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

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

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

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

Welcher Dynamics BC / NAV Windows User sperrt die Tabelle?

V8 Search XE Tutorial Video



Read more…

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

Ihr Team von DynamicsProject.com

Back to Top

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