Tag: Dynamics NAV

Kleine Artikel mit Tipps und Tricks für Microsoft Dynamics NAV.

Business Central Performance Tool

Posted on | by InfoMaster

Business Central Performance Tool. With the Business Central Performance Tool V8 Search XE you can increase the performance, analyze and improve the performance of your Dynamics Business Central or NAV solution.

A typical problem in the Dynamics world...

Some time ago we had an inquiry about the known problems in Business Central / NAV. The SQL Server performance for Dynamics Business Central / NAV would not be better than the updated NAV version 2013. Daily many table locks, frustrated users and an IT partner who is somewhat clueless.

Our offer...

Using V8 Care to analyze the "ACTUAL" state of the SQL Server and the Dynamics Business Central solution and to collect the bottlenecks in the database. True to the new motto "Data is the gold of the 21st century" . To our surprise, we got the answer: "Sufficient data for the analysis of the Dynamics Business Central problems had been collected." Since the interested party did not have its own IT experts in the company, he uses specialized IT service providers who use the SQL Server and Dynamics Business Central care for. It is true that we live in a world in which algorithms make the decisions in many areas about what has to happen if a certain result occurs or a data limit is exceeded. But in many application scenarios, people are and remain the final authority.

Our question, what kind of data was collected? With which SQL Server monitoring tool? There are fantastic real-time SQL Server monitoring tools. Unfortunately, SQL monitoring tools do not provide information about Dynamics AL code.

Thus, when it comes to monitoring IT security systems, the IT admin or chief security officer is ultimately the one who makes the decisions.

For this reason, we would like to briefly discuss the possibilities offered by our analysis tool V8 Search XE .

The problem:

SQL Server is capable of handling queries from a large number of concurrent users. When SQL Server handles requests from many clients, there is a high probability that conflicts will occur because different processes will request access to the same resources at the same time. A conflict where one process is waiting for another process to release a resource is called a block. Although in SQL Server a blocked process usually resolves itself when the first process releases the resource, a process can hold a transaction lock and not release it.

Our solution:

To unblock a blocked process from Dynamics NAV / Business Central, we must first determine which process is the blocking process. And then, if possible, analyze and optimize the Dynamics NAV/BC blocking process.
In V8 Search XE, there are many different ways to identify a blocking and unblocking process, which are listed below:

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
5. Business Central/NAV Server: Business Central Telemetry Data

 SQL Server: Extended Events

The goal of the Extended Events installed by V8 is to present all the information collected by the Extended Events sessions in a readable form. The SQL queries that exceed the specified threshold (we recommend starting with 10 seconds) are recorded and collected in different Extended Events sessions. The SQL scripts are used as a basis for code analysis in V8 Search XE. In V8 XE Profiler, SQL queries are recorded when they are created by the Dynamics Business Central / NAV object.

V8 Extended Events sessions:
1. blocked_process -> Table locks and deadlocks
2. long_duration -> Long running SQL queries in Business Central/NAV
. 3. v8_user_NAV_Trace -> This session allows you to view SQL queries for all statements issued by the C/AL code (Windows user name with SQL Server SPID). These are stored in the V8 XE profiler and displayed as comments.
/*
Get connection from the pool.
User: ComputerName\WindowsUsername
*/
4. V8_FullSQL_NAV_Trace -> The session allows SQL queries to be displayed for all statements issued by the C/AL code. These are collected and displayed as comments for a complete transaction in the V8 XE profiler of the SQL server.



 SQL Server: Dynamic Management Views (DMV)

"DMVs" are query structures built into SQL Server that provide details about the health and performance of servers and databases. DMVs provide a common mechanism for extracting "all things SQL" as well as Windows operating system performance data. There are several DMV categories that return configuration information and performance data.



 Windows Trace Events: SQL Trace Events

SQL Trace events track a specific set of SQL statements executed by the Business Central Server instance against the Business Central/NAV database on SQL Server.
The event data collected includes: session ID, tenant ID, the Business Central/NAV user, and the SQL statement. The listing is only the SQL portion of the Business Central Server trace events.

Important!
To collect this data, you need one V8 service per Business Central Server instance. This feature is available from version 7 of V8 Services and requires .NET Framework 4.7.2, which is not installed by default on older Dynamics NAV.

It is also possible to collect individual event IDs.

The following table lists a few Dynamics SQL trace events. For example:

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.

If you are using Dynamics Business Central version 18 or higher we recommend you to read this article Watch Business Central table locks live

 Business Central/NAV Server: C/AL tracing

Since the Microsoft Dynamics NAV 2013 version, the server has a feature that allows you to view the AL call stack for SQL commands. Full SQL Trace enables/disables tracing for all new and existing sessions per Dynamics Server instance.

This allows you to view SQL queries for any statements issued by the AL. All SQL statements between consecutive comments correspond to the AL statement starting with the first comment. These comments correspond to events when the connection is retrieved and returned to the Microsoft Dynamics NAV Server connection query. These comments are needed to separate SQL query issues from different clients on the same SQL connection. The SQL statement that matches these comments is issued by Microsoft Dynamics NAV Server, but not by AL. Comments containing only the username also correspond to SQL statements issued by Microsoft Dynamics NAV Server but not by Dyanmics AL code.

For example, Microsoft Dynamics NAV Server runs queries to calculate calculated fields that are displayed in the fact fields. These types of comments are required because Microsoft Dynamics NAV Server may run an SQL query without reconnecting to the pool, and they do not originate from Dynamics AL.

Important! To collect this data, you need one V8 service per Business Central Server instance.

Collecting and analyzing data
V8 Search XE offers two ways to collect event data from Business Central / NAV.

After the SQL trace has been captured, the data is stored in the SQL table. The trace was saved in the "V8 XEvents Full SQL Trace" table in the V8 Search XE database.

2. the complete AL programming code of the respective objects. The data is stored in the "V8 Performance Profiler" table in the V8 Search XE database.

The V8 Source Code Search module allows you to search your entire Dynamics NAV/BC codebase to find where specific code elements are referenced.

 Business Central/NAV Server: Business Central Telemetry Data

Business Central sends telemetry data for various activities and processes in environments and applications/extensions. Up to Business Central version 14 (Role Tailored Client) there was the very helpful function of “SQL Tracing for Microsoft Dynamics Business Central / NAV” (EnableFullALFunctionTracing = true). After Business Central was converted to the web client version (from version 15), the function in the Business Central server options has changed slightly.

Monitoring telemetry data gives you insight into the activity and overall health of your environments/apps, so you can diagnose issues and analyze operations that are impacting performance. The V8 service of V8 Search XE collects telemetry data for analysis and presentation to Business Central or Dynamics NAV on-premise versions.

V8 Service Telemetriedaten: Analyse- und Präsentationsdaten bis BC Version 14 (Role Tailored Client)

V8 Service Full AL Function Tracing: Analyse- und Präsentationsdaten bis BC Version 14 (Role Tailored Client)

V8 Service Telemetriedaten: Analyse- und Präsentationsdaten ab BC Version 15 (Web Client)

Zeigt, welche „SQL SERVER SPID“ in BC welche Session ID ist. Die Information ist für die Analyse von Performanceproblemen enorm wichtig!

SQL Statements von Business Central (sehr wichtig für Tabellensperren und Deadlocks)

The telemetry data is expanded by Microsoft with each new version of Business Central in order to provide more detailed information on any performance bottlenecks.
V8 Search XE can analyze and present telemetry data up to the latest version of Business Central.

Conclusion
This specific data, is very difficult to capture with a real-time SQL Server monitoring tool. You need to monitor all the Business Central Server instances in parallel.

V8 Search XE the Business Central Performance Tool is intended to enable all administrators and developers supporting a Dynamics NAV/BC ERP solution to make a statement about the weaknesses of the SQL commands generated by Dynamics Dynamics Business Central / NAV and to document them.

In any case, it pays off to have the Dynamics NAV / Business Central performance checked by a third party to find out what condition the ERP system and the SQL server are in.
After that, you can consider what options you then have for further action to improve SQL Server performance for Dynamics Business Central.

We will be happy to answer any further questions you may have on this topic in person.

Your dynamicsproject.com Team

Troubleshooting performance problems

Posted on | by InfoMaster


Troubleshooting performance issues with Dynamics Business Central or NAV with SQL Servers is difficult.
We the team at dynamicsproject.com are constantly thinking about how we can improve V8 Search XE in the fight against performance issues in Dynamics Business Central or NAV.

Extended Events (XE) is a great diagnostic tool introduced in SQL Server 2008. We use Extended Events (XE) as the main basis for data analysis in V8 Search XE. The V8 XE Profiler allows to run "Full SQL Tracing" in parallel via extended event tracing on all Dynamics NAV instances to capture table locks that may occur on any instance "live".
After turning on tracing, large volumes can be generated in shortest time with the advanced event tracing data. V8 Search XE reads the XEL files created by the asynchronous extended event file target. One event is returned per line in XML format. Reading large result sets may take a long time. By default, the V8_FullSQL_NAV_Trace event creates 5 files of 1 GB. With 5 GB of XEL data (approx. 1 million data records in XML format) the reading into the database tables for analysis purposes could take 45 minutes or longer.

That's a long wait, so we thought and about how to make importing faster.

The new V8 XE Loader.

This utility of V8 Search XE (from version 2.4.5) allows to quickly load the contents of the V8_FullSQL_NAV_Trace*.xel extended event files into a SQL Server database. The basic idea here is to provide the utility with a set of XEL files from the same extended event session. The utility reads the events parallel in multiple threads. This method reduced the time required to process a single file by a factor of ten. In our test, we were able to process the 5 GB XML files in just under 5 minutes and thus had the complete transaction including C/AL codes of the Dynamics NAV/BC session responsible for the table snapshot on the SQL server relatively faster.


This is the kind of C/AL code they should see to troubleshoot performance issues in Dynamics Business Central or NAV!


V8 XE Profiler Result
V8 XE Profiler Result


We will be happy to personally answer any further questions you may have on this topic.
Your dynamicsproject.com Team

Why is Dynamics NAV slow part 2

Posted on | by InfoMaster

Why is Dynamics NAV slow part 2



Why is Dynamics NAV slow part 2 - we would like to once again bring up the topic for you. The new view of things.

Imagine having a experienced Dynamics NAV partner for the topic of functionalities and customizations in Dynamics NAV, who knows that he has to earn your trust every day. A partner who understands your needs, plans, builds and implements the appropriate solutions.

After some time, NAV often runs very sluggishly, and that in time-critical situations of all things? You have invested a lot to build your ERP system. Time, money and resources have been used, but as soon as you call item card in NAV... you are already annoyed!
Why - because you waited a perceived eternity for the data to be visible. Or important information on orders from the connected web store are not processed quickly... does this sound familiar to you?
Since the NAV system is "live", the support of the ERP system by the on-site partner works only very ...

And what do most Dynamics NAV managers in the company do?

Little to nothing. You talk to the NAV partner. But he can't really get to grips with the problems either. And now? Search for a new Dynamics NAV partner? Search for the "1-click program" for NAV problems on the web?

There is no "one click everything will be fine solution" for NAV problems!!!!



NAV performance optimization tools are unfortunately not so many on the software market. Why actually? Quite simply - it's a gratuitous job to develop something like that. Nevertheless, we develop new products for you with our creativity and passion.

For example, our latest tool V8 Search XE - Dynamics NAV and SQL Server Performance Anaylzer. Why such a new mammoth task again?

"Because we love it... and we're a little nuts!"

Since 2012, with introduction of Dynamics NAV 2013, we have had a vision full of vigor and enthusiasm - to develop tools for Dynamics NAV and SQL Server to make life easier. We planned a whole product line called "Vision 8" . The eight in the name is actually not a "8" but a infinity sign "∞" (could be badly displayed when writing).


Why is Dynamics NAV slow part 2

Companies should focus on the needs of the user during product development. Ideally, the user will find the product useful and easy to use.

Make it simple: It's so easy to say. In reality, simplicity is often the more difficult task.

The challenge lies in the functional diversity of a "NAV Performance Analyzer

The fact that user-centered product development has become increasingly important in companies, especially in recent years, is due to the growing complexity of products such as Dynamics NAV and the SQL Server in users' everyday work.

The more complex the IT infrastructure, the more difficult it is to keep it high-performance and secure. Can high availability for critical enterprise software such as Dynamics NAV still be guaranteed at all? And what possibilities are there to simplify the complex topic of performance analysis?

There are a variety of tools for performance monitoring and optimization of SQL servers. Free monitoring tools with tips, tricks and know-how for performance problems - alternatives to expensive, large and complex IT infrastructure monster tools.

Whether free or expensive; will these tools help you with table locks or NAV clients that don't respond?

NO!

What exactly is the V8 Search XE tool and what makes it so special? What makes V8 Search XE different from other similar diagnostic tools - which actually don't exist; or have you found one on the Internet?

Why is Dynamics NAV slow Part 2 - Conclusion

No matter which way you choose, you should end up making your Dynamics NAV system fit for the future...
So why not go with V8 Search XE ...

We will be happy to answer any further questions you may have on this topic in person.

See also

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

Performance Probleme in Dynamics NAV

Posted on | by InfoMaster

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!


We will be happy to personally answer any further questions you may have on this topic. Simply contact us via our contact form or by e-mail to info@dynamicsproject.com!

 

Olav Treffurt

 

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.


We will be happy to personally answer any further questions you may have on this topic. Simply contact us via our contact form or by e-mail to info@dynamicsproject.com!

 

Your team from DynamicsProject.com

 

Support-Anrufe – Tabelle gesperrt?

Posted on | by InfoMaster

Support-Anrufe: Welcher Microsoft Dynamics NAV Benutzer hat eine Tabelle gesperrt?

 

Viele von Ihnen kennen die Support-Anrufe von verzweifelten Kunden oder Kollegen, die etwa so klingen: „Hilfe! Niemand kann etwas Buchen!“
„Alles, was wir bekommen, ist eine Nachricht, dass die Tabelle Artikelposten von einem anderen Benutzer gesperrt ist!“

„Find the NAV Session ID that holds the blocking lock“ – gerne, aber wie?

Bis NAV 2009R2 war die Sitzungs-ID in der NAV-Sessions-Liste dasselbe wie die SQL Server SPID. Beginnend mit Microsoft Dynamics NAV 2013, entspricht die Sitzungs-ID nicht mehr den SQL SPID.

Der SQL Server erkennt, dass eine Blockierung durch das NAV Service Tier entsteht mit der SPID XXX und als User wird der Netzwerkdienst angezeigt. AAAAAAHHH!!!“
Und welcher NAV Benutzer verursacht das Problem? Wen soll man anrufen, den Netzwerkdienst??

Dem Anschein nach ist der „Leidensdruck“ noch nicht hoch genug, dass sich Dynamics NAV Benutzer/Kunden von Dynamics NAV 2013 oder höher bei Ihren Microsoft Dynamics-Partner über diesen unbefriedigende bzw. nicht vorhandene Problemlösung beschweren.

Immer wieder Fragen mich meine Kollegen, Kunden und sogar Microsoft Dynamics-Partner nach einer Lösung.

Unsere erste Lösung der V8 Search XE – leider nicht ganz optimal für NAV Service Tiere auf verschieden Computern.

Basierend auf unserer ersten Idee, haben wir aus einer Windows-Applikation einen Windows-Service entwickelt. Damit ist das Problem der NAV Service Tiere auf verschiedenen Maschinen gelöst (guter Tipp von einem NAV Entwickler Kollegen).
Alle Informationen lassen in einer SQL Server Datenbank zusammenfassen. Somit kann die NAV Session ID, User Name und SQL SPID in einer SQL Sicht anzeigt werden. Damit stehen alle Analyse Möglichkeiten des SQL Server in Bezug auf Deadlocks, Blocking Process und vieles mehr für jeden Dynamics NAV Benutzer zur Verfügung.

Die Performance Optimierung in Dynamics NAV kann beginnen, da man jeden NAV Benutzer gezielt ansprechen kann, was er gerade in Dynamics NAV macht und warum die anderen Benutzer gesperrt werden!


Let’s have big fun!


Kleiner Hinweis:
Die Dynamics NAV Benutzer können in den seltensten Fällen etwas für das Sperren der Tabellen. In 95% der Fälle ist der Dynamics NAV C/AL Source Code die Ursache – nicht der NAV Benutzer!


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.

Ihr Nutzen: weniger Support-Anrufe!

 


Unser Workshop-Angebot – V8 Performance Management Pack


  • 1 Tag Vor-Ort- oder Analyse per Remote-Meetimg / Software installation durch/mit einen Mitarbeiter unseres Dynamics Project Teams
  • Installation, Konfiguration und Verwaltung von V8 Search XE
  • Konzept zur weiteren Vorgehensweise mit Detail-Anweisungen zur Dynamics NAV und SQL Server Optimierung


 

Features | SQL Server | Dynamics NAV


  • Echtzeit-System SQL-und Performance-Daten
  • Datenbank- und Protokolldateigröße
  • Sperren und Latches | Pufferverwaltungsstatistiken
  • Arbeitsspeicher | Festplattenleistung
  • Identifizierung von aufwändigen SQL Abfragen anhand von CPU-Zeit und durchschnittlicher Dauer
  • Aktive Benutzerverbindungen
  • Datenprotokollierung als CSV Datei – Datenerfassungsintervall konfigurierbar
  • Nutzung des neuen Features von Microsoft Dynamics NAV 2013 / 2015 / 2016 zur Analyse der C/AL-Aufrufliste für SQL-Befehle
  • Ermittlung welche SQL-Anweisungen aus der selektierten Session des NAV-Client generiert wurden
  • Analyse kostspieligster C/AL Aufrufe in Bezug auf die SQL Performance
  • Sichtbarkeit der Metadaten aller Objekte aus der NAV 2013 / 2015 / 2016 Objekt-Metadatentabelle
  • C/AL Source Code Compare and Merge Tool
  • C/AL Compare Html Documentation
  • Dynamics NAV Object Store incl. Function “Where Used?””
  • XE Explorer für SQL Server Extended Events
  • SQL Live Monitor
  • Html SQL Server Dokumenter
  • Vergleichen von Datenbankschemas
  • Transact-SQL-Editor
  • PowerShell Editor
  • SQL System Health Reports


We will be happy to personally answer any further questions you may have on this topic. Simply contact us via our contact form or by e-mail to info@dynamicsproject.com!

 

Your team from DynamicsProject.com

 

Dynamics NAV Performance Counters

Posted on | by InfoMaster

Dynamics NAV Performance Counters

Dynamics NAV performance counters and SQL Server integrated performance counters are powerful tools to track down system configuration errors and bottlenecks.

We would like to introduce the most significant of these performance counters in the NAV system environment (Dynamics NAV Performance Counters / SQL Server Performance Counters).

Keeping a NAV system performant (preferably without locks) is the most important and at the same time the most difficult task of a system manager. Particularly time-consuming are the problems whose cause lies deep in the NAV / SQL Server architecture, often not obvious at first glance. In order to get to the root of the problems, it is very helpful to know and locate the bottlenecks and bottlenecks of the system.
This is exactly where the Dynamics NAV and SQL Server Performance Counter comes in. At first glance, the sheer mass of different counters makes you lose track of them. The Dynamics NAV performance counters (Data Collector Set) provide information about how well the Microsoft Dynamics NAV Server is working. By using the V8 NAV SQL Studio monitoring tools, you can monitor the data of the performance counters of the components such as service tier, storage, physical disk and SQL Server, etc., in order to make any performance optimizations.

1. Dynamics NAV Performance Counters

There are several reasons why a SQL Server performance metrics values can be high in conjunction with the Dynamics NAV server instance. Perhaps there is non-optimal code in your NAV solution that is causing too many SQL calls. It is also possible that your data or metadata cache settings are set too low.
. There are 2 Dynamics NAV performance counters that show this problem:

#CategoryCounterDescriptionStatus
1Data and caching% Primary key cache hit ratePercentage of hits in the primary key cache, compared to the total requests in the primary key cache.>90%
2Data and caching% Result set cache hit ratePercentage of result set hits in the cache, compared to total result set cache requests.>90%

The primary key cache hit rate should be above 90%; otherwise, the Dynamics NAV server instance cache might be too small.

Data Cache Size (CustomSettings.config)

If you find that the "Data Cache" of the Dynamics NAV server instance is too small, you can adjust the value in this setting:

<add key=“DataCacheSize“ value=“9″ />

When running a "single tenant" NAV system the default value of 9 is probably good.

Here are the values to change the "Data Cache Size":

ValueMemory
9 (default)512Mb
101Gb
112Gb
124Gb
138Gb
1416Gb
1532Gb
……

Metadata Provider Cache Size

<add key=“MetadataProviderCacheSize“ value=“150″ />

You should only increase the "Metadata Provider Cache Size" of the Microsoft Dynamics NAV service tier if you notice a heavy load on the working memory via the performance counters.

2. Windows and SQL server performance counters

Here is our suggestion of the key performance indicators you should review:

#CategoryCounterDescriptionStatus
1Memory/Buffer ManagerBuffer Cache Hit RatioIndication of the percentage of data pages that exists in SQL Server memory without accessing the hard disk. A value lower than 90% is a clear sign of memory problem (increase SQL Server RAM).>= 90%
2CPU/ Processor% User TimeThe performance indicator "% User Time" corresponds to the percentage of time the processor spends executing user processes such as SQL Server.=< 70%
3DiskAvg. Disk Sec/ReadThe average time in milliseconds for each read on disk: > 20 is considered very poor, < 20 good, < 12 very good, and < 8 optimal.=< 20MS
4DiskAvg. Disk Sec/WriteThe average time in milliseconds for each write to disk: > 20 is considered very poor, < 20 good, < 12 very good, and 4 is poor, < 4 is good, < 2 is very good, < 1 is optimal.=< 20MS
5LocksAvg. Wait Time (in ms)The average length of the waiting time (in milliseconds) for each blocking request that could not be fulfilled immediately. An average wait time longer than 500ms indicates excessive blocking.=< 500MS
6MemoryAvailable BytesLow values for the "Available Bytes" performance indicator can be a sign that there is too little memory overall on the computer or that an application such as Dynamics NAV is not freeing up memory.>20MB
7MemoryPages/secA high value for the "Pages/sec" performance indicator may indicate excessive outsourcing.< 50
8NetworkOutput Queue LengthThe Output Queue Length performance indicator specifies the length of the output packet queue in packets.< 2
9SQL Server: Buffer ManagerOutput Queue LengthA value above 90 percent indicates that more than 90 percent of all data requests have been met by the data cache. Keep adding memory until the value is consistently above 90 percent.>90
10SQL Server Access MethodsPage Splits/secNumber of page splits per second that are the result of index page overflow.1. Defragment SQL Server indexes 2. Checking the Dynamics NAV C/AL keys0

Conclusion

Performance is one of the most important non-functional requirements that Dynamics NAV faces, especially with SQL Server. By now you will have noticed that some of these issues require greater concepts and techniques to get into. However, none of these topics are unsolvable for DBAs.

If this or similar topics have piqued your interest, I would be happy to engage in an open dialogue with you.

Your team from DynamicsProject.com

Back to Top

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.

 

Conclusion

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.

If this or similar topics have piqued your interest, I would be happy to engage in an open dialogue with you.

 

Your team from DynamicsProject.com

Back to Top

New blog for Dynamics NAV and Microsoft SQL Server

Posted on | by InfoMaster

New blog for Dynamics NAV and Microsoft SQL Server

 

Welcome to DynamicsProject.com!
Have fun on our new blog.

 

New blog for Dynamics NAV and Microsoft SQL Server. Since the topics of performance optimization and C/AL programming for Dynamics NAV and Microsoft SQL Server are very diverse and multifaceted, we will offer you short articles at regular intervals from today on, with which you can delve deeper into the subject matter. At the same time, the blog serves to give you a first impression of what you can expect from the Dynamics Project Team.

 

You can always ask us questions about the articles and we welcome any comments and feedback!

 

We wish you and us much success

Your team from DynamicsProject.com