Temporale Tabellen mit Systemversionsverwaltung und speicheroptimierten Tabellen

  • Artikel

Gilt für: SQL Server 2016 (13.x) und höher Azure SQL-DatenbankAzure 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. Sie bieten hohen Transaktionsdurchsatz, sperrenfreie Parallelität und gleichzeitig die Möglichkeit, große Mengen von Verlaufsdaten zu speichern, die leicht abgefragt werden können.

Ü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 sehr 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-Speichers ü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 ermöglichen einen hohen Transaktionsdurchsatz, sperrenfreie Parallelität und gleichzeitig die Möglichkeit, große Mengen von Verlaufsdaten zu speichern, da sie In-Memory-Tabellen zum Speichern von aktuellen Daten (die temporale Tabelle) und datenträgerbasierte Tabellen für Verlaufsdaten verwenden. Die Auswirkung auf DML-Vorgänge wird durch die Verwendung einer internen, automatisch generierten speicheroptimierten Stagingtabelle minimiert, die den aktuellen Verlauf speichert und ermöglicht, dass DMLs auf systemintern kompiliertem Code heraus ausgeführt werden können.

Das folgende Diagramm veranschaulicht diese Architektur.Temporale speicherinterne Architektur

Details zur Implementierung

Die folgenden Fakten über temporale Tabellen mit Systemversionsverwaltung und speicheroptimierten Tabellen sind Aspekte, die Sie berücksichtigen sollten, wenn Sie eine speicheroptimierte Tabelle mit Systemversionsverwaltung erstellen. Syntaxoptionen und ein Beispiel finden Sie unter CREATE TABLE (Transact-SQL).

  • 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. In Ad-hoc-Abfragen und nicht nativen Modulen wird die Verwendung der Klausel FOR SYSTEM TIME mit speicheroptimierten Tabellen 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 der aktuellen speicheroptimierten Tabelle sind.
  • Daten aus der internen speicheroptimierten Stagingtabelle werden vom asynchronen Datenleerungstask regelmäßig in die datenträgerbasierte Verlaufstabelle verschoben. Dieser Datenleerungsmechanismus hat zum Ziel, die internen Speicherpuffer bei unter 10 % der Arbeitsspeichernutzung der übergeordneten Objekte zu halten. Sie können die gesamte Arbeitsspeichernutzung der speicheroptimierten temporalen Tabelle mit Systemversionsverwaltung nachverfolgen, indem Sie sys.dm_db_xtp_memory_consumers (Transact-SQL) abfragen und die Daten für die interne speicheroptimierte Stagingtabelle sowie die aktuelle temporale Tabelle zusammenfassen.
  • Sie können eine Datenleerung erzwingen, indem Sie sp_xtp_flush_temporal_historyaufrufen.
  • 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 SNAPSHOT-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

Die interne speicheroptimierte Stagingtabelle ist ein internes Objekt, das vom System erstellt wird, 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 Spalte vom Typ Change_ID 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 8052 Bytes.
  • Die interne speicheroptimierte Stagingtabelle wird im Objekt-Explorer von SQL Server Management Studio nicht dargestellt.
  • Metadaten für diese Tabelle sowie für die Verbindung mit der aktuellen temporalen Tabelle finden Sie unter sys.internal_tables (Transact-SQL).

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 8 % der Arbeitsspeichernutzung der aktuellen temporalen Tabelle erreicht.

Der Datenleerungstask wird regelmäßig nach einem Zeitplan aktiviert, der basierend auf der vorhandenen Arbeitsauslastung variiert. Bei hoher Arbeitsauslastung bis zu alle 5 Sekunden und bei geringer Arbeitsauslastung nur jede 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 Datenleerung erzwingen, indem Sie sp_xtp_flush_temporal_history aufrufen und das Schema sowie den Tabellennamen angeben: sys.sp_xtp_flush_temporal_history @schema_name, @object_name. Mit diesem vom Benutzer ausgeführten Befehl wird derselbe Datenverschiebungsvorgang aufgerufen wie durch das Aufrufen des Datenleerungstasks durch das System gemäß internem Zeitplan.

Weitere Informationen