Einführung in speicheroptimierte Tabellen

Gilt für:SQL ServerAzure SQL-DatenbankVerwaltete Azure SQL-Instanz

Speicheroptimierte Tabellen werden mit CREATE TABLE (Transact-SQL) erstellt.

Speicheroptimierte Tabellen sind standardmäßig vollständig dauerhaft und bieten, wie Transaktionen in (herkömmlichen) datenträgerbasierten Tabellen, vollständige ACID-Eigenschaften (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit). Speicheroptimierte Tabellen und nativ kompilierte gespeicherte Prozeduren unterstützen nur einen Teil der Transact-SQL-Features.

Ab SQL Server 2016 und in der Azure SQL-Datenbank gelten keine Einschränkungen für Sortierungen oder Codeseiten , die für In-Memory OLTP spezifisch sind.

Beim Primärspeicher für speicheroptimierte Tabellen handelt es sich um den Hauptspeicher. Zeilen in der Tabelle werden aus dem Arbeitsspeicher gelesen und in diesen geschrieben. Eine zweite Kopie der Tabellendaten wird auf Festplatte gespeichert, aber nur zu Dauerhaftigkeitszwecken. Weitere Informationen zu dauerhaften Tabellen finden Sie unter Erstellen und Verwalten von Speicher für Memory-Optimized-Objekte . Daten in speicheroptimierten Tabellen werden während der Datenbankwiederherstellung nur vom Datenträger gelesen (z. B. nach einem Serverneustart).

Noch deutlichere Leistungsverbesserungen werden bei In-Memory OLTP durch die Unterstützung von dauerhaften Tabellen mit verzögerter Transaktionsdauerhaftigkeit erzielt. Verzögerte dauerhafte Transaktionen werden bald nach dem Commit der Transaktion auf dem Datenträger gespeichert, und die Kontrolle wird an den Client zurückgegeben. Im Austausch für die erhöhte Leistung gehen zugesicherte Transaktionen, die nicht auf dem Datenträger gespeichert sind, in einem Serverabsturz verloren oder schlagen fehl.

Neben den standardmäßigen dauerhaften speicheroptimierten Tabellen unterstützt SQL Server auch nicht dauerhafte speicheroptimierte Tabellen, die nicht protokolliert werden und ihre Daten nicht auf dem Datenträger gespeichert werden. Dies bedeutet, dass Transaktionen in diesen Tabellen keine Datenträger-E/A erfordern, aber die Daten gehen verloren, wenn ein Serverabsturz oder Failover auftritt.

In-Memory OLTP ist in SQL Server integriert, um in allen Bereichen wie Entwicklung, Bereitstellung, Verwaltbarkeit und Unterstützbarkeit eine reibungslose Benutzererfahrung zu ermöglichen. Eine Datenbank kann speicherinterne wie auch datenträgerbasierte Objekte enthalten.

Für Zeilen in speicheroptimierten Tabellen wird die Versionsverwaltung verwendet. Dies bedeutet, dass für jede Zeile in der Tabelle möglicherweise mehrere Versionen vorliegen. Alle Zeilenversionen werden in derselben Tabellendatenstruktur verwaltet. Die Zeilenversionsverwaltung wird verwendet, um gleichzeitige Lese- und Schreibvorgänge für dieselbe Zeile zuzulassen. Weitere Informationen zu gleichzeitigen Lese- und Schreibvorgängen in derselben Zeile finden Sie unter Transaktionen mit Memory-Optimized Tabellen.

Die folgende Abbildung veranschaulicht die Multiversionsverwaltung. Die Abbildung zeigt eine Tabelle mit drei Zeilen, und jede Zeile weist unterschiedliche Versionen auf.

Die Tabelle enthält drei Zeilen: r1, r2 und r3. r1 verfügt über drei Versionen, r2 über zwei Versionen und r3 über vier Versionen. Unterschiedliche Versionen derselben Zeile belegen nicht unbedingt aufeinander folgende Speicheradressen. Die unterschiedlichen Zielversionen können über die Tabellendatenstruktur verteilt sein.

Die speicheroptimierte Tabellendatenstruktur kann als Auflistung von Zeilenversionen gesehen werden. Während Zeilen in datenträgerbasierten Tabellen in Seiten und Blöcken angeordnet sind und einzelne Zeilen mithilfe der Seitenzahl und des Seitenoffsets adressiert werden, werden Zeilenversionen in speicheroptimierten Tabellen mithilfe von 8-Byte-Speicherzeigern adressiert.

Der Datenzugriff in speicheroptimierten Tabellen erfolgt auf zwei Arten:

• Durch systemintern kompilierte gespeicherte Prozeduren

• Durch interpretierte Transact-SQL außerhalb einer nativ kompilierten gespeicherten Prozedur. Diese Transact SQL-Anweisungen können sich entweder in interpretierten gespeicherten Prozeduren befinden oder als Ad-hoc-Transact-SQL-Anweisungen vorliegen.

Zugriff auf Daten in speicheroptimierten Tabellen

Auf speicheroptimierte Tabellen kann am effizientesten über nativ kompilierte gespeicherte Prozeduren (native kompilierte gespeicherte Prozeduren) zugegriffen werden. Auf speicheroptimierte Tabellen kann außerdem mit (herkömmlichem) interpretiertem Transact-SQL zugegriffen werden. Interpretiertes Transact-SQL bezieht sich auf den Zugriff auf speicheroptimierte Tabellen ohne eine systemintern kompilierte gespeicherte Prozedur. Beispiele für den Zugriff auf interpretiertes Transact SQL sind der Zugriff auf eine speicheroptimierte Tabelle über einen DML-Trigger, einen Ad-Hoc-Transact-SQL-Batch, eine Sicht und eine Tabellenwertfunktion.

In der folgenden Tabelle wird der systemeigene und interpretierte Transact-SQL-Zugriff für verschiedene Objekte zusammengefasst.

Funktion	Zugriff mithilfe einer systemintern kompilierten gespeicherten Prozedur	Interpretierter Transact-SQL-Zugriff	CLR-Zugriff
Speicheroptimierte Tabelle	Ja	Ja	Nr 1
Speicheroptimierter Tabellentyp	Ja	Ja	Nein
Systemintern kompilierte gespeicherte Prozedur	Das Schachteln von systemintern kompilierten gespeicherten Prozeduren wird jetzt unterstützt. Sie können in gespeicherten Prozeduren die EXECUTE-Syntax verwenden, solange die Prozedur, auf die verwiesen wird, ebenfalls systemintern kompiliert wird.	Ja	Nein*

¹Sie können nicht über die Kontextverbindung (die Verbindung von SQL Server beim Ausführen eines CLR-Moduls) auf eine speicheroptimierte Tabelle oder eine systemeigene gespeicherte Prozedur zugreifen. Sie können jedoch eine andere Verbindung erstellen und öffnen, über die Sie auf speicheroptimierte Tabellen und systemintern kompilierte gespeicherte Prozeduren zugreifen können.

Vertrauliche Daten in speicheroptimierten Tabellen können mithilfe von Always Encrypted geschützt werden. Es gelten die folgenden Einschränkungen:

• Bei Verwendung von Always Encrypted mit sicheren Enklaven wird die Verwendung von Enklaven-fähigen Schlüsseln für Spalten in speicheroptimierten Tabellen nicht unterstützt. Dies bedeutet, dass die direkte Verschlüsselung nicht verwendet werden kann und die anfängliche Verschlüsselung auf dem Client erfolgt.
• Always Encrypted wird für jede Spalte in einer speicheroptimierten Tabelle nicht unterstützt, wenn auf die Tabelle in einem systemeigenen kompilierten Modul verwiesen wird.

Leistung und Skalierbarkeit

Die folgenden Faktoren wirken sich auf die Leistungsgewinne aus, die mit In-Memory OLTP erzielt werden können:

Kommunikation: Eine Anwendung, die viele kurze Aufrufe gespeicherter Prozeduren verwendet, kann im Vergleich zu einer Anwendung mit weniger Aufrufen und mehr Funktionalität in jeder gespeicherten Prozedur einen geringeren Leistungsgewinn erzielen.

Transact-SQL Ausführung: In-Memory OLTP erzielt die beste Leistung, wenn sie systemeigene gespeicherte Prozeduren anstelle von interpretierten gespeicherten Prozeduren oder Abfrageausführungen verwenden. Dies kann einen Vorteil gegenüber dem Zugriff auf speicheroptimierte Tabellen aus solchen gespeicherten Prozeduren bieten.

Bereichsscan im Vergleich zur Punktsuche: Speicheroptimierte nicht gruppierte Indizes unterstützen Bereichsscans und sortierte Scans. Bei Punktsuchen erzielen Sie mit speicheroptimierten Hashindizes eine bessere Leistung als mit speicheroptimierten, nicht gruppierten Indizes. Speicheroptimierte, nicht gruppierte Indizes weisen eine bessere Leistung auf als datenträgerbasierte Indizes.

• Ab SQL Server 2016 kann der Abfrageplan für eine speicheroptimierte Tabelle die Tabelle parallel scannen. Dies verbessert die Leistung von Analyseabfragen.
  • Hashindizes können seit SQL Server 2016 auch parallel gescannt werden.
  • Nicht gruppierte Indizes können seit SQL Server 2016 auch parallel gescannt werden.

Indexvorgänge: Indexvorgänge werden nicht protokolliert, und sie sind nur im Arbeitsspeicher vorhanden.

Gleichzeitigkeit: Anwendungen, deren Leistung von der Gleichzeitigkeit auf Engine-Ebene beeinträchtigt wird, wie z. B. durch Latch-Konflikte oder Blockierungen, verbessern sich erheblich, wenn die Anwendung zu In-Memory OLTP wechselt.

In der folgenden Tabelle werden die Leistungs- und Skalierbarkeitsprobleme, die häufig in relationalen Datenbanken auftreten, zusammen mit einer möglichen Leistungssteigerung durch In-Memory OLTP aufgeführt.

Problem	Einfluss durch In-Memory OLTP
Leistung Hohe Ressourcenauslastung (CPU, E/A, Netzwerk oder Arbeitsspeicher).	Prozessor Nativ kompilierte gespeicherte Prozeduren können die CPU-Auslastung erheblich verringern, da sie weniger Anweisungen benötigen, um eine Transact-SQL Anweisung im Vergleich zu interpretierten gespeicherten Prozeduren auszuführen. In-Memory OLTP kann dazu beitragen, die Hardwareinvestitionen in skalierte Workloads zu reduzieren, da ein Server den Durchsatz mehrerer Server potenziell liefern kann. E/A Wenn bei der Verarbeitung ein E/A-Engpass aufgrund der Verarbeitung von Daten oder Indexseiten auftritt, lässt sich dieser durch In-Memory OLTP u. U. reduzieren. Zudem wird der Prüfpunktalgorithmus von In-Memory OLTP-Objekten kontinuierlich durchgeführt und führt nicht zu einem plötzlichen Anstieg von E/A-Vorgängen. Wenn der Arbeitssatz der leistungskritischen Tabellen jedoch nicht in den Arbeitsspeicher passt, wird In-Memory OLTP nicht angewendet, da Daten speicherresident sein müssen. Wenn bei der Protokollierung ein E/A-Engpass auftritt, kann In-Memory OLTP diesen Engpass verringern, da weniger Protokollierungsaktivität durchgeführt wird. Wenn eine oder mehrere speicheroptimierte Tabellen als nicht dauerhafte Tabellen konfiguriert sind, können Sie dadurch die Protokollierung für Daten eliminieren. Arbeitsspeicher In-Memory OLTP bietet keinen Leistungsvorteil. In-Memory OLTP kann den Arbeitsspeicher zusätzlich belasten, da die Objekte speicherresident sein müssen. Netzwerk In-Memory OLTP bietet keinen Leistungsvorteil. Die Daten müssen von der Datenebene an die Anwendungsebene übertragen werden.
Skalierbarkeit Die meisten Skalierungsprobleme bei SQL Server-Anwendungen werden durch Parallelitätsprobleme wie Konflikten bei Sperren, Latches und Spinlocks verursacht.	Latchkonflikte Ein typisches Szenario ist ein Konflikt auf der letzten Seite eines Indexes, wenn Zeilen gleichzeitig in Schlüsselreihenfolge einfügt werden. Da In-Memory OLTP beim Datenzugriff keine Latches verwendet, werden Skalierbarkeitsprobleme aufgrund von Latchkonflikten vollständig eliminiert. Spinlock-Konflikt Da In-Memory OLTP beim Zugriff auf Daten keine Sperren verwendet, werden die Skalierbarkeitsprobleme im Zusammenhang mit Spinlock-Konflikten vollständig beseitigt. Konflikte aufgrund von Sperren Wenn in der Datenbankanwendung Blockierungen zwischen Lese- und Schreibvorgängen auftreten, werden diese Blockierungsprobleme durch In-Memory OLTP beseitigt, da es eine neue Art der optimistischen Nebenläufigkeitssteuerung für die Implementierung der Transaktionsisolationsstufen verwendet. In-Memory OLTP verwendet TempDB nicht zum Speichern von Zeilenversionen. Wenn das Skalierungsproblem durch einen Konflikt zwischen zwei Schreibvorgängen verursacht wird, etwa zwei Transaktionen, die gleichzeitig dieselbe Zeile zu aktualisieren versuchen, führt In-Memory OLTP eine Transaktion erfolgreich durch und beendet die andere. Die fehlgeschlagene Transaktion muss entweder explizit oder implizit erneut übermittelt werden, wobei die Transaktion erneut versucht wird. In beiden Fällen müssen Sie Änderungen an der Anwendung vornehmen. Wenn in der Anwendung häufig Konflikte zwischen zwei Schreibvorgängen auftreten, wird der Wert der optimistischen Sperre verringert. Die Anwendung eignet sich nicht für In-Memory OLTP. Die meisten OLTP-Anwendungen weisen keine Schreibkonflikte auf, sofern diese nicht durch Sperrenausweitung verursacht werden.

Sicherheit auf Zeilenebene in speicheroptimierten Tabellen

Row-Level Sicherheit wird in speicheroptimierten Tabellen unterstützt. Richtlinien für die Sicherheit auf Zeilenebene werden auf speicheroptimierte Tabellen im Wesentlichen auf die gleiche Weise wie auf datenträgerbasierte Tabellen angewendet. Der einzige Unterschied ist, dass die als Sicherheitsprädikate verwendeten Inline-Tabellenwertfunktionen systemintern kompiliert (mit der Option WITH NATIVE_COMPILATION erstellt) werden müssen. Ausführliche Informationen finden Sie im Abschnitt " Funktionsübergreifende Kompatibilität " im Thema "Row-Level Sicherheit ".

Für speicheroptimierte Tabellen stehen verschiedene integrierte Sicherheitsfunktionen zur Verfügung, die für die Sicherheit auf Zeilenebene unerlässlich sind. Ausführliche Informationen finden Sie unter Integrierten Funktionen in nativen kompilierten Modulen.

EXECUTE AS CALLER – Alle systemeigenen Module unterstützen jetzt EXECUTE AS CALLER standardmäßig, auch wenn der Hinweis nicht angegeben ist. Dies liegt daran, dass erwartet wird, dass alle Sicherheits-Prädikatfunktionen auf Zeilenebene EXECUTE AS CALLER verwenden, damit die Funktion und alle integrierten Funktionen, die darin verwendet werden, im Kontext des aufrufenden Benutzers ausgewertet werden.
EXECUTE AS CALLER ist mit einer geringen Leistungseinbuße (ungefähr 10 %) verbunden, die durch das Überprüfen der Berechtigung des Aufrufers verursacht wird. Wenn das Modul EXECUTE AS OWNER oder EXECUTE AS SELF explizit angibt, werden diese Berechtigungsprüfungen und die zugehörigen Leistungskosten vermieden. Die Verwendung einer dieser Optionen zusammen mit den erwähnten integrierten Funktionen führt jedoch aufgrund des erforderlichen Kontextwechsels zu einer höheren Leistungseinbuße.

Szenarien

Eine kurze Erläuterung der typischen Szenarien, in denen In-Memory OLTP die Leistung verbessern kann, finden Sie unter In-Memory OLTP.

Weitere Informationen

In-Memory OLTP (In-Memory-Optimierung)