Datenbankbereinigungs-Workflow

Einleitung

Der Workflow Datenbankbereinigung, auf den Sie über den Knoten Administration > Produktion > Technische Workflows zugreifen können, ermöglicht das Löschen veralteter Daten, um das exponentielle Anwachsen der Datenbank zu verhindern. Der Workflow wird automatisch ohne das Eingreifen des Benutzers ausgelöst.

Konfiguration

Die Datenbankbereinigung wird auf zwei Ebenen konfiguriert: im Workflow-Planer und im Softwareverteilungs-Assistenten.

Workflow-Planung

HINWEIS

Weiterführende Informationen zur Planung finden Sie in diesem Abschnitt.

Standardmäßig wird die Datenbankbereinigung Der Workflow ist so konfiguriert, dass er täglich um 4 Uhr gestartet wird. Die Planung ermöglicht es, die Häufigkeit der Auslösung des Workflows zu ändern. Die folgenden Häufigkeiten sind verfügbar:

  • Mehrmals pro Tag
  • Täglich
  • Wöchentlich
  • Einmal

WICHTIG

Um die Datenbankbereinigung um an dem in der Planung definierten Datum und zu der Uhrzeit zu starten, muss die Workflow-Engine (wfserver) gestartet werden. Ist dies nicht der Fall, wird die Datenbankbereinigung erst beim nächsten Start der Workflow-Engine durchgeführt.

Implementierungsassistent

Die Implementierungsassistent, auf die über Tools > Erweitert kann konfiguriert werden, wie lange Daten gespeichert werden. Die Werte werden in Tagen ausgedrückt. Wenn diese Werte nicht geändert werden, verwendet der Workflow die Standardwerte.

Die Felder der Datenbereinigung -Fenster mit den folgenden Optionen übereinstimmen. Diese werden von einigen der von der Datenbankbereinigung workflow:

Alle Aufgaben, die von der Datenbankbereinigung Workflows werden im folgenden Abschnitt beschrieben.

Vom Datenbankbereinigungs-Workflow durchgeführte Aufgaben

Zu dem in der Workflow-Planung definierten Zeitpunkt (siehe Die Planung), startet die Workflow-Engine den Datenbankbereinigungsprozess. Die Datenbankbereinigung stellt eine Verbindung zur Datenbank her und führt die Aufgaben in der unten gezeigten Reihenfolge aus.

WICHTIG

Wenn eine dieser Aufgaben fehlschlägt, werden die folgenden nicht ausgeführt.
SQL-Abfragen mit LIMIT wird wiederholt ausgeführt, bis alle Informationen verarbeitet wurden.

HINWEIS

Die folgenden Abschnitte, in denen die Aufgaben des Workflows Datenbankbereinigung beschrieben werden, richten sich an Datenbankadministratoren oder Benutzer, die mit SQL-Sprache vertraut sind.

Listen zum Löschen der Bereinigung

Die erste von der Datenbankbereinigung löscht alle Gruppen mit der deleteStatus != 0 -Attribut aus NmsGroup. Die mit diesen Gruppen verknüpften und in anderen Tabellen vorhandenen Datensätze werden ebenfalls gelöscht.

  1. Zu löschende Listen werden mithilfe der folgenden SQL-Abfrage abgerufen:

    SELECT iGroupId, sLabel, iType FROM NmsGroup WHERE iDeleteStatus <> 0 OR tsExpirationDate <= GetDate() 
    
  2. Jede Liste enthält mehrere Links zu anderen Tabellen. Alle diese Links werden mithilfe der folgenden Abfrage stapelweise gelöscht:

    DELETE FROM $(relatedTable) WHERE iGroupId=$(l) IN (SELECT iGroupId FROM $(relatedTable) WHERE iGroupId=$(l) LIMIT 5000) 
    

    where $(relatedTable) ist eine Tabelle, die sich auf NmsGroup und $(l) ist die Listenkennung.

  3. Wenn es sich bei der Liste um eine Liste vom Typ "Liste" handelt, wird die zugeordnete Tabelle mithilfe der folgenden Abfrage gelöscht:

    DROP TABLE grp$(l)
    
  4. Alle Auswählen Die durch den Vorgang abgerufene Typliste wird mithilfe der folgenden Abfrage gelöscht:

    DELETE FROM NmsGroup WHERE iGroupId=$(l) 
    

    where $(l) ist die Listenkennung

Bereinigung der zu löschenden oder zu recycelenden Sendungen

Diese Aufgabe löscht alle zu löschenden oder recycelten Sendungen.

  1. Die Datenbankbereinigung wählt alle Sendungen aus, für die die deleteStatus -Feld hat den Wert Ja oder Recycling und deren Löschdatum vor dem in der Gelöschte Sendungen (NmsCleanup_RecycledDeliveryPurgeDelay) im Softwareverteilungs-Assistenten. Weitere Informationen hierzu finden Sie unter Implementierungsassistent. Dieser Zeitraum wird in Bezug auf das aktuelle Server-Datum berechnet.

  2. Für jeden Mid-Sourcing-Server wählt die Aufgabe die Liste der zu löschenden Sendungen aus.

  3. Die Datenbankbereinigung Der Workflow löscht Versandlogs, Anhänge, Informationen zur Mirrorseite und alle anderen damit verbundenen Daten.

  4. Vor dem endgültigen Löschen des Versands löscht der Workflow verknüpfte Informationen aus den folgenden Tabellen:

    • In der Ausschlusstabelle des Versands (NmsDlvExclusion), wird die folgende Abfrage verwendet:

      DELETE FROM NmsDlvExclusion WHERE iDeliveryId=$(l)
      

      where $(l) ist die Kennung des Versands.

    • In der Coupontabelle (NmsCouponValue), wird die folgende Abfrage verwendet (mit Massenlöschungen):

      DELETE FROM NmsCouponValue WHERE iMessageId IN (SELECT iMessageId FROM NmsCouponValue WHERE EXISTS (SELECT B.iBroadLogId FROM $(BroadLogTableName) B WHERE B.iDeliveryId = $(l) AND B.iBroadLogId = iMessageId ) LIMIT 5000)
      

      where $(l) ist die Kennung des Versands.

    • In den Versandlog-Tabellen (NmsBroadlogXxx), werden Massenlöschungen in Stapeln von 20.000 Datensätzen durchgeführt.

    • In den Tabellen mit Angebotsvorschlägen (NmsPropositionXxx), werden Massenlöschungen in Stapeln von 20.000 Datensätzen durchgeführt.

    • In den Trackinglog-Tabellen (NmsTrackingLogXx), werden Massenlöschungen in Stapeln von 20.000 Datensätzen durchgeführt.

    • In der Versandfragmenttabelle (NmsDeliveryPart), werden Massenlöschungen in Stapeln von 500.000 Datensätzen durchgeführt. Diese Tabelle enthält Personalisierungsinformationen zu den restlichen zu versendenden Nachrichten.

    • In der Tabelle der Mirrorseiten-Datenfragmente (NmsMirrorPageInfo), werden Massenlöschungen in 20.000 Datensätzen für abgelaufene Versandteile sowie für fertige oder abgebrochene Teile durchgeführt. Diese Tabelle enthält Personalisierungsinformationen zu allen Nachrichten, die zum Generieren von Mirrorseiten verwendet werden.

    • In der Mirrorseiten-Suchtabelle (NmsMirrorPageSearch), werden Massenlöschungen in Stapeln von 20.000 Datensätzen durchgeführt. Diese Tabelle ist ein Suchindex, der Zugriff auf Personalisierungsinformationen bietet, die im NmsMirrorPageInfo Tabelle.

    • In der Protokolltabelle für Batch-Prozesse (XtkJobLog), werden Massenlöschungen in Stapeln von 20.000 Datensätzen durchgeführt. Diese Tabelle enthält das Protokoll der zu löschenden Sendungen.

    • In der Versand-URL-Tracking-Tabelle (NmsTrackingUrl), wird die folgende Abfrage verwendet:

      DELETE FROM NmsTrackingUrl WHERE iDeliveryId=$(l)
      

      where $(l) ist die Kennung des Versands.

      Diese Tabelle enthält die URLs in den zu löschenden Sendungen, um deren Tracking zu ermöglichen.

  5. Der Versand wird aus der Versandtabelle (NmsDelivery):

    DELETE FROM NmsDelivery WHERE iDeliveryId = $(l)
    

    where $(l) ist die Kennung des Versands.

Sendungen mit Mid-Sourcing

Die Datenbankbereinigung Der Workflow löscht auch Sendungen auf Mid-Sourcing-Servern.

  1. Dazu prüft der Workflow, ob jeder Versand inaktiv ist (je nach Status). Wenn ein Versand aktiv ist, wird er vor dem Löschen angehalten. Die Überprüfung wird durch Ausführung der folgenden Abfrage durchgeführt:

    SELECT iState FROM NmsDelivery WHERE iDeliveryId = $(l) AND iState <> 100;
    

    where $(l) ist die Kennung des Versands.

  2. Wenn der Wert des Status Start pending , In Bearbeitung , Rückforderung steht aus , Aufschwung in Gang , Anhalten angefordert , Wird ausgesetzt oder Angehalten (Werte 51, 55, 61, 62, 71, 72, 75), wird der Versand angehalten und die Aufgabe löscht die verknüpften Informationen.

Bereinigung abgelaufener Sendungen

Diese Aufgabe beendet Sendungen, deren Gültigkeitszeitraum abgelaufen ist.

  1. Die Datenbankbereinigung erstellt die Liste der abgelaufenen Sendungen. Diese Liste enthält alle abgelaufenen Sendungen mit einem anderen Status als Abgeschlossen sowie vor kurzem den Versand mit über 10.000 nicht verarbeiteten Nachrichten gestoppt. Die folgende Abfrage wird verwendet:

    SELECT iDeliveryId, iState FROM NmsDelivery WHERE iDeleteStatus=0 AND iIsModel=0 AND iDeliveryMode=1 AND ( (iState >= 51 AND iState < 85 AND tsValidity IS NOT NULL AND tsValidity < $(currentDate) ) OR (iState = 85 AND DateMinusDays(15) < tsLastModified AND iToDeliver - iProcessed >= 10000 ))
    

    where Versandmodus 1 entspricht der Massenversand Modus, state 51 entspricht der Start pending state, state 85 entspricht der Angehalten Status und die höchste Anzahl von Versandlogs, die auf dem Versandserver gebündelt aktualisiert wurden, beträgt 10.000.

  2. Der Workflow enthält dann die Liste der kürzlich abgelaufenen Sendungen, die Mid-Sourcing verwenden. Sendungen, für die noch keine Versandlogs über den Mid-Sourcing-Server abgerufen wurden, sind ausgeschlossen.

    Die folgende Abfrage wird verwendet:

    SELECT iDeliveryId, tsValidity, iMidRemoteId, mData FROM NmsDelivery WHERE (iDeliveryMode = 4 AND (iState = 85 OR iState = 95) AND tsValidity IS NOT NULL AND (tsValidity < SubDays(GetDate() , 15) OR tsValidity < $(DateOfLastLogPullUp)) AND tsLastModified > SubDays(GetDate() , 15))
    
  3. Mithilfe der folgenden Abfrage wird ermittelt, ob das externe Konto noch aktiv ist, um Sendungen nach Datum zu filtern:

    SELECT iExtAccountId FROM NmsExtAccount WHERE iActive<>0 AND sName=$(providerName)
    
  4. In der Liste der abgelaufenen Sendungen Versandlogs mit dem Status Ausstehend , wechseln Sie zu Versand abgebrochen und alle Sendungen in dieser Liste wechseln zu Abgeschlossen .

    Die folgenden Abfragen werden verwendet:

    UPDATE $(BroadLogTableName) SET tsLastModified=$(curdate), iStatus=7, iMsgId=$(bl) WHERE iDeliveryId=$(dl) AND iStatus=6
    

    where $(curdate) das aktuelle Datum des Datenbankservers, $(bl) die Kennung der Versandlogs-Nachricht, $(dl) die Versandkennung, Versandstatus 6 entspricht der Ausstehend Status und Versandstatus 7 entspricht der Versand abgebrochen Status.

    UPDATE NmsDelivery SET iState = 95, tsLastModified = $(curdate), tsBroadEnd = tsValidity WHERE iDeliveryId = $(dl)
    

    where Versandstatus 95 entspricht der Abgeschlossen Status und $(dl) ist die Kennung des Versands.

  5. Alle Fragmente (deliveryParts) veraltete Sendungen werden gelöscht und alle veralteten Fragmente des laufenden Benachrichtigungsversands werden gelöscht. Für beide Aufgaben wird Massenlöschung verwendet.

    Die folgenden Abfragen werden verwendet:

    DELETE FROM NmsDeliveryPart WHERE iDeliveryPartId IN (SELECT iDeliveryPartId FROM NmsDeliveryPart WHERE iDeliveryId IN (SELECT iDeliveryId FROM NmsDelivery WHERE iState=95 OR iState=85) LIMIT 5000)
    
    DELETE FROM NmsDeliveryPart WHERE iDeliveryPartId IN (SELECT iDeliveryPartId FROM NmsDeliveryPart WHERE tsValidity < $(curDate) LIMIT 500000)
    

    where Versandstatus 95 entspricht der Abgeschlossen Status, Versandstatus 85 entspricht der Angehalten Status und $(curDate) ist das aktuelle Server-Datum.

Bereinigung der Mirrorseiten

Bei dieser Aufgabe werden die von Sendungen verwendeten Web-Ressourcen (Mirrorseiten) gelöscht.

  1. Zunächst wird die Liste der zu löschenden Sendungen mithilfe der folgenden Abfrage abgerufen:

    SELECT iDeliveryId, iNeedMirrorPage FROM NmsDelivery WHERE iWebResPurged = 0 AND tsWebValidity IS NOT NULL AND tsWebValidity < $(curdate)"
    

    where $(curDate) ist das aktuelle Server-Datum.

  2. Die NmsMirrorPageInfo -Tabelle wird dann bei Bedarf mithilfe der Kennung des zuvor wiederhergestellten Versands bereinigt. Die Massenlöschung wird verwendet, um die folgenden Abfragen zu generieren:

    DELETE FROM NmsMirrorPageInfo WHERE iMirrorPageInfoId IN (SELECT iMirrorPageInfoId FROM NmsMirrorPageInfo WHERE iDeliveryId = $(dl)) LIMIT 5000)
    
    DELETE FROM NmsMirrorPageSearch WHERE iMessageId IN (SELECT iMessageId FROM NmsMirrorPageSearch WHERE iDeliveryId = $(dl)) LIMIT 5000)
    

    where $(dl) ist die Kennung des Versands.

  3. Im Versandlog wird dann ein Eintrag hinzugefügt.

  4. Die bereinigten Sendungen werden dann identifiziert, um zu vermeiden, dass sie später erneut verarbeitet werden müssen. Die folgende Abfrage wird ausgeführt:

    UPDATE NmsDelivery SET iWebResPurged = 1 WHERE iDeliveryId IN ($(strIn))
    

    where $(strIn) ist die Liste der Versandkennungen.

Bereinigen von Arbeitstabellen

Diese Aufgabe löscht aus der Datenbank alle Arbeitstabellen, die Sendungen entsprechen, deren Status In Bearbeitung , Angehalten oder Gelöscht .

  1. Die Liste der Tabellen mit Namen, die mit wkDlv_ wird zuerst mit der folgenden Abfrage abgerufen (postgresql):

    SELECT relname FROM pg_class WHERE relname LIKE Lower('wkDlv_') ESCAPE E'\\' AND relkind IN ('r','v') AND pg_get_userbyid(relowner)<>'postgres'
    
  2. Die von laufenden Workflows verwendeten Tabellen werden dann ausgeschlossen. Die Liste der ausgeführten Sendungen wird mithilfe der folgenden Abfrage abgerufen:

    SELECT iDeliveryId FROM NmsDelivery WHERE iDeliveryId<>0 AND iDeleteStatus=0 AND iState NOT IN (0,85,100);
    

    wobei 0 der Wert ist, der mit der In Bearbeitung Versandstatus: 85 entspricht dem Angehalten -Status und 100 stimmt mit der Gelöscht Status.

  3. Nicht mehr verwendete Tabellen werden mithilfe der folgenden Abfrage gelöscht:

    DROP TABLE wkDlv_15487_1;
    

Bereinigung der durch Importe erzeugten Zurückweisungen

In diesem Schritt können Sie Datensätze löschen, für die während des Imports nicht alle Daten verarbeitet wurden.

  1. Die Massenlöschung erfolgt über die XtkReject -Tabelle mit der folgenden Abfrage:

    DELETE FROM XtkReject WHERE iRejectId IN (SELECT iRejectId FROM XtkReject WHERE tsLog < $(curDate)) LIMIT $(l))
    

    where $(curDate) ist das aktuelle Server-Datum, von dem wir den für die NmsCleanup_RejectsPurgeDelay Option (siehe Implementierungsassistent) und $(l) die maximale Anzahl von zu löschenden Datensätzen.

  2. Alle verwaisten Zurückweisungen werden dann mithilfe der folgenden Abfrage gelöscht:

    DELETE FROM XtkReject WHERE iJobId NOT IN (SELECT iJobId FROM XtkJob)
    

Bereinigen von Workflow-Instanzen

Diese Aufgabe löscht jede Workflow-Instanz mithilfe ihrer Kennung (lWorkflowId) und der Verlauf (lHistory). Löscht inaktive Tabellen, indem die Aufgabe zur Bereinigung der Arbeitstabelle erneut ausgeführt wird. Die Bereinigung löscht auch alle verwaisten Arbeitstabellen (wkf% und wkfhisto%) der gelöschten Workflows.

HINWEIS

Die Bereinigungshäufigkeit des Verlaufs wird für jeden Workflow im Verlauf in Tagen -Feld (Standardwert 30 Tage). Dieses Feld finden Sie im Ausführung in den Workflow-Eigenschaften. Weiterführende Informationen hierzu finden Sie in diesem Abschnitt.

  1. Um die Liste der zu löschenden Workflows abzurufen, wird die folgende Abfrage verwendet:

    SELECT iWorkflowId, iHistory FROM XtkWorkflow WHERE iWorkflowId<>0
    
  2. Diese Abfrage erzeugt mithilfe der folgenden Abfragen die Liste der Workflows, die zum Löschen aller verknüpften Logs, abgeschlossenen Aufgaben und abgeschlossenen Ereignisse verwendet werden:

    DELETE FROM XtkWorkflowLog WHERE iWorkflowId=$(lworkflow) AND tsLog < DateMinusDays($(lhistory))
    
    DELETE FROM XtkWorkflowTask WHERE iWorkflowId=$(lworkflow) AND iStatus<>0 AND tsCompletion < DateMinusDays($(lhistory)) 
    
    DELETE FROM XtkWorkflowEvent WHERE iWorkflowId=$(l) AND iStatus>2 AND tsProcessing < DateMinusDays($(lHistory))
    

    where $(lworkflow) ist die Kennung des Workflows und $(history) ist die Kennung des Verlaufs.

  3. Alle nicht verwendeten Tabellen werden gelöscht. Zu diesem Zweck werden alle Tabellen mithilfe eines wkf% Typmaske mit der folgenden Abfrage (postgresql):

    SELECT relname FROM pg_class WHERE relname LIKE Lower('wkf%') ESCAPE E'\\' AND relkind IN ('r','v') AND pg_get_userbyid(relowner)<>'postgres'
    
  4. Dann werden alle Tabellen ausgeschlossen, die von einer ausstehenden Workflow-Instanz verwendet werden. Die Liste der aktiven Workflows wird mithilfe der folgenden Abfrage abgerufen:

    SELECT iWorkflowId FROM XtkWorkflow WHERE iWorkflowId<>0 AND iState<>20
    
  5. Jede Workflow-Kennung wird dann abgerufen, um den Namen der Tabellen zu ermitteln, die von laufenden Workflows verwendet werden. Diese Namen werden aus der Liste der zuvor wiederhergestellten Tabellen ausgeschlossen.

  6. Verlaufstabellen vom Typ "inkrementelle Abfrage" werden mithilfe der folgenden Abfragen ausgeschlossen:

    SELECT relname FROM pg_class WHERE relname LIKE Lower('wkfhisto%') ESCAPE E'\\' AND relkind IN ('r','v') AND pg_get_userbyid(relowner)<>'postgres'
    
    SELECT iWorkflowId FROM XtkWorkflow WHERE iWorkflowId IN ($(strCondition))
    

    where $(strcondition) ist die Liste der Tabellen, die mit dem wkfhisto% Maske.

  7. Die verbleibenden Tabellen werden mithilfe der folgenden Abfrage gelöscht:

    DROP TABLE wkf15487_12;
    

Bereinigung der Workflow-Anmeldungen

Diese Aufgabe löscht Workflow-Anmeldungen mit der folgenden Abfrage:

DELETE FROM XtkWorkflowLogin WHERE iWorkflowId NOT IN (SELECT iWorkflowId FROM XtkWorkflow)

Bereinigung verwaister Arbeitstabellen

Diese Aufgabe löscht verwaiste Arbeitstabellen, die mit Gruppen verknüpft sind. Die NmsGroup -Tabelle speichert die zu bereinigenden Gruppen (mit einem anderen Typ als 0). Das Präfix der Tabellennamen lautet grp. Um die zu bereinigenden Gruppen zu identifizieren, wird die folgende Abfrage verwendet:

SELECT iGroupId FROM NmsGroup WHERE iType>0"

Besucherbereinigung

Durch Massenlöschung werden veraltete Datensätze aus der Besuchertabelle gelöscht. Veraltete Datensätze sind jene, deren letzte Änderung vor dem im Softwareverteilungs-Assistenten festgelegten Erhaltungszeitraum liegt (siehe Implementierungsassistent). Die folgende Abfrage wird verwendet:

DELETE FROM NmsVisitor WHERE iVisitorId IN (SELECT iVisitorId FROM NmsVisitor WHERE iRecipientId = 0 AND tsLastModified < AddDays(GetDate(), -30) AND iOrigin = 0 LIMIT 20000)

where $(tsDate) ist das aktuelle Server-Datum, von dem wir den für die Variable NmsCleanup_VisitorPurgeDelay -Option.

Bereinigung der NPAI

Mithilfe dieser Aufgabe können Sie Datensätze löschen, die gültige Adressen aus dem NmsAddress Tabelle. Die folgende Abfrage wird verwendet, um eine Massenlöschung durchzuführen:

DELETE FROM NmsAddress WHERE iAddressId IN (SELECT iAddressId FROM NmsAddress WHERE iStatus=2 AND tsLastModified < $(tsDate1) AND tsLastModified >= $(tsDate2) LIMIT 5000)

where status 2 entspricht der Gültig Status, $(tsDate1) das aktuelle Server-Datum ist und $(tsDate2) entspricht der NmsCleanup_LastCleanup -Option.

Bereinigung der Abonnements

Diese Aufgabe löscht alle vom Benutzer aus dem NmsSubscription -Tabelle mit Massenlöschung. Die folgende Abfrage wird verwendet:

DELETE FROM NmsSubscription WHERE iDeleteStatus <>0

Bereinigung der Trackinglogs

Diese Aufgabe löscht veraltete Datensätze aus den Tracking- und Webtracking-Log-Tabellen. Veraltete Datensätze sind jene, die vor dem im Softwareverteilungs-Assistenten festgelegten Erhaltungszeitraum liegen (siehe Implementierungsassistent).

  1. Zunächst wird die Liste der Trackinglog-Tabellen mithilfe der folgenden Abfrage abgerufen:

    SELECT distinct(sTrackingLogSchema) FROM NmsDeliveryMapping WHERE sTrackingLogSchema IS NOT NULL;
    
  2. Die Massenlöschung dient der Bereinigung aller Tabellen in der Liste der zuvor wiederhergestellten Tabellen. Die folgende Abfrage wird verwendet:

    DELETE FROM NmsTrackingLogRcp WHERE iTrackingLogId IN (SELECT iTrackingLogId FROM NmsTrackingLogRcp WHERE tsLog < $(tsDate) LIMIT 5000) 
    

    where $(tsDate) ist das aktuelle Server-Datum, von dem wir den für die NmsCleanup_TrackingLogPurgeDelay -Option.

  3. Die Trackingstatistiken werden mithilfe einer Massenlöschung bereinigt. Die folgende Abfrage wird verwendet:

    DELETE FROM NmsTrackingStats WHERE iTrackingStatsId IN (SELECT iTrackingStatsId FROM NmsTrackingStats WHERE tsStart < $(tsDate) LIMIT 5000) 
    

    where $(tsDate) ist das aktuelle Server-Datum, von dem wir den für die NmsCleanup_TrackingStatPurgeDelay -Option.

Bereinigung der Versandlogs

Auf diese Weise können die in verschiedenen Tabellen gespeicherten Versandlogs bereinigt werden.

  1. Zu diesem Zweck wird die Liste der Versandlog-Schemata mithilfe der folgenden Abfrage abgerufen:

    SELECT distinct(sBroadLogSchema) FROM NmsDeliveryMapping WHERE sBroadLogSchema IS NOT NULL UNION SELECT distinct(sBroadLogExclSchema) FROM NmsDeliveryMapping WHERE sBroadLogExclSchema IS NOT NULL
    
  2. Bei Verwendung von Mid-Sourcing muss die Variable NmsBroadLogMid -Tabelle wird in Versand-Mappings nicht referenziert. Die nms:broadLogMid -Schema zur Liste hinzugefügt, die von der vorherigen Abfrage abgerufen wurde.

  3. Die Datenbankbereinigung löscht dann veraltete Daten aus zuvor wiederhergestellten Tabellen. Die folgende Abfrage wird verwendet:

    DELETE FROM $(tableName) WHERE iBroadLogId IN (SELECT iBroadLogId FROM $(tableName) WHERE tsLastModified < $(option) LIMIT 5000) 
    

    where $(tableName) den Namen jeder Tabelle in der Schemakarte und $(option) das für die NmsCleanup_BroadLogPurgeDelay Option (siehe Implementierungsassistent).

  4. Schließlich prüft der Workflow, ob die NmsProviderMsgId -Tabelle vorhanden ist. Wenn ja, werden alle veralteten Daten mithilfe der folgenden Abfrage gelöscht:

    DELETE FROM NmsProviderMsgId WHERE iBroadLogId IN (SELECT iBroadLogId FROM NmsProviderMsgId WHERE tsCreated < $(option) LIMIT 5000)
    

    where $(option) entspricht dem Datum, das für die NmsCleanup_BroadLogPurgeDelay Option (siehe Implementierungsassistent).

Bereinigung der Tabelle "NmsEmailErrorStat"

Diese Aufgabe bereinigt die NmsEmailErrorStat Tabelle. Das Hauptprogramm (coalesceErrors) definiert zwei Daten:

  • Startdatum: Datum des nächsten Prozesses, der mit dem NmsLastErrorStatCoalesce oder dem letzten Datum in der Tabelle.
  • Enddatum: aktuelles Server-Datum.

Wenn das Startdatum größer oder gleich dem Enddatum ist, wird kein Prozess durchgeführt. In diesem Fall wird die coalesceUpToDate angezeigt.

Wenn das Startdatum vor dem Enddatum liegt, wird die NmsEmailErrorStat -Tabelle bereinigt.

Die Gesamtzahl der Fehler in der NmsEmailErrorStat -Tabelle wird zwischen dem Start- und dem Enddatum mithilfe der folgenden Abfrage abgerufen:

"SELECT COUNT(*) FROM NmsEmailErrorStat WHERE tsDate>= $(start) AND tsDate< $(end)"

where $end und $start sind die zuvor definierten Start- und Enddaten.

Wenn die Summe größer als 0 ist:

  1. Die folgende Abfrage wird ausgeführt, um nur Fehler über einen bestimmten Schwellenwert (also 20) hinaus zu erhalten:

    "SELECT iMXIP, iPublicId, SUM(iTotalConnections), SUM(iTotalErrors), SUM(iMessageErrors), SUM(iAbortedConnections), SUM(iFailedConnections), SUM(iRefusedConnections), SUM(iTimeoutConnections) FROM NmsEmailErrorStat WHERE tsDate>=$(start ) AND tsDate<$(end ) GROUP BY iMXIP, iPublicId HAVING SUM(iTotalErrors) >= 20"
    
  2. Die coalescingErrors angezeigt.

  3. Es wird eine neue Verbindung erstellt, um alle zwischen dem Start- und dem Enddatum aufgetretenen Fehler zu löschen. Die folgende Abfrage wird verwendet:

    "DELETE FROM NmsEmailErrorStat WHERE tsDate>=$(start) AND tsDate<$(end)"
    
  4. Jeder Fehler wird im NmsEmailErrorStat Tabelle mit der folgenden Abfrage:

    "INSERT INTO NmsEmailErrorStat(iMXIP, iPublicId, tsDate, iTotalConnections, iTotalErrors, iTimeoutConnections, iRefusedConnections, iAbortedConnections, iFailedConnections, iMessageErrors) VALUES($(lmxip ), $(lpublicId ), $(tsstart ), $(lconnections ), $(lconnectionErrors ),$(ltimeoutConnections ), $(lrefusedConnections ), $(labortedConnections ), $(lfailedConnections ), $(lmessageErrors))"
    

    wobei jede Variable mit einem Wert übereinstimmt, der von der vorherigen Abfrage abgerufen wurde.

  5. Die start wird mit den Werten des vorherigen Prozesses aktualisiert, um die Schleife abzuschließen.

Die Schleife und die Aufgabe werden beendet.

Bereinigungen werden auf der NmsEmailError und cleanupNmsMxDomain -Tabellen.

Bereinigung der NmsEmailError -Tabelle

Die folgende Abfrage wird verwendet:

DELETE FROM NmsEmailError WHERE iMXIP NOT IN (SELECT DISTINCT iMXIP FROM NmsEmailErrorStat)

Diese Abfrage löscht alle Zeilen ohne verknüpfte Datensätze im NmsEmailErrorStat von NmsEmailError Tabelle.

Bereinigung der NmsMxDomain-Tabelle

Die folgende Abfrage wird verwendet:

DELETE FROM NmsMxDomain WHERE iMXIP NOT IN (SELECT DISTINCT iMXIP FROM NmsEmailErrorStat)

Diese Abfrage löscht alle Zeilen, die keinen verknüpften Datensatz in der NmsEmailErrorStat aus der NmsMxDomain Tabelle.

Bereinigung der Vorschläge

Wenn die Variable Interaction installiert ist, wird diese Aufgabe ausgeführt, um die NmsPropositionXxx -Tabellen.

Die Liste der Vorschlagstabellen wird abgerufen und gebündelt gelöscht, indem die folgende Abfrage verwendet wird:

DELETE FROM NmsPropositionXxx WHERE iPropositionId IN (SELECT iPropositionId FROM NmsPropositionXxx WHERE tsLastModified < $(option) LIMIT 5000) 

where $(option) das für die NmsCleanup_PropositionPurgeDelay Option (siehe Implementierungsassistent).

Bereinigung der Simulationstabellen

Diese Aufgabe bereinigt verwaiste Simulationstabellen (die nicht mehr mit einer Angebotssimulation oder einer Versandsimulation verknüpft sind).

  1. Um die Liste der Simulationen abzurufen, die bereinigt werden müssen, wird die folgende Abfrage verwendet:

    SELECT iSimulationId FROM NmsSimulation WHERE iSimulationId<>0
    
  2. Der Name der zu löschenden Tabellen setzt sich aus wkSimu_ -Präfix gefolgt von der Kennung der Simulation (z. B.: wkSimu_456831_aggr):

    DROP TABLE wkSimu_456831_aggr
    

Bereinigung des Audit-Protokolls

Die folgende Abfrage wird verwendet:

DELETE FROM XtkAudit WHERE tsChanged < $(tsDate)

where $(tsDate) ist das aktuelle Server-Datum, ab dem der für XtkCleanup_AuditTrailPurgeDelay abgezogen.

Bereinigung von Nmsaddress

Die folgende Abfrage wird verwendet:

DELETE FROM NmsAddress WHERE iAddressId IN (SELECT iAddressId FROM NmsAddress WHERE iStatus=STATUS_QUARANTINE AND tsLastModified < $(NmsCleanup_AppSubscriptionRcpPurgeDelay + 5d) AND iType IN (MESSAGETYPE_IOS, MESSAGETYPE_ANDROID ) LIMIT 5000)

Diese Abfrage löscht alle Einträge, die sich auf iOS und Android beziehen.

Optimierung der Statistikaktualisierung und -speicherung

Die XtkCleanup_NoStats -Option können Sie das Verhalten des Speicheroptimierungsschritts des Bereinigungs-Workflows steuern.

Wenn die Variable XtkCleanup_NoStats nicht vorhanden ist oder wenn der Wert 0 beträgt, wird die Speicheroptimierung im Ausführlichen Modus (VACUUM VERBOSE ANALYZE) auf PostgreSQL ausgeführt und die Statistiken auf allen anderen Datenbanken aktualisiert. Um sicherzustellen, dass dieser Befehl ausgeführt wird, überprüfen Sie die PostgreSQL-Protokolle. VACUUM gibt Zeilen im folgenden Format aus: INFO: vacuuming "public.nmsactivecontact" und ANALYZE gibt die Ausgabezeilen im folgenden Format aus: INFO: analyzing "public.nmsactivecontact".

Wenn der Wert der Option 1 ist, werden die Statistiken in keiner Datenbank aktualisiert. Die folgende Protokollzeile wird in den Workflow-Logs angezeigt: Option 'XtkCleanup_NoStats' is set to '1'.

Wenn der Wert der Option 2 ist, wird die Speicheranalyse im Ausführlichen Modus (ANALYZE VERBOSE) auf PostgreSQL ausgeführt und die Statistiken auf allen anderen Datenbanken aktualisiert. Um sicherzustellen, dass dieser Befehl ausgeführt wird, überprüfen Sie die PostgreSQL-Protokolle. ANALYZE gibt die Ausgabezeilen im folgenden Format aus: INFO: analyzing "public.nmsactivecontact".

Abonnement-Bereinigung (NMAC)

Diese Aufgabe löscht alle Abonnements im Zusammenhang mit gelöschten Diensten oder Mobile Apps.

Um die Liste der Broadlog-Schemata abzurufen, wird die folgende Abfrage verwendet:

SELECT distinct(sBroadLogSchema) FROM NmsDeliveryMapping WHERE sBroadLogSchema IS NOT NULL

Die Aufgabe stellt dann die Namen der mit der appSubscription und löscht diese Tabellen.

Dieser Bereinigungs-Workflow löscht auch alle Einträge, bei denen disabled = 1 ist und die seit der im NmsCleanup_AppSubscriptionRcpPurgeDelay -Option.

Sitzungsinformationen bereinigen

Diese Aufgabe bereinigt Informationen aus dem sessionInfo -Tabelle, wird die folgende Abfrage verwendet:

 DELETE FROM XtkSessionInfo WHERE tsexpiration < $(curdate) 

Bereinigen abgelaufener Ereignisse

Diese Aufgabe bereinigt die in den Ausführungsinstanzen empfangenen und gespeicherten Ereignisse sowie die in einer Kontrollinstanz archivierten Ereignisse.

Bereinigungsreaktionen

Diese Aufgabe bereinigt die Reaktionen (Tabelle) NmsRemaMatchRcp), in der die Hypothesen gelöscht wurden.

Auf dieser Seite