Partager via

Limitations et considérations relatives au registre

  • Article

S’applique à : SQL Server 2022 (16.x)base de données Azure SQL Azure SQL Managed Instance

Certaines considérations et limitations doivent être prises en compte pour travailler avec des tables de registre en raison de la nature du contrôle de version du système et des données immuables.

Considérations et limitations générales

Prenez en compte les points suivants lorsque vous travaillez avec le registre.

Considérations et limitations relatives aux tables de registre

  • Les tables existantes d’une base de données qui ne sont pas des tables de registre ne peuvent pas être converties en tables de registre. Pour plus d’informations, consultez Migration de données de tables classiques dans des tables de registre.
  • Une fois créée, une table de registre ne peut pas être convertie en table qui n’est pas une table de registre.
  • La suppression des données anciennes dans les tables de registre en ajout seul ou la table d’historique de tables de registre pouvant être mises à jour n’est pas prise en charge.
  • TRUNCATE TABLE n’est pas pris en charge.
  • Quand une table de registre pouvant être mise à jour est créée, elle ajoute quatre colonnes GENERATED ALWAYS à la table de registre. Une table de registre en ajout seul ajoute deux colonnes à la table de registre. Ces nouvelles colonnes sont comptabilisées par rapport au nombre maximal de colonnes prises en charge dans Azure SQL Database (1 024).
  • Les tables en mémoire ne sont pas prises en charge.
  • Les jeux de colonnes éparses ne sont pas pris en charge.
  • La partition SWITCH IN/OUT n’est pas prise en charge.
  • DBCC CLONEDATABASE n'est pas pris en charge.
  • Les tables du registre ne peuvent pas avoir d’index de recherche en texte intégral.
  • Les tables de registre ne peuvent pas être des tables de graphe.
  • Les tables de registre ne peuvent pas être des FileTable.
  • Les tables de registre ne peuvent pas avoir d’index rowstore non-cluster quand elles ont un index columnstore clusterisé.
  • Le suivi des modifications n’est pas autorisé sur la table d’historique, à la différence des tables de registre.
  • La capture des changements de données n'est pas autorisée dans la table d'historique, mais elle l'est dans les tables du registre.
  • La réplication transactionnelle n’est pas prise en charge par les tables de registre.
  • La mise en miroir de bases de données n’est pas prise en charge.
  • Azure Synapse Link est pris en charge, mais uniquement pour la table du registre, pas pour la table de l'historique.
  • Modifiez le chemin d'accès manuellement après une restauration native d'une sauvegarde de base de données vers une Azure SQL Managed Instance.
  • Modifiez manuellement le chemin d'accès de synthèse après la création d'une liaison Managed Instance vers une Azure SQL Managed Instance.
  • SQL Data Sync n’est pas pris en charge avec les tables de registre.

Types de données non pris en charge

  • XML
  • SqlVariant
  • Type de données défini par l'utilisateur
  • FILESTREAM

Limitations relatives aux tables temporelles

Les tables de registre actualisables sont basées sur la technologie des tables temporelles et héritent de la plupart des limitations, mais pas de toutes. Vous trouverez ci-dessous la liste des limitations héritées des tables temporelles.

  • 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, ainsi que celui de la vue de registre.
  • Par défaut, la table d’historique est PAGE compressée.
  • Si la table actuelle est partitionnée, la table d’historique est créée sur le groupe de fichiers par défaut, car la configuration du partitionnement n’est pas répliquée automatiquement de la table actuelle vers la table d’historique.
  • Les tables temporelles et historiques ne peuvent pas être des FILETABLE. Elles peuvent contenir des colonnes de tout type de données pris en charge autre que FILESTREAM. FILETABLE et 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. Graph n’est pas pris en charge avec le registre.
  • Bien que les tables temporelles prennent en charge les types de données blob, comme (n)varchar(max), varbinary(max), (n)text, et image, elles entraînent des coûts de stockage importants et ont des répercussions sur les performances en raison de leur taille. Par conséquent, il convient de prendre des précautions lorsque vous concevez votre système si vous souhaitez utiliser 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).
  • L’option Online (WITH (ONLINE = ON) n’a aucun effet sur ALTER TABLE ALTER COLUMN dans le cas d’une table temporelle avec contrôle de version du système. L’opération ALTER COLUMN 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 faire référence aux colonnes GENERATED ALWAYS. Les tentatives d’insertion de valeurs directement dans ces colonnes sont bloquées.
  • UPDATETEXT et WRITETEXT ne sont pas pris en charge.
  • Les déclencheurs ne sont pas autorisés sur la table d’historique.
  • L'utilisation de technologies de réplication est limitée :
    • Always On (Toujours active) : entièrement prise en charge
    • Capture instantanée, fusion et réplication transactionnelle : non prises en charge par les tables temporelles
  • Une table d’historique ne peut pas être configurée comme table actuelle d’une chaîne de tables d’historique.
  • Les objets ou propriétés suivants ne sont pas répliqués de la table actuelle vers la table d'historique lors de la création de cette dernière :
    • Définition de la période
    • Définition de l’identité
    • Index
    • Statistiques
    • Contraintes de validation
    • Déclencheurs
    • Configuration du partitionnement
    • autorisations
    • Prédicats de sécurité au niveau des lignes

Considérations relatives aux modifications de schéma

Ajouter des colonnes

L’ajout de colonnes pouvant accepter la valeur Null est pris en charge. L'ajout de colonnes non-nullables n'est pas pris en charge. Le registre est conçu pour ignorer les valeurs Null lors du calcul du hachage d’une version de ligne. De ce fait, lorsqu’une colonne pouvant accepter la valeur Null est ajoutée, le registre modifie le schéma des tables de registre et d’historique pour inclure la nouvelle colonne, sans que cela affecte le hachage des lignes existantes. L’ajout de colonnes dans les tables de registre est capturé dans sys.ledger_column_history.

Suppression de colonnes et de tables

Normalement, la suppression d’une colonne ou d’une table efface complètement les données sous-jacentes de la base de données. Ce comportement est fondamentalement incompatible avec la fonctionnalité de registre, qui exige que les données soient immuables. Au lieu de supprimer les données, le registre renomme simplement les objets supprimés de sorte qu’ils soient supprimés logiquement du schéma utilisateur, mais restent physiquement dans la base de données. Toutes les colonnes supprimées sont également masquées dans le schéma de la table de registre. Elles sont donc invisibles pour l’application utilisateur. Toutefois, les données de ces objets supprimés restent disponibles dans le cadre du processus de vérification du registre. Elles permettent aux utilisateurs d’inspecter les données historiques au moyen des vues de registre correspondantes. La suppression de colonnes dans les tables de registre est capturée dans sys.ledger_column_history. La suppression d’une table de registre est capturée dans sys.ledger_table_history. Les tables de registre et objets dépendants supprimés sont marqués comme supprimés dans les vues de catalogue système et renommés :

  • Les tables de registre supprimées sont marquées comme supprimées, en définissant is_dropped_ledger_table dans sys.tables, et renommées au format MSSQL_DroppedLedgerTable_<dropped_ledger_table_name>_<GUID>.
  • Les tables d’historique supprimées pour les tables de registre pouvant être mises à jour sont renommées au format MSSQL_DroppedLedgerHistory_<dropped_history_table_name>_<GUID>.
  • Les vues de registre supprimées sont marquées comme supprimées, en définissant is_dropped_ledger_view dans sys.views, et renommées au format MSSQL_DroppedLedgerView_<dropped_ledger_view_name>_<GUID>.

Remarque

Le nom des tables de registre, des tables d'historique et des vues du registre supprimées peut être tronqué si la longueur de la table ou de la vue renommée dépasse 128 caractères.

Modification des colonnes

Toutes les modifications qui n’affectent pas les données sous-jacentes d’une table de registre sont prises en charge sans aucune gestion spéciale, car elles n’ont pas d’impact sur les hachages capturés dans le registre. Ces modifications sont les suivantes :

  • Modification de la possibilité d’accepter la valeur Null
  • Classement pour les chaînes Unicode
  • Longueur des colonnes de longueur variable

En revanche, les opérations susceptibles de changer le format des données existantes (par exemple la modification du type de données) ne sont pas prises en charge.

Contenu connexe