MS SQL 2000 Performance / Hardware

[SvB]

Hallo,

ist vielleicht hier nicht ganz richtig, aber ih stelle trotzdem mal meine Frage. Neben meiner Programmiererei betreue ich auch noch ein paar Netzwerke und ich habe da im Moment bei einem Kunden ein Problem. Ich habe dort einen neuen Server installiert mit folgenden Daten

Dual Xeon mit Dual Core 2,8GHz
8GB RAM
Windows Server 2003 Enterprise
2x gespiegelte Bootplatten SATA
1x Raid5 mit 4 Platten SATAII ohne HotSpare für Daten
Dual GBit Ethernet
Streamer
Der Server ist Domainencontroller, SQL Server, Fileserver und David von Tobit läuft da drauf.
Im SQL werden Daten einer Speditionssoftware gespeichert. Die SQL-Datenbank für den Speditionsbereich ist im Moment ca. 6,5GB groß.

Beim Kunden ist jetzt das Problem, dass das Teile der Speditionssoftware ziemlich lange dauern, d.h. wenn einzelne Programmteile geöffnet werden oder Daten gespeichert werden, dauert dass in der Regel zwischen 15 und 30 Sekunden, je nach Programmteil. Es arbeiten ca. 15 bis 20 Mitarbeiter mit der Speditionssoftware. Die Clients sind zwei Terminalserver, auf der die Anwender verteilt sind. Die Verbindung der Software zum SQL wird über eine ODBC-Verbindung gemacht. Die Terminalserver sind fast identisch mit dem SQL-Server, außer dass diese das Raid5 und den Streamer und den SQL-Server usw. nicht haben. Die Speditionssoftware ist nicht von mir, und der Hersteller reitet die ganze Zeit darauf rum, dass in den Server z.B. SCSI Platten rein müssten, damit das schneller wird. Jetzt könnte man vielleicht sagen, dass der Server etwas viel zu tun hat, aber in anbetracht der Leistung usw. ist der Server nicht ausgelastet, was auch die CPU Nutzung im Taskmanager zeigt. Am Anfang war auch nur ein SQL-Standard installiert und der Softwarehersteller meinte, um den Speicher zu nutzen wäre ein SQL-Enterprise sinnvoller und es würde schneller werden. Gesagt getan, der Softwarehersteller sollte dann den SQL-Enterprise installieren und danach war es auch nicht schneller. Jetzt hat er einen eigenen Server hingestellt mit folgender Ausstatting:
Dual Xeon 3,2GHz (ohne Dualcore)
6GB RAM
gespiegelte SCSI Bottplatten
gespiegelte SCSI Datenplatten
Windows Server 2003 Enterprise
SQL-Enterprise

Tatsächlich laufen jetzt einige Teile der Software etwas schneller, wobei ich mir nicht ganz vorstellen kann, dass es an den SCSI Platten hängen soll. die höhere Taktfrequenz sollte gegenüber dem Dualcore Zeug wohl auch nicht einen so großen unterschied machen.

Meine Frage: Gibt es unter Euch einige Spezialisten für MS-SQL, mit den ich mich mal unterhalten kann, am besten er Telefon, dait ich vielleicht noch ein paar erkenntnisse erlange. Ich bin auch dazu bereit, für das vermittelte Know How etwas dafür zu zahlen.

Bitte meldet Euch, denn ich bin so langsam etwas ratlos und habe keine Lust noch tonnenweise Zeug zu probieren oder umzukonfigurieren.

Grüße
Sven

[Bernhard Geyer]

In anbetracht der Tatsache das SCSI-Platten sich oft nur durchs Interface unterscheiden (ATA-Platte + Zusätzliche SCSI-Schnittstelle) denke ich nicht das das dies die Hauptbremse zwangsläufig ist. Da du jetzt ja eh einen gesonderten Rechner für die DB hast kannst Du das nicht mehr 1:1 vergleichen da sich die Systeme komplett unterscheiden. Neuer Rechner ist ja kein Domain-Controller und File-Server mehr und ....

Es ist eh nicht sinnvoll auf dem Zentralen Datenserver auch noch den Streamer hängen zu haben. Was wäre wenn dieser Rechner abgeraucht wäre? Ich denke mal es läuft ein Backup-Domaincontroller damit nicht das ganze Netzwerk steht. Du mußt erst auf dem neuen Rechner auch noch die Streamer-SW zum laufen bekommen bevor du die DB-Installation+Restauration durchführen kannst.

Aber zurück zu DB-Performance-Problem:

Kannst Du bei den (jetzt nicht mehr so kritischen) Aufrufen auf DB-Seite den Tracer mitlaufen lassen sowie auf Server + Clientseite Performance-Monitore + Taskmanager. Kontrolliere mal damit ob die Anwendung hier evtl. nicht komplette Tabellen zum Client überträgt und 15-30 Sekunden verständlich werden. D.h. du mußt teure Hardware kaufen weil u.U. die SW-Entwickler sich ein paar Optimierungen auf Clientseite gespart haben.

[jensw_2000]

Moin SvB,
Hinweise must du hier nicht bezahlen.

Berhnard hat ja schon ein paar brauchbare Punkte angeschnitten.

Ich denke auch, das dir der SQL-Profiler zeigen wird, das die DB-Abfragen nicht wirklich optimal sind.

Erstmal zu SCSI <-> SATA II .
Ich habe vor ein paar Monaten mein SCSI RAID 5 (Adaptec 3400S + 4x Fujitsu HDD 10000 Rpm) aus dem Rechner geschmissen, weil die Platten dauernd voll waren und mir der Preis pro MB SCSI Platte im Vergleich zu SATA einfach zu hoch war.
Jetzt habe ich einen ordentlichen SATA RAID Controller ( Areca ARC-1220 ) und 4 WD Raptor Platten im RAID 0+1 laufen. Der Schreib-Lese Durchsatz ist im Vergleich zu dem SCSI-RAID 2,5 mal zu hoch.

Ich vermute, das dein SATA Controller keine sehr gute Performance beim Errechnen der Paritätsdaten für das RAID 5 hat. RAID 5 ist auch nur Lesend schnell.
Der SQLServer schreibt alle Transaktionen in ein Transaktionsprotokoll. Bei komplexeren Abfragen, Stored Procs usw. werden alsu u.U. auch daten geschrieben. Der "schnelle" Lesevorgang kann also durch den parallelen "langsamen" Schreibvorgang gebremst werden.

Wenn du die Möglichkeit hast, die Datenpartition in ein RAID 0+1 zu Wandeln, dann wäre das sicher eine gute Idee.

Zusätzlich kann man den SQL-Server selbst auch noch optimieren. Dazu werde ich in Laufe des Wochenendes auch noch ein paar Zeilen schreiben ...











Schöne Grüße,
Jens

[Bernhard Geyer]

Noch ein Tipp: Datenbank-Dateien und Transaktionslog sollten auf unterschiedlichen RAID's liegen (Wenn's Budget erlaubt). Bringt auch noch mal was.

[jensw_2000]

Hier noch ein paar Dinge, die man bei der Konfiguration des SQL-Servers beachten sollte.


(Folgende Einstellungen findest du im Enterprise Manager > Rechtsklick auf dem SQL-Server > Eigenschaften)

Tabsheet > "Memory"
Du hast 8 GB RAM in der Maschine. Für den Windows, Tobit und die anderen Dienste sind 1-2GB mehr als genug.
Weise dem SQL-Server fest 6GB RAM zu.
- Option "Use fixed Memory Size" > auf 6 oder 7 GB
- Checkbox "Reserve physical memory for SQL Server" setzen

Du beschreibst, das Abfragen oft sehr lange laufen. Das hört sich nach einem schlecht optimierten Nutzung der DB an. Vermutlich zieht das Programm bei einigen Abfragen sehr viele Datensätze zum Client und verarbeitet diese dort. Besser wäre es, dem SQL-Server die Arbeit zu überlassen, und nur die Ergebnisse zum Client zu liefern. Bei Abfragen sollte immer eine sinnvolle und möglichst kleine Datenmenge zurückgegeben werden. Das kannst du nicht beeinflussen, weil das Programm nicht von dir gewartet wird. Allerdings hast du die Möglichkeit dem SQL-Server mehr Abfragespeicher pro Abfrage zuzuordnen.
- Option "Minimum Query Memory"
Erhöhe die Werte mal schrittweise und beobachte das Verhalten der Applikation. Bei"weniger optimalen" Abfragen die oft verwendet werden kann man damit einer Menge erreichen.

Tabsheet > "Processor"
Die Änderungen der CPU Nutzung bringen nur was, wenn der SQL-Server eine gewisse Last hat.
Wenn die CPU Last des SQL-Server Prozesses während des "Normalbetriebs" deutlich unter 10% bleibt, dann kannst du hier nicht viel optimieren.
Dennoch ein paar Hinweise zu den Optionen ....

Du hast einem schnellen SMP fähigen Prozessor und ein Serverbetriebssystem.
Damit ist die
- Option "Use Windows NT fibers" (... instead of threads)
für dich interessant. Parallele Prozesse werden dann etwas optimaler verwaltet. Diese Option sollte nie auf Singel-CPU Systemen bzw. "nicht Server Betriebssystemen" aktiviert werden.
Mit etwas Vorsicht kannst du die
- Checkbox "Boost SQL-Server priority"
aktivieren. Die ersten Tage nach dem Aktivieren der Option solltest du aber auf jeden Fall die Eventlogs des Servers kontrollieren. Wenn der SQL-Server Kommunikationsprobleme mit den Clients loggt, dann musst du die Priority Boost Option wieder abschalten. Die Leistung der Prozessors reicht in diesem Fall nicht aus.

Kommen wir zu den Eigenschaften der Datenbank ...
(Folgende Einstellungen findest du im Enterprise Manager > Rechtsklick auf der "Speditionsdatenbank" > Eigenschaften)

Da ich die Struktur das Datenbank nicht kenne, kann ich dir nur ein paar "spekulative" Eckdaten geben.

Tabsheet > "Data Files"
Die Dateioptionen sind manchmal nicht sehr optimal.
Stelle sicher, das die
- Option "automatically Grow File"
aktiv ist und das Diese nicht auf dem standardmäßigen Wert "10%" steht. Wenn die DB einen gewissen "Füllstand" überschreitet werden bei einer 6,5 GB großen DB immerhin 650 MB große Änderungen auf die Platte geschrieben. Ein fester Auto-Grow-Wert zwischen 80 und 100 MB sollte hier mehr Sinn machen. Bitte mache nicht den Fehler und schraube den AutoGrow Wert auf 1MB runter. Der SQL-Server würde sich dann zu sehr mit dem Warten seiner Datendatei beschäftigen.

Tabsheet > "Transaction Log"
Auch hier sind die Dateioptionen standardmäßig manchmal nicht optimal.
Stelle sicher, das die Option "automatically Grow File" aktiv ist. Der Default-Wert von 10% macht auch hier selten Sinn.
Empfehlung: Mach ein Backup der Datenbank (Recovery-Model "Simple") und merke dir die Größe des Transaktionsprotokolls (LDF). Lass den Kunden dann einen Tag lang mit der DB arbeiten.
Sieh nach, wieviel MB die LDF zugelegt hat. Den Differenzwert trägst du als festen Autogrow Wert für das Auto-Grow des Transaction-Logs ein.
Wenn der Wert sehr hoch ist (500MB +), dann ist es auch hier besser, den Auto-Grow-Wert zu verkleinern.

Tabsheet > "Options"
Damit der SQL-Server Zugriffsstatistiken führt und diese selbstständig aktualisiert, sollten die
- Checkboxen "Auto create statistics" und "Auto update statistics"
gesetzt sein. Mit Hilfe der Statistiken führt der SQL-Server eine ständige Selbstoptomierung aus.
Daher sollten diese Checkboxen nie abgeklickt werden.
- Die Option "Torn page detection" frisst etwas Performance. Du solltest sie aber dennoch nicht deaktivieren. Der SQL-Server sucht Transaktionen, die auf Grund von E/A Fehlern nicht vollständig abgeschlossen werden konnten. Dieser Haken kann bei fehlerhaften Platten bzw. Controllern irgendwann man wichtig werden .
Über das Aktivieren der
- Autoshrink Option
kann man sich streiten. Wenn sich der Server "langweilt" kann man die Option ruhig aktivieren. Andernfalls würde ich das Verkleinern der DB lieber über einen Wartungsplan nach Geschäftsschluss erledigen.

Damit das Transaktionsprotokoll nicht zu groß wird, setze ich das
- Recovery-Model auf "Simple".
Der SQL-Server setzt so nach dem Sichern der DB ein "Save-State" Flag und beginnt einen neuen Log-Zyklus. Das Transaktionsprotokoll wird nach dem Backup deutlich kleiner.


Wenn das Alles nichts bringt, nimm dir den Profiler und schau mal was der Server macht, während eine langsame Abfrage läuft. Wenn der Client damit beschäftigt ist 1-2 Millionen Datensätze abzusaugen, dann sprich mit deinem Kunden und reiche die "A"-Karte weiter an die Software-Bude. Ausserdem sollte möglichst viel Arbeit durch den SQL-Server erledigt werden und nicht durch den Client. Eine große DB ohne SP's und UDF's kann nur in wenigen Fällen optimal genutzt werden. Schlechte SP's und UDF's verursachen hingegen viel CPU-Last (und lange Lock-Zeiten) auf dem Server. Da kannst du u.U. auch mal einen Blick drauf werden.

Ich hoffe, das bringt dich schon mal ein Stück weiter.

Schöne Grüße,
Jens

[SvB]

Danke vorest mal für die Hilfe, bei der Menge, habe ich jetzt erst mal was zu tun. Als erstes werde ich noch mal nach Unterschieden in der SQL-Server Konfiguration suchen, ob die Software-Firma an ihrem Server nicht was anderes eingestellt haben als bei meinem und dann Schritt für Schritt weiter.
Vielleicht ändere ich auch mal das Raid5 in zwei mal gespiegelte Platte. Wenn Raid beim schreiben langsamer ist, dann bringt das eventuell auch schon was.
Ich werde mich dann noch mal melden.

Vielen Dank noch mal
Grüße
Sven

[shmia]

Prüfe doch mal, ob alle Tabellen einen Clustered Index haben!!

SQL-Code:

CREATE VIEW dbo.vwNoClusteredIndex
AS
SELECT     [name]
FROM         dbo.sysobjects so
WHERE     (NOT EXISTS
                          (SELECT     si.id
                            FROM          sysindexes si
                            WHERE      indid = 1 AND si.id = so.id)) AND (type = 'U')
ORDER BY name

Ein Tabelle ohne Clustered Index bedeutet beim MS SQL Server eine grosse Leistungsverschwendung
(bei mehr als 50 Datensätzen).

[alzaimar]

Ein Clustered Index alleine macht noch keinen Sommer bzw. eine performante DB. Der Clustered Index muss auf dem Feld (den Feldern) liegen, die am häufigsten für zeitkritische Abfragen verwendet werden. I.A. sind dies die Primary Keys (Indentity), kann aber auch mal eine Datumsspalte sein, wenn etwa eine Aufzeichnung bestimmter Ereignisse stattfindet und der Löwenanteil der Auswertungen über einen zeitlich begrenzten Bereich laufen.

Des Weiteren sind Indexe mit Augenmaß zu verwenden: Zu wenige führen zu den berüchtigten 'Table scans', zu viele zu Performanceeinbußen bei der Datenmanipulation: Immerhin müssen bei jeder Änderung alle Indexe überarbeitet werden.

Den Rest hat jens_w und Berhard Geyer schon gesagt.

[jensw_2000]

In Anbetracht, das SvB nicht entwicklungsseitig beteiligt ist, sollte er imho keine Modifikationen an der DB vornehmen. Wenn die Software-Bude später fremde Views oder neue Indizies findet, dann ist der schwarze Peter bei SvB, und das unabhängig davon ob der Fehler an der Software liegt oder nicht.

Ich würde einfach nur mit dem Profiler ein mehrstündiges "Performance-Tuning Trace" im Livebetrieb ziehen und das Tracefile mit dem Index Tuning Wizard auswerten. Zusätzlich noch einen Trace von der "langsamen Abfrage", um eventuelle clientseitige Schwächen aufzudecken.

Mit dem ganzen Geraffel würde ich mich dann zuerst an den Kunden wenden.


Schöne Grüße,
Jens

[SvB]

Hallo,

mir ist da beim Testen noch was eingefallen.
Inwieweit macht sich das an der Geschwindigkeit bemerkbar, da hier über ODBC gearbeitet wird.
Macht es einen Unterschied in der ODBC Konfiguration, ob ich den SQL-Server mit der IP-Adresse eintrage oder über den Computernamen?

Danke
Sven