Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 wie Transaktionen für (herkömmliche) datenträgerbasierte Tabellen sind auch Transaktionen für speicheroptimierte Tabellen vollständig atomar, konsistent, isoliert und dauerhaft (ACID). 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).
Für noch größere Leistungssteigerungen unterstützt In-Memory OLTP dauerhafte Tabellen mit verzögerter Transaktionsdauerhaftigkeit. 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.
Zeilen in speicheroptimierten Tabellen werden versioniert. 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 Multiversionierung. 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 verschiedenen Zeilenversionen 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 | Die Verschachtelung nativ kompilierter gespeicherter 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* |
1Sie 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. Der Zugriff auf speicheroptimierte Tabellen aus solchen gespeicherten Prozeduren kann von Vorteil sein.
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 | Auswirkungen von 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 von Daten- oder Indexseiten ein E/A-Engpass auftritt, kann In-Memory OLTP diesen möglicherweise verringern. 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. |
Latch-Konkurrenz 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 bei Ihrer Datenbankanwendung Probleme durch Blockierungen zwischen Lese- und Schreibvorgängen auftreten, beseitigt In-Memory OLTP diese, da dabei eine neue Form der optimistischen Nebenläufigkeitskontrolle verwendet wird, um alle Transaktionsisolationsstufen zu implementieren. 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 Ihrer Anwendung häufig Konflikte zwischen zwei Schreibvorgängen auftreten, verringert sich der Nutzen des optimistischen Sperrens. 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 nativen Module unterstützen und verwenden EXECUTE AS jetzt CALLER standardmäßig, auch wenn der Hinweis nicht angegeben ist. Dies liegt daran, dass erwartet wird, dass alle Sicherheits-Prädikatfunktionen auf Zeilenebene CALLER verwenden EXECUTE AS , damit die Funktion und alle integrierten Funktionen, die darin verwendet werden, im Kontext des aufrufenden Benutzers ausgewertet werden.
EXECUTE AS CALLER hat eine kleine Leistungseinbuße (ca. 10 %), die durch Berechtigungsprüfungen für den CALLER verursacht wird. Wenn das Modul EXECUTE AS OWNER oder EXECUTE AS SELF explizit angibt, werden diese Berechtigungsprüfungen und die damit verbundenen Leistungseinbußen 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.