Festplatten I/o Bei Komplexen Anfragen

[dani1983 10]

Hallo zusammen,

 

ich bin was das Thema SQL Server angeht relativ neu, muss mich aber in meiner Firma mehr oder weniger um die Administration einer gekauften Software kümmern welche SQL einsetzt.

 

Wir haben einen Datenbankserver mit MS SQL Server 2005 Enterprise mit 16GB RAM Xeon 4Core CPU und einer 120 GB SSD als Speicherort für die Datenbanken.

 

Mein Problem ist, das ich immer wieder über die mitgelieferte Webschnittstelle bei komplexen Abfragen timeouts bekomme (5 Minuten) und die Datenbank nicht schnell genug die Daten liefern kann.

 

Bei der Auslastung des Datenbankservers ist die Last des CPUs und RAMs immer um die 25-30%.

Einzig und allein die Last der Festplatten liegt bei 100% und die SSD hat einen I/O von um die 300Megabyte / Sekunde.

 

An der Stelle jetzt meine Frage:

 

Ist mit anderer Festplattenhardware noch mehr wie die 300MB/s drin? Evtl. noch eine 2te SSD und die TempDB von den anderen DB trennen? (Logs liegen bereits auf anderen Platten).

 

Die Tabellengrößen kann ich leider wenig beeinflussen. Tabellen mit mehr wie 10 oder sogar 100 Millionen Zeilen sind in der Datenbank keine Seltenheit.

 

Ich würde mich freuen wenn der ein oder andere noch ein paar nützliche Tips für mich hat.

 

 

Grüße Daniel

 

PS: Ein frohes neues Jahr euch noch :)

[NilsK 2.789]

Moin,

 

bei der Symptomatik bin ich fast sicher, dass das Problem nicht durch das Plattensystem verursacht wird, sondern durch fehlende Indizes oder ähnliche "Schnitzer" auf der Konfigurations- oder Programmebene. Das ist leider kein Thema für Laien, daher solltest du den Hersteller ins Boot holen.

 

Schöne Grüße, Nils

[NeMiX 76]

Nur als Nachfrage ist das eine einzel SSD oder Raid1?

[dani1983 10]

Hallo NilsK,

 

das war auch mein erster Gedanke - und der Hersteller ist schon informiert, aber nach seinen Aussagen reicht das System von seiner Leistungsfähigkeit aus und die Datenbank wäre in Ordnung. Damit gebe ich mich zwar nicht zufrieden und habe nachgehackt, aber ich prüfe immer gern in mehrere Richtungen.

 

Was ich beim initialen Post vergessen habe ist, das ich über den SQL Profiler einer der Prozeduren die so ewig lange brauchen "abgefangen" habe.

Führe ich diese Prozedur im Management Studio aus, so dauert diese ebenfalls extrem lang.

 

Zur Erklärung: diese Prozedur löscht Einträge aus verschiedenen Tabellen und wird pro Zeile aus einer Tabelle immer wieder aufgerufen. Diese Tabelle hat aber über 30000 Zeilen und so oft müsste die Prozedur auch laufen, nur ein Durchlauf braucht so um die 40s. Also bekomm ich da ein kleines zeitliches Problem ;-)

 

Zu NeMiX: ich verwende eine einzelne SSD und die Datenbank auf der SSD verbraucht ca. die Hälfte des Speicherplatzes (60GB).

 

Grüße

Daniel

[NilsK 2.789]

Moin,

 

wie gesagt, was du beschreibst, deutet auf fehlende Indizes, Sperrkonflikte oder Ähnliches hin. Probleme dieser Art erschlägt mal selten wirksam mit der Hardware, und es wird auch kaum so sein, dass die Datenbank "nicht in Ordnung" ist, nur ist sie eben vermutlich auch nicht optimiert. Und vielleicht gibt es auch Programmierfehler, aber da ist es durchaus üblich, dass der Hersteller das so lange abstreitet, bis der Beweis gelingt ...

 

Wenn du schon Profiler-Daten hast, kannst du die an den Index-Assistenten verfüttern (den müsste es in SQL 2005 geben), damit er dir vorschlägt, welche Indizes du ergänzen solltest. Vielleicht sieht das Ganze danach schon anders aus.

 

Schöne Grüße, Nils

[dani1983 10]

Hi,

 

danke für den Tip.

Das Tool welches ich jetzt "gefunden" habe heisst bei mir "Database Engine Tuning Advisor".

Dies hab ich mit einem Trace des Profilers gefüttert aber er hat mir keine zusätzlichen Indizes empfohlen.

 

Abgesehen von ein paar Warnungen (S008    exec STAT_Guardian.dbo.Get_Report_ID         1    Event does not reference any tables) hat er mix nix angezeigt.

 

Trotzdem hat er mir geholfen weil ich mir in der Übersicht die vorhandenen Indizes angeschaut habe, und einige Indizes mit 11GB größe 66Millionen Zeilen gefunden habe.

Nach einem Rebuild aller "großen" Indizes funktioniert auch die Web-Anzeige innerhalb von 5 Sek., die vorher nach 5 Minuten einen Timeout hatte...

 

Ich denke damit hab ich jetzt ein paar Anhaltspunkte um den Hersteller auf die Füße treten zu können mir Optimierungs-scripts für die Datenbank zur Verfügung zu stellen. Alle paar Wochen alle Indizes (waren mindestens 30 Stück) neu aufbauen steht nämlich nicht in meinem Arbeitsvertrag ;-)

 

 

Vielen Dank für deine Hilfe.

 

Daniel

[NilsK 2.789]

Moin,

 

gerne, danke für die Rückmeldung! :)

 

Schöne Grüße, Nils

[Dukel 436]

Hi,

[...]

Ich denke damit hab ich jetzt ein paar Anhaltspunkte um den Hersteller auf die Füße treten zu können mir Optimierungs-scripts für die Datenbank zur Verfügung zu stellen. Alle paar Wochen alle Indizes (waren mindestens 30 Stück) neu aufbauen steht nämlich nicht in meinem Arbeitsvertrag ;-)

 

Das ist ein Job für Wartungspläne und saubere Konfiguration der Datenbanken (und nicht die beibehaltung der Standardeinstellungen). Sollte der Hersteller aber wissen.

[dani1983 10]

Hallo Dukel,

 

und genau so etwas brauche ich anscheinend auch.

Ich finde es vom Hersteller etwas blauäugig die Datenbank zu installieren (wurde in Zusammenarbeit mit mir durchgeführt) und anschließend nie wieder anzufassen.

Bei so einem Datenvolumen wie die Software erzeugt ist eine regelmäßige Wartung und Optimierung offensichtlich sehr von Nöten :)

[NilsK 2.789]

Moin,

 

Ich finde es vom Hersteller etwas blauäugig die Datenbank zu installieren (wurde in Zusammenarbeit mit mir durchgeführt) und anschließend nie wieder anzufassen.

 

da ist dir durchaus zuzustimmen, aber erfahrungsgemäß gehen die meisten Hersteller genau so vor.

 

Schöne Grüße, Nils