Considérations et limitations liées aux tables temporelles

S’applique à : SQL Server 2016 (13.x) et versions ultérieures Azure SQL DatabaseAzure SQL Managed InstanceSQL database in Microsoft Fabric

Lorsque vous travaillez avec des tables temporelles, soyez conscient des considérations et limitations suivantes dues à la nature du versionnement système :

  • Une table temporelle doit avoir une clé primaire définie, pour corréler les enregistrements entre la table actuelle et la table historique. La table d’historique ne peut pas avoir de clé primaire définie.

  • Les colonnes de période SYSTEM_TIME utilisées pour enregistrer les valeurs ValidFrom et ValidTo doivent être définies avec le type de données datetime2.

  • La syntaxe temporelle fonctionne sur les tables ou les vues stockées localement dans la base de données. Avec des objets distants comme des tables sur un serveur lié ou des tables externes, vous ne pouvez pas utiliser la clause FOR ou les prédicats de période directement dans la requête.

  • Si le nom d’une table d’historique est spécifié lors de sa création, vous devez spécifier le nom du schéma et de la table.

  • Par défaut, la table d’historique est compressée par PAGE.

  • Si la table actuelle est partitionnée, la table historique est créée sur le groupe de fichiers par défaut car la configuration de partitionnement n’est pas reproduite automatiquement de la table actuelle vers la table historique.

  • Les tables temporelles et d’historique ne peuvent pas utiliser FileTable ou FILESTREAM. FileTable and FILESTREAM autorisent la manipulation des données en dehors de SQL Server. Par conséquent, le contrôle de version du système ne peut pas être garanti.

  • Une table de nœuds ou d’arêtes ne peut pas être créée ou modifiée en tant que table temporelle.

  • Même si les tables temporelles prennent en charge les types de données blob, comme (n)varchar(max), varbinary(max), (n)text et image, ceux-ci entraînent des coûts de stockage importants et ont un impact sur les performances en raison de leur taille. Lorsque vous concevez votre système, soyez prudent lorsque vous utilisez ces types de données.

  • La table d’historique doit être créée dans la même base de données que la table actuelle. L’interrogation temporelle sur un serveur lié n’est pas prise en charge.

  • La table d’historique ne peut pas posséder de contraintes (clé primaire, clé étrangère, table ou colonne).

  • Les vues indexées ne sont pas prises en charge en plus des requêtes temporelles (qui utilisent la clause FOR SYSTEM_TIME).

  • L’option En ligne (WITH (ONLINE = ON) n’a aucun effet sur ALTER TABLE ALTER COLUMN dans une table temporelle versionnée par le système. L’opération sur la colonne ALTER n’est pas effectuée en ligne, quelle que soit la valeur spécifiée pour l’option ONLINE.

  • Les instructions INSERT et UPDATE ne peuvent pas référencer les colonnes de la période SYSTEM_TIME. Les tentatives d’insertion de valeurs directement dans ces colonnes sont bloquées.

  • TRUNCATE TABLE n’est pas pris en charge alors que SYSTEM_VERSIONING est ON.

  • La modification directe des données dans une table d’historique n’est pas autorisée.

  • Pour éviter d’invalider la logique du langage de manipulation des données (DML), INSTEAD OF les déclencheurs ne sont autorisés ni sur la table actuelle ni sur la table historique. Les déclencheurs AFTER sont autorisés uniquement dans la table actuelle. Ces déclencheurs sont bloqués dans la table d’historique afin d’éviter l’invalidation de la logique DML.

  • L’utilisation de technologies de réplication est limitée :

    • Groupes de disponibilité : entièrement pris en charge

    • Capture des données modifiées et suivi des modifications : pris en charge uniquement pour la table actuelle

    • Capture instantanée et réplication transactionnelle : uniquement prise en charge pour un serveur de publication unique sans activation de Temporal et un abonné avec Temporal activé. L'utilisation de plusieurs abonnés n'est pas prise en charge en raison d'une dépendance à l'égard de l'horloge du système local, ce qui peut entraîner des données temporelles incohérentes. Dans ce cas, le serveur de publication est utilisé pour une charge de travail de traitement transactionnel en ligne (OLTP), tandis que le serveur d’abonnement sert à décharger la charge liée au reporting, y compris les requêtes AS OF. Lorsque l’agent de distribution commence, il ouvre une transaction qui reste ouverte jusqu’à ce que l’agent de distribution s’arrête. ValidFrom et ValidTo sont remplis jusqu’au moment de début de la première transaction que commence l’agent de distribution. Il est préférable d’exécuter l’agent de distribution selon une planification et non pas en continu (son comportement par défaut) s’il est important pour votre application ou votre organisation que ValidFrom et ValidTo soient renseignés avec une heure proche de l’heure système actuelle. Pour plus d’informations, voir Scénarios d’usage des tables temporelles.

    • Réplication par fusion : Non prise en charge pour les tables temporelles

  • Les requêtes régulières affectent uniquement les données dans la table actuelle. Pour interroger des données dans la table d’historique, vous devez utiliser des requêtes temporelles. Pour plus d’informations, consultez Interroger les données d'une table temporelle version système.

  • Une stratégie d’indexation optimale inclut un index columnstore groupé ou un index rowstore B-tree sur la table courante, et un index columnstore regroupé sur la table historique, pour une taille et des performances de stockage optimales. Si vous créez ou utilisez votre propre tableau historique, créez ce type d’index composé de colonnes de période commençant par la colonne de fin de période. Cet index accélère les requêtes temporelles et les requêtes faisant partie de la vérification de cohérence des données. La table d’historique par défaut crée un index de rowstore regroupé basé sur les colonnes de période (fin, début). Au minimum, utilisez un index rowstore non clusteré.

  • Les objets/propriétés suivantes ne sont pas répliqués de la table actuelle vers la table d’historique lors de la création de la table d’historique :

    • Définition de période
    • Définition de l’identité
    • Indexes
    • Statistics
    • Vérifier les contraintes
    • Triggers
    • Configuration du partitionnement
    • Permissions
    • Prédicats de sécurité au niveau des lignes

  • On ne peut pas configurer une table d’historique comme la table actuelle dans une chaîne de tableaux d’historique.

Note

De manière générale, la documentation SQL Server utilise le terme B-tree en référence aux index. Dans les index rowstore, le moteur de base de données implémente une structure B+. Cela ne s’applique pas aux index columnstore ou aux index sur les tables à mémoire optimisée. Pour plus d’informations, consultez le Guide de conception et d’architecture d’index SQL Server et Azure SQL.

Contenu connexe

  • Last updated on