Verkaufshistorie kommt ins "stocken"
4. Dezember 2007 22:17
Hi,
wir Arbeiten mit NAV 4.00 SP1 und bekommen von unseren Vertriebsmitarbeiten Beschwerden, dass die Verkaufshistorie zu langsam ist.
40 User arbeiten auf der SQL-Datenbank (SQL-Server 2000). Davon mindestens 30 über insgesamt 4 TerminalServer.
Nun kommt es unregelmäßig zum "stocken" in der Verkaufshistorie.
Den Object Cache haben wir für 4 User nun auf 64000 erhöht. Leider ohne Erfolg.
Wie kann man so ein Performance-Problem besser eingrenzen?
Wäre super wenn jemand einen Weg vorschlagen kann.
wir Arbeiten mit NAV 4.00 SP1 und bekommen von unseren Vertriebsmitarbeiten Beschwerden, dass die Verkaufshistorie zu langsam ist.
40 User arbeiten auf der SQL-Datenbank (SQL-Server 2000). Davon mindestens 30 über insgesamt 4 TerminalServer.
Nun kommt es unregelmäßig zum "stocken" in der Verkaufshistorie.
Den Object Cache haben wir für 4 User nun auf 64000 erhöht. Leider ohne Erfolg.
Wie kann man so ein Performance-Problem besser eingrenzen?
Wäre super wenn jemand einen Weg vorschlagen kann.
4. Dezember 2007 22:55
Hallo,
wie sieht's mit dem Server bzw. der Infrastruktur aus.
Für mich siehts nach dem ersten groben Anschein danach aus dass der Server "zu macht" und danach normal weiter arbeitet.
CPU, Speicher, Festplatten das wäre Interessant. Navision ist extrem I/O lastig...
Gruß
Gerhard
wie sieht's mit dem Server bzw. der Infrastruktur aus.
Für mich siehts nach dem ersten groben Anschein danach aus dass der Server "zu macht" und danach normal weiter arbeitet.
CPU, Speicher, Festplatten das wäre Interessant. Navision ist extrem I/O lastig...
Gruß
Gerhard
5. Dezember 2007 11:58
Nun, meine erste Empfehlung ist, mal das Forum nach "SQL Performance" zu durchsuchen - hier findest Du sicher EINIGES zu dem Thema ...
Etwas konkreter: Ich vermute mal, dass die DB in keiner Weise "getuned" ist. Welche DB Wartungesarbeiten werden regelmäßig durchgeführt?
Lange Antwortzeiten sind im wesentlichen auf 2 Probleme zurückzuführen:
1. Sperren/Blockaden (hört sich in Deinem Fall nicht danach an)
2. "Schlechte" Ausführungspläne
Ich vermute, das bei dem beschriebenen Problem Punkt 2 relevant ist; also ein sub-optimaler Index für die Abfrage verwendet wird. Beweisführung wäre via SQL Profiler und Query Analyzer möglich ...
Abhilfe schafft das Erstellen/Ändern eines optimalen Indexes.
Etwas konkreter: Ich vermute mal, dass die DB in keiner Weise "getuned" ist. Welche DB Wartungesarbeiten werden regelmäßig durchgeführt?
Lange Antwortzeiten sind im wesentlichen auf 2 Probleme zurückzuführen:
1. Sperren/Blockaden (hört sich in Deinem Fall nicht danach an)
2. "Schlechte" Ausführungspläne
Ich vermute, das bei dem beschriebenen Problem Punkt 2 relevant ist; also ein sub-optimaler Index für die Abfrage verwendet wird. Beweisführung wäre via SQL Profiler und Query Analyzer möglich ...
Abhilfe schafft das Erstellen/Ändern eines optimalen Indexes.
5. Dezember 2007 15:51
Hi,
unser Server hat 4 GB Arbeitsspeicher, 2 x P4 Xenon 2,6
Festplatten Mylex AR352 2xu160 64 MB Cache
5 x 2 x 36 GB RAID 1 + Sicherungsplatte 1 x 73 GB
Windows Server 2000 incl SP4, SQL Server 2000 SP3
1 GB Etherlink Netzwerkanbindung.
Ausführungspläne gibt es eigentlich kein.
unser Server hat 4 GB Arbeitsspeicher, 2 x P4 Xenon 2,6
Festplatten Mylex AR352 2xu160 64 MB Cache
5 x 2 x 36 GB RAID 1 + Sicherungsplatte 1 x 73 GB
Windows Server 2000 incl SP4, SQL Server 2000 SP3
1 GB Etherlink Netzwerkanbindung.
Ausführungspläne gibt es eigentlich kein.
6. Dezember 2007 11:38
bräu hat geschrieben:unser Server hat 4 GB Arbeitsspeicher, 2 x P4 Xenon 2,6
Festplatten Mylex AR352 2xu160 64 MB Cache
5 x 2 x 36 GB RAID 1 + Sicherungsplatte 1 x 73 GB
Windows Server 2000 incl SP4, SQL Server 2000 SP3
1 GB Etherlink Netzwerkanbindung.
Kann prinzipiell ausreichend sein, hängt aber von der DB Größe und dem Transaktionsvolumen ab, sowie der Konfiguration von HW/Server/DB - insbesondere die Verteilung der Datenbaken auf den Festplatten ... etc. (wie gesagt, das Thema ist im Forum schon MEHRFACH diskutiert worden)
bräu hat geschrieben:Ausführungspläne gibt es eigentlich kein.
Du meinst wahrscheinlich "Wartungspläne". Schlecht
.
Ohne periodische Wartung wird jeder SQL Server früher oder später Probleme bekommen. Du benötigts mindestes:
- Tägliche Aktualisierung der Statistiken
- Wöchentlicher Index Rebuild
- Wöchentliches SIFT Clean-Up
Diese Wartung wir aber nur für eine gewisse "Grundperformance" sorgen. Probleme aufgrung von "schlechten Abfragen bzw. Ausführungsplänen" lassen sich damit kaum beseitigen (abgesehen von den Statistiken).
Via SQL Profiler kann man ermitteln, welchen Execution PLan SQL Server verwendet, wenn eure "Verkaufshistorie" benutzt wird. Werden hier Operationen wie "Index Scan" (schlecht) oder "Clustered Index Scan" (noch schlechter) oder gar "Table Scan" (schlimmer geht's nicht) aufgezeigt, dann fehlt dem System der richtige Index für diese Abfrage ...
8. Dezember 2007 13:36
Sorry,
ich habe echt ein zeitliches Problem. Natürlich werde ich so schnell es geht das Forum auf Performance durchsuchen.
Um aber mit Informationen nicht zu "geizen" hier ein paar Daten aus Navision: Dabenbank belegt ist 37 GB, Größe: 48 GB,
Wir senden ca. 400 Pakete täglich raus, haben ca. 20000 Kunden und ca. 60000 Artikel.
Mit der Datenbank sind wir seit Anfang 2006 unterwegs und haben demnach ca. 160.000 Positionen in der Historie - allerdings 1,9 Mio. Verkaufsrechnungszeilen und ca. 700.000 Artikelposten.
Das sollte den Umfang einigermaßen gut beschreiben.
Um die Verteilung auf die Festplatten etc. zu erfahren muss ich noch mit den Kollegen sprechen -
In Navision sieht das so aus:
Die erste Datenbankdatei mit ca. 4GB auf d:
eine zweite auch auf D: im gleichen verzeichnis mit 25 GB
eine dritte auf e: mit fast 19 GB.
Das erste Trans.prot auf f: mit ca. 14 GB und
ein zweites auf g: mit 21,5 GB
ob das wirklich auch physikalisch unterschiedliche Platten sind bringe ich noch in Erfahrung.
Vielen Dank für die Hilfe.
Gruß
Bräu
ich habe echt ein zeitliches Problem. Natürlich werde ich so schnell es geht das Forum auf Performance durchsuchen.
Um aber mit Informationen nicht zu "geizen" hier ein paar Daten aus Navision: Dabenbank belegt ist 37 GB, Größe: 48 GB,
Wir senden ca. 400 Pakete täglich raus, haben ca. 20000 Kunden und ca. 60000 Artikel.
Mit der Datenbank sind wir seit Anfang 2006 unterwegs und haben demnach ca. 160.000 Positionen in der Historie - allerdings 1,9 Mio. Verkaufsrechnungszeilen und ca. 700.000 Artikelposten.
Das sollte den Umfang einigermaßen gut beschreiben.
Um die Verteilung auf die Festplatten etc. zu erfahren muss ich noch mit den Kollegen sprechen -
In Navision sieht das so aus:
Die erste Datenbankdatei mit ca. 4GB auf d:
eine zweite auch auf D: im gleichen verzeichnis mit 25 GB
eine dritte auf e: mit fast 19 GB.
Das erste Trans.prot auf f: mit ca. 14 GB und
ein zweites auf g: mit 21,5 GB
ob das wirklich auch physikalisch unterschiedliche Platten sind bringe ich noch in Erfahrung.
Vielen Dank für die Hilfe.
Gruß
Bräu
8. Dezember 2007 17:16
Das Transaktionsprotokoll erscheint mir doch sehr groß
habt Ihr keinen Warungsplan, der das Transaktionsprotokoll Stündlich oder Halbstündlich sichert? bei Eurem Aufkommen wäre halbstündlich besser. in der Regel ist das Transaktionsprotokoll maximal die Hälfte der Datenbank.
habt Ihr keinen Warungsplan, der das Transaktionsprotokoll Stündlich oder Halbstündlich sichert? bei Eurem Aufkommen wäre halbstündlich besser. in der Regel ist das Transaktionsprotokoll maximal die Hälfte der Datenbank.