Tables à maintenir
Dernière mise à jour : 21 janvier 2025
- S'applique à :
- Campaign Classic v7
La liste des tables à maintenir dépend de votre version d’Adobe Campaign, de l’utilisation que vous en faites et de la configuration du modèle de données.
Dans la liste qui suit, ne sont mentionnées que les tables les plus sujettes à la fragmentation. Les impacts sont les suivants :
- une surconsommation de l'espace-disque qui impacte les performances d'accès à la base,
- des index qui n’ont pas été mis à jour depuis longtemps ce qui réduit les performances des requêtes.
Tables Adobe Campaign
| Nom de la table | Taille | Activité principale | Commentaires |
|---|---|---|---|
| NmsDelivery | Petit volume | Mises à jour | Il existe un enregistrement par action de diffusion. Un seul enregistrement peut être mis à jour plusieurs fois tout au long du processus de diffusion. Par conséquent, les index de cette table ont tendance à se fragmenter rapidement. |
| NmsDeliveryPart | Volume moyen | Insertions, mises à jour, suppressions | Table de travail dans laquelle les enregistrements sont insérés pendant la préparation de la diffusion, puis mis à jour lors de la diffusion, puis supprimés lorsque la diffusion est terminée. Cette table a tendance à se fragmenter rapidement, même si sa taille moyenne reste modeste. |
| NmsMirrorPageInfo | Gros volume | Insertions, suppressions | Cette table contient les informations nécessaires à la génération de pages miroir personnalisées. Elle contient un champ mémo (CLOB) et, par conséquent, a tendance à être très volumineuse. Le volume est directement proportionnel à l'historique des pages miroir conservées. |
| NmsDeliveryStat | Volume moyen | Insertions, mises à jour, suppressions | Cette table contient des statistiques sur le processus de diffusion. Ses enregistrements sont régulièrement mis à jour. |
| NmsAddress | Volume moyen | Mises à jour, Insertions | Cette table contient des informations sur les adresses e-mail. Elle est fréquemment mise à jour lors du processus de mise en quarantaine ; les enregistrements sont créés lors de la première erreur de diffusion, mis à jour lorsque les compteurs sont modifiés, puis supprimés lorsque la diffusion parvient à destination. |
| XtkWorkflow | Petit volume | Mises à jour | A chaque instance de workflow correspond un enregistrement, soit peu d'enregistrements. Cependant la table est fréquemment mise à jour tout au long du déroulement du workflow et lors de la mise à jour de son statut. |
| XtkWorkflowTask | Petit volume | Insertions, mises à jour, suppressions | L'exécution d'une activité de workflow crée un enregistrement dans la table. Le système de purge des données les supprime une fois qu'elles sont expirées. |
| XtkWorkflowEvent | Petit volume | Insertions, mises à jour, suppressions | Chaque transition activée entre les tâches d’un workflow entraîne la création d’un enregistrement dans cette table. Le mécanisme de purge les supprime une fois qu’ils ont expiré. |
| XtkWorkflowJob | Très petit volume | Insertions, mises à jour, suppressions | Cette table est spécifique au moteur de workflow. Elle permet d'envoyer des commandes aux workflows (Démarrer, Arrêter et Mettre en pause, par exemple). Bien qu'elle soit de petite taille, cette table est prise en compte lors du nettoyage des tables transactionnelles liées aux workflows. |
| NmsBroadLog | Table la plus volumineuse du système | Insertions, mises à jour, suppressions | Cette table est la plus volumineuse du système. À chaque message envoyé correspond un enregistrement. Ces enregistrements sont insérés dans la table, mis à jour pour assurer un tracking du statut de la diffusion, puis supprimés lorsque l'historique est purgé. |
| NmsTrackingLog | Gros volume | Insertions, suppressions | Les logs de tracking sont insérés dans la table puis supprimés lorsque l'historique est purgé mais ne sont pas mis à jour. |
| NmsBroadlogMsg | Petit volume | Mises à jour | Cette table contient des informations permettant de qualifier les erreurs SMTP. Elle est assez petite, mais sera massivement mise à jour. Les index de cette table ont donc tendance à se fragmenter rapidement. |
| NmsEmailErrorStat | Volume moyen | Insertions, mises à jour, suppressions | Cette table contient les agrégats sur les erreurs SMTP, classées par domaine. Elle contient initialement des informations détaillées qui sont agrégées par la tâche de nettoyage une fois qu’elle devient obsolète. |
| NmsBroadLogMid (sur une instance de mid-sourcing) | Gros volume | Insertions, mises à jour, suppressions | Uniquement lorsque l'instance 5.10 (ou ultérieure) est utilisée comme instance de midsourcing. Il s’agit de l’une des tables les plus volumineuses de la base de données. À chaque message envoyé correspond un enregistrement. Ces enregistrements sont insérés, mis à jour pour suivre le statut de la diffusion et supprimés lorsque l'historique est purgé. Dans le cas d'une architecture midsourcing, il est recommandé de limiter l'historique (généralement moins de deux mois), de telle sorte que cette table garde une taille raisonnable, soit moins de 30 Go pour 60 millions de lignes comprenant les données et les index. Il est cependant très important de la reconstruire de temps à autre. |
| NmsBroadLogRcp (lorsque la table NmsRecipient est utilisée) | Gros volume | Insertions, mises à jour, suppressions | Il s’agit de la table la plus volumineuse du système. À chaque message envoyé correspond un enregistrement. Ces enregistrements sont insérés dans la table, mis à jour pour assurer un tracking du statut de la diffusion, puis supprimés lorsque l'historique est purgé. Dans la version 5.10, cette table est plus petite que la table équivalente en version 4.05 (NmsBroadLog) du fait que le texte du message SMTP est factorisé dans la table NmsBroadLogMsg dans la version 5.10. Il est cependant indispensable de recréer l'index de cette table régulièrement (toutes les deux semaines est une bonne base de départ) et de la reconstruire entièrement de temps à autre (tous les mois environ ou avant que les performances ne soient trop dégradées). |
| YyyBroadLogXxx (lorsqu'une table de destinataires externe est utilisée) | Gros volume | Insertions, mises à jour, suppressions | Identique à NmsBroadLogRcp, mais avec une table de destinataires externe. Veuillez adapter Yyy et Xxx avec les valeurs de votre mapping de diffusion. |
| NmsTrackingLogRcp (lorsque la table NmsRecipient est utilisée) | Gros volume | Insertions, suppressions | Les logs de tracking sont insérés dans la table puis supprimés lorsque l'historique est purgé mais ne sont pas mis à jour. Le volume dépend de la durée de rétention des données. |
| YyyTrackingLogXxx (lorsqu'une table de destinataires externe est utilisée) | Gros volume | Insertions, suppressions | Identique à NmsTrackingLogRcp, mais avec une table de destinataires externe. Veuillez adapter Yyy et Xxx avec les valeurs utilisées dans votre mapping de diffusion. |
| NmsBroadLogRtEvent (instance d'exécution Message Center) | Gros volume | Insertions, mises à jour, suppressions | Similaire aux autres tables de broadlogs, mais avec la table NmsRtEvent au lieu de NmsRecipient. |
| NmsTrackingLogRtEvent (instance d'exécution Message Center) | Gros volume | Insertions, suppressions | Similaire aux autres tables de trackingLog, mais avec la table NmsRtEvent au lieu de NmsRecipient. |
| NmsRtEvent (instance d'exécution Message Center) | Gros volume | Insertions, mises à jour, suppressions | Table contenant la file d'attente des événements Message Center. Le statut de ces événements est mis à jour par Message Center au fur et à mesure de leur traitement. Les suppressions sont effectuées pendant la purge. Il est conseillé de régulièrement recréer l'index de cette table et la reconstruire. |
| NmsEventHisto (instance de pilotage Message Center) | Gros volume | Insertions, mises à jour, suppressions | Semblable à NmsRtEvent. Cette table archive tous les événements de toutes les instances d'exécution. Elle n'est utilisée par aucun processus temps réel, uniquement par des rapports. |
| NmsMobileApp | Très petit volume | Insertions, mises à jour, suppressions | Table contenant les applications mobiles ainsi que leur configuration. |
| NmsAppSubscriptionRcp | Gros volume | Insertions, mises à jour | Table contenant les identifiants d'appareils mobiles (adresses) utilisés pour envoyer la notification (similaire à une table de destinataire). |
| NmsBroadLogAppSubRcp | Gros volume | Insertions, mises à jour, suppressions | Similaire aux autres tables de broadlogs, mais avec la table NmsappSubscriptionRcp au lieu de NmsRecipient. |
| NmsTrackingLogAppSubRcp | Gros volume | Insertions, suppressions | Similaire aux autres tables de trackingLog, mais avec la table NmsappSubscriptionRcp au lieu de NmsRecipient. |
| XtkSessionInfo | Petit volume | Insertions, suppressions | Table contenant les sessions utilisateurs. Le nombre d'insertions et de suppressions est très important. |
Tables Clients
En plus de la liste ci-dessus, les tables créées par les clientes et clients (qui n’existent pas dans le modèle de données Adobe Campaign) lors de la configuration de la plateforme peuvent également être sujettes à la fragmentation, en particulier si elles sont fréquemment mises à jour lors des procédures de synchronisation ou de chargement des données. Ces tables peuvent faire partie du modèle de données d'Adobe Campaign (NmsRecipient, par exemple). C'est donc à la personne chargée de l'administration de la plateforme Adobe Campaign qu’il appartient de rechercher ces tables personnalisées dans le modèle de base de données spécifique. Ces tables ne sont pas nécessairement mentionnées explicitement dans nos procédures de maintenance.
Page précédenteRecommandations
Page suivanteTypes de maintenance
Campaign
