Tables à maintenir

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 ralentit le temps de réponse des requêtes.

Tables Adobe Campaign

Nom de la table
Taille
Activité principale
Commentaires
NmsDelivery
Petit volume
Mises à jour
A chaque action de diffusion correspond un enregistrement. Un seul enregistrement peut être mis à jour plusieurs fois tout au long du processus de diffusion. Par conséquent, les index de cette table se trouvent rapidement fragmentés.
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) ce qui a pour conséquence d'augmenter énormément sa taille. Son volume est proportionnel à l'historique des pages miroir qui est conservé.
NmsDeliveryStat
Volume moyen
Insertions, mises à jour, suppressions
Cette table contient les statistiques du processus de diffusion. Ses enregistrements sont fréquemment mis à jour.
NmsAddress
Volume moyen
Mises à jour, Insertions
Cette table contient les informations propres aux adresses email. 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 à l'adresse spécifiée.
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
L'activation d'une transition dans un 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.
XtkWorkflowJob
Très petit volume
Insertions, mises à jour, suppressions
Cette table est propre au fonctionnement interne du moteur de workflow. Elle sert à envoyer des commandes aux workflows (Démarrer, Arrêter, 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. A chaque message envoyé correspond un enregistrement. Ces enregistrements sont insérés dans la table, mis à jour régulièrement 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 de petite taille mais est amenée à être massivement mise à jour, par conséquent ses index se trouvent rapidement fragmentés.
NmsEmailErrorStat
Volume moyen
Insertions, mises à jour, suppressions
Cette table contient les agrégats des erreurs SMTP classées par domaine. Au départ elle contient des informations détaillées qui sont agrégées par le workflow de nettoyage lorsqu'elles deviennent obsolètes.
NmsBroadLogMid (sur une instance de mid-sourcing)
Gros volume
Insertions, mises à jour, suppressions
Cette table n'existe que lorsque l'instance mid-sourcing est en version 5.10 et ultérieure. Il s'agit de l'une des tables les plus volumineuses. A chaque message envoyé correspond un enregistrement. Ces enregistrements sont insérés dans la table, mis à jour régulièrement pour assurer un tracking du statut de la diffusion puis supprimés lorsque l'historique est purgé. Dans le cas d'une architecture mid-sourcing, il est recommandé de limiter l'historique (habituellement moins de deux mois). Par conséquent, cette table garde une taille raisonnable, soit moins de 30Go 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
Cette table est l'une des plus volumineuses. A chaque message envoyé correspond un enregistrement. Ces enregistrements sont insérés dans la table, mis à jour régulièrement pour assurer un tracking du statut de la diffusion puis supprimés lorsque l'historique est purgé. Cette table est plus petite en version 5.10 que la table équivalente en version 4.05 (NmsBroadLog) du fait que le message texte SMTP est factorisé dans la table NmsBroadLogMsg en v5.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 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
Idem que pour NmsBroadLogRcp mais avec une table de destinataires externe. Remplacer Yyy et Xxx avec les valeurs utilisées dans 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
Idem que pour NmsTrackingLogRcp mais avec une table de destinataires externe. Remplacer 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 qui contient la file des événements Message Center. Le statut de ces événements est mis à jour par Message Center au fur et à mesure de leur traitement. La suppression est effectuée lors de 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
Similaire à la table 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

Les tables créées par les clients (qui n'existent pas dans le modèle de données d'Adobe Campaign) lors de la mise en place de la plateforme sont également sujettes à la fragmentation. C'est le cas notamment lorsqu'elles sont fréquemment mises à jour lors de chargements de données ou de procédures de synchronisation. Ces tables peuvent faire partie du modèle de données d'Adobe Campaign (comme NmsRecipient par exemple). C'est donc à l'administrateur de la plateforme Adobe Campaign de rechercher l'existence de ces tables spécifiques dans le modèle de données. Il se peut que ces tables ne soient pas explicitement mentionnées dans les procédures de maintenance.

Sur cette page