[Gelöst] Lange Ladezeiten für Tabelle languageTxt

Hallo Leute,

nach längerem Debugging bin ich nun auf das Problem gestoßen, dass der Ladevorgang einer Tabelle (LanguageTxt) enorm lange dauert. Dies könnte ich mir vorstellen, wenn die Tabelle enorm viele Einträge hätte, die Größe liegt aber lediglich bei ca 16.000 Datensätzen. Außerdem werden mit der verwendeten Abfrage nur wenige Datensätze (ca. 2-5) unter Verwendung eines speziellen Index ausgewählt.

Kennt jemand von euch ähnliche Probleme und hat sie idealerweise schon gelöst? Die Suchfunktion hat mir leider nichts dazu ausgespuckt.

Sollte es kein allgemeines Problem sein: Kann mir bitte jemand helfen, das Problem zu analysieren. Welche anderen Informationen braucht ihr?

aktuelle MS Dynamics Version: 4.0.2502.116.0
SQL-Server: 2005 9.0.4053

Danke und Grüße

joerg

Zuletzt geändert von Lysior am 5. März 2010 14:32, insgesamt 1-mal geändert.

Hallo Jörg,

Was meinst du den mit Ladevorgang?
Was genau ist enorm lange?
Kannst du das DAX SQL Statement posten?

LG
Christian

Hallo ChriD,

beim Absetzen des Statements:

Code:

 while select forupdate langTxt
    where langTxt.TxtTableId == 30031
        && langTxt.TxtRecId   == progRecID
        && langTxt.LanguageId == 'de'
        && langTxt.TxtType    == s4mlanguagetexttype::PressLong         {


erscheint in der Statusanzeige für mehrere Sekunden: Loading LanguageTxt(mnd). Und dies bei jedem Aufruf der Funktion.

Da die Funktion mehrere Datensätzen an mehrere Tagen aktualisiert, wird das zu nem ziemlichen Performance-Killer. Natürlich könnte ich versuchen, das komplette Update in ein update_recordset zu packen, das würde aber ziemlich kompliziert.

Habe noch nen Screenshot von der Struktur der Tabelle angehängt, da sie gegenüber (sys) verändert wurde.

Grüße

joerg

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Ok,

Sieht alles ja ganz in Ordnung aus. Normalerweise dürfte die Performance hier überhaupt kein Thema sein.
Hast du schon mal versucht die Statistiken der Tabelle neu zu berechnen?
Die Statistiken von Tabellen sind für die Performance sehr wichtig!

Es könnte auch sein das das System die Ganze Tabelle einliest da sie den Cache Lookup auf "Entire Table" hat. Wär mir aber neu das
dies zur Folge hat das bei nem forupdate die gesamte Tabelle neu geladen wird. (sollte ja nur fürs lesen ziehen)

Also ich würde mal die Statistiken für die Tabelle neu rechnen lassen (Macht man über die Datenbank. Einfach mal "Update table statistics" googln. Der Befehl ist je nach DB anders)
Falls dass nichts hilft mal probeweise den Cache Lookup umstellen auf "None" und nochmals schaun.

Anders kann ich mir das Problem net erklären (außer der DB Server is komplett unterdimensioniert)

lg

Danke erstmal für die Hinweise.

Die Statistics werden jede Nacht aktualisiert und auch ein Rebuild auf den Index hat nichts gebracht.

Wo wird der Cache Lookup eingestellt? Im SQL-Server oder in Dynamics? Und wo genau?

Der Cache Lookup wird im Dynamics AX bei den Tabelleneigenschaften umgestellt.
Tabelle im AOT anwählen -> Rechtsklick Eigenschaften -> ChachLookup
Das ist ein DropDown da kann man auswählen inwiweit AX die Tabelle cacht. Diese ist bei dieser Tabelle auf "EntireTable"
Das eventuell mal auf "None" zum testen. Bei "EntireTable" dürftenämlich beim ersten Select auf die Tabelle die gesamte Tabelle in den Cache gelesen werden.
Scheint so als ob das bei nem forupdate Select auch ist...
http://msdn.microsoft.com/en-us/library ... 10%29.aspx

Sollte das auch nicht helfen bitte mal den SQL Trace unter Extras->Optionen einschalten, Schwellenwert runter auf 100,
Speichern in Tabelle auswählen, dann das Statement ausführen was langsam ist und dann unter "Verwaltung->Abfragen->Datenbank->Traceprotokoll der ...."
anwählen. Dor sollte dann das Statement drinnen stehen und dort klannst du auch die Abfragepläne ansehen welche AX benutzt um die Daten auf der DB zu selektieren. Also z.B welchen Indizess es nimmt usw...

Wenn man da auch nichts raussieht bleibt als letzte Möglichkeit das ganze am SQL Server direkt zu tracen.

LG

Hi ChriD,

danke das hat schon mal enorm geholfen. Die Performance ist noch nicht grandios, aber das liegt dann an unserer Programmierung. Muss ich wohl nochmal ran

Danke und Grüße

joerg