Benutzer mit den meisten Antworten
Geringe CPU - Last bei SQL 2008

Frage
-
Hallo,
wir haben einen SQL Server 2008(version10.0) mit SP3.
Die Hardware ist ein HP DL380 mit 2 XEON Prozessoren und 32GB Ram.
Aber irgendwie wird die Hardware nicht richtig ausgenutzt.Beispiel:
In einer Tabelle habe ich ca. 620.000 Datensätze.
Da dies alles nur Logs sind, möchte ich diese mit delete myTable zu löschen.
Das dauert nun schon über 20 Minuten. Die CPU-Last liegt bei 1% abundzu gibt es dann mal 10% das war es aber auch schon.Gibt es eine Einstellung wie ich Last auf die CPU bekomme??
Kann mir da jemand weiterhelfen???
Antworten
-
Ich denke es könnte an den Standardeinstellung des Logfiles liegen.
Aktuell steht es auf : Automatische Vergrößerung.
Dateivergrößerung: in Prozent = 10autsch, das tut weh.
bitte ASAP auf einen feste Groesse xx MBs aendern.
da das Log unterdessen schon x-mal vergroessert wurde, ist das Logfile stark fragmentiert und damit extrem ineffizient.
Du solltest daher das Logfile bei naechster Gelegenheit auf 1MB shrinken und dann in 8192 MB Schritten auf die notwendige Groesse expandieren - damit ist die interne Struktur des Logfiles vernuenftig konfiguriert.
Je nach eurer Situation solltest du zwingend das Wachstum des Logfiles einschraenken so dass nicht versehentlich die Disk(s) gefuellt werden und ein Ruecksetzen in Normalzustand dann vielleicht aufgrund fehlendem Diskplatz nicht mehr problemlos moeglich ist
Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.
- Als Antwort markiert Raul TalmaciuMicrosoft contingent staff Montag, 25. März 2013 10:46
-
Hallo Daniel,
prinzipiell hast Du Recht, aber die pauschale Empfehlung mit 8 GB kann ich so nicht stehenlassen:
http://www.insidesql.org/blogs/cmu/sql_server/schon-mal-von-vlfs-gehoertProbiere doch bitte mal die Performance bei Dir mit den dort beschriebenen Skripten aus.
Für die meisten Anwendungen dürften 8 GB einfach zu viel sein.Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP
http://www.insidesql.org/blogs/cmu/- Als Antwort markiert Raul TalmaciuMicrosoft contingent staff Montag, 25. März 2013 10:46
Alle Antworten
-
Hi,
zuerst solltest Du mal schauen, was da überhaupt passiert. Kann es sein, dass die Tabelle noch Referenzen auf andere Tabellen, die evtl. auch wieder Referenzen auf weitere Tabellen, ... hat?
Falls es keine Referenzen gibt, kannst Du die auch mittels TRUNCATE TABLE <DeineTabelle> leeren, das sollte schneller gehen.
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community- Als Antwort vorgeschlagen Uwe RickenMVP Donnerstag, 14. März 2013 10:02
-
hast Du schon mal nachgeschaut ob nicht der Disk I/O den Engpass darstellt und die Daten nicht ausreichend schnell geliefert werden koennen.
Beim Schreiben in die DB - z.b. DELETE, INSERT, UPDATE - werden die Aenderungen zuerst im Log geschrieben. Hast Du mal geprueft, ob das Logfile nicht staendig vergroessert wird und dabei die unsinnigen Defaultwerte benutzt werden ?
Ich nehme mal an, dass Du mindestens Windows Server 2008R2 benutzt, dann kannst Du im Taskmanager den Resource Monitor oeffnen und dort die Disk Performance anschauen um herauszufinden ob eine Diskqueue aussergewoehnlich gefuellt ist.
Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.
-
Wir haben 2008 ohne R2
Die Last auf den Platten ist auch niedrig.
Dort sind SAS Platten mit 10.000 U/minIch denke es könnte an den Standardeinstellung des Logfiles liegen.
Aktuell steht es auf : Automatische Vergrößerung.
Dateivergrößerung: in Prozent = 10Maximale Dateigröße: Beschränkt vergrößerbar(MB) 2.097.152
-
Ich denke es könnte an den Standardeinstellung des Logfiles liegen.
Aktuell steht es auf : Automatische Vergrößerung.
Dateivergrößerung: in Prozent = 10autsch, das tut weh.
bitte ASAP auf einen feste Groesse xx MBs aendern.
da das Log unterdessen schon x-mal vergroessert wurde, ist das Logfile stark fragmentiert und damit extrem ineffizient.
Du solltest daher das Logfile bei naechster Gelegenheit auf 1MB shrinken und dann in 8192 MB Schritten auf die notwendige Groesse expandieren - damit ist die interne Struktur des Logfiles vernuenftig konfiguriert.
Je nach eurer Situation solltest du zwingend das Wachstum des Logfiles einschraenken so dass nicht versehentlich die Disk(s) gefuellt werden und ein Ruecksetzen in Normalzustand dann vielleicht aufgrund fehlendem Diskplatz nicht mehr problemlos moeglich ist
Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.
- Als Antwort markiert Raul TalmaciuMicrosoft contingent staff Montag, 25. März 2013 10:46
-
In einer Tabelle habe ich ca. 620.000 Datensätze.
Da dies alles nur Logs sind, möchte ich diese mit delete myTable zu löschen.das sind nicht unbedingt sehr viele Datensaetze und deshalb sollte die Performance schon besser sein.
wie Stefan schreibt, wenn Du alle Records der Tabelle loeschen musst/moechtest, solltest Du besser Truncate Table benutzen falls keine ForeignKey Referenzen auf die Tabelle existieren, dann erfolgt das Loeschen in Sekundenbruchteilen und auch das Log wird nicht mit den geloeschten Records gefuellt.
Falls Du einzelne Records in der Tabelle loeschen moechtest, verwendet die Tabelle einen clustered index oder ist es ein Heap Tabelle ?
Please use Mark as Answer if my post solved your problem and use Vote As Helpful if a post was useful.
- Bearbeitet Daniel_Steiner Mittwoch, 13. März 2013 19:57
-
Hallo,
ist die Thematik noch aktuell?
Gruss,
RaulRaul Talmaciu, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können. -
Hallo Daniel,
prinzipiell hast Du Recht, aber die pauschale Empfehlung mit 8 GB kann ich so nicht stehenlassen:
http://www.insidesql.org/blogs/cmu/sql_server/schon-mal-von-vlfs-gehoertProbiere doch bitte mal die Performance bei Dir mit den dort beschriebenen Skripten aus.
Für die meisten Anwendungen dürften 8 GB einfach zu viel sein.Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP
http://www.insidesql.org/blogs/cmu/- Als Antwort markiert Raul TalmaciuMicrosoft contingent staff Montag, 25. März 2013 10:46