Documentation Campaign Campaign Classic v7 Documentation

Tables to maintain

Last update: September 18, 2024

Topics:
Monitoring

The list of tables to maintain depends on your version of Adobe Campaign, how you use it and on the data model 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 data model) 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.

Previous pageRecommendations

Next pageTypes of maintenance