Show Menu
SUJETS×

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.