Stockage des données d'activité
Cette rubrique décrit le stockage des données d'activité, les problèmes de performances engendrés par l'augmentation progressive de la taille des tables de l'activité et la manière dont le composant BAM permet de résoudre ces difficultés en séparant les tables des activités en cours de celles des activités terminées. Cette rubrique traite également des fenêtres en ligne permettant d'interroger les données et de l'utilisation du partitionnement dans les analyses BAM pour augmenter les performances.
Le principe fondamental du stockage des données d'activité consiste à disposer d'une table par type d'activité, où chaque enregistrement représente une instance d'activité différente (par exemple, une instance en cours ou terminée).
Dans l'exemple développé ci-après, l'activité considérée est le traitement d'un bon de commande. La table se présente alors de la manière suivante :
| Bon de cmde n° | Heure réception | City | Quantité | Heure expédition | Heure livraison |
|---|---|---|---|---|---|
| 123 | 8h00 | Seattle | 150 | 8h24 | 12h45 |
| 124 | 8h30 | Seattle | 234 | 8h45 | 13h20 |
| 125 | 8h35 | Redmond | 87 | 9h05 | 14h30 |
| 126 | 8h45 | Seattle | 450 | 9h20 | 15h10 |
| 127 | 8h55 | Redmond | 200 | 9h30 | <NULL> |
| 128 | 8h57 | Seattle | 340 | 9h20 | 15h05 |
| 129 | 9h12 | Seattle | 120 | 9h45 | <NULL> |
| 130 | 9h30 | Redmond | 25 | 10h15 | <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 cette table, lorsque le composant BAM reçoit un nouveau bon de commande, une nouvelle ligne est insérée et des valeurs autres que « null » sont attribuées à certaines colonnes (heure de réception, ville, quantité, etc.). Ensuite, une fois que vous avez validé l'expédition du bon de commande, l'analyse BAM définit une valeur non « null » dans la colonne correspondant à l'heure d'expédition. Enfin, lorsque la commande a été livrée, l'analyse BAM attribue une valeur autre que « null » pour l'heure de livraison.
Les performances de cette implémentation simplifiée se détériorent rapidement au fil du temps. Au départ, le nombre de transactions pouvant être effectuées par le serveur SQL étant limité (restriction principalement due au processeur), l'impact sur les performances est réduit. En revanche, au bout d'un certain temps, les performances diminuent considérablement. Dans le même temps, la longueur moyenne de la file d'attente pour les E/S du disque augmente jusqu'à dépasser les capacités :
Rapport performances de l'analyse BAM en écriture / longueur de la file d'attente du disque
Cette évolution est due à l'augmentation de la taille de la table au fur et à mesure que de nouvelles instances du processus d'entreprise prennent fin. Par exemple, un premier appel à la procédure stockée (instruction UPDATE) entraîne une recherche sur les numéros de bon de commande dans l'index mis en cluster ainsi qu'une lecture de certaines pages en mémoire. Les instances du processus de bon de commande étant indépendantes les unes des autres (certaines sont longues, d'autres très brèves), l'appel à la procédure stockée suivant peut concerner une autre instance de bon de commande et donc nécessiter la lecture de pages de données en mémoire différentes. Tant que le nombre total d'enregistrements de bon de commande est réduit, le serveur SQL met en mémoire cache toutes les pages de données. Lorsque le nombre de ces enregistrements devient trop important, la fréquence d'accès au cache diminue et chaque opération requiert une lecture sur le disque physique. Il semble que dans une telle situation, aucune activité d'interrogation de la table ne soit possible.
Tables BAM
Pour contourner ce problème, l'analyse BAM utilise deux tables distinctes : dans le schéma ci-après, une table est consacrée aux activités en cours et une autre aux activités terminées.
BAM Tables
Dans ce schéma, l'objectif est d'obtenir, d'une part, une table dont la taille reste raisonnable et où ont lieu les mises à jour et, d'autre part, une table dont la taille peut augmenter et qui est accessible de façon incrémentielle (instructions INSERT uniquement). Dans l'exemple présenté ici, seules les commandes en cours de traitement sont placées dans la table active tandis que celles qui ont déjà été livrées sont placées dans la table des activités terminées.
Au départ, cette structure à tables multiples est plus lente qu'une table unique fonctionnant à l'aide d'instructions INSERT/UPDATE en raison du système de déclenchement utilisé, mais à long terme, ses performances en écriture restent stables.
Fenêtre en ligne et données d'activité
Dans un premier temps, le stockage d'activité gère les requêtes relatives aux activités en cours ou venant de se terminer. L'analyse BAM se charge ensuite d'archiver et de supprimer de la base de données d'importation principale BAM les activités terminées depuis un certain temps. Les données d'activité transitent par le composant BAM et sont disponibles pour d'éventuelles requêtes pendant une période définie par la fenêtre en ligne.
Partitionnement BAM
Pour obtenir des performances élevées et éviter les temps d'arrêt, le stockage d'activité utilise un partitionnement en fonction de la date et de l'heure de fin de l'activité. Le composant BAM réalise cette opération en remplaçant régulièrement la table des activités terminées par une table vide de format identique. Les nouvelles activités terminées sont ensuite placées dans la table vide tandis que l'analyse BAM conserve l'ancienne table pour d'éventuelles requêtes, comme indiqué dans le schéma ci-dessous :
Remplacement de partition BAM
Une fois qu'une partition se trouve en dehors de la fenêtre en ligne spécifiée, le composant BAM l'archive puis la supprime. Afin de rendre cette opération moins complexe pour l'utilisateur, l'analyse BAM gère également une vue partitionnée du formulaire :
SELECT * FROM Active
UNION ALL
SELECT * FROM Completed
UNION ALL
Cette vue est automatiquement régénérée à chaque création ou suppression d'une partition.
Notez les remarques suivantes concernant le partitionnement de l'analyse BAM :
Le nom de la vue partitionnée est bam_<ActivityName>_AllInstances. Cette vue n'est pas destinée à des interrogations directes mais peut être utile lors du dépannage des outils BAM. Pour effectuer des requêtes sur les données provenant des vues que vous avez créées pour chaque catégorie d'utilisateurs d'activités, utilisez une nouvelle vue. Pour plus d’informations, consultez Interrogation des données d’instance.
Vous définissez la fenêtre en ligne en modifiant les valeurs de 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/vidage. À chaque exécution, ce lot tronque une nouvelle partition et archive et supprime toutes les partitions se trouvant en dehors de la fenêtre en ligne spécifiée.
Si vous n'avez pas configuré de base de données pour archiver les partitions, le composant BAM supprime les anciennes données d'activité sans les archiver au préalable.