native Datenbank beschleunigen

[NAV5.0]

Hallo zusammen,

unsere native Datenbank ist leider in Stapelbuchungsvorgängen, im speziellen "liefern und fakturieren" von Verkaufsaufträgen, sehr langsam geworden. Teilweise um die 20-30 Minuten (früher sogar 45 Minuten) Dauer.

Da ich in dem Bereich neu bin, habe ich versucht mit Hilfe des Forums eine Lösung zu finden. Unsere Datenbank lag bereits bei 92 % Auslastung. Also habe ich diese von 40 GB auf 56 GB erweitert.
Daraufhin lief es auch wieder 3-4 Tage richtig schnell (5-15 Minuten), doch dann ist es plötzlich wieder langsam geworden, obwohl ich nichts weiter geändert habe. Die Anzahl der Aufträge hat sich währenddessen auch nicht geändert, sondern lag im durchschnittlichen Bereich. Leider ist ein Umstieg auf SQL und damit auf ein neueres NAV vorerst nicht geplant. An der Serverhardware wurde auch nichts geändert und auch nicht an den Netzwerkeinstellungen am Server. Außerdem hat sich seit der Erweiterung die tägliche Sicherung von 15 Minuten Dauer auf teilweise über 1 Stunde verlängert :(

Die DB wurde vor meiner Zeit auf 4 Dateien gesplittet, welche alle auf der selben Partition liegen...
800.000 DBMS Cache
Commit Cache ist an
Object Cache = 32.000

Könnt ihr mir vielleicht weiterhelfen, damit sich die Stapelvorgänge wieder auf 5-15 Minuten Dauer verkürzen?

[Kowa]

Herzlich Willkommen im Forum!

Die DB wurde vor meiner Zeit auf 4 Dateien gesplittet, welche alle auf der selben Partition liegen...

Die Datenbankteile gehören auf verschiedene Platten, damit sich die Transaktionsdaten schnell wegschreiben lassen, nicht auf eine Platte.
Was für Serverhardware wird denn überhaupt eingesetzt? Welcher Plattentyp (SSD-Platten?), welches RAID-System, und wieviele User arbeiten parallel im System?

[fiddi]

Hallo,

der Servercache sollte auch auf ca 1GB erhöht werden.

Eine Sache die vorübergehend hilft, ist das optimieren der Tabellen. Das macht die Datenbank vorübergehend kleiner (es wird weniger Platz in der DB-Datei benötigt) und effizienter. Aber über kurz oder lang wirst du um den SQL-Server nicht herum kommen.
Und bei Thema SSDs ist in unserem Bereich zu beachten, das diese Platten i.d.R. nur eine begrenzte Menge an Schreibzugriffen erlauben, d.h. wenn eine bestimmte Anzahl Terrabytes auf die Platte geschrieben wurden ist Schluss. Das können bei einer einfachen 1TB SSD schon mal nur 120 TBW (Terra Byte Written) sein, bei einer servertauglichen Platte aber auch 14000 TBW. Der Preisunterschied zwischen beiden ist in etwa Faktor 10-15.Für jemanden der nur seine Fotos einmal auf die Platte schreibt um Sie dann nur zu lesen ist das kein Problem, für einen Datenbankserver ist das aber schon eine wichtige Sache, da hier wesentlich häufiger auf die Platte geschrieben wird. Auch wer die Datensicherung seines Servers auf SSD machen möchte, sollte sich damit auseinander setzen.

Um die Performance des Servers zu erhöhen, sollten die DB- Teile jeweils auf eigenen Platten liegen, wobei man sich heute darüber streiten kann, ob es noch Sinn macht das zu tun.
Vielmehr bringt bei euren Schreibtransaktionen ein Cache- RAID- Controller mit eingeschaltetem Write- Cache mehr. (Der Write- Cache erfordert allerdings geeignete Hardware (BBU,USV), damit bei einem Stromausfall die DB- nicht zerstört wird).
Und die DB sollte nicht auf eine RAID 5 liegen, da dieses bei Schreibtransaktionen langsamer ist. Besser ist hier ein RAID1 oder RAID10.

Aber wie gesagt, auf Dauer wirst du um den SQL-Server nicht herum kommen, da er wesentlich besser die heutige Hardware (CPU-Kerne, Arbeitsspeicher) ausnutzen kann.

Gruß Fiddi

[winfy]

Hallo zusammen,

unsere native Datenbank ist leider in Stapelbuchungsvorgängen, im speziellen "liefern und fakturieren" von Verkaufsaufträgen, sehr langsam geworden. Teilweise um die 20-30 Minuten (früher sogar 45 Minuten) Dauer.

Da ich in dem Bereich neu bin, habe ich versucht mit Hilfe des Forums eine Lösung zu finden. Unsere Datenbank lag bereits bei 92 % Auslastung. Also habe ich diese von 40 GB auf 56 GB erweitert.

Wieviele Aufträge verbucht er denn in deinen angegebenen 30 Minuten? Wieviele User sind gleichzeitig auf der DB? RAID10 ?

Hast du beim Erweitern einfach nur Datei->Datenbank->Erweitern gemacht?
Das ist bei mehreren Parts nicht so günstig.

Besser: Datei->Datenbank->Erweitern->Erweitert dann für die jeweiligen Parts gleichmäßig die Parts im Feld "Erweitern (KB)" erhöhen.
Standardmäßig schlägt bei der obigen Variante NAV nur dem letzten Part die Erweiterung zu. (Kannst du jetzt leider nicht mehr so einfach rückgängig machen, es sei denn du hast Zeit und baust die Datenbank neu auf und importierst alle Mandanten mit dem zeitaufwendigen Schlüsselaufbau.)

Zum Thema SSD Platten kann ich mich meinen Vorrednern nur anschließen, das bringt Performance vor allem bei deinen Schreibzugriffen und sollte bei modernen Server SSD Platten auch mit den begrenzten Schreibaktionen für Jahrzehnte kein Problem sein.

Und ganz wichtig deinen DBMS Cache auf 1GB erhöhen (mehr geht nicht)!

mfg,
winfy

[Kowa]

Eine Sache die vorübergehend hilft, ist das optimieren der Tabellen. Das macht die Datenbank vorübergehend kleiner (es wird weniger Platz in der DB-Datei benötigt) und effizienter.

Kleiner sicherlich, aber von der Performance eher weniger effizienter wenn die DB auf mehrere Platten verteilt wurde. So wie Timo das hier in einem ähnlichen Performancefall erläutert hat die alte Navisioncrew das immer kommuniziert.

Außerdem - wie im anderen Thread erwähnt - könnte auch ein neuer Virenscanner die Datenbank behindern.

[fiddi]

Hallo,

Kleiner sicherlich, aber von der Performance eher weniger effizienter wenn die DB auf mehrere Platten verteilt wurde. So wie Timo das hier in einem ähnlichen Performancefall erläutert hat die alte Navisioncrew das immer kommuniziert.

Das ist eher nur theoretisch richtig, wenn die platte kontinuierlich lesen kann, geht das in der Regel auch schneller, als wenn sich das System die Daten von mehreren Platten zusammen suchen muss. Und optimal gefüllte Schlüsselpages erzeugen weniger Zugriffe auf die Platte, was per Definition schon mal schneller ist.

Ob und wann das etwas bringt oder nicht, muss man im konkreten Fall mit der vorhandenen Hardware klären.

Zum Thema SSD ist kein Problem. Meine SSD in meinem Entwicklungsrechner hat in den 3 Wochen, in der Sie in Betrieb ist bereits 1TB durch, da ich nicht sehr viel buche, dürfte das in einem realen System sehr viel mehr sein.

Gruß Fiddi

[Kowa]

Das ist eher nur theoretisch richtig, wenn die platte kontinuierlich lesen kann, geht das in der Regel auch schneller, als wenn sich das System die Daten von mehreren Platten zusammen suchen muss.

Ich habe da damit auch praktische Erfahrungen, weil ich das aus Platzgründen in einer Zeit, als eine Navision-DB maximal 32 GB groß werden konnte (das war bei 2.01 noch so ) notgedrungen alle paar Tage machen musste, weil die sonst ganz zugelaufen wäre. Damals wurde die Leseperformance etwas besser, aber die Schreibperformance schlechter, und innerhalb von kürzester Zeit war sowieso wieder alles beim alten.

Es mag sein, das SSD-Platten heute da anders reagieren würden, aber diesen Optimierungsbutton sollte man m.E. eher gedanklich ganz ausblenden.

[fiddi]

Hallo,

Damals wurde die Leseperformance etwas besser, aber die Schreibperformance schlechter, und innerhalb von kürzester Zeit war sowieso wieder alles beim alten.

Das ist auch heute, und auch beim SQL-Server so.
Da die Schlüssel hier optimiert werden, sind die Schlüsselpages optimal gefüllt. Müssen jetzt mehrere Datensätze eingefügt werden, müssen u.U. neue Schlüsselpages eingefügt und der Schlüsselbaum reorganisiert werden. Das dauert etwas länger als bei nur teilweise gefüllten Schlüsseln, wo man häufiger noch Platz findet. Die Leseperformance steigt dagegen, weil weniger Schlüsselpages zum suchen nach einem Datensatz benötigt werden.

aber diesen Optimierungsbutton sollte man m.E. eher gedanklich ganz ausblenden.

Da bin ich nicht ganz deiner Meinung.
Wer hofft damit auf Dauer eine bessere Performance zu erreichen, der hofft da sicherlich vergebens.
Wer aber kurzfristig eine Besserung erreichen möchte (weil z.B. die Inventur ansteht, und man die Posten bzw. das Inventur- Buchblatt berechnen beschleunigen möchte), da bringt das schon etwas.

Gruß Fiddi

[NAV5.0]

Besten Dank für die zahlreichen Antworten! :)

Zum Thema Hardware kann ich später genaueres sagen. Es ist aber kein alter Server (ca. 3 Jahre).

Folgendens kann ich schon einmal zusammenfassen:
- keine SSD's vorhanden
- es arbeiten parallel 19 User im System --> während Stapelbuchungen verlangsamen sich auch die Reports und Stapelbuchungen bei anderen Usern enorm
- die Anzahl der Aufträge schwankt zwischen 180-max. 350 Aufträgen, je Stapelbuchung

Tabellen optimieren habe ich im Testsystem ausprobiert und würde lieber die Finger davon lassen. Zumindest ist es dort abgeschmiert und hier im Forum habe ich auch schon öfters gelesen das dies maximal kurzfristig etwas bringt.

Aber das mit dem verteilen auf mehrere physische Pletten und entsprechende Partitionen habe ich auch schon einmal gelesen, wie schätzt ihr hier den Geschwindigkeitesvorteil ein, wenn ich zum Beispiel die 4 Teile auf zwei Platten (jwl. 2 Teile) verteile?
SSD's wären sicherlich eine interessante Überlegung, insbesondere da aktuelle auch resistenter sind als vor paar Jahren. Da sind dann die Kosten eine Frage...

@winfy:
Ich habe alle Teile gleichmäßig erweitert. Dazu gab es im Forum eine gute Anleitung, so wie du es beschreibst.
Wenn ich den DBMS Cache erhöhe, läuft dann evtl. die Sicherung wieder besser? Kann der DBMS Cache im laufenden Betrieb erhöht werden?

[winfy]

Ich habe alle Teile gleichmäßig erweitert. Dazu gab es im Forum eine gute Anleitung, so wie du es beschreibst.
Wenn ich den DBMS Cache erhöhe, läuft dann evtl. die Sicherung wieder besser? Kann der DBMS Cache im laufenden Betrieb erhöht werden?

Ich würde den Dienst deinstallieren und dann mit den neuen Einstellungen installieren.
Im laufenden Betrieb geht es jedenfalls nicht.

Für 180-350 Aufträge 20-30 Minuten ist echt hart.
Das ist ja ein Auftrag in 5 Sek? Wieviele Zeilen habt ihr in einem Auftrag?

Bei uns waren das damals auf SSD knapp 400 Auftrage pro Minute. Ein Auftrag hatte im Schnitt 5 Zeilen.

Gruß,
winfy

[fiddi]

Hallo,

Wenn ich den DBMS Cache erhöhe, läuft dann evtl. die Sicherung wieder besser?

Nicht wirklich, und was meinst du damit?

Kann der DBMS Cache im laufenden Betrieb erhöht werden?

Nein.

die Anzahl der Aufträge schwankt zwischen 180-max. 350 Aufträgen, je Stapelbuchung

Bei dem Volumen solltest du dir sehr zügig Gedanken über ein Update auf =>NAV2015 machen, da du sonst noch mehr Probleme bekommen wirst (Max. DB- Größe, Daten(rück)sicherung,...) die native ist hier irgendwann am Ende. Und so ein Update benötigt Vorlauf.
Warum empfehle ich das: Wenn du die deine ganzen Buchungen mal als Akten vorstellst, dann hast du, seitdem Ihr angefangen habt, immer mehr Akten erstellt. Diese Akten kann der Rechner am Anfang Speicher- Aktenschrank (Cache) verwalten, es sind ja noch nicht so viele. Wenn es jetzt aber mehr werden, dann muss er immer öfter ins Archiv (Festplatte) nach den den Daten suchen. Bei der Native-DB ist es soviel ich weiß nur ein Mitarbeiter (CPU-Kern) der einen recht kleinen Aktenschrank (1GB Cache) am Platz hat, bevor er ins Archiv rennen muss. Da ihr immer mehr Daten produziert wird diese Missverhältnis zwischen Daten im Cache und auf der Platte immer größer werden.
Der SQL-Server ist hier wesentlich besser skalierbar. Er kann alle CPU-Kerne und den größten Teil des vorhandenen Arbeitsspeichers nutzen, bevor er auf die Platten zugreifen muss. Das könnte man mit NAV 5.0 und SQL- Client evtl. auch noch hinbekommen. Die wesentlich bessere Optimierung von NAV2015 auf den SQL- Server bringt hier noch bessere Ergebnisse.



Ein wichtiges Performance- Problem hat der CC außerdem noch (egal ob SQL oder Native): Der Datenbankserver ist ein reines Datengrab. Alle zu bearbeitenden Daten müssen über das Netzwerk zum Client und wieder zurück übertragen werden. Deshalb ist das Stapelbuchen direkt auf dem Server gestartet u.U. erheblich schneller als von einem mit 100 MBit/s- Netzwerk angeschlossenen Arbeitsplatz.

Gruß Fiddi

[Kowa]

wenn ich zum Beispiel die 4 Teile auf zwei Platten (jwl. 2 Teile) verteile?

Wenn dann 2 Teile auf 2 Platten, aber 3-4 Platten wären grundsätzlich schon angebrachter.
Ein Datenbankteil kann maximal 130,922,000 bytes, also 130 GB groß sein. Es bringt nichts, diese auf einer Platte mit einem Schreib-/Lesekopf noch zu unterteilen.
Maximum Database Size for a Microsoft Dynamics NAV Native Database
Die Aufteilung ergibt nur aus historischer Sicht einen Sinn, da ging es nicht anders. Bis 2.01 waren es nur max. 2 GB pro Datenbankteil (maximal 16 Teile x 2 = 32 GB).

[m_schneider]

Hast du schon mal mit dem Clientmonitor geschaut, ob irgendwelche Funktionen besonders lange brauchen oder sehr häufig angetriggert werden. Ich hatte mal ein Problem mit einem Workflowmodul und dem Drucken eines Berichtes. Da wurde eine Tabelle mit zig tausend Datensätzen ständig aufgerufen und durchlaufen.

[NAV5.0]

Danke für die zahlreichen Antworten. Ich melde mich jetzt erst zurück, da wir viele Projekte laufen haben, hoffe ihr seid mir nicht sauer :)

Ich habe alle Teile gleichmäßig erweitert. Dazu gab es im Forum eine gute Anleitung, so wie du es beschreibst.
Wenn ich den DBMS Cache erhöhe, läuft dann evtl. die Sicherung wieder besser? Kann der DBMS Cache im laufenden Betrieb erhöht werden?

Ich würde den Dienst deinstallieren und dann mit den neuen Einstellungen installieren.
Im laufenden Betrieb geht es jedenfalls nicht.

Für 180-350 Aufträge 20-30 Minuten ist echt hart.
Das ist ja ein Auftrag in 5 Sek? Wieviele Zeilen habt ihr in einem Auftrag?

Bei uns waren das damals auf SSD knapp 400 Auftrage pro Minute. Ein Auftrag hatte im Schnitt 5 Zeilen.

Gruß,
winfy

Also im Durchschnitt hat bei uns jeder Auftrag 20 Zeilen. Heute hat es wieder 45 Minuten gedauert, währenddessen war ich aber auch eine Auswertung am erstellen.

@ fiddi
Ich meine die tägliche Sicherung unserer Datenbank aus Navision heraus. Diese dauert gelegentlich mehr als eine Stunde.
Leider ist bei uns kein Update auf eine höhere Navision Version geplant. SQL wäre sicher eine gute Alternative, allerdings haben unsere Navision Berater gesagt, dass dies auch nur mit einem neueren Navision möglich ist. Oder kann man einen Umzug der Daten bei NAV 5.0 SP1 auf SQL durchführen?

@m_schneider
Ich würde das mal von unseren NAV-Beratern prüfen lassen.

Insgesamt benötigen wir einen NAV-Berater der auf die Datenbank Optimierung speziallisiert ist, da dies bei unserem leider nicht möglich ist. Kann mir hier jemand evtl. ein paar Empfehlungen geben an wen wir uns wenden könnten oder ist hier im Forum evtl. jmd.?

[fiddi]

Ich meine die tägliche Sicherung unserer Datenbank aus Navision heraus.

Hast du schon mal versucht eine Datenbank aus der Datensicherung wieder zu erstellen?

Gruß Fiddi

[Kowa]

Oder kann man einen Umzug der Daten bei NAV 5.0 SP1 auf SQL durchführen?

Das geht, gerade in dieser Version kam seinerzeit eine wesentliche Umstellung in der Art wie die Summenindizes (SIFT) verwaltet werden, zwecks Performancesteigerung.
http://forum.mibuso.com/discussion/25381/sift-on-sql-in-5-0-sp1
Der Quellcode sollte unabhängig davon aber auch optimiert werden, damit die in Version 4.01 für den SQL-Server eingeführten Befehle wie FINDSET, FINDFIRST, FINDLAST und ISEMPTY auch genutzt werden. Beim Native Server ist dieses nicht erforderlich.

[winfy]

Insgesamt benötigen wir einen NAV-Berater der auf die Datenbank Optimierung speziallisiert ist, da dies bei unserem leider nicht möglich ist. Kann mir hier jemand evtl. ein paar Empfehlungen geben an wen wir uns wenden könnten oder ist hier im Forum evtl. jmd.?

Die meisten Berater werden dir vermutlich nahelegen auf SQL Server zu wechseln und wenn du schon einmal dabei bist auch gleich auf eine höhere NAV Version zu wechseln.

Falls du das, aus welchen Gründen auch immer, nicht durchsetzen kannst, dann kannst du eigentlich nur die Hardwarebasis drunter verbessern (schnellerer Server mit z.b. RAID10 + SSD Server Festplatten, GigaBit LAN).
Kommt darauf an wo nun der Flaschenhals bei euch liegt. Das würde dann aber nur mittelfristig zum Erfolg führen und das Update etwas herauszögern. Das richtet sich natürlich danach wieviel GB die DB wächst und mit Kosten für die Hardware ist das auch verbunden.

zur Datensicherung in der nativen DB:
Wie fiddi schon andeutete wirst du Zeitprobleme beim Wiederherstellen der .fbk Sicherungen haben, da alle Schlüssel neu aufgebaut werden (kann mehrere Stunden bis Tage dauern).
An deiner Stelle würde ich zusätzlich die komplette Datenbank per "hotcopy" auch im laufenden Betrieb wegsichern lassen, diese lassen sich im Zweifel schneller wiederherstellen, da die Datenbank-Dateien nur zurück kopiert werden müssen.

mfg,
winfy

[fiddi]

Wie fiddi schon andeutete wirst du Zeitprobleme beim Wiederherstellen der .fbk Sicherungen haben, da alle Schlüssel neu aufgebaut werden (kann mehrere Stunden bis Tage dauern).

Es kann aber auch sein, dass die lizensierte DB- Größe nicht ausreicht, um die Datensicherung einzuspielen.

Gruß Fiddi

[NAV5.0]

Hallo zusammen,

ich werde den DBMS Cache erhöhen. Könnt ihr mir sagen ob die folgende Vorgehensweise für NAV 5.0 auch die richtige ist?

1. Navision Dienst in der Registry wählen
2. cache von 800.000 auf 1.000.000 erhöhen
3. commitcache auf "1" lassen
4. Dienst neu starten

Unsere NAV Beratung hat mir empfohlen die *.fbk Sicherungen auf eine neu aufgesetzte Datenbankdatei einzuspielen, damit sich alle Schlüssel wieder aufbauen. Das soll zu einer schnelleren Datenbank führen. Hat hier evtl. jemand Erfahrungen mit solch einer Vorgehensweise?

[NAV5.0]

Hallo zusammen!

habe heute endlich mal den Cache erhöht. Bin jetzt mal gespannt wie lange der Stapellauf gleich dauern wird.

[Izzy]

Hallo zusammen,

Ich möchte nur anfügen, dass unsere Umstellung auf SSD's eine massive Performanceverbesserung mit sich brachte. Wir reden sicher von Faktor 5-10x, was auch in etwa der reinen Leistungssteigerung der Schreibgeschwindikeit der SSD entspricht. Insbesondere das umbenennen von Primärschlüsseln war sehr langsam (bis zu 3 Minuten lockdown). Heute ist es in 15 Sekunden erledigt.

Unser Setup:
PowerEdge T320
15 Users, keine Remote
Langsamer Perc H310 Raid Adapter
Raid 1, nun mit 2x 480 GB SSD (Samsung SM863)

Diese SSD's sind business tauglich und nun wirklich erschwinglich. Bei uns hat sich die Umstellung (unabhängig aller anderen Optimierungsmöglichkeiten!) auf jedenfall gelohnt.

[Kowa]

Unsere NAV Beratung hat mir empfohlen die *.fbk Sicherungen auf eine neu aufgesetzte Datenbankdatei einzuspielen, damit sich alle Schlüssel wieder aufbauen. Das soll zu einer schnelleren Datenbank führen. […]

Das führt kurzfristig zu einer kleineren Datenbank, aber das hält je nach Useraktivität meist nur ein paar Tage vor.
Ansonsten geht das Suchen anfangs schon schneller, aber das Schreiben nicht. Der Effekt ist quasi analog wie oben schon beschrieben für den Optimierungsbutton für einzelne Tabellen, nur das hier dann die ganze Datenbank betroffen ist.

[NAV5.0]

Danke für die Erklärung Kowa. Dann lasse ich das vorerst, da dies schon an einem Wochenende durchgeführt werden müsste.

Leider hat die Erhöhung des DBMS Cache auch nicht zu einer Performancesteigerung bei der Stapelbuchung geführt. Denke wir werden mittelfristig auf SQL mit unserem NAV 5.0 SP1 umstellen.

@Izzy:

Danke für die Info, das hört sich wirklich gut an! Habt ihr auch eine native DB? Wir haben auch den RAID Controller und fast den gleichen Server.

An SSDs habe ich auch bereits gedacht. Muss aber noch prüfen wie lang die durchschnittliche Lebensdauer moderner SSDs mittlerweile ist. Vielleicht wäre das wirklich dem teureren Wechsel auf SQL vorzuziehen.

[Izzy]

ja wir laufen auf der native db mit 5.0 sp1. die modernen business ssd sind auf jahre ausgerichtet. da brauchst du dir keine sorgen machen. ausserdem kannst du mit raid controller tools den zustand der ssd's anzeigen lassen, deren life nimmt mit der zeit (viel zeit und viel lese und schreibzyklen) ab und man kann rechtzeitig reagieren. trotzdem sollten auch wir auf sql umstellen, ist mir auch persoenlich viel sympathischer. aber eben... sollten :) ... nimm ssd's und das problem entschaerft sich massiv! lg