[Gelöst]Key Optimierung

[Matt Kirby]

Hallo!

Ich bin gerade dabei eine Key Optimierung einiger Tabellen durchzuführen. Im Fokus habe ich besonders die Postentabellen. Im Moment arbeite ich gerade die Reihenfolge der Keys durch und versuche diese nach den vorhandenen Daten in eine sinnvolle Reihenfolge zu bringen.

Was kann ich noch tun um möglichst effektive Ergebnisse in kurzer Zeit zu erhalten? Ich habe dazu ein technisches NAV 2009 auf einer 4'er Objektbasis. Das Ganze läuft auf einen SQL 2005 Server. Leider sind alles Tools, die ich gefunden habe, nur bis NAV 5 und für NAV 6 nicht brauchbar.

Gruß

Matt Kirby

Zuletzt geändert von Matt Kirby am 25. Februar 2010 11:52, insgesamt 1-mal geändert.

Mit der Optimierung von Keys habe ich mich bis jetzt nicht beschäftigt, aber mehr RAM im SQL-Server wirkt manchmal Wunder und dürfte fast am schnellsten gehen.

Volker

Meine Empfehlung in aller Kürze :Lass dass sein !

Das Herumfrickeln and Keys und Indexen ohne vorher ein Problem erkannt und verstanden zu haben führt in 100% aller Fälle zur Verschlechterung der Performance ...

Eine ausführlichere Antwort findest Du hier: http://dynamicsuser.net/blogs/stryk/archive/2009/11/26/technical-airlift-2009-munich-nav-sql-performance-optimization-indexes.aspx

Und: brauchbare Tools gibt's schon http://www.stryk.info/toolbox.html

Vielen Dank für die Informationen.
Ich bin jetzt so vorgegangen: Ich habe mir einfach die Keys einiger wichtige Tabellen vorgenommen, wie z.B. Cust. Ledger Entries. Dort habe ich mir für den Anfang einmal die Reihenfolge der Felder in den Keys angeschaut und nach dem Eleminierungsprinzip einige Schlüssel von der Feldreihenfolge umgestellt.
Aus:

Code:

Document No.,Document Type,Customer No.

habe ich diesen Key erstellt:

Code:

Document No.,Customer No.,Document Type

Nach meiner Aufassung ist dieser Schlüssel besser, da es mehr Customer gibt wie Dokumententypen gibt.

Zur Umstellung der Keys habe ich das Unused Key Tool benutzt, welches mir anzeigt, welche Schlüssel nicht mehr benutzt werden. Es zeigt aber auch die Codestellen an, an denen die Schlüssel benutzt werden. Nun bin ich hingegangen und habe die Reihenfolge der Felder in den Keys geändert und gleichzeit habe ich die Codestellen geändert. Meistens wird mit SetCurrentKey gearbeitet und die Stellen lassen sich relativ leicht ändern, wenn man mit suchen und ersetzen dran geht, nachdem man die betroffenen Objekte als Textdateien ausgelesen hat.

Um die Optimierung zu überprüfen habe ich jeweils Trace-Dateien vom SQL Server und die Logs aus dem Performance Monitor von bestimmten Aktionen, wie z.B. Verkaufsrechnung buchen.

Leider stolper ich an manchen Stellen.
Ich habe hier aus Tabelle 21 den Key:

Code:

Customer No.,Open,Positive,Due Date,Currency Code

Diesen hätte ich gerne umgestellt nach:

Code:

Customer No.,Due Date,Open,Positive,Currency Code

An einigen Codestellen, steht allerdings sowas:
SETCURRENTKEY("Customer No.",Open,Positiv);

Ich weiss nicht recht, wie ich damit nun umgehen soll. Ich habe ja das "Due Date" nun an 2. Stelle. Dieses Feld taucht aber bei der SETCURRENTKEY-Funktion nicht auf.

Kann mir da jemand helfen?

Gruß
Matt

Hallo Matt,

ich kann mich hier nur der Meinung von Jörg anschließen: Finger weg von Optimierungsversuchen, wenn deine Kenntnisse in den entsprechenden Bereichen nicht ausreichen.

Das ist auf keinen Fall böse gemeint, aber deine Fragen suggerieren mir, dass dir noch wichtige Kenntnisse aus dem Bereich NAV/SQL fehlen. Beispielsweise die Frage nach dem SETCURRENTKEY(...): Wenn in dem Befehl nicht alle Felder eines Schlüssels angegeben werden, dann wird der erste passende Schlüssel auf den die angeforderten Felder passen zur Sortierung verwendet.

Insgesamt kann ich dir nur davon abraten, Performancetuning betreiben zu wollen, ohne konkrete Messergebnisse, Tests und vor allen Dingen Erfahrung als Basis zu haben. Das ist etwas, was man im allgemeinen als "Verschlimmbesserung" - gerne auch hin bis zum totalen Stillstand und Datenverlust - bezeichnet.

Notier dir über einen Zeitraum konkrete Punkte bei denen deiner Meinung nach die Performance nicht wie erwartet ist oder die dir auffallen. Mach gerne auch Traces und Logs dieser Probleme wenn möglich (du findest hier und in anderen Foren dutzende sinnvoller Beiträge dazu). Und lass dir dann für 2-3 Tage jemanden ins Haus kommen, der sich mit diesem Thema professionell auseinandersetzt und nimm die Informationen für dich mit. Danach kannst du zumindest die Bottlenecks genauer identifizieren und mit konkreteren Hinweisen und Fragen an die Experten herangehen um das Thema in einigen Jahren selbst ganz in die Hand zu nehmen.

Hallo Matt Kirby,

deine Änderung des Schlüssels bringt im zweifel nichts.
Wenn du dafür gesorgt hast, das deine Belegnummernserien sich nicht überlappen, d.h. man kann an der Belegnummer erkennen, das es ein Lieferschein oder ein Rechnung ist, dann ist die "Document No." schon so selektiv, dass die restlichen Felder des Schlüssels fast überflüssig sind. (Das mit den Nummernserien sollte man als wichtige Optimierungshilfe weitergeben , außerdem funktioniert Navigate sonst nicht vernünftig)

Ich kann mich meinen Vorrednern nur anschließen:
Wenn du nicht genau weißt was und warum du es tust, lass die Finger von der Schlüsseloptimierung.

Vor allen Dingen dann, wenn deine Datenbank noch nicht mit realen Daten und einem gewissen Stand an Buchungen hat. (Die CRONUS-DB ist keine Basis für Schlüsseloptimierungen, auch wenn bestimmte Firmen das anders sehen )
Außerdem sind Schlüsseloptimierungen abhängig vom Einsatz der NAV-DB. Jeder Anwender nutzt einen anderen Satz an Funktionen, die jeweils eine andere Basis an Tabellen und Schlüsseln erfordern, deshalb solltest du mit einer Schlüsseloptimierung erst beginnen, wenn es irgendwo hakt, und vor allen Dingen wenn genügend Daten im System sind, die eine Optimierung sinnvoll erscheinen lassen. Ob dann eine Optimierung oder die Definition z.B. eines Views besser ist muss man im konkreten Fall entscheiden.

Deshalb folge besser SilverX's Empfehlung: Lass das System erst mal laufen, notiere dir wo es klemmt, und wenn du genügend Punkte gesammelt hast. Hol dir jemanden, der in dem Bereich Lesen und Schreiben kann. (Auch hier im Forum sind einige Leute aktiv, die sich damit auskennen und so etwas professionell machen )

Gruß, Fiddi

Ja, ja! Ich habe es trotz aller Kritik selbst versucht. Eine Optimierung der Cust. Ledger Entry Tabelle durch umstellen der Reihenfolge der Key-Felder brachte nach der Analyse mit SQL-Profiler.... nichts! Dazu war es noch sau viel arbeit bis man alle Codestellen entsprechend umgestellt hat.

Also bin ich jetzt dazu übergegangen gezielt nach Problemen zu suchen. Ich habe ein SQL-Server Profile beim Buchen von Einkaufsbestellungen erstellt. Im Log sind mir gleich Stellen aufgefallen, die sehr hohe Werte haben. An der Stelle wird ein INSERT in die Value Entry Tabelle gemacht. Die Werte:
Reads: 18005
Writes: 111
Duration: 189010
CPU: 47

Das Insert-Statement kommt im Log ziemlich häufig mit ähnlich hohen Werten vor.

Der Execution Plan zeigte keine Auffälligkeiten. Ich habe das Insert-Statement genommen und im SQL Server Management Studio laufen gelassen. Komischerweise habe ich dort dann diese Werte bekommen:
Reads: 308
Writes: 18
Duration: 119006
CPU: 93

Wodurch entstehen diese krassen Unterschiede? Und wie kann ich die Optimierungsmöglichkeiten der Tabelle Value Entry prüfen? Im Ausführungsplan gibt es keine Index Seek oder Scan.

Ja, ja! Ich habe es trotz aller Kritik selbst versucht. ... Ich habe das Insert-Statement genommen und im SQL Server Management Studio laufen gelassen.

Oh, oh .. Ich hoffe mal sehr, dass Du das auf einer Testbüchse gemacht hast ... Daten via Management Studio anlegen - und noch dazu Wertposten - kann mal ganz schnell die Datenbank schrotten; soll heißen: die logische Integrität in NAV geht verloren ...

Außerdem hört sich das schon seltsam an, da ein INSERT immer gleich abläuft (mehr oder weniger). Beim INSERT gibt's keine "Index Seeks" oder "Index Scans" sondern nur "Clustered Index Inserts" ...

Schreibende Transaktionen kann man kaum durch Index-Optimierung verbessern; das Schreiben wird nur dann schneller wenn die Anzahl von SIFT/VSIFT und Indexen verringert wird - auch das Bedarf einer eingehenden Analyse, andernfalls wird der Schuss ebenfalls nach hinten losgehen ...

Ich empfehle Dir dringend dich nur auf die SELECTs zu konzentrieren, wenn Du schon selber herumbasteln möchtest ... Besser wäre es wohl, wenn Du Dir kompetenten Beistand suchst

Na, sicher habe ich eine Testdatenbank. Soooo naiv bin ich nun auch wieder nicht
Dachte ich mir, dass sich das seltsam anhört. Deswegen habe ich es hier gepostet

Deine Aussage helfen mir ja schon etwas weiter. Dann kann ich meinen Fokus auf etwas anderem richten.
Vielleicht besuche ich mal einen Kurs bei Dir....

Na, sicher habe ich eine Testdatenbank. Soooo naiv bin ich nun auch wieder nicht

Du vielleicht nicht, aber man kann sich ja nie wirklich sicher sein...

Also was die Vorgehensweise (?) zum "Troubleshooting" angeht, so versuche ich (für den nächsten "Field Guide" ) das Ganze vereinfacht als PAP darzustellen - siehe Anhang. Vielleicht hilft's was?!

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

Vielen Dank an alle, die mir so bereitwillig geantwortet haben. Ich habe mittlerweile einiges lernen können und werde die Erfahrungen gut in neue Projekte einsetzen können.

Stryk: Dein Buch habe ich vor mir liegen. Es ist wirklich sehr informativ. Ich hoffe, wir werden noch einiges von Dir lesen können.

Das Thema werde ich jetzt erstmal als gelöst markieren. Nochmals vielen Dank. Vielleicht sieht man sich ja auf dem CT in Hamburg