Show Menu
TOPICS×

Tables to maintain

The list of tables to maintain depends on your version of Adobe Campaign, how you use it and on the datamodel configuration.
The following list contains only the tables most subject to fragmentation. The impacts are as follows:
  • overconsumption of disk space, thus affecting database access,
  • indexes which have not been regularly updated, which slows down query performance.

Adobe Campaign tables

Table name Size Main type of activity Comments
NmsDelivery Small Updates There is one record per delivery action. A single record can be updated several times to reflect delivery progress, so indexes on this table tend to fragment rapidly.
NmsDeliveryPart Medium Insertions, updates, deletions Work table which records are inserted into during delivery preparation. They are then updated during delivery and finally deleted once the delivery is complete. This table tends to fragment rapidly even though its average size is fairly limited.
NmsMirrorPageInfo Large Insertions, deletions This table contains the information needed to generate personalized mirror pages. It contains a memo (CLOB) field, and as such will tend to be very large. The volume is directly proportional to the history of mirror pages kept.
NmsDeliveryStat Medium Insertions, updates, deletions This table contains statistics on the delivery process. Its records are regularly updated.
NmsAddress Medium Updates, insertions This table contains information on email addresses. It is frequently updated as part of the quarantine process (records are created at the first delivery error, updated when the counters change and deleted once delivery is successful).
XtkWorkflow Small Updates There is one record per workflow instance, so very few records. However the table it is regularly updated to reflect status and progress.
XtkWorkflowTask Small Insertions, updates, deletions Each execution of a workflow activity leads to the creation of a record in this table. The purge mechanism deletes them once they are expired.
XtkWorkflowEvent Small Insertions, updates, deletions Each transition activated between tasks in a workflow leads to the creation of a record in this table. The purge mechanism deletes them once they are expired.
XtkWorkflowJob Very small Insertions, updates, deletions This table is specific to the workflow engine. It enables the sending of commands to workflows (Start, Stop, Pause, for instance). Although it is small, this table is taken into account during the purge of transactional tables linked to workflows.
NmsBroadLog Largest Insertions, updates, deletions This is the largest table in the system. There is one record per message sent, and these records are inserted, updated to track the delivery status, and deleted when the history is purged.
NmsTrackingLog Large Insertions, deletions Tracking logs are inserted and deleted when the history is purged, but they are not updated.
NmsBroadlogMsg Small Updates This table contains information used for qualifying SMTP errors. It is fairly small, but will be massively updated, so indexes on this table tend to fragment rapidly.
NmsEmailErrorStat Medium Insertions, updates, deletions This table contains the aggregates on SMTP errors sorted by domain. It initially contains detailed information which is aggregated by the cleanup task once it becomes outdated.
NmsBroadLogMid (on a mid-sourcing instance) Large Insertions, updates, deletions Only when the 5.10 (or later) instance is used as a mid-sourcing instance. This is one of the largest table in the database. There is one record per message sent, and these records are inserted, updated to track the delivery status, and deleted when the history is purged. When using mid-sourcing, the recommendation is to limit the history (usually less than two months), so this table remains reasonable in terms of size (less than 30 Go for 60 million rows, data+index), but it is very important to rebuild it from time to time.
NmsBroadLogRcp (when the NmsRecipient table is used) Large Insertions, updates, deletions This is the largest table in the system. There is one record per message sent, and these records are inserted, updated to track the delivery status, and deleted when the history is purged. Note that in 5.10, this table is smaller than the equivalent in 4.05 (NmsBroadLog) since the SMTP message text is factorized in the NmsBroadLogMsg table in the 5.10 version. However, it remains essential to re-index this table regularly (every other week to start with), and completely rebuild it from time to time (once a month, or when performance is impacted).
YyyBroadLogXxx (when an external recipient table is used) Large Insertions, updates, deletions Same as NmsBroadLogRcp but with an external recipient table. Please adapt Yyy and Xxx with the values in your delivery mapping.
NmsTrackingLogRcp (when the NmsRecipient table is used) Large Insertions, deletions Tracking logs are inserted and deleted when the history is purged, but they are not updated. The volume depends on the length of data retention.
YyyTrackingLogXxx (when the external recipient table is used) Large Insertions, deletions Same as NmsTrackingLogRcp but with an external recipient table. Please adapt Yyy and Xxx with the values used in your delivery mapping.
NmsBroadLogRtEvent (Message Center execution instance) Large Insertions, updates, deletions Similar to the other broadlog tables, but with the NmsRtEvent instead of NmsRecipient.
NmsTrackingLogRtEvent( Message Center execution instance) Large Insertions, deletions Similar to the other trackingLog tables, but with the NmsRtEvent table instead of NmsRecipient.
NmsRtEvent (Message Center execution instance) Large Insertions, updates, deletions Table containing the Message Center event queue. The status of these events is updated by Message Center as they are processed. Deletions are carried out during the purge. We advise you to regularly recreate the index of this table and rebuild it.
NmsEventHisto (Message Center control instance) Large Insertions, updates, deletions Similar to NmsRtEvent. This table archives every event from all the execution instances. It is used by no real time process, only by reports.
NmsMobileApp Very small Insertions, updates, deletions Tables that include mobile applications and their configuration.
NmsAppSubscriptionRcp Large Insertions, updates Table that includes the identifiers of mobile devices (addresses) used to send the notification (similar to a recipient table).
NmsBroadLogAppSubRcp Large Insertions, updates, deletions Similar to the other broadlog tables, but with the NmsappSubscriptionRcp instead of NmsRecipient.
NmsTrackingLogAppSubRcp Large Insertions, deletions Similar to the other trackingLog tables, but with the NmsappSubscriptionRcp table instead of NmsRecipient.
XtkSessionInfo Small Insertions, deletions Table that includes user sessions. The number of insertions and deletions is very important.

Customer tables

In addition to the list above, tables containing created by customers (which do not exist in the Adobe Campaign datamodel) during platform setup can also be subject to fragmentation, especially if they are frequently updated during data loading or synchronization procedures. These tables can be part of the default Adobe Campaign data model (for instance NmsRecipient ). In this case, it is up to the administrator of the Adobe Campaign platform to conduct an audit of its specific database model to find these custom tables. These tables aren't necessarily mentioned explicitly in our maintenance procedures.