none
Pages im RAM RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo Allerseits,nach meinem Kenntnisstand versucht der SQLServer immer, Pages im Speicher zu halten, um Abfragen schnell bedienen zu können. Kann man also von einer In-Memory-Datenbank sprechen?

    Und ist dieses Cache-Verhalten auch in der Azure-Cloud so vorhanden. Konkret bei SQL Server Managed Instance?

    Virenfreie Grüße Und Dankeschön

    Olaf

    Mittwoch, 18. März 2020 15:55
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Nein, eine In-Memory-DB hat alles im Memory und kann daher die Tabellenobjekte in einer effizienteren Methodik speichern. Bevorzugt sei hier die Column-Speicherung statt der Row-Speicherung genannt.

    Dieses Cache-Verhalten ist eine grundsätzliche Eigenschaft jeder Datenbank, da letztlich ja alles für den Zugriff im Speicher liegen muss.

    Mittwoch, 18. März 2020 17:40
    |
  • Question
    Anmelden
    0
    Anmelden

    Außerdem werden bei einer In-Memory-Datenbank nicht alle Objekte persistiert, so dass es zu Datenverlusten kommt, wenn der Server gebootet wird. Das kann durchaus gewünscht sein, wenn es sich hier z. B. um Verwaltungsdaten aktueller Sessions handelt, die es danach ja nicht mehr gibt.

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

    Donnerstag, 19. März 2020 06:54
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden
    Aber solange genügend RAM-Speicher vorhanden, bleiben einmal geladene Seiten im Speicher, richtig?
    Donnerstag, 19. März 2020 09:02
    |
  • Question
    Anmelden
    0
    Anmelden

    Beim SQL-Server wird die Größe des benötogten RAM eindeutig festgelegt.
    Wie hoch das Paging der Seiten (also das verdrängen) ist, kannst du hier prüfen:
    https://docs.microsoft.com/de-de/sql/relational-databases/performance-monitor/monitor-memory-usage?view=sql-server-ver15

    Allerdings gibt es genügend Plattenaktivitäten beim Schreiben von Transaktionslogs sowie Tabellenupdates (Insert/Update/Delete), die bei einer In-Memory-DB gar nicht stattfinden.

    Somit bist du immer noch von einer In-Memory-DB weit entfernt.

    Willst du eine vergleichbarkeit, solltest du dir eine RAM-Disk anlegen, die deine DB sowie Logs aufnehmen kann, eine SQL-Server-Instanz mit max. 1GB Speicher erstellen und die DB im Read-Only-Modus betreiben.
    Ein echter Vergleich ist das aber nicht.

    Donnerstag, 19. März 2020 09:13
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Olaf,

    "... versucht der SQLServer immer, Pages im Speicher zu halten, um Abfragen schnell bedienen zu können."

    Genau so ist es. Grundregel bei jedem RDBMS; Daten können nur aus dem RAM verarbeitet werden! Das gilt auch für DML-Operationen. Jeder Schreibprozess lädt erst die Datenseite(n) in den Arbeitsspeicher und schreibt erst dort die Daten!

    Das ist vollkommen unkritisch, da Microsoft SQL Server die Aktionen im Transaktionslog persistiert! Bei einem Neustart des Servers können also die bestätigten Transaktionen mittels REDO in der Datenbank persistiert werden und nicht vollendete Transaktionen werden mittels UNDO rückgängig gemacht.

    "Kann man also von einer In-Memory-Datenbank sprechen?"

    Das hängt von "Deiner" Interpretation ab. Eine echte InMemory-Tabelle liefert für das Lesen nicht unbedingt bessere Werte als eine "Disk-based"-Tabelle. Der eigentliche Vorteil einer der InMemory-Technologie liegt darin, dass es keine Sperren mehr gibt!

    Jos de Bruijn (Microsoft) hat die Technologie in einem Video erklärt:

    https://www.youtube.com/watch?v=l5l5eophmK4&t=0

    "Und ist dieses Cache-Verhalten auch in der Azure-Cloud so vorhanden. Konkret bei SQL Server Managed Instance?"

    Einfach ausgedrückt: Ja. PaaS ist nichts anderes als ein Microsoft SQL Server, der Deine Datenbanken hostet. Für Operations ist Microsoft zuständig. Die Technologie ist die Gleiche!

    Bleibt alle gesund in diesen Tagen...

    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Donnerstag, 26. März 2020 16:48
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Suchender,

    "Allerdings gibt es genügend Plattenaktivitäten beim Schreiben von Transaktionslogs sowie Tabellenupdates (Insert/Update/Delete), die bei einer In-Memory-DB gar nicht stattfinden."

    Das stimmt so nicht ganz. Auch InMemory-Tabellen müssen Checkpoints schreiben (unabhängig davon, ob sie SCHEMA_ONLY oder SCHEMA_AND_DATA angelegt werden).

    Hier kann man es genauer nachlesen:

    https://docs.microsoft.com/de-de/archive/blogs/sqlcat/logging-and-checkpoint-process-for-memory-optimized-tables-2

    Bleibt alle gesund in diesen Tagen

    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Donnerstag, 26. März 2020 16:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich sprach ja auch von In-Memeory-DB's.
    Die haben keine Plattenaktivitäten außer ich synchronisiere sie tatsächlich noch mit der DISK.
    I.d.R. passiert dies allerdings eher zyklisch als transaktionsorientiert.

    Speicheroptimierte Tabellen sind nur Elemente einer normalen diskorientierten Datenbank um Optimierungen durchzuführen.

    Die Gefahr bei In-Memory-DB's ist eben: Strom weg, Datenbank weg.

    Donnerstag, 26. März 2020 17:30
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Suchender,

    wenn Du Consistency und Durability für Deine Daten brauchst, musst Du IMMER auf die Disk schreiben; das gilt natürlich auch für InMemory-Datenbanken.

    Checkpoint-Consistency wird durch drei Techniken sichergestellt:

    FUZZY

    Ein Prüfpunkt wird durchgeführt ohne Garantie für den Status des Wertes, der gesichert wird

    Action Consistent

    Jeder gesicherte Wert, der durch einen Prüfpunkt gesichert wird, ist garantiert atomar und enthält einen korrekten Wert

    Transaction Consistent

    die konsistenteste aller drei Garantien, bei denen der Status des Prüfpunkts transaktionskonsistent ist

    Quelle: http://www.dbis.informatik.hu-berlin.de/fileadmin/lectures/WS2015_16/NeueKonzepte_VL/MainMemoryDatabaseSystemsAnOverview.pdf

    Unabhängig von der Methode ist doch eines sicherlich unbestreitbar. Persistente Daten MÜSSEN auf einem persistenten Datenträger gespeichert werden. Die einzige Frage, die sich hier stellt, ist die, wie aufwändig der Schreibprozess ist.

    Eine speicheroptimierte Tabelle mit der Option SCHEMA_AND_DATA zeichnet die Transaktionen in der Logdatei auf. Diese Transaktionen werden jedoch nur geschrieben, wenn die Transaktion committed ist.
    Dies unterscheidet sich von den festplattenbasierten Tabellen, die einen Write-Ahead-Mechanismus verwenden.

    Bei speicheroptimierten Tabellen wird der Checkpoint von einem Worker-Thread in der In-Memory-OLTP-Engine ausgeführt, der sich von den Checkpoint-Threads für die festplattenbasierten Tabellen unterscheidet. Der speicheroptimierte Checkpoint schreibt die Daten, die neu eingefügten Daten enthalten, in die Datendateien. Der "Delta-Stream" enthält alle gelöschten Daten, in die Delta-Dateien geschrieben werden.
    Diese Daten und Delta-Dateien, die als Checkpoint File Pairs (CFPs) bezeichnet werden, werden sequentiell geschrieben. Wichtig ist, dass eine UPDATE-Operationen als DELETE- und dann INSERT-Operationen betrachtet wird!

    Long Story short: Auch InMemory-Datenbanke oder InMemory-Tabellen müssen zur Sicherstellung von Consistency and Durability Schreibprozesse auf das Disksystem vornehmen. Die Herausforderung liegt darin, diese Schreibprozesse so zu beschleunigen, dass möglichst wenig Einfluss auf die Transaktionszeiten genommen wird.

    Bleibt alle gesund in diesen Tagen...

    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Freitag, 27. März 2020 06:34
    |