none
"Speicherloch" nach MSSQLSERVER Dienst Restart RRS feed

  • Allgemeine Diskussion

  • Hallo,

    nach jedem Restart des SQL-Server Dienstes haben wir anscheinend in Abhängigkeit des verbrauchten Speichers, einen automatischen Prozess des SQL-Servers laufen, den wir nicht identifizieren, bzw. erklären können. Er taucht unabhängig von der Uhrzeit auf und ist eher an einer Speichergrenze festzumachen. Auffällig ist, das durch diesen Prozess eine erhöhte Schreibaktivität in die mdf-Dateien stattfindet. Während diesem Prozess werden innerhalb einer Dauer von 10 Minuten bis zu 50GB Arbeitsspeicher verbraucht und danach wieder freigegeben. Das Ganze wäre nicht tragisch, wenn es nicht gerade während der Benutzeranmeldungen zwischen 7:00 und 10:00 Uhr stattfinden würde. 

    Um welchen Prozess kann es sich hier handeln und wie lässt er sich beeinflussen?

    System: SQL-Server 2012 unter Windows Server 2012.

    Eine entsprechende Grafik kann ich leider noch nicht anhängen.

    Danke & Gruß, Bodo

    Donnerstag, 20. Februar 2014 12:23

Alle Antworten

  • Hallo Bodo,
    auf welchem Stand ist der SQL Server genau? Select @@Version;
    SP1 + CU2 sollten meiner Meinung nach mindestens drauf sein, da hier Fehler im Management des ASP gefixed wurden.

    Schreibt der Prozess in alle MDF-Dateien?
    Wie kannst Du das erkennen?
     Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Donnerstag, 20. Februar 2014 13:31
    Beantworter
  • Gleich noch eine Frage:

    Wie oft macht ihr einen Restart?

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Donnerstag, 20. Februar 2014 13:36
    Beantworter
  • Hallo Christoph,

    danke für die schnelle Rückmeldung. Es ist die Version: Microsoft SQL Server 2012 - 11.0.2100.60 (X64) installiert.

    Soweit ich feststellen konnte wird in alle mdf's geschrieben, soweit sich das bei ca. 200 mdf's überblicken läßt.

    Zu sehen ist der Vorgang im Aktivitätsmonitor vom Management-Studio unter Datendatei-E/A.

    Gruß, Bodo

    Donnerstag, 20. Februar 2014 15:18
  • ... zur Zeit starten wir den Dienst alle 2-3 Tage neu. Nach ca. 3 Tagen beklagen sich User, das es zu Verzögerungen oder Verbindungsabbrüchen kommt und das obwohl keinerlei Anzeichen (Buffer, IO, Cache, Locks, Seitenlebenszeit, usw.) darauf hindeuten und auch noch 35GB Speicher frei sind. Nach einem Restart ist die Welt wieder in Ordnung.

    Ciao, Bodo

    Donnerstag, 20. Februar 2014 15:19
  • Ich würde stark empfehlen, der Ursache auf den Grund zu gehen.

    Ein SQL Server Neustart leert den Cache und birgt dadurch allein schon eine Ursache für Performance-Probleme im Anschluss. - Das das jetzt weniger gravierend ist, als das ursächliche Problem, zeigt ja nur, das das Problem wirklich groß ist, so dass der Neustart weniger ins Gewicht fällt. - Auch müssen alle Datenbanken nach dem Start recovered werden. (Dabei werden unter Umständen auch die mdfs beschrieben.)


    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com

    Freitag, 21. Februar 2014 09:37
  • Hallo Bodo,
    dann ist die Ursache klar.
    Mit der RTM Version macht ihr keine vernünftige Produktion.
    Minimum SP1 und CU2, besser noch das aktuellste CU einspielen!

    http://support.microsoft.com/kb/2769594
    SQL Server 2012 experiences out-of-memory errors

    Cumulative update information:
    - Cumulative Update 2 for SQL Server 2012 SP1
    - Cumulative Update 5 for SQL Server 2012
     Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Freitag, 21. Februar 2014 11:10
    Beantworter
  • Danke für die Infos! Ich denke damit kommen wir schon mal ein großes Stück weiter. 

    Das die Neustarts keine langfristige Lösung sind ist uns klar. Die Fehlersuche gestaltet sich nur als sehr aufwändig. Aber vielleicht kommen wir mit dem von Christoph beschriebenen Update weiter.

    Gibt es eine Möglichkeit, den SQL-Server "geregelt" neu zu starten, also ohne das recover der Datenbanken auszulösen? Das wäre nur um die nächsten Tage zu überbrücken, bis wir die SP's und CU's eingespielt haben, mit der Hoffnung auf Besserung.

    Danke Euch Beiden!

    Viele Grüße, Bodo

    Freitag, 21. Februar 2014 14:38
  • Vielen Dank für die Info. Das klingt sehr vielversprechend. Ich werde über die Ergebnisse berichten.

    Viele Grüße, Bodo

    Freitag, 21. Februar 2014 14:40
  • ...

    Gibt es eine Möglichkeit, den SQL-Server "geregelt" neu zu starten, also ohne das recover der Datenbanken auszulösen? Das wäre nur um die nächsten Tage zu überbrücken, bis wir die SP's und CU's eingespielt haben, mit der Hoffnung auf Besserung.

    ...

    Der SQL Server muss immer sicherstellen, das er die Datenbanken in einem konsistenten Zustand hat. Und nach einem Neustart weiß er das erst nach dem Recovery-Prozess. Man kann natürlich vor dem Stoppen einen manuellen Checkpoint auf der jeweiligen Datenbank ausführen, und somit die Zeit dafür vorziehen, so dass er weniger nach dem Neustart "Checkpointen" muss. Ob das lohnt, muss man von Fall zu Fall entscheiden. Jedenfalls kann man es damit manuell steuern.

    Viel Erfolg


    Andreas Wolter (Blog | Twitter)
    MCM - Microsoft Certified Master SQL Server 2008
    MCSM - Microsoft Certified Solutions Master Data Platform, SQL Server 2012
    www.andreas-wolter.com | www.SarpedonQualityLab.com

    Sonntag, 23. Februar 2014 11:49
  • Die Zeit für das Recovery hängt auch von der Anzahl der VLFs ab. Siehe hierzu:
    http://www.insidesql.org/blogs/cmu/sql_server/schon-mal-von-vlfs-gehoert
    http://www.insidesql.org/blogs/cmu/sql_server/aenderungen-bei-dbcc-loginfo

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Montag, 24. Februar 2014 11:22
    Beantworter