SQL-Verhalten -> Native Verhalten

Hallo,

habe einen Report geschrieben, der Mandantenübergreifend Daten ändert. In der Testdatenbank (Nativ) dauert der Report gerade mal 3 -5 Min
Wird aber der Report in der SQL-Datenbank gestartet, dann dauert er nur bei einem Mandanten schon mehr als 20 Min und es kommen Meldungen
das "Ändere datensätze in Tabelle xy" Obwohl definitiv nur in einer Tabelle von mir Datensätze geändert werden.

Kann man so einen Report auf SQL optimieren? wenn ja, was ist zu tun?

Denn mein Report macht eigentlich etwas ganz einfaches..... (gucke in tabelle xy und schreibe den Wert von Feld 4711 in das Feld in Tabelle ab)

Hi!

Nun, dass sich "native" in Sachen "Performance" anders verhält als "SQL" ist soz. ein ganz natürliches Verhalten ...

Aber man kann da schon eine ganze Menge machen; allerdings gibt es auch viele Anforderungen und Voraussetungen die erfüllt sein müssen; zu Beispiel Hardware/Plattform, eingestzte Editionen/Versionen der Programme (NAV/SQL), SIFT vs. VSIFT, Query Hintings, Filter/Schlüssel/Indexe ... uvm. ...

Wenn Du das Forum nach "SQL Performance" durchsuchst, dann wirst Du haufenweise Tipps & Ratschläge zu dem Thema erhalten!

Unabhängig davon: Wenn Du die Report-Ausführung mal mittels SQL Profiler aufzeichnest, dann such' dort mal dach Operationen die lange dauern (Duration > 50 msec) und viel I/O erzeugen (Reads > 1000). Wenn Du solche Abfragen hier posten könntest, dann kann ich Dir ggf. ganz konkret Hilfestellung geben.

Dazu benötigen ich auch: NAV Version (Build No.!), SQL Version (Build No.) und grobe Hardware-Spezifikationen & Setup.

Gruß,
Jörg

Wir mussten den Report jetzt stoppen, weil er zu lange dauert.

Das einzige was mir noch einfällt dazu ist das es sich eigentlich nur um den Befehl Rename handeln kann, denn ich muss ein Feld
des Primary Key ändern, also nicht per Modify, sondern Rename

die Navision Version ist 5.01

Hallo Pegasus,

das mit dem Ändern des Primär-Schlüssels ist wahrscheinlich dein Problem. Standardmäßig wird der Primärschlüssel aus NAV als sog. Clustered Index auf dem SQL-Server angelegt. D.h. die Daten werden nach dem Primärschlüssel sortiert in der Datenbank abgelegt. Woraus folgt, das er bei jeder Schlüsseländerung die Daten neu sortiert. Ich würde jetzt versuchen einen zweiten Schlüssel auf die Tabelle zu legen, der nicht das geänderte Feld enthält, und diesen als Clustered zu definieren. Dann versucht SQL die Daten nicht jedesmal neu zu sortieren, sondern nur den Schlüssel.

Gruß, Fiddi

Rename würde ich vermeiden. Wenn möglich schreibe einen neuen Datensatz mit den neuen PK Feldern und lösch den alten Datensatz im Anschluss. Dann sollte es auch schneller gehen.

Rename würde ich vermeiden. Wenn möglich schreibe einen neuen Datensatz mit den neuen PK Feldern und lösch den alten Datensatz im Anschluss. Dann sollte es auch schneller gehen.

Wenn man diese „Abkürzung“ nimmt, muss man vorher aber immer prüfen , ob es nicht Felder in anderen Tabellen gibt, die eine Table Relation auf die PK Felder haben. Die werden dabei sonst nicht mitgeändert, was bei einem RENAME der Fall wäre.

Wie prüft man das? wo kann ich das sehen? denn wahrscheinlich sind es diese Tabellen die er dann versucht zu ändern

Rename würde ich vermeiden. Wenn möglich schreibe einen neuen Datensatz mit den neuen PK Feldern und lösch den alten Datensatz im Anschluss. Dann sollte es auch schneller gehen.

Wenn man diese „Abkürzung“ nimmt, muss man vorher aber immer prüfen , ob es nicht Felder in anderen Tabellen gibt, die eine Table Relation auf die PK Felder haben. Die werden dabei sonst nicht mitgeändert, was bei einem RENAME der Fall wäre.

Ups :X

Ich war jetzt ohne Nachdenken von einem Zusammengesetzten Schlüssel (mit FK auf andere Tabellen) und nicht von "Stammdaten" ausgegangen. Also bitte vorsicht mit meiner Lösung. Sorry...

Habe nochmal in der Tabelle "Feld" nachgesehen und zwar tablerelations gefunden, aber die waren unkritisch.
Zumal ich den Report jetzt in einer TestSQL ausprobiert habe und da lief er ohne Probleme

(mit der Lösung neuer Datensatz und alten löschen)

Danke für den Hinweis

Wie prüft man das? wo kann ich das sehen? denn wahrscheinlich sind es diese Tabellen die er dann versucht zu ändern

Mit dem Development Toolkit oder "zu Fuß" über Analyse des Programmcodes aller Tabellen nach einem Textexport ( nach TableRelation=[...]) suchen, wobei bei den Auslassungspunkten dann die Tabellenname steht, in der die PK Felder geändert werden sollen.

Außerdem kann es durchaus Felder geben, die keine eindeutige TableRelation haben, sondern eine bedingte, die noch von anderen Parametern abhängig ist. Das "Nr." Feld in der Verkaufs-/Einkaufszeile ist der beste Beispiel dafür. Wenn z.B. eine Artikelnr. auch als Sachkontonr. vorkommt, muss zusätzlich die Art der Zeile berücksichtigt werden. Mit dem RENAME ist man auch da abgesichert. Nur die Felder, bei denen beim Erstellen der Feldes die TableRelation vergessen wurde, werden davon nicht erwischt.

Beim mandantenübergreifenden Tabellen muss außerdem beachtet werden, dass wenn Tabelle A (mandantenübergreifend) ein Feld mit einer TableRelation zu Tabelle B hat, diese auch mandantenübergreifend sein sollte. Der native Server lässt das zwar durchgehen, der SQL-Server gibt aber eine Fehlermeldung aus, wenn man bei Datenbank/Ändern/Integration dann "Verbindungen aktualisieren" einschaltet.

Habe nochmal in der Tabelle "Feld" nachgesehen und zwar tablerelations gefunden, aber die waren unkritisch.

Das geht für die Table Relation sicherlich am schnellsten, aber da kann man nicht erkennen, welche Tabellen mandantenübergreifend sind.
Das SQL-Eigenschaft, dass mandantenübergreifende und mandantenspezifische Table Relations ggf. geprüft werden, betrifft auch normale Felder außerhalb des PK. Trotzdem kann es böse nach hinten losgehen, allzu viele Tabellen mandantenübergreifend zu schalten. Die Artikeltabelle z.B. wird bei jeder Lagerregulierung durch die Wertposten des Mandanten mit einem aktuellen durchschnittlichen Einstandspreis versorgt. Wenn die mandantenübergreifend geschaltet ist, bricht hier ein heilloses Chaos aus.

Mit dem RENAME ist man auch da abgesichert. Nur die Felder, bei denen beim Erstellen der Feldes die TableRelation vergessen wurde, werden davon nicht erwischt.

Aus aktuellem Anlass eine Warnung: Im Standard von 5.0 und 2009 wurden die TableRelations in den Artikel- und Wertposten für Felder "Job No." /Projektnr. und "Job Task No."/Projektaufgabenr. vergessen (KB961905)