[Gelöst] HILFE! Ernste Probleme nach Upgrade 3.70 -> 5.00

Wir sind alle nicht so wirklich glücklich über unser NAVISION 5.00.

Auf gesetzte Filter antwortet Navision sehr langsam, trotz richtig gewählter Sortierung. Manchmal vergehen fast 10 Sekunden bis sich eine Form öffnet. Nicht nachvollziehbare Tabellensperren machen manchmal das Arbeiten unmöglich und verlangen einen Neustart der Server-Dienste.
Die Plattenzugriffe schlagen bei 100% an, wärend die Prozessoren sich langweilen. Wir haben ca. 70 Curr. User. Hardware vom Allerfeinsten.

Für uns ist das sehr rätselhaft. Bin mittelweile für jeden Tipp dankbar.
Hat jemand ähnliche Erfahrungen gemacht? Denke mit Schrecken an die nächsten Tage, wenn ich keine Lösung finde.

Unser NAVISION-Partner hat keinen Plan mit SQL-Server 2005

Zuletzt geändert von dreimal_m am 8. Mai 2008 14:10, insgesamt 1-mal geändert.

Hallo Martin,

hab mal ein paar Fragen.

Welches Raid-Level wird verwendet? Wie sind die Datenbankdatein und das Transaktionprotokoll der Navision-Datenbank verteilt? Wo liegen die System-Datenbanken Master, Model, MSDB und Temp?

Sind die Performace-Probleme immer bei den gleichen Aktionen spürbar oder entstehen diese Performance-Probleme grunsätzlich überall und immer? Nutzt ihr ausschließlich den Navision-Standard oder habt ihr eine Brachen-/Speziallösung? Sind viele Individualprogrammierungen vorhanden?

Gruß, Marc

Guten Morgen Martin,

aus deinen Angaben entnehme ich, dass NAV 3.70 problemlos oder zumindest wesentlich flüssiger lief. Ich gehe auch davon aus, dass es sich um ein technisches Update handelt.

Dazu einige Fragen:

Welche Änderungen außer dem Update auf 5.00 habt ihr durchgeführt? Z.B. native -> SQL2005 oder SQL2000 -> 2005?

Welches Build von NAV 5.00 läuft bei euch?

Welches Build des SQL Server 2005 läuft bei euch (SP2, CU5/6)?

Waren die Probleme direkt nach dem Update festzustellen oder erst im späteren Verlauf?

Und nun die Fragen von Marc :P

Raid-Level 1, SQL-Build 9.0.3054, NAVSISION 5.0 (5.0). Echtes Update, nicht nur rein technisch.
Alle Datenbankdateien, Transaktionsprotokolle sind auf der gleichen Maschine.
Die Probleme ziehen sich durch die gesamte Anwendung. Extrem bei Filtern. Wechseln von Sortierungen.
Anteil an Individualprogrammierung im Verhältnis zum Standard ca. 15%.
Performanceprobleme bestehen von Beginn an, nach Umstellung auf die 5.0.

SQL-Build 9.0.3054

Da müsste noch SP2 und CU6 für SP2 installiert werden.

Wie sieht die Plattenaufteilung aus? Alles auf der selben Platte oder min. 3x RAID (z.B. 1x RAID1 für das OS, 1x RAID10 für SQL-Daten, 1x RAID1 für SQL-LOG)

Hallo!

Puuh ... wo anfangen ...

1. Die SQL Server Version ist irgendaws "post SP2" - die Version hat noch einige Bugs, ein Update auf mindestens 3200 (aktuell 3232) ist empfohlen (http://support.microsoft.com/kb/937137/)

1.b. Platform Konfiguration: Max. Degree of Parallelism = 1, bei 32bit auf korrekte RAM addressierung achten!

2. NAV 5.0 funktioniert erst mit SP1 richtig mit SQL Server 2005. Ohne SP1 ist NAV deutlich langsamer (alleine die Zugriffe auf die "Links" drücken die Performance um 10%) und instabiler
(NAV Versions: http://dynamicsuser.net/blogs/waldo/archive/2008/01/17/platform-updates-overview-3-70-b-5-0-update-1-1.aspx)

3. Die DB-Dateien und TLogs müssen korrekt auf den verschiedenen HDD Volumes verteilt werden!

4. "Index Hinting" muss deaktiviert werden:

Code:

CREATE TABLE [$ndo$dbconfig] (config VARCHAR(1024))
GRANT SELECT ON [$ndo$dbconfig] TO [public]
GO
INSERT INTO [$ndo$dbconfig] VALUES ('IndexHint=No')

5.-X. DB Maintenance, Index Tuning, SIFT Tuning (vor SP1), C/AL Code Optimierung (Cursorsteuerung mit FINDSET, etc.) uvm.

Gruß,
Jörg

Vielen Dank erstmal für die bisherige Unterstützung. Als kleiner Zwischenbericht erstmal nur soviel, dass das Problem immer noch besteht.
Wir werden Mitte Mai Spezialisten im Hause haben. Sobald unser Problem gelöst ist, werde ich an dieser Stelle berichten.

Es verstärkt sich wohl immer mehr der Verdacht, dass wir das SP1 für NAV 5.0 einspielen müssen.
Wo kann ich mir das direkt Downloaden?

Wenn ich richtig gesehen habe, dann gibt es hier noch keinen Download für die DE 5.00 SP1. Das einfachste wäre, euren Partner zu bitten, euch eine CD/DVD zukommen zu lassen oder einen Download anzubieten. Oder "jemand" (hint ) stellt es hier in den Downloadbereich.

Insgesamt ist es sicherlich richtig, dass das SP1 noch eine Menge Potential hat im Bereich Performance hat. Grundsätzlich also die richtige Entscheidung.

Kannst du aber vielleicht nochmal kurz erläutern, welche von den hier gemachten Vorschlägen ihr bereits umgesetzt habt und wie euer Stand bezüglich Service Packs und Hotfixes auf SQL ist? Vielleicht kann man das Eine oder Andere noch im Vorfeld hier über das Forum klären.

Ich wäre auch bereit eine kurze Telefonsession zu machen, da solche Probleme über einen längeren Zeitraum wie bei euch einem an die Substanz gehen können (eigene Erfahrung).

Nur soviel vorab: Wir haben unserem NAV-Partner nun die aktuellen Objekte übermittelt, da er uns bestätigte, dass beim Umstellen von SQL2000 auf SQL2005 etliches zu bedenken und umzustellen sei und man deshalb ein Team aus Spezialisten gebildet habe, die nichts anders tun.

SQL-technisch gesehen sei, lt. Aussage meines Kollegen aus der IT, alles auf dem neuesten Stand.
Mein Job ist schließlich nur die Betreuung von NAV, wenn es technisch wird, mutiere ich zum Anwender.
Dass das mir an die Substanz geht, kann ich allerdings bestätigen, da es heute besonders schlimm war und nur ein Neustart des Servers Abhilfe schaffte.
Sobald es Neues gibt, berichte ich.

Hallo Martin,

das hört sich für mich alles sehr abenteuerlich an... Dazu fällt mir das tote Pferd ein

Auch der Status eures Systems ist mir nicht mehr ganz klar, da ihr nach einem technischen und Objektupdate (denke aber mal es handelt sich nur um ein technisches Update) eigentlich nicht plötzlich alle Objekte anfassen müsst, damit das System wieder so läuft wie unter SQL 2000 / NAV 3.70.

Sicherlich gibt es Laufzeitunterschiede der verschiedenen Versionen, aber so schlimm kann der Unterschied nicht sein, ohne dass es auf SQL Seite essentielle Unterschiede zum vorherigen System gibt.

Ich kann nur mein Angebot wiederholen.

Wir haben ein komplettes Update von Attain 3.70B auf Microsoft Dynamics NAV 5.0 durchgeführt und im Zuge der Umstellung auch gleich vom SQL-Server 2000 auf den SQL-Server 2005 umgestellt.

Hi!

Nun, "Spezialisten" gibt's ja so einige deshalb würde es mich sehr interssieren, was dieser so für Erkenntnisse gewinnt ...

Wie schon in einem vorherigen Posting gesagt: NAV 5.0 hat erhebliche Schwächen im Umgang mit SQL Server - Wenn NAV 5.0, dann muss es wohl SP1 (Update xy) sein ...

Und: wie Carsten schon gesagt hat, es wäre interessant zu wissen, welche Maßnahmen denn schon - erfolglos? - implementiert wurden ...

Hi Martin,

ok, damit ist der Punkt Objektupdate/technisches Update endgültig geklärt. Dann bin ich wirklich gespannt, was die "Task Force" an den 5.00 Objekten noch so alles anstellt, damit die euch den Performanceschub bringen.

Mir fällt jetzt auf Anhieb mal nur die eine oder andere Ecke in den NAV 5.00 Objekten ein ein wo man ein wenig drehen kann. Aber Objekte loszuschicken und dann was zurück zu bekommen was die Probleme löst, obendrein noch von SQL (2000) nach SQL (2005), klingt für mich ehrlich etwas nach Abenteuerspielplatz...

Hallo Freunde, es gibt Positives zu berichten.
In der Keydefinition der Tabellen exitiert ein Feld "SQL-Index". Hier war bei keiner Tabelle ein Wert eingetragen.
Nachdem wir die Keys aus dem Feld "Key" in das Feld "SQL-Index" kopiert hatten, hat sich die Antwortzeit blitzartig verbessert.
Abfragen, wie die "Verkaufshistorie", die vorher überhaupt kein Ergebnis lieferten, laufen nun im Extremfall in 2 Sekunden ab, bei wiederholtem Aufruf sogar ohne zeitliche Verzögerung (Cache).
Hat hier unser Systemhaus geschlampert?

Im 5er Standard sind für einige Tabellen explizite SQL Indizes definiert. Für 5.00 SP1 wurde das wieder rückgängig gemacht, da man festgestellt hat, dass u.a. beim Umsortieren der Daten im Speicher der Performancegewinn wieder zunichte gemacht werden kann. Das mal so als Info nebenbei.

Normalerweise wird auf dem SQL Server der entsprechende NAV Index erzeugt und für Abfragen herangezogen, sofern kein expliziter SQL Index angegeben ist. Und (mit obiger Tabelle von Jörg (IndexHint=No)) wird erreicht, dass nicht die vorgegebenen Indizes der Business Logik (SETCURRENTKEY) sodern die vom SQL Server ermittelten verwendet werden.

Aber ein reiner fehlender SQLIndex wird das von dir beschriebene inperformante Verhalten meiner Meinung nach nicht hervorrufen. Es sei denn nebenbei (wie auch immer das zustande kommt) ist auch der Haken MaintainSQLIndex nicht gesetzt. Damit würde sich das Verhalten allerdings mehr als erklären.

Kannst du was zu der Schlüsseldefinition (besonders die Hakenfelder) vor und nach der Änderung sagen? Vielleicht die Schlüsseldefinition als Textexport für vorher und nachher? Dann kann man sicher noch mehr sagen.

Interessant wäre auch zu wissen, ob die von Jörg erwähnte Tabelle (CREATE TABLE) existiert und gefüllt ist und welche Build Nummer der SQL Server nun hat. Dann kann ich (und natürlich auch Andere) ggf. noch weitere Möglichkeiten für Performancesteigerung aufzeigen.

Nun, was durch das Kopieren von "Key" nach "SQL Index" passiert - empfehle ich übrigens immer zu tun! - ist folgendes:

Der Non-Clustered Index wird nicht mehr als UNIQUE aufgebaut (= weniger Rechenarbeit für SQL Server) und überflüssige Primärschlüsselfelder werden nicht mehr angefügt (= Index wird z.T. erheblich kleiner, Schreib-/Lese-Leistung kann deutlich verbessert werden).

Jetzt das Ganze noch Ent-SIFT-en (vor 5.00 SP1), die richtigen Clustered Indexes auf bestimmte Tabellen und 80% der Optimierung sind durch!

Dann geht's weiter mit den etwas schwierigeren Patienten, d.h. Indizierung, Index- oder Recompile-Hints (Plan Guides?) und zum Schluss geht's dem C/AL Code an den Kragen ...

Nun, was durch das Kopieren von "Key" nach "SQL Index" passiert - empfehle ich übrigens immer zu tun! - ist folgendes:

Gut, schon. Aber das kann ja nicht wirklich das Problem gewesen sein!? Oder hab ich etwas übersehen?

Mich interessiert wirklich was das eigentliche Problem war, um mein Wissen zu erweitern

Kommt darauf an wie viel Müll man damit los geworden ist ...

Durch setzten von "SQL Index" werden die NCI ja auch neu aufgebaut - sprich defragmentiert, Füllfaktoren wieder hergestellt werden, etc. - ich denke, dass diese "Maintenance" erheblich zum Erfolg beigetragen hat ...

Statusbericht:
Nachdem wir gestern Abend in unserem Echtsystem bei allen Tabellen > 500 Datensätzen die SQL-Indexe eingetragen haben, läuft unser NAV 5.0 zur vollsten Zufriedenheit aller 70 Sessions.
CPU-Last ca. 2 - 5%, Platten ca. 60 - 74%, kleine Ausreisser gehen kurzzeitig an die 100%, Speicherauslastung ca. 1,6 GB.
Sollten wir von unserem frischgebackenen NAVISION-Partner etwas hören, werde ich berichten.
Nochmals vielen Dank für die Mitwirkung und das Engagement an alle an diesem Thread beteiligten Forumskollegen.