none
Freigabe von Arbeits-Speicher im SQL-Server RRS feed

  • Frage

  • Hallo,

    ich hoffe ich trete jetzt keine Fundamental-Diskussion vom Haufen. Mein Kenntnisstand hinsichtlich RAM-Nutzung unter SQL-Server ist wie folgt:

    • ich definiere dem Server / der SQL-Server-Instanz, wie viel RAM ihr maximal zur Verfügung steht
    • dieser RAM wird Stück für Stück genutzt, bis er voll ist. Hat man eine 10GB Datenbank und 20GB RAM zugewiesen, wird also irgendwann die gesamte DB im RAM liegen (vorausgesetzt, dass jede Ecke der DB mal abgefragt wurde)
    • der RAM wird solange in Beschlag genommen, bis der Server neu gestartet wird
    • wird über den definierten Maximalwert Speicher benötigt, wird die Temp-DB angezapft und zugemüllt

    Soweit korrekt?

    Nun denn, dann das folgende Szenario: Ich habe auf dem Server 100 Datenbanken, 99 davon sind eher weniger wichtig und werden auch nur gelegentlich genutzt. Diese 99 Datenbanken sind je 1 GB groß. Dann habe ich eine wichtige DB, die 80GB groß ist. Der Instanz habe ich 100GB RAM zugewiesen.

    Wie animiere ich den SQL Server jetzt bevorzugt Daten in den RAM zu legen, der für die wichtige DB benötigt wird, und RAM für die 99 kleinen DB wieder freizugeben. So wie ich es bisher verstehe, "müllt" der RAM Stück für Stück mit den Abfragen zu - wenn also Abfragen gegen die 99 x 1GB Datenbanken gefahren werden, blockieren diese Daten meinen Speicher und Dtaen für die wichtige DB müssen dann in's Pagefile..

    Oder andersrum: Wie kann ich den SQL Server vom nutzen der Pagefile abhalten und ihn animieren, doch lieber etwas Speicher wieder freizugeben?

    Montag, 3. August 2015 12:58

Antworten

  • Hallo,

    das ist so erst mal nicht möglich, der SQL Server verwaltet den verwendeten Speicher so, wie er es für richtig hält und in der Regel ist es so auch am besten; siehe MSDN Memory Management Architecture . Früher gab es eine PinTable Funktion, um Tabellen zu markieren, das sie möglichst permanent im Speicher gehalten wird; das ist weg gefallen, weil es eben dem Dynamic Memory Management entgegenstand.

    Eine Option wäre, eine zweite SQL Server Instanz auf dem Server zu installieren, die dann für die "unwichtigen" Datenbanken verwendet wird; den Speicher könntest Du dann zu 90% auf die wichtige und 10% auf die unwichtige Instanz zuweisen.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]


    Dienstag, 4. August 2015 06:33

Alle Antworten

  • Hallo,

    das ist so erst mal nicht möglich, der SQL Server verwaltet den verwendeten Speicher so, wie er es für richtig hält und in der Regel ist es so auch am besten; siehe MSDN Memory Management Architecture . Früher gab es eine PinTable Funktion, um Tabellen zu markieren, das sie möglichst permanent im Speicher gehalten wird; das ist weg gefallen, weil es eben dem Dynamic Memory Management entgegenstand.

    Eine Option wäre, eine zweite SQL Server Instanz auf dem Server zu installieren, die dann für die "unwichtigen" Datenbanken verwendet wird; den Speicher könntest Du dann zu 90% auf die wichtige und 10% auf die unwichtige Instanz zuweisen.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]


    Dienstag, 4. August 2015 06:33
  • Hallo Olaf,

    danke für die Antwort. Leider fällt die Option mit der zweiten Instanz flach, hat zum Einen lizenztechnische Aspekte, zum Anderen das Problem, dass die Anwendung, die den Server hauptsächlich nutzt, nur gleichzeitig in einer Instanz arbeiten kann und aber auf alle DBs Zugriff benötigt..

    Dienstag, 4. August 2015 07:26
  • Da der SQL Server 2014 nun doch schon eine Weile auf dem Markt, und das Folge-Release (SQL Server 2016) auch nicht mehr fern in der Zukunft liegt, wage ich mal eine weitere Variante anzudeuten:

    Mit der neuen In-Memory Engine "XTP" lassen sich sogenannte memory optimized Tabellen und Indexe definieren. Diese liegen dann garantiert immer im Hauptspeicher, und haben noch ganz andere Vorteile wie z.B. komplett Latch- und Lockfreie Zugriffsmechanismen. Als Ersatz für temporäre Tabellen gibt es auch memory optimized Tabellenvariablen, die niemals irgendwie TempDB I/O verursachen.

    :)


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Freitag, 7. August 2015 10:14
  • Hallo Andreas, Danke für den Ausblick, leider wird das wohl noch eine ganze Weile dauern - die Anwendung wird mit kommenden Release SQL2012-kompatibel...
    Samstag, 8. August 2015 06:00
  • Hallo Philipp,
    ich würde erst mal sagen, dass Deine Annahme nicht korrekt ist.
    Siehe hierzu auch diesen Artikel von mir:
    http://www.insidesql.org/blogs/cmu/sql_server/lock-pages-in-memory

    Wird die Speichergrenze erreicht, werden ältere nicht mehr genutzte Seiten aus dem Speicher entfernt. Sollten es noch "Dirty Pages" sein, werden sie zuerst auf Platte geschrieben.
    Welche Datenbanken "wichtig" sind, entscheiden die Anwender durch die Intensität der Nutzung. Genau genommen geht es aber um die Seiten (Pages) in den Datenbanken, denn selbst bei einer 90 GB Datenbank kann es sein, dass sich die Arbeit auf wenige Seiten konzentriert und nur einige hundert MB für eine optimale Nutzung notwendig sind.

    Was sagt denn der Performance Counter "Page Life Expectancy" bei Dir?

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

    Montag, 10. August 2015 08:55
    Beantworter