webbi - Di 03.05.05 14:17
Titel: MS-SQL voll auslasten?

---

Hallo!

Ich habe folgendes Problem:

Ich habe eine MS-SQL 2000 Server mit SP3 auf einem Dual P4 HT Xenon (je 3,06 GHz) mit 2 GB RAM und 2 73 GB SCSI Platten (Raid 1) OS: Windows 2000 Server Sp4

Das Problem ist jetzt, dass ich eine Applikation habe, die den Server kurzzeitig extrem beanspruchen sollte. Allerdings wird der Server offensichtlich kauf belastet (Siehe ScreenShot.jpg) und die Abfrage dauert ca. 10 Sekunden.

Die betreffende Table hat 2 Integer- und 250 SmallInt-Felder

Die ausgeführten Querys (50 Stück) Filtern die Table (Filter über je 100 der 250 SmallInt-Felder) und befüllen danach eines der Integer Felder.
Die Table enthält zur Zeit 50.000 Datensätze und sollte aber auf ca. 10.000.000 erweitert werden.

Mir kommt es einfach nur komisch vor, dass die CPU-Auslastung nicht wirklich ansteigt...

Was kann ich da machen?

Edit: Habe gerade zum testen 50.000 Datensätze von einer Table in eine Andere kopiert (je 252 Fehlder). Es Dauerte 20 Sekunden aber im Task-Manager war kaum Auslastung zu sehen.

MAlsleben - Di 03.05.05 14:42

---

Hi,

als erstes würde ich Hyperthreading ausschalten. Manche Datenbanken laufen dann performanter. Als zweites ist der Spreicher relativ gering ausgelastet. Da müßte noch etwas im SQL-Server umkonfiguriert werden, das er sich mehr Speicher krallt. Und als 3. Aspekt, kommt es immer auf die Operation an. Wenn viele Plattenzugriffe zum Schreiben notwendig sind, geht der Prozessor nicht hoch, weil dann einfach die Platte selbst bei SCSI bremst.

Gruß Micha.

webbi - Di 03.05.05 14:48

---

Danke!

Speicher ist ja absolut nicht ausgelastet...

HT ausschalten problier ich gleich mal...

alzaimar - Fr 06.05.05 20:47

---

Habe Dir im anderen Thread geantwortet... Das hier ist präziser.

Also: Der SQL-Server ist so gut programmiert (wirklich), das man es kaum schafft, die CPU zu 100% zuzuballern. Was Du siehst, ist einfach eine richtige Auslastung der DB. Check mal die Cachehits und die SQL-Server Auslastung.

Deine Queries sind ja nun wirklich 'pervers', wenn Du in der Tat über alle 50000 Felder gehst. Das ist doch nicht wirklich nötig, oder?

Kannst Du das nicht On-The-Fly machen? über ein Trigger? Also, wenn eines der SmallInts verändert wird, passt Du dann eben die INT Felder entsprechend an.

Eins ist klar: SQL-Server ist bei Updates 100% sicher, aber eben lahm. MySQL ist schnell, aber eben nicht 100% sicher. Und Access ist noch schneller, aber eben auch noch unsicherer.

Du musst eintscheiden, was Du willst. Eventuell hilft hier vielleicht wirklich so ein Schrott wie Access, um die Tabelle zu füllen. Dann kannst Du sieh mit Bulkload in den Server blasen und anschliessend bearbeiten. Ach, Möglichkeiten gibt es viele.

webbi - Mo 09.05.05 07:49

---

pervers oder nicht, mir bleibt nichts anderes übrig - Mit Trigger oder so ist es nicht möglich, da sich das Verhältnis von den SmallInt-Felder zu dem INT-Feld jedes Mal Verändert (Es gib 50*190 * 200*2000 verschidene Abfragemöglichkeiten...)

Access und schnell? Was genau meinst du mit Sicher?

Noch was: Ich habe die Datenbank aufgeblasen und dann sieht man die Auslastung schon - Auch auf der Festplatte - Screenschot ist Dabei...

alzaimar - Mo 09.05.05 09:11

---

Du bist ja "cool", gleich zwei Threads mit dem Thema zu öffnen...

Also: Der SQL-Server wartet bei einer Änderung, bis die Daten physikalisch auf der Platte gelandet sind. Deshalb ist der SQL-Server sicher wie Fort Knox. Access macht sich nicht die Mühe, und ist deshalb ca. 10-1000 x schneller (Schätzung) als eine echte DB. Dafür solltest Du aber auch nicht während des Updates den Stecker ziehen, oder dein Energieversorger dir den Saft abdrehen, oder die Platte eine Macke haben etc.. Gleiches gilt für MySQL, deshalb sind die ja so schnell.

So, um nun 20 MB Daten zu schreiben, benltigt der SQL-Server nun mal eine Weile. Du kannst alles in eine Transaktion packen (wenn du denn 10 Mio UPDATE-Anweisungen hast). Wie im anderen Thread schon vorgeschlagen, würde ich BCP nehmen. Das bringt maximale Performance.

webbi - Di 10.05.05 10:46

---

Habe Das Programm zum testen mal auf Access umgebaut - Dauert deutlich länger...