Datenbank langsam wenn Report gedruckt wird?
22. Juni 2006 11:15
Hallo zusammen,
wir haben folgendes Problem, seit wir unseren neuen Server einsetzen
Dual 3.0 GHz Xeon (HT)
RAM 2048
10 DB Teile mit Raid 1 bei einer DB-Größe von 30 GB
Navision Konfig:
Cache 775.000 kB
CommitCache= yes
jedesmal wenn wir einen Report drucken der etwas umfangreicher ist (z.B. Provisions-Report) geht unser Server in die Knie und das ganze Haus kann nicht mehr arbeiten. Wir können uns nicht so richtig erklären woran das liegt, der neue Server ist um einiges stärker als der alte und laut Doku soll die Perfomance besser werden je mehr DB-Teile man erstellt. Hat jemand von euch ähnliche Erfahrungen gemacht? Vielleicht doch zuviele DB-Teile? Ich würde mich über jeden Tip sehr freuen.
Grüße Jan
Edit: Wir setzen Raid 1 nicht Raid 0 ein...Raid 0 ist natürlich des Teufels *räusper*
wir haben folgendes Problem, seit wir unseren neuen Server einsetzen
Dual 3.0 GHz Xeon (HT)
RAM 2048
10 DB Teile mit Raid 1 bei einer DB-Größe von 30 GB
Navision Konfig:
Cache 775.000 kB
CommitCache= yes
jedesmal wenn wir einen Report drucken der etwas umfangreicher ist (z.B. Provisions-Report) geht unser Server in die Knie und das ganze Haus kann nicht mehr arbeiten. Wir können uns nicht so richtig erklären woran das liegt, der neue Server ist um einiges stärker als der alte und laut Doku soll die Perfomance besser werden je mehr DB-Teile man erstellt. Hat jemand von euch ähnliche Erfahrungen gemacht? Vielleicht doch zuviele DB-Teile? Ich würde mich über jeden Tip sehr freuen.
Grüße Jan
Edit: Wir setzen Raid 1 nicht Raid 0 ein...Raid 0 ist natürlich des Teufels *räusper*
22. Juni 2006 13:37
Auf wievielen Festplatten hast Du Deine DB Teile?
Den Geschwindigkeitsvorteil hast Du meiner Erfahrung nach nur wenn Du sie auf mehrere Paltten verteilst.
Den Geschwindigkeitsvorteil hast Du meiner Erfahrung nach nur wenn Du sie auf mehrere Paltten verteilst.
22. Juni 2006 13:57
Hallo Benjamin,
die Datenbankteile liegen alle auf verschiedenen Festplatten.
Gruß Jan
die Datenbankteile liegen alle auf verschiedenen Festplatten.
Gruß Jan
22. Juni 2006 14:24
Hallo,
da dieser Leistungseinbruch erst seit dem neuen Server ist, würde ich Versuchen einen Festplatten-Leistungstest durchzuführen
z.B. Si-Soft Sandra oder Professonelleren.
Wenn du auf beiden Servern diesen durchgeführt hast, kannst du die beiden Werte miteinander vergleichen.
Wenn der neue Server schlechter ist im Festplattendurchsatz als der alte, wäre zu Prüfen, ob der Schreibcache evtl. deaktiv ist. (Dieser sollte bei Datenbankverwendung nur aktiv sein, wenn eine USV am Server ist!)
Hast du Versucht diesen Report direkt auf dem Server zu starten, möglicherweise Funktioniert das Netzwerk nicht sauber!
Gruß Mikka
da dieser Leistungseinbruch erst seit dem neuen Server ist, würde ich Versuchen einen Festplatten-Leistungstest durchzuführen
z.B. Si-Soft Sandra oder Professonelleren.
Wenn du auf beiden Servern diesen durchgeführt hast, kannst du die beiden Werte miteinander vergleichen.
Wenn der neue Server schlechter ist im Festplattendurchsatz als der alte, wäre zu Prüfen, ob der Schreibcache evtl. deaktiv ist. (Dieser sollte bei Datenbankverwendung nur aktiv sein, wenn eine USV am Server ist!)
Hast du Versucht diesen Report direkt auf dem Server zu starten, möglicherweise Funktioniert das Netzwerk nicht sauber!
Gruß Mikka
22. Juni 2006 14:26
Hallo,
danke für den Tipp, das mit Si-Soft werde ich mal testen. Den Report auf dem Server zu starten bringt auch nichts, das hab ich schon ausprobiert.
Gruß Jan
danke für den Tipp, das mit Si-Soft werde ich mal testen. Den Report auf dem Server zu starten bringt auch nichts, das hab ich schon ausprobiert.
Gruß Jan
22. Juni 2006 14:36
Kleine anmerkung zu Si-Soft,
ich weiß nicht genau, ob Si-Soft Sandra ein Ideales Werkzeug für Raid-Systeme ist.
Dieses sollte ein Tipp in die Richtung Festpalttentest sein!
Gruß Michael
ich weiß nicht genau, ob Si-Soft Sandra ein Ideales Werkzeug für Raid-Systeme ist.
Dieses sollte ein Tipp in die Richtung Festpalttentest sein!
Gruß Michael
22. Juni 2006 14:37
Das weiss ich auch nicht 
, ich frag einfach mal in der Administration nach. Aber die Idee einen Performance-Test durchzuführen finde ich prinzipiell gut 
, ich frag einfach mal in der Administration nach. Aber die Idee einen Performance-Test durchzuführen finde ich prinzipiell gut
22. Juni 2006 14:42
Ok, die Admins haben gemeint SiSoft wäre da nicht so ganz das geeignete Tool, die fragen jetzt mal bei unserem Server-Gott nach. Der ist heute aber leider ausser Haus, sobald ich was weiss geb ich hier wieder Rückmeldung.
Gruß Jan
Gruß Jan
29. Juni 2006 16:29
Eine kleine Rückfrage; der Schreibcache auf den Festplatten selbst ist deaktiviert, der auf dem Raid-Controller jedoch aktiv. Welcher Cache ist denn nun gemeint? Die Meinung unserer Experten ist dass der Zugriff noch langsamer werden würde wenn man den Cache auf den controllern deaktiviert. Ist das so korrekt?
Gruß Jan
Gruß Jan
29. Juni 2006 20:14
Schreib-/Lese-Cache (egal welcher und wo) dient immer dem Performance-Gewinn.
Problem: Wenn beim Schreiben der Strom ausfallen sollte, sind die Daten noch nicht alle (physikalisch) in der Datenbank angekommen, obwohl die Anwendung dies glaubt.
Grund: Der Schreibcache lagert die Daten solange im Schreibcache, bis es sich lohnt, die Daten in einem Rutsch auf die Platte zu schreiben.
Vergleich aus der realen Welt:
Du bringst ja auch nicht jede leere Sprudelflasche einzeln zum Getränkeshop, sondern wartest auch, bis der ganze Kasten leer ist.
Problem: Wenn beim Schreiben der Strom ausfallen sollte, sind die Daten noch nicht alle (physikalisch) in der Datenbank angekommen, obwohl die Anwendung dies glaubt.
Grund: Der Schreibcache lagert die Daten solange im Schreibcache, bis es sich lohnt, die Daten in einem Rutsch auf die Platte zu schreiben.
Vergleich aus der realen Welt:
Du bringst ja auch nicht jede leere Sprudelflasche einzeln zum Getränkeshop, sondern wartest auch, bis der ganze Kasten leer ist.