Commit Cache ist voll
19. Januar 2007 10:36
hallo...
ich habe seit kurzem ein mächtiges problem. bei uns läuft navision 3.7 auf einem windows 2000 server mit 2gb ram.
es kommt nun immer öffter zu performance problemen. das öffnen von einem einfachen fenseter in navision (z.b. gebuchte rechnung) dauert lang und buchungen bzw. berichte lassen lange auf sich warten. hin und wieder erscheint dann die meldung "commit cache ist voll"!!
der dbms-cache ist auf 1.000.000 eingestellt. das ist zumindest im fenster "datenbankinformation" zu lesen. ( über extras->optionen wird aber für dbms cache der wert <8000> angezeigt. warum ist das bloß so?)
über den taskmanager habe ich gesehen dass der server.exe 1.000.000 speicher belegt.
ich habe keine idee was nun zu tun ist und warum der cache immer wieder voll läuft.
die datenbankgröße ist zur zeit 34GB und davon belegt sind 87%.
kann ich den dbms-cache höher setzen? kann ich irgendwo festlegen wie groß der commit-cache sein soll? oder muss ich die hardware verbessern (z.b. schnellere festplatte)
hat vielleicht jemand erfahrung damit?
viele grüße
shahram
hallo...
ich habe seit kurzem ein mächtiges problem. bei uns läuft navision 3.7 auf einem windows 2000 server mit 2gb ram.
es kommt nun immer öffter zu performance problemen. das öffnen von einem einfachen fenseter in navision (z.b. gebuchte rechnung) dauert lang und buchungen bzw. berichte lassen lange auf sich warten. hin und wieder erscheint dann die meldung "commit cache ist voll"!!
der dbms-cache ist auf 1.000.000 eingestellt. das ist zumindest im fenster "datenbankinformation" zu lesen. ( über extras->optionen wird aber für dbms cache der wert <8000> angezeigt. warum ist das bloß so?)
über den taskmanager habe ich gesehen dass der server.exe 1.000.000 speicher belegt.
ich habe keine idee was nun zu tun ist und warum der cache immer wieder voll läuft.
die datenbankgröße ist zur zeit 34GB und davon belegt sind 87%.
kann ich den dbms-cache höher setzen? kann ich irgendwo festlegen wie groß der commit-cache sein soll? oder muss ich die hardware verbessern (z.b. schnellere festplatte)
hat vielleicht jemand erfahrung damit?
viele grüße
shahram
hallo...
19. Januar 2007 12:06
Also ...
Ein nativer NAV Datenbank Server kann nicht mehr als 1 GB DBMS Cache allokieren, die Servereinstellung 1.000.000 ist daher maximal (und bei 2 GB RAM nicht zu verbessern, d.h. 1 GB steht dem Betriebssystem zur Verfügung)
Entscheidend ist, ob bei der Serverkonfiguration "Commit Cache = Ja" eingestellt ist (siehe Datei - Datenbank - Informationen).
Die Einstellungen die man unter den "Optionen" findet sind dabei unerheblich, sie spielen nur eine Rolle wenn auf eine Datenbank direkt - also ohne Server - zugegriffen wird.
(Hier ist lediglich der "Objekt Cache" wirklich von Bedeutung).
Zurück zum COMMIT Cache: Ist dieser aktiviert, so wird etwa ein Drittel des DBMS Caches dafür verwendet, also etwa 300 MB. Ist der Cache voll (u.a.), so schreibt NAV die Daten physikalisch in die DB.
DAs Problem bei deiner Datenbank ist zweifellos der "Füllgrad" von 87%. NAV benötigt freie DB Blöcke zur Verwaltung der Transaktionen nach Versions Prinzip: Hier werden Blöcke allokiert/reserviert, Transaktionen soz. temporär durchgeführt, und bei COMMIT werden diese Blöcke als "neue" globale Version freigegeben.
Um dies einigermaßen performant zu bewerkstelligen, sollten min. 30%, besser 50% freier Platz verfügbar sein.
Also: Platz "freischaufeln" (alte Daten löschen/comprimieren, Tabellen Optimierung, etc.) oder DB erweitern.
Sollte helfen ...
Ein nativer NAV Datenbank Server kann nicht mehr als 1 GB DBMS Cache allokieren, die Servereinstellung 1.000.000 ist daher maximal (und bei 2 GB RAM nicht zu verbessern, d.h. 1 GB steht dem Betriebssystem zur Verfügung)
Entscheidend ist, ob bei der Serverkonfiguration "Commit Cache = Ja" eingestellt ist (siehe Datei - Datenbank - Informationen).
Die Einstellungen die man unter den "Optionen" findet sind dabei unerheblich, sie spielen nur eine Rolle wenn auf eine Datenbank direkt - also ohne Server - zugegriffen wird.
(Hier ist lediglich der "Objekt Cache" wirklich von Bedeutung).
Zurück zum COMMIT Cache: Ist dieser aktiviert, so wird etwa ein Drittel des DBMS Caches dafür verwendet, also etwa 300 MB. Ist der Cache voll (u.a.), so schreibt NAV die Daten physikalisch in die DB.
DAs Problem bei deiner Datenbank ist zweifellos der "Füllgrad" von 87%. NAV benötigt freie DB Blöcke zur Verwaltung der Transaktionen nach Versions Prinzip: Hier werden Blöcke allokiert/reserviert, Transaktionen soz. temporär durchgeführt, und bei COMMIT werden diese Blöcke als "neue" globale Version freigegeben.
Um dies einigermaßen performant zu bewerkstelligen, sollten min. 30%, besser 50% freier Platz verfügbar sein.
Also: Platz "freischaufeln" (alte Daten löschen/comprimieren, Tabellen Optimierung, etc.) oder DB erweitern.
Sollte helfen ...
11. Juli 2007 11:44
stryk hat geschrieben:Um dies einigermaßen performant zu bewerkstelligen, sollten min. 30%, besser 50% freier Platz verfügbar sein.
Also: Platz "freischaufeln" (alte Daten löschen/comprimieren, Tabellen Optimierung, etc.) oder DB erweitern.
Sollte helfen ...
Daten komprimieren und Tabellen Optimieren?
Wie / wo kann man das machen?
Unsere Datenbank ist auch mal wieder zu 94%. Wenn möglich wollte ich nun erstmal eine "optimierung/komprimierung" vornehmen, bevor ich die Datenbank erweitere.
Unsere DB ist derzeit 15 GB groß und zu 94% belegt.
50% freier Platz waere Ratsam... dann müsste ich die DB auf ca. hmm 23 GB erweitern?
11. Juli 2007 11:51
elTorito hat geschrieben:Daten komprimieren und Tabellen Optimieren?
Wie / wo kann man das machen?
Finanzbuchhaltung - Periodische Aktivitäten - Datumskomprimierung - und dort die entsprechenden Menüpunkte. Ich denke, das war es, was Jörg mit "Komprimieren" meinte.
elTorito hat geschrieben:50% freier Platz waere Ratsam... dann müsste ich die DB auf ca. hmm 23 GB erweitern?
Richtig. Heute Abend nach Feierabend eben eine halbe Stunde Zeit nehmen und die Datenbank erweitern. Morgen werden die Kollegen wahrscheinlich glücklicher sein.
Gruß, Marc
11. Juli 2007 12:57
Hi!
Genau, mit "Komprimieren" ist die Datumskomprimierung in den verschiedenen Modulen gemeint.
Mit "Optimieren" meine ich die Anwendung des "Table Optimizers": Datei - Datenbank - Information - Tabellen - Optimieren
Dabei werden die Daten- & Index-blöcke neu angeordnet, soz. defragmentiert. Somit wird zwar Speicherplatz in der DB freigegeben; allerdings kann sich die Optimierung bestimmter Tabellen auch negativ auf die Perfromance auswirken: Zitat (Kowa): "... die Datenbank braucht das Chaos ..."
P.S.: Achtung - betrifft nur "native" DB, nicht SQL Server!
Genau, mit "Komprimieren" ist die Datumskomprimierung in den verschiedenen Modulen gemeint.
Mit "Optimieren" meine ich die Anwendung des "Table Optimizers": Datei - Datenbank - Information - Tabellen - Optimieren
Dabei werden die Daten- & Index-blöcke neu angeordnet, soz. defragmentiert. Somit wird zwar Speicherplatz in der DB freigegeben; allerdings kann sich die Optimierung bestimmter Tabellen auch negativ auf die Perfromance auswirken: Zitat (Kowa): "... die Datenbank braucht das Chaos ..."
P.S.: Achtung - betrifft nur "native" DB, nicht SQL Server!
11. Juli 2007 13:11
Marc Teuber hat geschrieben:Finanzbuchhaltung - Periodische Aktivitäten - Datumskomprimierung
Datumskomprimierungen sind für mich immer die letzte Wahl, da man dadurch den Detailierungsgrad der Daten für Auswertungen einbüsst. Speicherplatzerweiterungen sind ja heutzutage kein Problem und auch kein grosser Kostenfaktor mehr. Wir haben einen Kunden, der mit einer 70GB grossen Datenbank arbeitet (native). Natürlich ist die DB auf diverse Partitionen verteilt.
Nach meinem Kenntnisstand sollten nicht mehr als 80% der DB belegt sein. Wird die DB zu 'vollgestopft' (gegen 100%) kann es zu irreparablen Schäden kommen, die eine Weiterverwendung der DB verunmöglicht.
11. Juli 2007 18:22
Da muss ich rotsch zu 100% Recht geben:
Über jede Information ist man irgendwann einmal froh.
Der Effekt einer Optimierung ist am deutlichsten zu sehen, wenn man eine Datenrücksicherung macht. Wir machen das ca. alle 3 Monate für unsern Testserver. Wenn hier der Unterschied zum Produktivsystem groß ist, wird nach Feierabend die Produktivdatenbank optimiert.
Wegen der Cache-Einstellung wurde mir mal erklärt, dass es auch zu Problemen führen kann, wenn diese zu groß ist.
Es gibt eine Formel mit Anzahl User und so....das kann doch bestimmt einer der MS-Partner heraussuchen ...oder?
Gruß
Carsten
Über jede Information ist man irgendwann einmal froh.
Der Effekt einer Optimierung ist am deutlichsten zu sehen, wenn man eine Datenrücksicherung macht. Wir machen das ca. alle 3 Monate für unsern Testserver. Wenn hier der Unterschied zum Produktivsystem groß ist, wird nach Feierabend die Produktivdatenbank optimiert.
Wegen der Cache-Einstellung wurde mir mal erklärt, dass es auch zu Problemen führen kann, wenn diese zu groß ist.
Es gibt eine Formel mit Anzahl User und so....das kann doch bestimmt einer der MS-Partner heraussuchen ...oder?
Gruß
Carsten
13. Juli 2007 09:16
bräu hat geschrieben:Wegen der Cache-Einstellung wurde mir mal erklärt, dass es auch zu Problemen führen kann, wenn diese zu groß ist.
Es gibt eine Formel mit Anzahl User und so....das kann doch bestimmt einer der MS-Partner heraussuchen ...oder?
Mir sind keine Probleme mit dem Cache bekannt, außer er wurde zu klein gewählt
-->Performanceprobleme
Die "Oberer-Grenze" liegt bei 1 GB, wenn ich das richtig in Erinnerung habe.
Auf der Navision CD gibt es eine PDF Datei, in der dieses beschrieben wird.
(Weiß leider nicht mehr welche!)
Gruß Mikka
13. Juli 2007 11:38
mikka hat geschrieben:Auf der Navision CD gibt es eine PDF Datei, in der dieses beschrieben wird.
(Weiß leider nicht mehr welche!)
Gruß Mikka
w1w1ism - Database Serevr Installation & System Management.pdf ?