Teilen über

Temporale Tabellen mit Systemversionsverwaltung für speicheroptimierte Tabellen

  • Artikel

Gilt für: SQL Server 2016 (13.x) und höher Azure SQL-Datenbank Azure SQL Managed Instance

Temporale Tabellen mit Systemversionsverwaltung für speicheroptimierte Tabellen bieten eine kostengünstige Lösung für Szenarien, in denen zusätzlich zur Datensammlung mit In-Memory-OLTP-Arbeitsauslastungen Datenüberwachung und Zeitpunktanalyse erforderlich sind.

Ü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. Normalerweise wird der Datenverlauf für eine lange Zeit beibehalten (mehrere Monate sogar Jahre), auch wenn er nicht regelmäßig abgefragt wird.

Datenüberwachung und zeitbasierte Analyse können in verschiedenen Umgebungen erforderlich sein, vor allem bei OLTP-Systemen, die eine sehr große Anzahl von Anforderungen verarbeiten und bei denen In-Memory-OLTP-Technologie verwendet 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.

Temporale Tabellen mit Systemversionsverwaltung für speicheroptimierte Tabellen bieten einen hohen Transaktionsdurchsatz und eine sperrenfreie Parallelität. Sie bieten Ihnen die Möglichkeit, große Mengen an Verlaufsdaten zu speichern, indem Sie speicherinterne Tabellen zum Speichern aktueller Daten (der temporalen Tabelle) und datenträgerbasierte 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 Verlaufstabelle für speicheroptimierte Tabellen mit Systemversionsverwaltung muss datenträgerbasiert sein, unabhängig davon, ob sie vom Endbenutzer oder vom System erstellt wurde.

  • Abfragen, die nur die aktuelle speicherinterne Tabelle betreffen, können in nativ kompilierten T-SQL-Modulenverwendet werden. Temporale Abfragen mit der Klausel FOR SYSTEM TIME werden in nativ kompilierten Modulen nicht unterstützt. Die Klausel FOR SYSTEM TIME wird bei speicheroptimierten Tabellen in Ad-hoc-Abfragen und nicht nativen Modulen unterstützt.

  • Wenn SYSTEM_VERSIONING = ON, wird automatisch eine interne speicheroptimierte Stagingtabelle erstellt, um die neuesten mit der Systemversionsverwaltung erfassten Änderungen zu übernehmen, die das Ergebnis von Aktualisierungs- und Löschvorgängen in einer aktuellen speicheroptimierten Tabelle sind.

  • Daten aus der internen speicheroptimierten Stagingtabelle werden von einem asynchronen Datenleerungstask regelmäßig in die datenträgerbasierte Verlaufstabelle verschoben. Dieser Datenleerungsmechanismus hält die internen Speicherpuffer bei unter 10 Prozent der Arbeitsspeichernutzung der übergeordneten Objekte. Sie können die gesamte Arbeitsspeichernutzung der speicheroptimierten temporalen Tabelle mit Systemversionsverwaltung nachverfolgen, indem Sie sys.dm_db_xtp_memory_consumers abfragen und die Daten für die interne speicheroptimierte Stagingtabelle sowie die aktuelle temporale Tabelle zusammenfassen.

  • Sie können eine Datenentleerung manuell vornehmen, indem Sie sp_xtp_flush_temporal_history ausführen.

  • Wenn SYSTEM_VERSIONING = OFF oder wenn das Schema einer Tabelle mit Systemversionsverwaltung durch Hinzufügen, Löschen oder Ändern von Spalten geändert wurde, wird der gesamte Inhalt des internen Stagingpuffers in die datenträgerbasierte Verlaufstabelle 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-Vorgänge, die das Tabellenschema intern ändern, müssen eine Datenleerung ausführen, wodurch sich die Dauer des Vorgangs möglicherweise verlängert.

Die interne speicheroptimierte Stagingtabelle

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

  • Der Tabellenname wird im folgenden Format generiert: Memory_Optimized_History_Table_<object_id>, wobei <object_id> der Bezeichner der aktuellen temporalen Tabelle ist.

  • Die Tabelle repliziert das Schema der aktuellen temporalen Tabelle inklusive einer bigint-Spalte. Diese zusätzliche Spalte gewährleistet die Eindeutigkeit der in den internen Verlaufspuffer verschobenen Zeilen.

  • 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. Der neue Höchstwert ist jetzt 8.052 Bytes.

  • Die interne speicheroptimierte Stagingtabelle wird im Objekt-Explorer von SQL Server Management Studio nicht dargestellt.

  • Metadaten für diese Tabelle und ihre Verbindung mit der aktuellen temporalen Tabelle finden Sie unter sys.internal_tables.

Der Datenleerungstask

Die Datenleerung ist ein regelmäßig aktivierter Tasks, der überprüft, ob eine speicheroptimierte Tabelle eine größenbasierte Arbeitsspeicherbedingung für das Verschieben von Daten erfüllt. Das Verschieben der Daten beginnt, wenn die Arbeitsspeichernutzung der internen Stagingtabelle acht Prozent der Arbeitsspeichernutzung der aktuellen temporalen Tabelle erreicht.

Der Datenleerungstask wird regelmäßig nach einem Zeitplan aktiviert, der basierend auf der vorhandenen Arbeitsauslastung variiert. 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, für die eine Bereinigung erforderlich ist, wird ein Thread erzeugt.

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>;

Es wird derselbe Datenverschiebungsvorgang aufgerufen, wie wenn das System den Datenleerungstasks gemäß seinem internen Zeitplan ausführt.

Zugehöriger Inhalt