8
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.
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.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 164877
Url: https://administrator.de/contentid/164877
Ausgedruckt am: 17.11.2024 um 16:11 Uhr
8 Kommentare
Neuester Kommentar
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
Gruß
Anton
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
Gruß
Anton
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.
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
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
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.
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
benutzen die vielen Einzelabfragen Indizies, oder ist jedesmal ein full table scan notwendig ?
Evtl. lindert es Dein Problem, entsprechende Indizies anzulegen.
Gruß
Anton
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.
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
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
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.
