Navision SQL Server Optimierung seit dem Release NAV 5.0 SP1 bis NAV 2009 SP1

das Thema SQL Performance ist schon immer eines unserer “heißen” Themen gewesen. Im Folgenden möchte ich ein paar wesentliche Punkte darlegen, was sich eigentlich seit der Version NAV 5.0 SP1 signifikantes in der technischen Umgebung vom NAV Client in der Kommunikation mit dem SQL Server geändert hat und welche Fortschritte in der Performance erreicht wurden.

• Der SQL Index wird seit der Version NAV 5.0 SP1 nicht mehr genutzt

Erfahrung haben gezeigt, dass der SQL Index mit der Index Definition von NAV nicht harmonisiert bezüglich der Indexabfrage des TSQL Statements  “UPDLOCK”. Bei diesem Statement werden die Records beim Lesen gelockt, um nicht verändert zu werden.  So wurden in der Version NAV 4.0 SP3 bis zum Update6 (KB 940718) und dem Hotfix  KB950920 ausschließlich die sogenannten “Fast Forward Cursor” (FFo)  verwendet, welche bei der Indexabfrage die “WHERE” Klausel optimiert abfragt und überprüft welcher Datensatz  mit der NAV Indexdefinition korreliert.

Ab der Version NAV 5.0 wurde die finsql.exe Runtimeumgebung so programmiert , dass die Ergebnismenge dynamisch sein muss, d.h. diese Ergebnismenge enthält nur Zeilen in denen ein “Insert” oder “Update” erfolgt ist und enthält keine Zeilen, die gelöscht worden sind. Darum wird seit NAV 5.0 der Dynamic Cursor für die Abfragen des NAV Clients auf dem SQL Server verwendet, um eine dynamische Ergebnismenge in den Abfragen zu generieren. Hierbei versucht der SQL Server immer versucht einen Zugriffsplan erstellt, der die verschiedenen Indizes mit dem “ORDER BY” Statement sortiert und die geleichen Ergebnismengen mit dem WHERE Statement abgleicht. Dadurch wird ein eine SQL Server interne statistische Ereignismenge angelegt, welche nur die veränderten Datensätze der momentanen Transaktion zwischen NAV Client und SQL Server enthält. Der FFo Cursor beliebt aber weiterhin in der finsql.exe integriert, und wird für die Anfragen von Form verwendet, der Dynamic Cursor für die Abfragen der Tabellen.

Diese dynamische Generierung von Ereignismengen durch die Dynamic Cursor hat zu folge, dass SQL Indizes nicht an Tabelle verwendet werden sollten, welche während dem Schreibzugriff einen Lese- oder Änderungszugriff erfahren.

• Parameter Sniffing gibt es nur im SQL Server 2005 und bis Dynamics NAV 5.0 RTM

Es gibt jedoch eine eine Unterschied im Verhalten der finsql.exe beim Zugriff auf einen SQL Server 2005 und SQL Server 2008. Im SQL Server 2005 wird eine Zugriffsplan auf Grund von Histogrammen erstellt, in dem eine Liste generiert wird, in der Parameter (wie ein WHERE Statement zu einem dedizierten Wert) zu einer Spalte einer Tabelle bestimme Werte zugewiesen werden. Hier wird ein Zugriffsplan erstellt, welcher auf errechneten Werten der ersten in der Tabelle existierenden SQL Indexe oder Cluster Indexes. Dabei wird aber immer nur die erste Spalte des Indexes beachtete. Das hat des Öfteren zu Performanceproblemen geführt, da in dem so genannten Parameter Sniffing diese evaluierten Parameter nicht für untergeordneten  Anfragen auf diese Tabelle anwendbar sind. "Parameter Sniffing" bezieht sich auf hier einen Prozess, bei dem Umgebung für die Ausführung von SQL Server die aktuellen Werte der Parameter während der Kompilierung oder Neukompilierung "sniffs" übergibt und dem Abfrageoptimierer so verwendet werden können, dass darus möglicherweise schnellere Abfrageausführungspläne generieren werden. Das Wort "aktuellen" bezieht sich auf die Werte der Parameter im Aufruf-Anweisung, welche durch eine Kompilierung oder eine Neukompilierung verursacht vorhanden.wurden.

In späteren Schnittstellen Versionen (API’s) von NAV zu SQL Server (in NAV ab dem SP1 für NAV 5.0) wurde aber auch das verändert. Dies Veränderung ist mit in die Veröffentlichung des SQL Servers 2008 eingeflossen und bezieht sich auf die Abfragealgorithmen welche hier “Optimize for unknown” heißt.

Diese Abfrage verändert das Verhalten der finsql.exe in der Art, dass nun keine Histogramme mehr verwendet werden und jeder Index einer Tabelle wird nun gleichwertig betrachtet und nicht mehr nur der erste Index. Das hat nun den Vorteil, das die Anzahl der Abfragen reduziert werden und somit die Performance des NAV SQL Clients sich steigert.

Für eine technische Erklärung der SQL Clients von NAV möchte ich Sie auf folgenden Blogeintrag meines Kollegen Lars Lohdorf Larsen hinweisen

Abschließend kann gesagt werden, das die Optimierung der Performance vom NAV Client immer weiter verbessert wird in neune Releases. Es gilt abzuwarten was in neuen Produktversionen diesbezüglich noch zu erwarten ist.

 

Herzliche Grüsse,

Peter Schimon Mosessohn

Specialist Support Engineer Microsoft Dynamics NAV

EMEA Customer Support & Services - SMS&P

Comments

• Anonymous
  February 26, 2010
  The comment has been removed
• Anonymous
  February 26, 2010
  The comment has been removed
• Anonymous
  February 28, 2010
  The comment has been removed