Systemversionierte temporale Tabellen mit speicheroptimierten Tabellen

Gilt für: SQL Server 2016 (13.x) und höhere Versionen von 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.

Anmerkung

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

  • Mit SYSTEM_VERSIONING = ON wird automatisch eine interne speicheroptimierte Stagingtabelle erstellt, um die neuesten systemversionsverwalteten Änderungen aufzunehmen, die sich aus Aktualisierungs- und Löschvorgängen für eine aktuelle speicheroptimierte Tabelle ergeben.

  • Daten aus der internen speicheroptimierten Stagingtabelle werden regelmäßig durch eine asynchrone Datenleerungsaufgabe in die datenträgerbasierte History-Tabelle verschoben. Dieser Datenleerungsmechanismus hält die internen Speicherpuffer bei unter 10 Prozent der Arbeitsspeichernutzung der übergeordneten Objekte. Sie können den gesamten Arbeitsspeicherverbrauch der speicheroptimierten systemversionsverwalteten temporalen Tabelle ermitteln, 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.

  • Mit SYSTEM_VERSIONING = OFF oder wenn das Schema einer systemversionsverwalteten Tabelle durch das Hinzufügen, Entfernen oder Ändern von Spalten geändert wird, wird der vollständige 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 Zeilen, die in den internen Verlaufspuffer 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. 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.

Die Aufgabe zum Leeren der Daten

Der Datenflush ist eine regelmäßig ausgeführte Aufgabe, die überprüft, ob eine speicheroptimierte Tabelle eine von der Speichergröße abhängige Bedingung für die Datenverschiebung erfüllt. Die Datenverschiebung beginnt, wenn der Speicherverbrauch der internen Staging-Tabelle acht Prozent des Speicherverbrauchs der aktuellen temporalen 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.

Zugehöriger Inhalt

  • Last updated on