Überlegungen und Einschränkungen zu temporalen Tabellen

  • Artikel

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 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 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 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_VERSIONING ON 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 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 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. 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 Dokumentation wird der Begriff „B-Struktur“ im Allgemeinen in Bezug auf Indizes verwendet. In Zeilenspeicherindizes implementiert die Datenbank-Engine eine B+-Struktur. Das gilt nicht für Columnstore-Indizes oder Indizes in speicheroptimierten Tabellen. Weitere Informationen finden Sie im Leitfaden zur Architektur und zum Entwerfen von SQL Server- und Azure SQL-Indizes.

Zugehöriger Inhalt