SQL Server 2000 Verbindungen langsam

[nouse459]

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

[MiSchn1980]

Hi,

kann es vielleicht an den Festplatten liegen?

Wie sind die Inserts denn geschrieben? Zeile für Zeile oder als BULK?

Gruss

Michael

[Ralf Jansen]

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.

Das Nadelohr ist offensichtlich das Plattensubsystem wie du selbst festgestellt hast. Hast du die Chance die DB Files zu verteilen oder zumindest die TempDB auf eine andere Platte/Controller zu verlagern?

Ich bringe gerade Warteschlangenlänge und SQL Profiler nicht zusammen (oder kenne die entsprechende Funktion noch nicht). Meinst du eigentlich die Leistungsüberwachung/Performance Monitor von Windows?

[nouse459]

Hi,

kann es vielleicht an den Festplatten liegen?

Wie sind die Inserts denn geschrieben? Zeile für Zeile oder als BULK?

Gruss

Michael

eher unwahrscheinlich, dass es am Server selbst liegt.
Könnte man aber vielleicht noch mal prüfen.

Die Inserts werden Zeile für Zeile geschrieben.
Das ist VB6 (!) und dort steht einem nur die veraltete ADO Technologie zur Verfügung. Also quasi:

DIM rs As New ADODB.Recordset
rs.CursorLocation = adUseClient
rs.Open SQLStatement....
IF rs.BOF And rs.EOF Then
   rs.AddNew......
   rs!Attribut = xyz
End If

usw... 

[nouse459]

Das Nadelohr ist offensichtlich das Plattensubsystem wie du selbst festgestellt hast. Hast du die Chance die DB Files zu verteilen oder zumindest die TempDB auf eine andere Platte/Controller zu verlagern?

Ich bringe gerade Warteschlangenlänge und SQL Profiler nicht zusammen (oder kenne die entsprechende Funktion noch nicht). Meinst du eigentlich die Leistungsüberwachung/Performance Monitor von Windows?

zu 1) Nein, habe ich nicht wirklich. Auf C liegen die Systemdateien.
zu 2) Das ist der Systemmonitor unter "Extras" ;-)

Ich habe festgestellt, dass auf einer Tabelle 25 Indizes liegen. Kann das nicht eventuell beim Speichern Performance-Einbußen bringen ?
Die müssen ja auch dann neu berechnet werden und gesetzt werden ?

Bei vielleicht dann entsprechend 1000 Schreibvorgängen kann das doch auch nicht mehr produktiv sein.

[Ralf Jansen]

Ich habe festgestellt, dass auf einer Tabelle 25 Indizes liegen. Kann das nicht eventuell beim Speichern Performance-Einbußen bringen ?
Die müssen ja auch dann neu berechnet werden und gesetzt werden ?

Allerdings. Aber die kannst du doch bestimmt einfach mal deaktivieren um das zu bestätigen oder?

[nouse459]

Allerdings. Aber die kannst du doch bestimmt einfach mal deaktivieren um das zu bestätigen oder?

Wie willst du denn einen Index deaktivieren ? Vll löschen....

Eine Maßnahme wäre das vielleicht.

Andererseits...

Mit weniger Indizes wird die betreffende Tabelle vll schneller gespeichert, was aber wiederum zu Performance-Problemen bei anderen, teils sehr komplexen Abfragen, Funktionen, SQL-Prozeduren kommen kann, die eben auf diese Indizes basieren.

[Ralf Jansen]

Wie willst du denn einen Index deaktivieren ? Vll löschen....

Zum Beispiel. Deaktivieren geht aber auch per Management Studio oder 'ALTER INDEX'.

Mit weniger Indizes wird die betreffende Tabelle vll schneller gespeichert, was aber wiederum zu Performance-Problemen bei anderen, teils sehr komplexen Abfragen, Funktionen, SQL-Prozeduren kommen kann, die eben auf diese Indizes basieren.

Es geht doch nur darum herauszufinden ob dein 'vermuteter' Zusammenhang auch wirklich stimmt. Wenns nicht oder nicht nur an den Indizes liegt kannst du weitersuchen wenn doch ist das eine Güterabwegung ob die Einfügeperformance wichtiger ist als die Abfrageperformance. Bei beidem das Maximum geht prinzipiell nicht.

[MiSchn1980]

Ich würde die Indizes auch mal abschalten und dann teste.

Hast du inzwischen mal eine Messung der Festplatten gemacht?

Wir hatten mal der Fall, dass der Server nur sehr langsam die Daten verarbeitet hatte. Da waren es dann tatsächlich die Platten. Die gelieferte Datenmenge war zu groß für die Lese-/ schreibzeiten der Platten.

Gruss
Michael

[nouse459]

HD noch nicht geprüft, ist ein RAID 5.
Wird regelmäßig defragmentiert und gewartet.
Ich habe die Integrität der Datenbank mit DBCC CHECKDB geprüft, keine Fehler.
Da das ein Mehrkernprozessor ist, habe ich die Einstellung auf Paralleles Bearbeiten der SQL-Abfragen geändert. Im Moment werden so bis zu 5 SQL-Queries parallel bearbeitet. Ebenso geändert: die Priorität auf den SQL-Server.

Diese Maßnahmen führten scheinbar zu einem höheren Durchsatz.

Ich werd das mal noch beobachten.