Hallo,
wir haben ein kleines Performance-Problem auf unserem Server.
Ca. 30 Benutzer greifen in Stoßzeiten gemeinsam auf SQL Server 2000 DB zu.
Auf dem Server läuft Windows Server 2003 R2 SP 2.
Prozessor: AMD Phenom 9750 Quad-Core 2,41 GHz und 4 GB RAM.
Frontend ist u.a. ein VB6 Programm mit ADO.
Die Scandichte bei den kritischen Tabellen liegt teilweise unter 20 %.
Dabei ist die betreffende Tabelle ca. 600.000 Zeilen groß.
Die Gesamtgröße der korrespondierenden DB liegt bei ca. 3,6 GB.
Wundern tut mich hier, dass der Schreib-Zugriff auf die betreffenden Tabellen
(realisiert mit Recordsets) nicht permanent langsam ist, wie der teilweise hohe Fragmentierungsgrad nahelegen könnte, sondern eben nur in Stoßzeiten vorkommt.
Dann allerdings kann ein Schreibvorgang schon mal bei vielleicht 30 Zeilen bis zu 3 Minuten dauern.
Ich finde einfach nicht das Nadelöhr. Der SQL Profiler zeigt höchstens genau diesen Sachverhalt an, eben, dass die Warteschlangenlänge des Datenträgers voll ist und der Server die Daten nicht mehr zeitnah schreiben kann.
Habt ihr eine Idee, wie man die Lese/Schreibvorgänge auf die DB beschleunigen könnte ? ( Außer die Indizes zu reorganisieren und neu zu setzen)
Abgesehen davon, dass 30 (!) Benutzerverbindungen doch eigentlich für einen SQL Server recht wenig sein müssten.
Am Netzwerk selbst kann es eigentlich nicht liegen. Das wurde erst dieses Jahr überholt.
VIELEN Dank für jede Idee
Stephan
wir haben ein kleines Performance-Problem auf unserem Server.
Ca. 30 Benutzer greifen in Stoßzeiten gemeinsam auf SQL Server 2000 DB zu.
Auf dem Server läuft Windows Server 2003 R2 SP 2.
Prozessor: AMD Phenom 9750 Quad-Core 2,41 GHz und 4 GB RAM.
Frontend ist u.a. ein VB6 Programm mit ADO.
Die Scandichte bei den kritischen Tabellen liegt teilweise unter 20 %.
Dabei ist die betreffende Tabelle ca. 600.000 Zeilen groß.
Die Gesamtgröße der korrespondierenden DB liegt bei ca. 3,6 GB.
Wundern tut mich hier, dass der Schreib-Zugriff auf die betreffenden Tabellen
(realisiert mit Recordsets) nicht permanent langsam ist, wie der teilweise hohe Fragmentierungsgrad nahelegen könnte, sondern eben nur in Stoßzeiten vorkommt.
Dann allerdings kann ein Schreibvorgang schon mal bei vielleicht 30 Zeilen bis zu 3 Minuten dauern.
Ich finde einfach nicht das Nadelöhr. Der SQL Profiler zeigt höchstens genau diesen Sachverhalt an, eben, dass die Warteschlangenlänge des Datenträgers voll ist und der Server die Daten nicht mehr zeitnah schreiben kann.
Habt ihr eine Idee, wie man die Lese/Schreibvorgänge auf die DB beschleunigen könnte ? ( Außer die Indizes zu reorganisieren und neu zu setzen)
Abgesehen davon, dass 30 (!) Benutzerverbindungen doch eigentlich für einen SQL Server recht wenig sein müssten.
Am Netzwerk selbst kann es eigentlich nicht liegen. Das wurde erst dieses Jahr überholt.
VIELEN Dank für jede Idee
Stephan
Comment