SQL Server Geschwindigkeit - Speicherort

[christophorus 11]

Hallo zusammen,

habe heute eine Frage zum Thema SQL Speed. Wir setzten hier ein SQL DB ein die ca. 2 GB groß ist. Klingt ja noch relatib harmlos, leider dauern komplexe Abfragen und Bericht bereits 5 bis 10 Minuten. Die DB ist bestandteil einer Software die angeschaft wurde, also keine Selbstbastelei - was natürlich keine Garantie ist, dass die Entwickler der Software sauber gearbeitet haben.

Nun jedoch zu meiner Frage:

Wie arbeitet der SQL Server 2000 bei Abfragen? Wird jedesmal die Festplatte beansprucht? Kann man vielleicht die Komplette DB in den Arbeitsspeicher laden und und von dort die Abfragen fahren? Jedes mal wenn sich etwas an der DB ändern würde, müsste die Änderung natürlich auf die Platte geschrieben werden. Hat jemand vielleicht schon Erfahrungen mit Solid State Disks gesamelt? Die zugrifszeiten sind natürlich ein Traum und im Enterprise Sektor sollten die Teile doch ein Thema sein oder?

Würde mich freuen wenn Ihr vielleicht den einen oder anderen Tipp für mich hättet um meine Misere hier vom Tisch zu bekommen.

 

Ich danke im Voraus für jede Antwort

 

Schöne Grüße

Chris

[Dirk_privat 10]

Servus,

 

ganz wichtig bei SQL oder auch bei anderen DB´s, ist die Transaction logs auf eine andere Platte zu moven. Sind die DB und die Logs auf der gleichen physikalischen HD? Gib mal ein paar mehr Infos´zu Deinem System. Wieviel RAM, was für Platten, was läuft sonst noch drauf?

 

Gruß

Dirk

[Cybquest 36]

Vor längerer Zeit hatte ich auch mal ein Problem mit einem langsamen SQL-Server. Der RAM, den der SQL-Server belegen darf, wird ja in dessen Parametern definiert und dort hatte ich damals 20 statt 200MB drin. Nach der Änderung auf 200 gings dann richtig fix :)

 

Aber wie gesagt, das war "damals"... WIN NT, SQL 6.5 ;)

 

Gruß, Frank

[christophorus 11]

Der Server ist ein FSC mit einem Dual Core Xeon 5130 und 4 GB RAM sowie windows 2003R2 und zwei 15k sscsi platten im Raid 1 -

Hab eine C und E Partition. Auf C ist System und SQL Server installiert und auf E sind die SQL Server Daten und Log Dateien.

[Dirk_privat 10]

Servus,

 

so wie Dein System aussieht ist es klar, daß Du Performance Probleme hast. Du hast das System, die Auslagerungsdatei, die Transaction logs und die DB´s auf einer physikalischen Disk.

Den schnellsten ERfolg erzielst Du, wenn Du zwei zusätzliche 15k HD´s einbaust im RAID1 und den SQL darauf verschiebst. Am allerbesten wäre natürlich RAID1 für das System, noch ein RAID1 für die logs und ein weiteres RAID1 für die DB´s. Das hängt natürlich auch von der Anzahl der User ab. Aber im Moment läuft alles auf einer Platte, das kann schon zäh sein.

 

Gruß

Dirk

[christophorus 11]

Das macht mich noch echt Wahnsinnig hier mit dem Server :-(

hab eigentlich "nur" 20 User.

Wollte jetzt mal ein testsystem aufsetzten mit einer Solid State Disk auf die ich die DB legen wollte. Hab da schon einiges gelesen und mich schlau gemacht in die Richtung. Leide ist das ganz doch etwas teuer im Moment. 5000 Euro mag ich nicht dafür hinlegen.

Werde erstmal das Festplatten Thema lösen und dann schau ich mal weiter. Danke für die Unterstützung.

 

Schöne Grüße

Chris

[BuzzeR 10]

Hi christophorus.

 

Solid State Disks sind im Enterprise Bereich kein Thema ... vertrau mir. Vielmehr ist

die intelligente Verteilung von Diensten und wie diese genutzt werden ein wichtiger

Punkt.

 

Ein ausgewachsenener SQL-Server hat selbst bei so intensiven Aufgaben, wie

der Poduktionsplanung und Steuerung (PPS) keinerlei Probleme, sofern die DB

und die darauf zugreifenden Applikationen entsprechend angelegt wurden.

 

Um was für eine Anwendung handelt es sich bei Dir genau?

Was sind für Dich komplexe Anfragen?

 

LG

BuzzeR

[christophorus 11]

Es handelt sich um ein Warenwirtschaftssystem das mittlerweile aus 170 Tabellen besteht.

Bei sehr komplexen Abfragen die Werte aus verschiedenen Tabellen zusammenfügen dauern die Abfragen schon sehr lange (ca. 5-10 Minuten)

Es handelt sich um ein erworbenes System keine Eigenentwicklung :-)

Ich habe jetzt über die Feiertage eine Testdatenbank erstellt auf einer Solid State Disk und einem sehr schwachen System um vergleichsdaten zu bekommen. Das Ergebniss war nicht überraschend, durch die geringen Zugriffszeiten konnte reduzierte sich die Wartezeit auf ca. 2 Minuten bei der identischen Abfrage. Die Ergebnisse werden hier über die Microsoft Reporting Services ausgegeben.

Warum meinst du würde ein SSD hier nichts bringen? Der Datentransfer spielt hier in der DB keiner große Rolle. Das Augenmerkt richtet sich auf schnelle Datenbereitstellung sowie ein schnelles Reportingsystem. Natürlich könnte ich jetzt ein weiteres Raid1 in den Server hängen um die DB und LOG Dateien zu spliten, aber welche Argumente sprechen nun gegen SSD? Der Vorteil ist denke ich ganz klar, deutliche geringere Zugriffszeiten. Der nachteil duch die 5000000 Schreib/Lesecyklen erscheint mir durch die inteligente Datenverteilung keiner mehr zu sein. Bei den Enterprise SSD's werden die daten auf die Disk verteilt obwohl es sich um die gleichen Daten handelt z.B. Auslagerungsdatei. Natürlich hat alles seienn Preis, aber 1000 Euro für eine derarttige Preformancesteigerung ist denke ich vertretbar wenn man die Preise von SSCSI 15K Platten als Referenz heranzieht oder?

Scheint sich hier wirklich zu einem sehr interessanten Thema zu entwickeln, ich danke allen für Ihre Beteiligung,Ideen und Ratschläge.

 

Schöne Grüße

Chris

[hh2000 10]

Moin,

 

es sollte vor Umbauarbeiten vorher ermittelt werden, wo es denn hängt. So kann man den Index-Optimierer durchlaufen lassen und sich auch mal den Ausführungsplan des betroffenen View anschauen.

Stichwort TableScan, gruppierter Index, Index usw. Da kann tlw. sehr viel Performance verloren gehen.

 

Falls Du die DB als Kopie auch zum testen zur Verfügung hast, würde ich erstmal damit

experimentieren.

 

Ansonsten würde ich - wenn nötig - wie schon oben vorgeschlagen, die DB-Daten und Log-Dateien physikalisch trennen.

 

Gruß Kai

[Weihnachtsmann 10]

Viele Infos zur Performance Optimierung gibts auf SQL Server Database Performance Tuning And Other Articles

 

Ich würde aber auch auf die Festplatten tippen. Evtl. könntest du mit perfmon während eine Abfrage läuft mal analysieren wo der Flaschenhals liegt.

 

Gruß

Weihnachtsmann

[substyle 20]

Bei riichtig heftigem Workload kann auch eine Raid Controller mit Cache

weiterhelfen (nachdem das RAID subset optimiert wurde)

Man sollte jedoch nur zertifizierte Hardware einsetzen. (WriteCacheing)

 

subby

 

P.S.: Auch SAS ist mal einen Blick wert!