Systemversionierte temporale Tabellen mit speicheroptimierten Tabellen

Gilt für: SQL Server 2016 (13.x) und höhere Versionen von Azure SQL Managed Instance

Systemversionierte temporale Tabellen für speicheroptimierte Tabellen bieten eine kosteneffiziente Lösung für Szenarien, in denen Datenaudit und Zeitpunktanalyse zusätzlich zu den mit im Speicher gesammelten OLTP-Workloads erhobenen Daten erforderlich sind.

Note

Speicheroptimierte zeitliche Tabellen sind nur in SQL Server und azure SQL Managed Instance verfügbar. Speicheroptimierte Tabellen und zeitliche Tabellen sind unabhängig in der Azure SQL-Datenbank verfügbar.

Übersicht

Temporale Tabellen mit Systemversionsverwaltung speichern automatisch einen vollständigen Verlauf der Datenänderungen und stellen praktische Transact-SQL-Erweiterungen für die Zeitpunktanalyse zur Verfügung. In einem typischen Szenario wird die Datenhistorie lange gespeichert (mehrere Monate, sogar Jahre), auch wenn sie nicht regelmäßig abgefragt wird.

Datenaudit und zeitbasierte Analysen können in verschiedenen Umgebungen erforderlich sein, insbesondere in OLTP-Systemen, die extrem viele Anfragen verarbeiten und in denen im Speicher OLTP-Technologie eingesetzt wird. Die Verwendung speicheroptimierter Tabellen in temporalen Szenarien ist jedoch schwierig, da die riesige Menge an generierten historischen Daten häufig die Grenzen des verfügbaren RAM überschreitet. Gleichzeitig ist es keine optimale Lösung, schreibgeschützte historische Daten, auf die mit zunehmendem Alter immer seltener zugegriffen wird, im RAM zu speichern.

Systemversionierte temporale Tabellen für speicheroptimierte Tabellen bieten einen hohen Transaktionsdurchsatz und Nebenläufigkeit ohne Sperren. Sie können eine große Menge an Verlaufsdaten speichern, indem Sie In-Memory-Tabellen zum Speichern aktueller Daten (die Temporaltabelle) sowie festplattenbasierte Tabellen für historische Daten verwenden. Die Auswirkung auf DML-Vorgänge wird durch die Verwendung einer internen, automatisch generierten speicheroptimierten Stagingtabelle verringert, die den aktuellen Verlauf speichert und ermöglicht, dass DMLs auf systemintern kompiliertem Code heraus ausgeführt werden können.

Diese Architektur wird anhand des folgenden Diagramms veranschaulicht.

Diagramm einer temporalen In-Memory-Architektur.

Details zur Implementierung

Beachten Sie beim Erstellen einer speicheroptimierten Tabelle mit Systemversionsverwaltung die folgenden Überlegungen. Syntaxoptionen und ein Beispiel finden Sie unter CREATE TABLE.

  • Nur dauerhafte speicheroptimierte Tabellen können der Systemversionsverwaltung unterliegen (DURABILITY = SCHEMA_AND_DATA).

  • Die History-Tabelle für eine speicheroptimierte, systemversionierte Tabelle muss festplattenbasiert sein, egal ob Sie sie erstellen oder das System sie erstellt.

  • Du kannst Abfragen verwenden, die nur die aktuelle In-Memory-Tabelle in nativ kompilierten T-SQL-Modulen betreffen. Nativ kompilierte Module unterstützen die Klausel FOR SYSTEM TIME nicht, aber Ad-hoc-Abfragen und nicht-native Module können die Klausel gegen speicheroptimierte Tabellen verwenden.

  • Mit SYSTEM_VERSIONING = ON erstellt das System automatisch eine interne speicheroptimierte Staging-Tabelle, um die neuesten systemversionierten Änderungen aufzunehmen, die sich aus Aktualisierungs- und Löschvorgängen in einer aktuellen speicheroptimierten Tabelle ergeben.

  • Eine asynchrone Datenflush-Aufgabe überträgt regelmäßig Daten von der internen, speicheroptimierten Staging-Tabelle zur festplattenbasierten Historientabelle. Dieser Datenleerungsmechanismus hält die internen Speicherpuffer bei unter 10 Prozent der Arbeitsspeichernutzung der übergeordneten Objekte. Man kann den gesamten Speicherverbrauch einer speicheroptimierten, systemversionierten temporalen Tabelle verfolgen, indem man sys.dm_db_xtp_memory_consumers abfragt und die Daten für die interne, speicheroptimierte Staging-Tabelle und die aktuelle temporale Tabelle zusammenfasst.

  • Um einen Daten-Flush manuell durchzuführen, führen Sie sp_xtp_flush_temporal_history aus.

  • Mit SYSTEM_VERSIONING = OFF, oder wenn Sie das Schema einer systemversionierten Tabelle durch Hinzufügen, Löschen oder Ändern von Spalten ändern, wird der gesamte Inhalt des internen Staging-Puffers in die festplattenbasierte Historietabelle verschoben.

  • Das Abfragen von Verlaufsdaten ist unter der Momentaufnahme-Isolationsstufe effektiv und gibt stets eine Vereinigung des In-Memory-Stagingpuffers und der datenträgerbasierten Tabelle ohne Duplikate zurück.

  • ALTER TABLE Operationen, die das Tabellenschema intern ändern, müssen einen Datenflush durchführen, der die Operation verlängern kann.

Die interne speicheroptimierte Stagingtabelle

Das System erstellt eine interne speicheroptimierte Stagingtabelle, um DML-Vorgänge zu optimieren.

  • Der Tabellenname verwendet folgendes Format: Memory_Optimized_History_Table_<object_id> wobei <object_id> die Kennung der aktuellen temporalen Tabelle ist.

  • Die Tabelle repliziert das Schema der aktuellen temporalen Tabelle plus eine Biggint-Spalte . Diese zusätzliche Spalte garantiert die Eindeutigkeit der Zeilen, die in den internen Historienpuffer verschoben werden.

  • Die zusätzliche Spalte weist das folgende Namensformat auf: Change_ID[<suffix>], wobei <suffix> optional hinzugefügt wird, falls die Tabelle bereits über eine Change_ID-Spalte verfügt.

  • Die maximale Zeilengröße für eine speicheroptimierte Tabelle mit Systemversionsverwaltung wird aufgrund der zusätzlichen bigint-Spalte in der Stagingtabelle um 8 Bytes reduziert. Das Maximum beträgt jetzt 8.052 Bytes.

  • Die interne, speicheroptimierte Staging-Tabelle erscheint nicht im Objekt-Explorer von SQL Server Management Studio.

  • Metadaten zu dieser Tabelle und ihrer Verbindung zur aktuellen zeitlichen Tabelle finden Sie in sys.internal_tables.

Die Aufgabe zum Leeren der Daten

Die Datenflush-Aufgabe wird regelmäßig ausgeführt und prüft, ob eine speicheroptimierte Tabelle eine speichergrößenbasierte Bedingung für Datenbewegung erfüllt. Die Datenübertragung beginnt, wenn der Speicherverbrauch der internen Staging Table acht Prozent des Speicherverbrauchs der aktuellen zeitlichen Tabelle erreicht.

Die Aufgabe zum Leeren von Daten wird regelmäßig nach einem Zeitplan ausgeführt, der von der aktuellen Auslastung abhängt. Bei einer hohen Arbeitsauslastung wird die Aufgabe alle 5 Sekunden ausgeführt. Bei einer geringen Arbeitsauslastung erhöht sich die Häufigkeit auf einmal pro Minute. Für jede interne speicheroptimierte Stagingtabelle, die bereinigt werden muss, wird ein Thread gestartet.

Bei der Datenleerung werden alle Datensätze aus dem In-Memory-Puffer gelöscht, die älter als die älteste, aktuell ausgeführte Transaktion sind, um diese Datensätze in die datenträgerbasierte Verlaufstabelle zu verschieben.

Sie können eine Datenentleerung ausführen, indem Sie sp_xtp_flush_temporal_history ausführen und den Schema- und Tabellennamen angeben:

EXEC sys.sp_xtp_flush_temporal_history <schema_name>, <object_name>;

Derselbe Datenbewegungsprozess wird ausgelöst wie bei der Ausführung der Aufgabe zur Datenleerung durch das System gemäß seinem internen Zeitplan.

Verwandte Inhalte

  • Last updated on