Tables to maintain tables-to-maintain
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 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.
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 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.
recommendation-more-help
601d79c3-e613-4db3-889a-ae959cd9e3e1