Überlegungen und Einschränkungen zu temporalen Tabellen
Gilt für: SQL Server 2016 (13.x) und höher
Azure SQL-Datenbank
Azure SQL Managed Instance
Aufgrund der Eigenschaften der Systemversionsverwaltung gibt es einige Überlegungen und Einschränkungen, derer Sie sich bei der Arbeit mit temporalen Tabellen bewusst sein müssen:
Für eine temporale Tabelle muss ein Primärschlüssel definiert sein, um Datensätze zwischen der aktuellen Tabelle und den Verlaufstabellen zu korrelieren. Für die Verlaufstabelle kann kein Primärschlüssel definiert sein.
Die
SYSTEM_TIME
-Zeitraumspalten, die verwendet werden, um die WerteValidFrom
undValidTo
aufzuzeichnen, müssen mit dem Datentyp datetime2 definiert sein.Die temporale Syntax funktioniert für Tabellen oder Sichten, die lokal in der Datenbank gespeichert sind. Bei Remoteobjekten, wie z. B. Tabellen auf einem Verbindungsserver oder externen Tabellen, können Sie die
FOR
-Klausel- oder Perioden-Prädikate nicht direkt in der Abfrage verwenden.Falls der Name einer Verlaufstabelle während der Erstellung der Verlaufstabelle angegeben wird, müssen Sie das Schema und den Tabellennamen angeben.
Standardmäßig ist die Verlaufstabelle
PAGE
-komprimiert.Falls die aktuelle Tabelle partitioniert wurde, kann die Verlaufstabelle auf der Standarddateigruppe erstellt werden, da die Partitionierungskonfiguration nicht automatisch von der aktuellen auf die Verlaufstabelle repliziert wird.
Temporale Tabellen und Verlaufstabellen können FileTable oder FILESTREAM nicht verwenden. FileTable und FILESTREAM ermöglichen die Datenbearbeitung außerhalb von SQL Server, und somit kann die Systemversionsverwaltung nicht garantiert werden.
Eine Knoten- oder Edgetabelle kann nicht als temporale Tabelle erstellt oder in eine solche geändert werden.
Temporale Tabellen unterstützen zwar Blobdatentypen wie (n)varchar(max), varbinary(max), (n)text und image, ziehen jedoch signifikante Speicherkosten auf sich und wirken sich aufgrund ihrer Größe auf die Leistung aus. Daher sollten Sie beim Entwerfen Ihres Systems vorsichtig sein, wenn Sie diese Datentypen verwenden.
Die Verlaufstabelle muss in derselben Datenbank wie die aktuelle Tabelle erstellt werden. Temporale Abfragen über Verbindungsserver werden nicht unterstützt.
Die Verlaufstabelle darf keine Einschränkungen aufweisen (Primärschlüssel-, Fremdschlüssel-, Tabellen- oder Spalteneinschränkungen).
Indizierte Sichten, die temporale Abfragen (Abfragen, die die
FOR SYSTEM_TIME
-Klausel verwenden) überlagern, werden nicht unterstützt.Die Onlineoption (
WITH (ONLINE = ON
) hat keine Auswirkungen aufALTER TABLE ALTER COLUMN
, wenn es sich um eine temporale Tabelle mit Systemversionsverwaltung handelt. DieALTER
-Spalte wird nicht als Onlinevorgang ausgeführt, unabhängig davon, welche Werte für dieONLINE
-Option angegeben wurden.INSERT
- undUPDATE
-Anweisungen können nicht auf dieSYSTEM_TIME
-Zeitraumspalten verweisen. Jeder Versuch, Werte direkt in diese Spalten einzufügen, wird blockiert.TRUNCATE TABLE
wird nicht unterstützt, wennSYSTEM_VERSIONING
ON
ist.Die direkte Änderung von Daten in einer Verlaufstabelle ist nicht zulässig.
ON DELETE CASCADE
undON UPDATE CASCADE
sind in der aktuellen Tabelle nicht zulässig. Das heißt, dass in den Fällen, in denen die temporale Tabelle als verweisende Tabelle in der Fremdschlüsselbeziehung (entsprichtparent_object_id
insys.foreign_key
) fungiert, keineCASCADE
-Optionen zulässig sind. Verwenden Sie Anwendungslogik oder AFTER-Trigger, um die Konsistenz beim Löschen mit der Primärschlüsseltabelle (entsprichtreferenced_object_id
insys.foreign_key
) beizubehalten, um diese Einschränkung zu umgehen. Falls die Primärschlüsseltabelle temporal und die verweisende Tabelle nicht temporal ist, gibt es keine solche Einschränkung.
INSTEAD OF
-Trigger sind weder bei der aktuellen noch bei der Verlaufstabelle zulässig, um zu verhindern, dass die DML-Logik ungültig wird.AFTER
-Trigger sind nur in der aktuellen Tabelle zulässig. In der Verlaufstabelle werden diese Trigger blockiert, um zu vermeiden, dass die DML-Logik blockiert wird.Die Verwendung der Replikationstechniken ist eingeschränkt:
Verfügbarkeitsgruppen: vollständig unterstützt
Change Data Capture und Änderungsnachverfolgung: nur für die aktuelle Tabelle unterstützt.
Schnappschuss und Transaktionsreplikation: unterstützt nur einen Verleger mit deaktivierten temporalen Tabellen und einen Abonnenten mit aktivierten temporalen Tabellen. Die Verwendung von mehreren Abonnenten wird aufgrund einer Abhängigkeit von der lokalen Systemuhr, die zu inkonsistenten temporalen Daten führen kann, nicht unterstützt. In diesem Fall wird der Verleger für eine OLTP-Arbeitsauslastung verwendet, während der Abonnent zum Verlagern der Berichtserstellung dient (einschließlich „
AS OF
“-Abfragen). Wenn der Verteilungs-Agent startet, öffnet er eine Transaktion, die geöffnet bleibt, bis der Agent angehalten wird.ValidFrom
undValidTo
werden mit der Startzeit der ersten Transaktion aufgefüllt, die vom Verteilungs-Agent gestartet wird. Möglicherweise ist es besser, den Verteilungs-Agent nach einem Zeitplan auszuführen, statt das Standardverhalten zu verwenden und ihn fortlaufend auszuführen, wenn für Ihre Anwendung oder Organisation wichtig ist, dassValidFrom
undValidTo
mit einer Zeit aufgefüllt werden, die nur wenig von der aktuellen Systemzeit abweicht. Weitere Informationen finden Sie unter temporale Tabellen-Verwendungsszenarien.Mergereplikation: wird für temporale Tabellen nicht unterstützt
Reguläre Abfragen betreffen nur Daten in der aktuellen Tabelle. Zum Abfragen von Daten in der Verlaufstabelle müssen Sie zeitliche Abfragen verwenden. Weitere Informationen finden Sie unter Abfragen von Daten in einer temporalen Tabelle mit Systemversionsverwaltung.
Eine optimale Indizierungsstrategie enthält einen gruppierten Columnstore-Index und/oder einen B-Strukturindex auf der aktuellen Tabelle und einen Columnstore-Index auf der Verlaufstabelle für die optimale Speichergröße und -Leistung. Falls Sie Ihre eigene Verlaufstabelle erstellen oder verwenden, empfehlen wir Ihnen dringend, diese Art Index zu erstellen. Dieser Index sollte aus Zeitraumspalten bestehen und mit der Spalte „Ende des Zeitraums“ beginnen. Dieser Index beschleunigt temporale Abfragen sowie die Abfragen, die Teil der Datenkonsistenzüberprüfung sind. Die Standardverlaufstabelle hat einen für Sie erstellten gruppierten Rowstore-Index, der auf den Zeitraumspalten (Ende, Start) basiert. Ein nicht gruppierter Rowstore-Index wird mindestens empfohlen.
Die folgenden Objekte bzw. Eigenschaften werden beim Erstellen der Verlaufstabelle nicht aus der aktuellen Tabelle in die Verlaufstabelle repliziert:
- Periodendefinition
- Identitätsdefinition
- Indizes
- Statistik
- Check-Einschränkungen
- Auslöser
- Partitionierungskonfiguration
- Berechtigungen
- Prädikate für die Sicherheit auf Zeilenebene
Eine Verlaufstabelle kann nicht als aktuelle Tabelle in einer Kette von Verlaufstabellen konfiguriert werden.
Hinweis
In der SQL Server-Dokumentation wird der Begriff „B-Struktur“ im Allgemeinen in Bezug auf Indizes verwendet. In Zeilenspeicherindizes implementiert SQL Server eine B+-Struktur. Dies gilt nicht für Columnstore-Indizes oder In-Memory-Datenspeicher. Weitere Informationen finden Sie im Leitfaden zur Architektur und zum Entwerfen von SQL Server- und Azure SQL-Indizes.
Zugehöriger Inhalt
- Temporale Tabellen
- Erste Schritte mit temporalen Tabellen mit Systemversionsverwaltung
- Systemkonsistenzprüfungen von temporalen Tabellen
- Partitionierung mit temporalen Tabellen
- Sicherheit bei temporalen Tabellen
- Verwalten der Beibehaltung von Verlaufsdaten in temporalen Tabellen mit Systemversionsverwaltung
- Temporale Tabellen mit Systemversionsverwaltung für speicheroptimierte Tabellen
- Metadatenansichten und Funktionen für temporale Tabellen