Überlegungen und Einschränkungen zu temporalen Tabellen

  • Artikel

Gilt für: SQL Server 2016 (13.x) und höher Azure SQL-DatenbankAzure 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 Werte ValidFrom und ValidTo 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 kein FileTable oder FILESTREAM verwenden, da FileTable und FILESTREAM die Datenbearbeitung außerhalb von SQL Server ermöglichen. Daher 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 der gleichen 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 auf ALTER TABLE ALTER COLUMN, wenn es sich um eine temporale Tabelle mit Systemversionsverwaltung handelt. Die ALTER-Spalte wird nicht als Onlinevorgang ausgeführt, unabhängig davon, welche Werte für die ONLINE-Option angegeben wurden.

  • INSERT- und UPDATE-Anweisungen können nicht auf die SYSTEM_TIME-Zeitraumspalten verweisen. Jeder Versuch, Werte direkt in diese Spalten einzufügen, wird blockiert.

  • TRUNCATE TABLE wird nicht unterstützt, wenn SYSTEM_VERSIONINGON ist.

  • Die direkte Änderung von Daten in einer Verlaufstabelle ist nicht zulässig.

  • ON DELETE CASCADE und ON 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 (entspricht parent_object_id in sys.foreign_key) fungiert, keine CASCADE-Optionen zulässig sind. Verwenden Sie Anwendungslogik oder AFTER-Trigger, um die Konsistenz beim Löschen mit der Primärschlüsseltabelle (entspricht referenced_object_id in sys.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 sie 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 nicht unterstützt, da dies aufgrund der Abhängigkeit von der lokalen Systemuhr zu inkonsistenten temporalen Daten führen könnte. 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 und ValidTo 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, dass ValidFrom und ValidTo 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, um die temporalen Abfragen sowie die Abfragen, die Teil der Datenkonsistenzüberprüfung sind, zu beschleunigen. 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.

Nächste Schritte