onnlein
Goto Top

MS SQL 2000 Lastprobleme

Ressourcenmanagement möglich?

Hallo zusammen,

ich habe hier einen Windows Server 2000 auf einem virtuellen Win 2003 64Bit Standard. Der VM steht ein Core eines E5410 und 8 GB RAM zur Verfügung. Nicht viel, reicht aber für alles bis auf eines aus: Es gibt eine Anwendung, die den ganzen Server lahmlegt mit Stundenlangen Importvorgängen, die sehr aufwändige Prüfungen beinhalten. So lange die Ressourcen so limitiert sind, wäre es fantastisch, wenn ich diesen Vorgang (wird immer vom selber Programm durchgeführt) limitieren könnte, so dass die anderen Anwendungen nicht langsamer werden. Ich kann auch in die SQL-Statements eingreifen. Clients sind 90% XP Pro 32bit, Rest Win7 64 bit.

Der SQL-Prozess nimmt sich eigentlich kaum mal über 2 GB RAM, ansonsten läuft auf der Maschine nichts.

Gibt es da eine Möglichkeit? Ich bin mir sicher, dass man den Code optimieren könnte, aber eine Zwischenlösung wäre wirklich hilfreich.

schönen Dank vorab.

Content-ID: 164877

Url: https://administrator.de/forum/ms-sql-2000-lastprobleme-164877.html

Ausgedruckt am: 23.12.2024 um 12:12 Uhr

Anton28
Anton28 19.04.2011 um 18:07:40 Uhr
Goto Top
Hallo Onnlein,

wenn Du das Problem schon identrifiziert hast, was hindert Dich daran, diesen Server wieder ein eigenes Blech zu geben ?

Ich denke, weder die Cpu noch das RAM sind Dein großes Problem, sondern der durchsatz Richtung Platten !

Nur weil man einen SQL-Server virtualisieren kann, muss es eine gute Lösung sein face-smile

Gruß

Anton
Onnlein
Onnlein 19.04.2011 um 18:18:47 Uhr
Goto Top
Bin mir nicht sicher, dass es wirklich an der Virtualisierung liegt. Der Importvorgang ist recht exotisch, da gibt es auch keine richtigen Vergleichswerte. Für den "Normalbetrieb" gibt es keine Probleme. Zudem glaube ich, dass ein eigenes Blech nur in einem schnelleren Import resultiert, dieser aber die Maschine trotzdem zu 100% auslasten wird. Es wäre in jedem Fall gut, solche zeitlich unkritischen Aufgaben niedriger priorisieren zu können, damit Aufgaben mit Userinteraktion zügig laufen.
Anton28
Anton28 19.04.2011 um 18:27:44 Uhr
Goto Top
Hallo Onnlein,

was lastet den Deiner Meinung nach die VM aus ?

Wie lange und wie oft läuft dieser exotische Import Job ?

Wie groß ist denn Deine Datenbank ?

Wie groß ist das Transaktionslog ?

Wie wird ein commit gesetzt ?

Gruß

Anton
Onnlein
Onnlein 19.04.2011 um 18:37:43 Uhr
Goto Top
Zitat von @Anton28:
was lastet den Deiner Meinung nach die VM aus ?

Die vielen einzelnen SQL-Statements, teilweise mit Join. Die relationale Datenbank wird hier ziemlich vergewaltigt, ist aber momentan halt so. Wird besser, bis dahin hätte ich gerne Linderung.


Wie lange und wie oft läuft dieser exotische Import Job ?

Jobs laufen komprimiert recht oft, je 30 bis 120min.


Wie groß ist denn Deine Datenbank ?

Haupt-DB 1,3 GB, Hilfsdatenbank 8GB. MDF/LDF je ähnlich groß. Wöchentliche Verkleinerung.


Wie wird ein commit gesetzt ?

Commit sollte über kompletten Import laufen. Aber das schreiben ist gar nicht das große Problem, sondern die vielen Einzelabfragen bei der Überprüfung. Der Lastunterschied zwischen Simulation und tatsächlichem Import ist gering.
Anton28
Anton28 19.04.2011 um 18:41:59 Uhr
Goto Top
Hallo Onnlein,.

benutzen die vielen Einzelabfragen Indizies, oder ist jedesmal ein full table scan notwendig ?

Evtl. lindert es Dein Problem, entsprechende Indizies anzulegen.

Gruß

Anton
Onnlein
Onnlein 20.04.2011 um 11:38:22 Uhr
Goto Top
Naja, Problem hierbei ist, dass ich oft genau einen Datensatz identifizieren und holen muss. Das Query ist recht optimiert und wahrscheinlich weniger das Problem - also die Ausführungszeit selber. Nur dass es etliche Tausende einzelne Abfragen sind ist wahrscheinlich problematisch.
Anton28
Anton28 20.04.2011 um 13:03:42 Uhr
Goto Top
Hallo Onnlein,

was sind denn das für sonderbare Daten ?
Welche Anwendung ist das ?
Nach welechen Kriterien wird der Datensatz ermittelt ?
Selbst wenn Du nur einen Datensatz brauchst und dieser nicht über eine eindeutige Satznummer in der Tabelle ermittelt werden kann, endet Deine Query in einem
full table scan ?

Gruß

Anton
Onnlein
Onnlein 20.04.2011 um 14:00:27 Uhr
Goto Top
Das sind massenhaft manuell erhobene Daten, in der Quelldatei ohne richtigen Schlüssel. Um die einzulesen, muss ich vorher überprüfen, ob dieser Datensatz prinzipiell schon existiert, identisch ist oder sich an den Nutzdaten geändert hat.