Partager via

Performances des tables temporelles optimisées en mémoire avec gestion de version par le système

  • Article

S’applique à : SQL Server 2016 (13.x) et versions ultérieures Azure SQL Database Azure SQL Managed Instance

Cet article décrit certaines considérations relatives aux performances lors de l’utilisation de tables temporelles optimisées en mémoire à version contrôlée par le système.

L’ajout du contrôle de version à une table non temporelle a un impact sur les opérations de mise à jour et de suppression, car la table historique est mise à jour automatiquement.

Considérations relatives aux performances

Chaque mise à jour et suppression est enregistrée dans une table d’historique mémoire optimisée interne. Vous pouvez rencontrer une consommation inattendue de mémoire si votre charge de travail utilise ces deux opérations massivement. C'est pourquoi nous vous conseillons de tenir compte des éléments suivants :

  • N’effectuez pas de suppressions massives de la table actuelle en une seule étape. Envisagez de supprimer les données en plusieurs lots par un vidage manuel intermédiaire, en appelant sp_xtp_flush_temporal_historyou pendant SYSTEM_VERSIONING = OFF.

  • N'effectuez pas de mises à jour massives de la table en une seule fois, car cela peut entraîner une consommation de mémoire deux fois supérieure à la quantité de mémoire nécessaire pour mettre à jour une table à non optimisée pour la mémoire temporelle. Ce doublement de la consommation de mémoire est temporaire, car la tâche de vidange des données fonctionne régulièrement pour maintenir la consommation de mémoire des tables de stockage internes dans les limites prévues en régime permanent. La limite est de 10 % de la consommation de mémoire de la table temporelle actuelle. Envisagez d’effectuer des mises à jour massives en plusieurs lots ou pendant SYSTEM_VERSIONING = OFF, comme pour définir les valeurs par défaut des nouvelles colonnes ajoutées.

La période d'activation de la tâche de nettoyage des données n'est pas configurable, mais vous pouvez exécuter manuellement sp_xtp_flush_temporal_history si nécessaire.

Envisagez d’utiliser l’index columnstore en cluster comme option de stockage pour la table historique sur disque, notamment si vous prévoyez d’exécuter des requêtes d’analyse sur des données historiques qui utilisent des fonctions d’agrégation ou de fenêtrage. Dans ce cas, un index columnstore cluster est un choix optimal pour votre table d’historique. Les index columnstore en cluster fournissent une bonne compression des données et se comportent de manière conviviale, en s’alignant sur la façon dont les données d’historique sont générées.

Contenu connexe