Zu wartende Tabellen

Die Liste der zu pflegenden Tabellen hängt von Ihrer Adobe Campaign-Version, ihrer Verwendung und der Konfiguration des Datenmodells ab.

Die folgende Liste enthält nur die Tabellen, die am stärksten fragmentiert sind. Die Auswirkungen lauten wie folgt:

  • Überbelegung von Speicherplatz, was sich auf den Datenbankzugriff auswirkt,
  • nicht regelmäßig aktualisierte Indizes, was die Abfrageleistung verlangsamt.

Adobe Campaign-Tabellen

Tabellenname
Größe
Haupttyp der Aktivität
Erklärung
NmsDelivery
Klein
Aktualisierungen
Pro Versandaktion ist ein Datensatz vorhanden. Ein einzelner Datensatz kann mehrmals aktualisiert werden, um den Versandfortschritt widerzuspiegeln. Die Indizes in dieser Tabelle neigen daher dazu, schnell zu fragmentieren.
NmsDeliveryPart
Mittel
Einfügen, Aktualisieren, Löschen
Arbeitstabelle, in welche Datensätze bei der Versandvorbereitung eingefügt werden. Diese werden dann während des Versands aktualisiert und nach Abschluss des Versands gelöscht.
Diese Tabelle neigt dazu, schnell zu fragmentieren, obwohl ihre durchschnittliche Größe recht begrenzt ist.
NmsMirrorPageInfo
Groß
Einfügungen, Löschungen
Diese Tabelle enthält die Informationen, die zum Generieren personalisierter Mirrorseiten erforderlich sind. Es enthält ein Memo-Feld (CLOB) und ist daher in der Regel sehr groß. Das Volumen ist direkt proportional zum Verlauf der Mirrorseiten, die gespeichert werden.
NmsDeliveryStat
Mittel
Einfügen, Aktualisieren, Löschen
Diese Tabelle enthält Statistiken zum Versandprozess. Ihre Aufzeichnungen werden regelmäßig aktualisiert.
NmsAddress
Mittel
Aktualisierungen, Einfügungen
Diese Tabelle enthält Informationen zu E-Mail-Adressen. Sie wird im Rahmen des Quarantänevorgangs häufig aktualisiert (Datensätze werden beim ersten Versandfehler erstellt, bei Änderung der Zähler aktualisiert und nach erfolgreichem Versand gelöscht).
XtkWorkflow
Klein
Aktualisierungen
Pro Workflow-Instanz gibt es einen Datensatz, also nur sehr wenige Datensätze. Die Tabelle wird jedoch regelmäßig aktualisiert, um Status und Fortschritt widerzuspiegeln.
XtkWorkflowTask
Klein
Einfügen, Aktualisieren, Löschen
Jede Ausführung einer Workflow-Aktivität führt zur Erstellung eines Datensatzes in dieser Tabelle. Der Bereinigungsmechanismus löscht sie, sobald sie abgelaufen sind.
XtkWorkflowEvent
Klein
Einfügen, Aktualisieren, Löschen
Jede Transition, die zwischen Aufgaben in einem Workflow aktiviert wird, führt zur Erstellung eines Datensatzes in dieser Tabelle. Der Bereinigungsmechanismus löscht sie, sobald sie abgelaufen sind.
XtkWorkflowJob
Sehr klein
Einfügen, Aktualisieren, Löschen
Diese Tabelle ist spezifisch für die Workflow-Engine. Dies ermöglicht das Senden von Befehlen an Workflows (z. B. Start, Stopp, Pause). Diese Tabelle ist zwar klein, wird aber bei der Bereinigung der mit Workflows verknüpften Transaktionstabellen berücksichtigt.
NmsBroadLog
Größter
Einfügen, Aktualisieren, Löschen
Dies ist die größte Tabelle im System. Pro gesendeter Nachricht wird ein Datensatz gesendet. Diese Datensätze werden eingefügt, aktualisiert, um den Versandstatus zu verfolgen, und beim Löschen des Verlaufs gelöscht.
NmsTrackingLog
Groß
Einfügungen, Löschungen
Trackinglogs werden eingefügt und gelöscht, wenn der Verlauf bereinigt wird, sie werden jedoch nicht aktualisiert.
NmsBroadlogMsg
Klein
Aktualisierungen
Diese Tabelle enthält Informationen zum Qualifizieren von SMTP-Fehlern. Sie ist relativ klein, wird jedoch massiv aktualisiert, sodass Indizes auf dieser Tabelle häufig schnell fragmentiert werden.
NmsEmailErrorStat
Mittel
Einfügen, Aktualisieren, Löschen
Diese Tabelle enthält die Aggregate für SMTP-Fehler, sortiert nach Domain. Er enthält zunächst detaillierte Informationen, die von der Bereinigungsaufgabe aggregiert werden, sobald sie veraltet ist.
NmsBroadLogMid (auf einer Mid-Sourcing-Instanz)
Groß
Einfügen, Aktualisieren, Löschen
Nur wenn die Instanz 5.10 (oder höher) als Mid-Sourcing-Instanz verwendet wird. Dies ist eine der größten Tabellen in der Datenbank. Pro gesendeter Nachricht wird ein Datensatz gesendet. Diese Datensätze werden eingefügt, aktualisiert, um den Versandstatus zu verfolgen, und beim Löschen des Verlaufs gelöscht. Bei der Verwendung von Mid-Sourcing besteht die Empfehlung darin, den Verlauf zu begrenzen (in der Regel weniger als zwei Monate). Daher bleibt diese Tabelle im Hinblick auf die Größe vernünftig (weniger als 30 Go for 60 Millionen rows, data+index). Es ist jedoch sehr wichtig, sie von Zeit zu Zeit neu zu erstellen.
NmsBroadLogRcp (wenn die NmsRecipient-Tabelle verwendet wird)
Groß
Einfügen, Aktualisieren, Löschen
Dies ist die größte Tabelle im System. Pro gesendeter Nachricht wird ein Datensatz gesendet. Diese Datensätze werden eingefügt, aktualisiert, um den Versandstatus zu verfolgen, und beim Löschen des Verlaufs gelöscht. Beachten Sie, dass diese Tabelle in Version 5.10 kleiner ist als die Entsprechung in Version 4.05 (NmsBroadLog), da der SMTP-Nachrichtentext in der Tabelle NmsBroadLogMsg in Version 5.10 faktorisiert ist. Es ist jedoch nach wie vor wichtig, diese Tabelle regelmäßig neu zu indizieren (alle zwei Wochen zu Beginn) und sie von Zeit zu Zeit (einmal im Monat oder bei beeinträchtigter Leistung) vollständig neu zu erstellen.
YyyBroadLogXx (wenn eine externe Empfängertabelle verwendet wird)
Groß
Einfügen, Aktualisieren, Löschen
Entspricht NmsBroadLogRcp aber mit einer externen Empfängertabelle. Passen Sie YYY und XXX an die Werte in Ihrem Versand-Mapping an.
NmsTrackingLogRcp (wenn die NmsRecipient-Tabelle verwendet wird)
Groß
Einfügungen, Löschungen
Trackinglogs werden eingefügt und gelöscht, wenn der Verlauf bereinigt wird, sie werden jedoch nicht aktualisiert. Das Volumen hängt von der Dauer der Datenaufbewahrung ab.
YyyTrackingLogXx (wenn die externe Empfängertabelle verwendet wird)
Groß
Einfügungen, Löschungen
Entspricht NmsTrackingLogRcp, aber mit einer externen Empfängertabelle. Passen Sie YYY und XXX an die Werte an, die in Ihrem Versand-Mapping verwendet werden.
NmsBroadLogRtEvent (Message Center-Ausführungsinstanz)
Groß
Einfügen, Aktualisieren, Löschen
Ähnlich wie bei anderen Broadlog-Tabellen, jedoch mit dem NmsRtEvent anstelle von NmsRecipient.
NmsTrackingLogRtEvent( Message Center-Ausführungsinstanz)
Groß
Einfügungen, Löschungen
Ähnlich wie bei anderen trackingLog -Tabellen, jedoch mit der NmsRtEvent -Tabelle anstelle von NmsRecipient .
NmsRtEvent (Message Center-Ausführungsinstanz)
Groß
Einfügen, Aktualisieren, Löschen
Tabelle, die die Message-Center-Ereigniswarteschlange enthält. Der Status dieser Ereignisse wird von Message Center bei der Verarbeitung aktualisiert. Löschungen werden während der Bereinigung durchgeführt. Wir empfehlen Ihnen, den Index dieser Tabelle regelmäßig neu zu erstellen und neu zu erstellen.
NmsEventHisto (Message Center-Kontrollinstanz)
Groß
Einfügen, Aktualisieren, Löschen
Ähnlich wie NmsRtEvent. Diese Tabelle archiviert alle Ereignisse aus allen Ausführungsinstanzen. Sie wird nicht in Echtzeit, sondern nur von Berichten verwendet.
NmsMobileApp
Sehr klein
Einfügen, Aktualisieren, Löschen
Tabellen mit Mobile Apps und deren Konfiguration.
NmsAppSubscriptionRcp
Groß
Einfügungen, Aktualisierungen
Tabelle mit den Kennungen der Mobilgeräte (Adressen), die zum Senden der Benachrichtigung verwendet werden (ähnlich wie bei einer Empfängertabelle).
NmsBroadLogAppSubRcp
Groß
Einfügen, Aktualisieren, Löschen
Ähnlich wie bei anderen Broadlog-Tabellen, jedoch mit NmsappSubscriptionRcp anstelle von NmsRecipient.
NmsTrackingLogAppSubRcp
Groß
Einfügungen, Löschungen
Ähnlich wie bei anderen trackingLog-Tabellen, jedoch mit der Tabelle NmsappSubscriptionRcp anstelle von NmsRecipient.
XtkSessionInfo
Klein
Einfügungen, Löschungen
Tabelle mit Benutzersitzungen. Die Anzahl der Einfügungen und Löschungen ist sehr wichtig.

Kundentabellen

Zusätzlich zur obigen Liste können auch Tabellen, die von Kunden erstellt wurden (die nicht im Adobe Campaign-Datenmodell vorhanden sind), während der Plattformeinrichtung fragmentiert werden, insbesondere wenn sie häufig während der Datenladevorgänge oder Synchronisierungsvorgänge aktualisiert werden. Diese Tabellen können Teil des standardmäßigen Adobe Campaign-Datenmodells sein (z. B. NmsRecipient). In diesem Fall ist es Sache des Administrators der Adobe Campaign-Plattform, eine Prüfung seines spezifischen Datenbankmodells durchzuführen, um diese benutzerdefinierten Tabellen zu finden. Diese Tabellen werden nicht unbedingt in unseren Wartungsverfahren explizit erwähnt.

Auf dieser Seite