Stockage des données d’activité

Cette rubrique décrit le stockage des données d’activité, les problèmes de performances causés par la croissance des tables d’activité au fil du temps et la façon dont BAM résout ces problèmes de performances avec des tables distinctes pour les activités en cours et les activités terminées. Cette rubrique décrit également la fenêtre en ligne pour l’interrogation des données et la façon dont vous pouvez utiliser le partitionnement dans BAM pour des performances plus élevées.

L’idée de base du stockage de données d’activité consiste à avoir une table distincte pour chaque type d’activité, dans laquelle chaque enregistrement représente une instance d’activité différente (par exemple, en cours ou terminée).

Dans cet exemple, si l’activité était commande d’achat, la table se présente comme suit :

Po po#	RecvTime	Ville	Quantité	ShipTime	Temps de livraison
123	8h00	Seattle	150	8h24	12h45
124	8h30	Seattle	234	8h45	13h20
125	8h35 du matin	Redmond	87	9h05	14h30
126	8h45	Seattle	450	9h20	13h10
127	8h55 du matin	Redmond	200	9h30 du matin	<NULL>
128	8h57	Seattle	340	9h20	13h05
129	9h12	Seattle	120	9h45	<NULL>
130	9h30	Redmond	25	10 h 15	<NULL>
131	9:45	Seattle	250	10h35	<NULL>
132	10h00	Redmond	100	<NULL>	<NULL>
133	10h15	Seattle	230	<NULL>	<NULL>
134	10h25	Redmond	45	<NULL>	<NULL>

Dans ce tableau, lorsque BAM reçoit un nouveau bon de commande, il insère une nouvelle ligne et définit certaines colonnes sur des valeurs non null (RecvTime, City, Quantity, etc.). Plus tard, lorsque vous approuvez et envoyez cette commande d’achat, BAM définit ShipTime sur une valeur non null. Enfin, lorsque vous recevez et confirmez l’expédition, BAM définit DeliveryTime sur une valeur non null.

Les performances de cette implémentation simpliste se dégradent rapidement au fil du temps. Au début, les performances sont limitées par le nombre de transactions que le serveur SQL peut effectuer (essentiellement liée au processeur), mais après un certain temps, elle diminue considérablement. En même temps, la longueur moyenne de la file d’attente pour les E/S de disque augmente au-delà des limites acceptables :

Performance d'écriture de BAM et longueur de la file d’attente du disque

La raison en est que la taille de la table augmente à mesure que d’autres instances du processus métier se terminent. Par exemple, la première fois, l’instruction UPDATE de la procédure stockée provoque une recherche sur l’index cluster pour le numéro de bon de commande et lit certaines pages en mémoire. Étant donné que les instances du processus de bon de commande sont indépendantes (certaines prennent beaucoup de temps, mais certaines sont courtes), l’appel suivant à la procédure stockée peut être pour une autre instance de bon de commande et nécessite donc la lecture de différentes pages de données en mémoire. Tant que le nombre total d’enregistrements de bon de commande est petit, SQL Server met en cache toutes les pages de données en mémoire. Lorsque le nombre d’enregistrements augmente suffisamment grand, le taux d’accès au cache diminue et chaque opération nécessite une lecture de disque physique. Apparemment, dans ce cas, aucune requête contre la table n'est possible.

Tables BAM

Pour éviter ce problème, BAM utilise deux tables distinctes : une pour les activités toujours en cours, et une autre pour les tables terminées dans la figure suivante :

BAM Tables

Dans cette figure, l’idée est de conserver une table relativement petite dans laquelle les mises à jour se produisent et une autre qui augmente, mais est accessible de manière incrémentielle (INSERTs uniquement). Dans l’exemple, seules les commandes en cours de traitement se trouvent dans la table active, tandis que toutes les commandes qui ont déjà été livrées vont à la table terminée.

En raison du déclencheur, cette structure de tables est plus lente qu’une instruction INSERT/UPDATE d’une table unique au début, mais conserve les performances d’écriture stables au fil du temps.

Fenêtre en ligne pour les données d’activité

Le stockage d’activités gère principalement les requêtes pour les activités actuelles ou récemment terminées. BAM archive, puis purge les activités très anciennes et terminées de la base de données d'importation principale BAM. Ainsi, les données d’activité transitent par BAM et sont disponibles pour les requêtes pendant une fenêtre en ligne configurable.

Partitionnement BAM

Pour améliorer les performances et éviter les temps d’arrêt, le stockage d’activité utilise le partitionnement en fonction de l’horodatage lorsque l’activité a été terminée. BAM effectue cette opération en permutant régulièrement la table terminée avec une autre table vide du même format. Une fois que BAM effectue cette opération, les autres activités terminées passent dans la nouvelle table, tandis que BAM conserve l’ancienne uniquement pour les requêtes, comme dans la figure suivante :

Échange de partition BAM

Une fois qu'une partition est totalement en dehors de la fenêtre en ligne, BAM l'archive puis la supprime. Pour réduire cette complexité de l’utilisateur, BAM conserve également une vue partitionnée du formulaire :

SELECT * FROM Active   
UNION ALL   
SELECT * FROM Completed   
UNION ALL  
  

BAM recrée automatiquement cette vue chaque fois qu’elle crée ou supprime une partition.

Notez les points suivants sur le partitionnement BAM :

• Le nom de la vue partitionnée est bam_<ActivityName>_AllInstances. Cette vue n’est pas destinée aux requêtes directes, mais peut être utile lors de la résolution des problèmes de l’instrumentation BAM. Vous devez interroger les données à partir des vues spécifiques pour chaque catégorie d’utilisateurs professionnels que vous créez en haut de cette vue. Pour plus d’informations, consultez Interroger les données d’instance.

• Vous définissez la fenêtre en ligne en modifiant les valeurs pour OnlineWindowTimeUnit et OnlineWindowLength dans l’enregistrement de l’activité actuelle dans la table bam_Metadata_Activities dans la base de données d’importation principale.

• Le package DTS, BAM_DM_<ActivityName>, effectue le partitionnement et l’archivage/purge. Chaque fois que ce package s’exécute, il tronque une autre partition et archive/supprime toutes les partitions qui se trouvent en dehors de la fenêtre en ligne.

• Si vous n’avez pas configuré la base de données d’archivage, BAM supprime les anciennes données d’activité sans archivage.

Voir aussi

Infrastructure dynamique BAM