none
Geringe CPU - Last bei SQL 2008 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    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???

    Mittwoch, 13. März 2013 18:49
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden
    Ich denke es könnte an den Standardeinstellung des Logfiles liegen.

    Aktuell steht es auf : Automatische Vergrößerung.
    Dateivergrößerung: in Prozent = 10

    autsch, 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.

    Mittwoch, 13. März 2013 19:51
    |
  • Question
    Anmelden
    0
    Anmelden

    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-gehoert

    Probiere 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/

    Donnerstag, 21. März 2013 08:22
    |
    Beantworter

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    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
    Mittwoch, 13. März 2013 18:51
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Danke schon mal für den Tip,

    aber warum werden nicht mehr CPU benötigt. Das ist ja genau so als hätte ich einen Ferrari und fahr auf der Autobahn nur 60KMH.

    Bei verschachtelten Selects habe ich das gleiche Problem.

    Mittwoch, 13. März 2013 18:55
    |
  • Question
    Anmelden
    0
    Anmelden

    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.

    Mittwoch, 13. März 2013 19:03
    |
  • Question
    Anmelden
    0
    Anmelden

    Wir haben 2008 ohne R2

    Die Last auf den Platten ist auch niedrig.
    Dort sind SAS Platten mit 10.000 U/min

    Ich denke es könnte an den Standardeinstellung des Logfiles liegen.
    Aktuell steht es auf : Automatische Vergrößerung.
    Dateivergrößerung: in Prozent = 10

    Maximale Dateigröße: Beschränkt vergrößerbar(MB) 2.097.152

    Mittwoch, 13. März 2013 19:31
    |
  • Question
    Anmelden
    0
    Anmelden
    Ich denke es könnte an den Standardeinstellung des Logfiles liegen.

    Aktuell steht es auf : Automatische Vergrößerung.
    Dateivergrößerung: in Prozent = 10

    autsch, 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.

    Mittwoch, 13. März 2013 19:51
    |
  • Question
    Anmelden
    0
    Anmelden

    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.


    Mittwoch, 13. März 2013 19:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Mit Truncate gehts ruckzuck.
    Ich werde gleich mal die Transferdatei verkleinern, und dann auf einen festen Wert setzen.

    Mittwoch, 13. März 2013 20:00
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    ist die Thematik noch aktuell?

    Gruss,
    Raul

    Raul 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.

    Montag, 18. März 2013 11:00
    |
  • Question
    Anmelden
    0
    Anmelden

    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-gehoert

    Probiere 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/

    Donnerstag, 21. März 2013 08:22
    |
    Beantworter