Gérer les données historiques avec la stratégie de conservation

Une fois la stratégie de conservation des données définie pour une base de données et la table sous-jacente, une tâche de minuteur de temps en arrière-plan s’exécute pour supprimer tous les enregistrements obsolètes de la table à laquelle la stratégie de conservation est appliquée. L’identification des lignes correspondantes et leur suppression de la table sont effectuées de façon transparente par la tâche en arrière-plan planifiée et exécutée par le système. La condition d’ancienneté pour les lignes de table est vérifiée par rapport à la colonne filter_column spécifiée dans la définition de table. Si la période de rétention est définie à une semaine, par exemple, les lignes de la table admissibles au nettoyage remplissent l’une des conditions suivantes :

• Si la colonne de filtre utilise le type de donnée DATETIMEOFFSET, la condition est filter_column < DATEADD(WEEK, -1, SYSUTCDATETIME())
• Sinon, la condition est filter_column < DATEADD(WEEK, -1, SYSDATETIME())

Phases de nettoyage de la conservation des données

L’opération de nettoyage de la conservation des données comprend deux phases :

1. La découverte : dans cette phase, l’opération de nettoyage identifie toutes les tables dans les bases de données utilisateur afin de créer une liste de nettoyage. La découverte se produit une fois par jour.
2. Le nettoyage : dans cette phase, le nettoyage est exécuté sur toutes les tables qui ont une période de conservation des données limitée et qui ont été identifiées lors de la découverte. Si l’opération de nettoyage ne peut pas être effectuée sur une table, alors cette table est ignorée pendant la tâche en cours et fera l’objet d’une nouvelle tentative dans l’itération suivante. Le nettoyage obéit aux principes suivants :
   • Si une ligne obsolète est verrouillée par une autre transaction, cette ligne est ignorée.
   • Le nettoyage s’exécute avec un dépassement de délai d'attente de verrou par défaut de 5 secondes. Si les verrous ne peuvent pas être acquis sur les tables dans ce délai, la table est ignorée pendant l’exécution en cours et fera l’objet d’une nouvelle tentative dans l’itération suivante.
   • En cas d’erreur lors du nettoyage d’une table, cette table est ignorée jusqu’à une nouvelle tentative dans la prochaine itération.

Nettoyage manuel

Selon les paramètres de conservation des données appliqués à une table et la nature de la charge de travail sur la base de données, il peut arriver que le thread de nettoyage automatique ne supprime pas complètement toutes les lignes obsolètes lors de son exécution. Pour permettre aux utilisateurs de supprimer manuellement des lignes obsolètes, la procédure stockée sys.sp_cleanup_data_retention a été introduite dans Azure SQL Edge.

Cette procédure stockée accepte trois paramètres :

• @schema_name : nom du schéma propriétaire de la table. Obligatoire.
• @table_name : nom de la table qui fait l’objet du nettoyage manuel. Obligatoire.
• @rowcount : variable de sortie. Retourne le nombre de lignes qui ont été nettoyées par la procédure stockée de nettoyage manuel. facultatif.

Pour plus d’informations, consultez sys.sp_cleanup_data_retention (Transact-SQL).

L’exemple suivant illustre l’exécution de la procédure stockée de nettoyage manuel pour la table dbo.data_retention_table.

DECLARE @rowcnt BIGINT;
EXEC sys.sp_cleanup_data_retention 'dbo', 'data_retention_table', @rowcnt OUTPUT;
SELECT @rowcnt;

Comment les lignes obsolètes sont supprimées

Le processus de nettoyage dépend de la disposition de l’index de la table. Une tâche en arrière-plan est créée pour effectuer le nettoyage des données obsolètes dans toutes les tables où la période de conservation est limitée. La logique de nettoyage de l’index rowstore (segment de mémoire ou arbre B (B-tree)) supprime les lignes anciennes par petits blocs (jusqu’à 10 000). Cela réduit la charge sur le journal de la base de données et sur le sous-système d’E/S. Bien que la logique de nettoyage utilise l’index d’arbre B (B-tree) requis, l’ordre des suppressions des lignes antérieures à la période de rétention ne peut pas être garanti. Autrement dit, n’acceptez pas de dépendances relatives à l’ordre de nettoyage dans vos applications.

La tâche de nettoyage pour les indexes regroupés columnstore supprime d’un seul coup l’ensemble des groupes de lignes (généralement 1 million de lignes chacun). Ce procédé est efficace, surtout lorsque les données sont générées et deviennent obsolètes très rapidement.

Grâce à une excellente compression des données et à un nettoyage efficace de la conservation des données, les indexes regroupés columnstore sont un choix idéal dans les scénarios où votre charge de travail produit rapidement de grandes quantités de données.

Surveiller le nettoyage de la conservation des données

Les opérations de nettoyage de la stratégie de conservation des données peuvent être surveillées à l’aide de la fonctionnalité d’événements étendus dans Azure SQL Edge. Pour plus d'informations sur les événements étendus, consultez Vue d’ensemble des événements étendus.

Les événements étendus suivants facilitent le suivi de l’état des opérations de nettoyage.

De plus, un nouveau type de mémoire tampon en anneau nommé RING_BUFFER_DATA_RETENTION_CLEANUP a été ajouté à la vue de gestion dynamique sys.dm_os_ring_buffers. Cette vue peut être utilisée pour superviser les opérations de nettoyage de la stratégie de conservation des données.

Contenu connexe

• Stratégie de conservation des données
• Activer et désactiver les stratégies de conservation des données