How-To: Ein Anwendungsbeispiel zum Verwenden der In-Memory OLTP Funktion
Wie im vorangegangen Artikel Daten schneller verarbeiten mit verbesserter In-Memory OLTP Funktion vorgestellt, kann die Nutzung der speicher-optimierten Tabellen und nativen gespeicherten Prozeduren eine Leistungssteigerung des SQL Servers (ab 2014 Edition) bewirken.
In diesem Artikel sehen wir uns an, wie speicher-optimierte Tabellen eingerichtet und verwendet werden können und welche Voraussetzungen wir dafür schaffen müssen.
Innerhalb des Artikel wird für die Beispiel-SQL-Skripte das fiktive Projekt Bucharchiv angenommen.
Voraussetzungen
Als Voraussetzung gibt Microsoft das Kompatibilitäts-Level der Datenbank an. Dieses muss mindestens einen Wert von „130“ haben. Mit dem nachfolgenden SQL-Befehl können Sie das Kompatibilitäts-Level Ihrer Datenbank prüfen:
Hat ihre Datenbank nicht das notwendige Kompatibilitäts-Level, können Sie dieses mit dem folgenden SQL-Befehl anpassen:
Da in den meisten Fällen nicht alle Tabellen Ihrer Datenbank „In-memory“-Tabellen sein werden, werden Sie an einen Punkt gelangen, an dem Sie SQL-Abfragen über „disk-based“ und „in-memory“ Tabellen ausführen müssen. Sollen diese SQL-Abfragen zusätzlich in einer Transaktion ausgeführt werden, spricht man von „Cross-Container“-Transaktionen. Um diese problemlos verwenden zu können, muss zunächst aber das Transaktions-Isolations-Level der speicher-optimierten Tabellen auf „SNAPSHOT“ konfiguriert werden.
Bei der Verwendung von nativen gespeicherten Prozeduren ist die Konfiguration auf das Isolations-Level „SNAPSHOT“ für speicher-optimierte Tabellen immer notwendig, auch wenn keine normalen Tabellen einbezogen werden.
Die letzte Voraussetzung, die für die Verwendung von „In-memory“-Tabellen erfüllt sein muss, ist die Erstellung einer „memory-optimized FILEGROUP“, die die Daten der speicher-optimierten Tabellen enthält. Diese Filegroup ist direkt der Datenbank zugeordnet und kann für jede Datenbank nur ein einziges Mal erstellt werden. Hinweis: Für Azure SQL Datenbanken ist die Erstellung einer solchen „memory-optimized FILEGROUP“ nicht notwendig.
Was beinhaltet eine „memory-optimized FILEGROUP“?
Eine „memory-optimized FILEGROUP“ kann beliebig viele Container enthalten, mindestens aber einen. Diese Container können auf verschiedenen Speicherorten abgelegt werden. Ein Container selbst enthält die im vorhergehenden Artikel eingeführten Checkpoint-Dateien, also Daten und Delta-Datei-Paarungen.
Eine „memory-optimized FILEGROUP“ kann zu jedem Zeitpunkt angelegt werden. Es ist also nicht notwendig diese gleich bei der Erstellung der Datenbank anzulegen. Mit dem nachfolgenden Befehl legen Sie die „memory-optimized FILEGROUP“ an:
Ein Nachteil: Einmal angelegt, kann die „memory-optimized FILEGROUP“ nur noch entfernt werden, wenn die gesamte Datenbank gelöscht wird.
Der nachfolgende Befehl zeigt Ihnen, wie Sie der „memory-optimized FILEGROUP“ einen Container hinzufügen:
Bei der Zuweisung des Speicherortes des Containers ist zu beachten, dass Sie für einen Container keine Maximalgröße angeben können. Zudem kann ein Container weder gelöscht werden, wenn in ihm bereits Daten enthalten sind, noch können die Daten und die Delta-Datei in einen anderen Container verschoben werden.
Lesen Sie mehr über „memory-optimized FILEGROUP“ in diesem Microsoft-Artikel.
Verwendung
Ist der SQL Server und Ihre Datenbank fertig konfiguriert, können nun speicher-optimierte Tabellen in Ihrer Datenbank angelegt werden. Für das Projekt Bucharchiv soll der Übersichtlichkeit wegen nur die Tabelle Buecher angelegt werden. Dementsprechend wird in diesem Beispiel auch kein Augenmerk auf Normalisierung gelegt.
Mit diesem Skript können Sie eine speicher-optimierte Tabelle anlegen:
Beim Erstellen des Skriptes ist das Augenmerk auf die zwei Optionen Memory_Optimized und Durability zu legen. Mit der ersten Option legen Sie fest, dass die anzulegende Tabelle eine speicher-optimierte Tabelle ist. Die zweite Option bestimmt, ob für diese Tabelle nur das Schema oder auch die Daten gespeichert werden sollen. In diesem Fall wurde die Einstellung Schema und Daten verwendet.
Hinweis: Auch mit dem aktuellen Management Studio für den SQL Server 2016 (April-Preview) kann eine speicher-optimierte Tabelle nur per Skript angelegt werden.
Schema-Änderungen an speicher-optimierten Tabellen können mit den Standard-„ALTER TABLE“-Befehlen durchgeführt werden. Hinzu kommen die „ALTER TABLE“-Befehle „ADD/DROP/ALTER INDEX“. Diese werden nur für speicher-optimierte Tabellen unterstützt, da ein „CREATE INDEX“, „DROP INDEX“ bzw. „ALTER INDEX“ ohne die Nutzung des „ALTER TABLE“-Befehls für speicher-optimierte Tabellen nicht unterstützt wird.
Lesen Sie mehr über die Änderung von Indizes von speicher-optimierten Tabellen in diesem Microsoft-Artikel.
Die Verwendung der Tabelle erfolgt wieder mit den regulären SQL-Befehlen für das Abfragen, Einfügen, Ändern und Löschen von Daten. Im nachfolgenden Beispiel wurden zunächst zwei Bücher in die speicher-optimierte Tabelle eingefügt.
Im Anschluss wurde das Ergebnis des Einfügens mittels eines regulären SQL-SELECTS abgefragt. Den SQL-Befehl und das Ergebnis sehen Sie nachfolgend.
Da beim Anlegen der Tabelle nicht daran gedacht wurde die Seitenzahl eines Buches zu speichern, soll als nächstes das aktuelle Schema der speicher-optimierten Tabelle erweitert werden. Zusätzlich werden für die zwei eingefügten Bücher die Seitenzahlen eingetragen. Auch das erfolgt, wie dargestellt, wieder mit regulären SQL-Befehlen.
Als Probe, ob alles geklappt hat, soll wieder ein SELECT auf die Bücher-Tabelle ausgeführt werden. Anhand des Ergebnis ist ersichtlich, dass alles funktioniert hat.
Fazit
In diesem Artikel haben wir zunächst geklärt, welche Schritte notwendig sind um den SQL Server und die benötigte Datenbank auf die Nutzung von speicher-optimierten Tabellen vorzubereiten. Im Anschluss haben wir in einem Beispiel-Szenario eine speicher-optimierte Tabelle angelegt, nachträglich das Schema angepasst, mit Daten befüllt und wieder ausgelesen. All das wurde mit Standard-SQL-Befehlen durchgeführt, so dass eine Umstellung auf speicher-optimierte Tabellen für Ihre Anwendung(en) ohne Anpassungen durchführbar ist.
Verfasst von Tino Krüger.