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

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

Cet article aborde des considérations spécifiques de performance lorsque vous utilisez des tables temporelles optimisées pour la mémoire version 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 pourriez subir une consommation de mémoire inattendue si votre charge de travail utilise beaucoup ces deux opérations. Tenez compte des éléments suivants :

  • N’effectuez pas de suppressions massives de la table actuelle en une seule étape. Envisagez la suppression des données par lots, avec un vidage manuel des données entre chaque lot, à l’aide de sp_xtp_flush_temporal_history, ou lors de SYSTEM_VERSIONING = OFF.

  • Ne réalisez pas de mises à jour massives de tables en même temps, car cela peut consommer deux fois plus de mémoire nécessaire pour mettre à jour une table non optimisée en 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 un stockage de colonnes en cluster comme option de stockage pour une table d’historique basée sur disque, surtout si vous prévoyez d’effectuer des requêtes analytiques sur des données historiques utilisant des fonctions d’agrégat ou de fenêtrage. Dans ce cas, un index columnstore clusterisé constitue 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

  • Last updated on