Hallo!

Ich habe eine Applikation die einen SQL-Server kurzzeitig voll auslastet.
Das passiert mehrmals täglich, muss aber jedes mahl extrem schnell gehen...

Darum dachte ich an parallel-computing.

Nun stellt sich die frage wie das besser zu realisieren ist. Windows/Linux - Welcher SQL-Server?

Ich dachte and 10 Dual Xenon (je 1,7 GHz) Maschinen mit je 2 GB RAM.

Hat jemand Erfahrung mit so was?

Primär wäre zu klären, wodurch der Server ausgelastet wird.
Ist es Prozessorlast? Dann kann ein Dual-Prozessor abhilfe schaffen.
Ist es I/O-Last? Dann hilft dir das sehr wahrscheinlich nicht.

Ich habe es auf einem Dual P4 HT Xenon (je 3,06 GHz) mit 2 GB RAM und 2 73 GB SCSI Platten (Raid 1) getestet und da war der Prozessor voll ausgelastet...

Das beantwortet die Frage nicht.
Ich habe heute aber die "Jasocul-Spezial-Brille-mit-Sonderdurchblick" auf und die sagt mir, dass du größere Aktionen auf der Datenbank machst.
Das würde bedeuten, dass du hohe I/O-Last hast.
Ich würde in dem Fall Linux mit Clustering verwenden. Evtl. genügt schon der Einsatz von Linux, da die Festplattensteuerung dort anders läuft und dadurch schon schneller ist.
Dass die Datenbank das auch unterstützen muss, versteht sich von selbst.
Auch ein Dual-Prozessor nützt dir nichts, wenn die Datenbank ihre Berechnungen nicht verteilen kann.

Platte wären SCSI-Raid 0 oder Fiberchannel... - Da sehe ich also nicht so das Problem....

Kann MY-SQL die Auslastung aufteilen?

Hi,

macht doch mal mit dem Windows-Systzemmonitor verschiedene Messeungen, damit Du erstmal rausbekommst wo der Flaschenhals ist. Einfach ins geradewohl Hardware aufzumotzen ist nicht der richtige Weg.

Gruß Micha.

MAlsleben hat folgendes geschrieben:

macht doch mal mit dem Windows-Systzemmonitor verschiedene Messeungen, damit Du erstmal rausbekommst wo der Flaschenhals ist.

Dass eine Analyse (womit auch immer) notwendig ist, hoffte ich oben schon angedeutet zu haben.
Außerdem wäre vielleicht auch noch die Frage zu klären, was "kurzzeitig" bedeutet.
Neue Hardware bietet sich bei solchen Umstellungen meistens an, da dadurch sicher gestellt ist, dass man bei Installations- oder Folgeproblemen ein funktionierendes System im Rückhalt hat. Das ist allerdings auch eine Preisfrage.

Leistungsmonitor habe ich schon installiert - werde mir das ganze mal anschauen und die Ergebnisse dann posten...

Kurzzeitig bedeutet in diesem Fall, dass das ganze nicht mehr als 30 Sekunden dauern sollte...

Auf dem Test-PC dauert es ca. 5 Minuten...

Die Preisfrage ist übrigens eher nebensächlich...

Habe mir das ganze jetzt angeschaut - die erste Hälfte der Abfrage bremst die Platte - ist ein SQL-Update, die zweite Hälfte der CPU - ist ein SQL-Select...

... die erste Hälfte ist ein Update, die zweite ein Select...
Du meinst sicherlich 'viele' updates... Das riecht nach Überindexierung. Wenn die Tabelle zu viele Indexe enthält, dann ist so ein Update schon mächtig rechenintensiv.

Wenn ein SELECT die CPU zuballert, fehlen meistens Indexe. Oder Du aggregierst eine fette Datenmenge. Oder du saugst eben 1000000 Zeilen. Im ersten Fall hilft eine Indexanalyse, im zweiten eine redundant angelegte Tabelle, die die Aggregate (SUM, MIN, MAX etc.) per Trigger auf der Quelltabelle pflegt.
Im dritten Fall wechsle den Beruf

Die Table hat 2 Indexe - Vom Indexoptimierungs-Assistent überprüft

Und ob 10.000.000 Datensätze a 252 Felder viele Daten sind muss wohl kaum diskutiert werden - Ich kann ich den Beruf noch ein wenig ausüben

Meine Frage war eher die, ob es ein 'UPDATE' Statement ist, oder 10.000.000.

Updates kosten Zeit. Da kann man herzlich wenig machen, ausser:
Wenn die Tabelle jedesmal neu erstellt wird, dann versuche BCP. Schneller als mit BCP gehts nicht.
Und da Du deinen Beruf noch ein wenig ausüben kannst, weisst Du ja auch, wie man damit umgeht.

Es sind 50.

bulk-copy nützt mir leider nichts, da ich die Table ja nie neu aufbaue...

Ich bekomme in nächster Zeit eine Testmachiene mit etwas mehr Leistung (4*3GHz, 32 GB RAM, ...) und dann sehe ich es eh...

Danke inzwischen....

Teste doch mal:

Ob Du die indexe ab/anschaltest oder nicht, wäre zu testen. Bei zwei Indexen meine ich, kann man drauf verzichten...
Der Vorteil wäre, das das INSERT genau eine Operation ist, mit einem Write auf die Platte. Wenn dein Speicher mitmacht, vielleicht klappts.
Ansonsten hilft die schnellere Kiste wohl nix, sondern ein schnelleres I/O subsystem, meinste nich?
Im Internet bin ich mal auf einen Artikel gestossen, der sich mit der Optimierung des SQL-Servers befasst hat. Da stand auch sowas drin. Googel doch mal nach SQL-Server, oder check doch mal [url]www.sqlteam.com[/url]. Nicht das dieser Artikel da drin war, aber da gibts ein Topic über Performance Tuning, vielleicht hilft dir das weiter.

Dein Problem ist wirklich kniffelig. Benötigst du denn die Tabelle *sofort*, oder kannst Du dir nicht den Luxus leisten, sie häppchenweise rüberzuschaufeln? Sowas hab ich mal gemacht, bei mir warens 30 Minuten Volllast mit 20 Tabellen. In der Zeit haben sich die User 'nen Wolf gewartet, also hab ich immer nur ein paar Dinger rübergeblasen, dann gings.

Danke, schau ich mir alles mal an, wenn ich die neue Testmachiene habe...

Die hat übrigens auch schnellere Platten - SCSI und Fiberchannel zum vergleichen...

Die Ergebnisse brauch ich leider sofort...
Die Idee mit dem Aufteilen hatte ich auch schon - aber so, dass die Daten auf mehere Server aufteile und die Ergebnisse dann zusammefasse... Mach schauen, was der Testserver schafft...