Datenbankbereinigungs-Workflow

Einleitung

Mit dem Arbeitsablauf Datenbankbereinigung, auf den über den Knoten Administration > Produktion > Technischen Workflows zugegriffen werden kann, können Sie veraltete Daten löschen, um ein exponentielles Datenbankwachstum zu vermeiden. Der Workflow wird automatisch ohne Benutzereingriff ausgelöst.

Konfiguration

Die Datenbankbereinigung wird auf zwei Ebenen konfiguriert: in der Workflow-Planung und im Bereitstellungsassistenten.

Workflow-Planung

HINWEIS

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

Standardmäßig ist der Arbeitsablauf Datenbankbereinigung für den täglichen Beginn um 4AM konfiguriert. Mit der Planung können Sie den Workflow ändern, der die Häufigkeit auslöst. Die folgenden Frequenzen stehen zur Verfügung:

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

WICHTIG

Damit der Arbeitsablauf Datenbankbereinigung zu dem in der Planung definierten Zeitpunkt zum Beginn führt, muss das Workflow-Engine (wfserver) gestartet werden. Ist dies nicht der Fall, erfolgt die Datenbereingung der Datenbank erst nach dem nächsten Starten des Workflow-Engine.

Bereitstellungsassistent

Mit dem Implementierungsassistenten, der über das Menü Tools > Erweitert aufgerufen wird, können Sie konfigurieren, wie lange Daten gespeichert werden. Die Werte werden in Tagen angegeben. Wenn diese Werte nicht geändert werden, verwendet der Workflow die Standardwerte.

Die Felder im Fenster Datenbereinigung stimmen mit den folgenden Optionen überein. Diese werden von einigen der Aufgaben verwendet, die vom Datenbankbereinigung-Arbeitsablauf ausgeführt werden:

Alle Aufgaben, die vom Datenbankbereinigung-Arbeitsablauf ausgeführt werden, werden im folgenden Abschnitt beschrieben.

Aufgaben, die vom Datenbankbereinigungs-Workflowdurchgeführt werden

Zu dem in der Workflow-Planung definierten Zeitpunkt (siehe Die Planung) Beginn das 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 dem Attribut LIMIT werden wiederholt ausgeführt, bis alle Informationen verarbeitet sind.

HINWEIS

Die folgenden Abschnitte, die die Aufgaben des Arbeitsablaufs für die Datenbankbereinigung beschreiben, sind für Datenbankadministratoren oder Benutzer mit SQL-Kenntnissen vorbehalten.

Listen zum Löschen der Bereinigung

Die erste Aufgabe, die vom Datenbank-Bereinigung-Arbeitsablauf ausgeführt wird, löscht alle Gruppen mit dem deleteStatus != 0 Attribut von 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 wiederhergestellt:

    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 mit der folgenden Abfrage stapelweise gelöscht:

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

    wobei $(relatedTable) eine Tabelle ist, die mit NmsGroup und $(l) mit der Liste-ID in Verbindung steht.

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

    DROP TABLE grp$(l)
    
  4. Jede Select-Liste, die durch den Vorgang wiederhergestellt wurde, wird mit der folgenden Abfrage gelöscht:

    DELETE FROM NmsGroup WHERE iGroupId=$(l) 
    

    wobei $(l) der Identifikator der Liste ist

Bereinigung der zu löschenden oder zu recycelnden Versand

Mit dieser Aufgabe werden alle zu löschenden oder zu recycelnden Versand bereinigt.

  1. Der Arbeitsablauf Datenbankbereinigung wählt alle Versand aus, für die das Feld deleteStatus den Wert Ja oder Recycled hat und deren Löschdatum älter ist als der in Gelöschte Versand (Nr) definierte Zeitraum msCleanup_RecycledDeliveryPurgeDelay)-Feld des Bereitstellungsassistenten. Weitere Informationen finden Sie unter Bereitstellungsassistent. Dieser Zeitraum wird im Verhältnis zum aktuellen Serverdatum berechnet.

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

  3. Der Arbeitsablauf Datenbankbereinigung löscht Versandlogs, Anlagen, Informationen zur Mirrorseite und alle anderen zugehörigen Daten.

  4. Bevor Sie den Versand endgültig löschen, werden die verknüpften Informationen aus den folgenden Tabellen entfernt:

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

      DELETE FROM NmsDlvExclusion WHERE iDeliveryId=$(l)
      

      wobei $(l) der Bezeichner des Versands ist.

    • In der Coupon-Tabelle (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)
      

      wobei $(l) der Bezeichner des Versands ist.

    • In den Protokolltabellen des Versands (NmsBroadlogXxx) werden Massenlöschungen in Stapeln von 20.000 Datensätzen ausgeführt.

    • In den Angebotsvorschlag-Tabellen (NmsPropositionXxx) werden Massenlöschungen in Stapeln von 20.000 Datensätzen ausgeführt.

    • In den Verfolgungsprotokolltabellen (NmsTrackinglogXxx) werden Massenlöschungen in Stapeln von 20.000 Datensätzen ausgeführt.

    • In der Fragment-Tabelle des Versands (NmsDeliveryPart) werden Massenlöschungen in Stapeln von 500.000 Datensätzen ausgeführt. Diese Tabelle enthält Personalisierungsinformationen zu den verbleibenden zu liefernden Nachrichten.

    • In der Datenfragmenttabelle der Mirrorseite (NmsMirrorPageInfo) werden Massenlöschungen in Stapeln von 20.000 Datensätzen für abgelaufene Versand und für fertige oder abgebrochene Teile ausgeführt. Diese Tabelle enthält Personalisierungsinformationen zu allen Nachrichten, die zum Generieren von Mirrorseiten verwendet werden.

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

    • In der Stapelverarbeitungsprotokolltabelle (XtkJobLog) werden Massenlöschungen in Stapeln von 20.000 Datensätzen ausgeführt. Diese Tabelle enthält das Protokoll der zu löschenden Versand.

    • In der Verfolgungstabelle für Versand-URL (NmsTrackingUrl) wird die folgende Abfrage verwendet:

      DELETE FROM NmsTrackingUrl WHERE iDeliveryId=$(l)
      

      wobei $(l) der Bezeichner des Versands ist.

      Diese Tabelle enthält die URLs in den zu löschenden Versänden, um deren Verfolgung zu aktivieren.

  5. Der Versand wird aus der Tabelle "Versand"(NmsDelivery) gelöscht:

    DELETE FROM NmsDelivery WHERE iDeliveryId = $(l)
    

    wobei $(l) der Bezeichner des Versands ist.

Versand, die Mid-Sourcingverwenden

Der Arbeitsablauf Datenbankbereinigung löscht auch Versand auf dem/den Mid-Sourcing-Server(n).

  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 beendet. Die Kontrolle wird wie folgt durchgeführt:

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

    wobei $(l) der Bezeichner des Versands ist.

  2. Wenn der Statuswert Beginn ausstehend , Wird ausgeführt , Wiederherstellung ausstehend , Wiederherstellung läuft , Angeforderte Pause , Anhalten in Bearbeitung oder ist 12/>Paused (Werte 51, 55, 61, 62, 71, 72, 75), wird der Versand gestoppt und die Aufgabe löscht die verknüpften Informationen.

Bereinigung abgelaufener Versand

Diese Aufgabe beendet Versand, deren Gültigkeitsdauer abgelaufen ist.

  1. Der Arbeitsablauf Datenbankbereinigung erstellt die Liste der Versand, die abgelaufen sind. Diese Liste umfasst alle abgelaufenen Versand mit einem anderen Status als Fertig sowie kürzlich angehaltene Versand mit über 10.000 nicht verarbeiteten Nachrichten. 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 ))
    

    wobei Versand mode 1 mit dem Mass Versand-Modus übereinstimmt, state 51 mit dem Status Beginn ausstehend übereinstimmt, state 85 mit dem Status Angehalten übereinstimmt, und die höchste Anzahl von Versandlogs, die auf dem Versand-Server gezählt werden, gleich 10.000.

  2. Der Workflow umfasst dann die Liste der zuletzt abgelaufenen Versand, die Mid-Sourcing verwenden. Versand, für die noch keine Versandlogs über den Mid-Sourcing-Server wiederhergestellt wurden, werden 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. Mit der folgenden Abfrage wird ermittelt, ob das Externe Konto noch aktiv ist, um Versand nach Datum zu filtern:

    SELECT iExtAccountId FROM NmsExtAccount WHERE iActive<>0 AND sName=$(providerName)
    
  4. In Liste abgelaufener Versand wechseln Versandlogs, deren Status Ausstehend lautet, zu Versand abgebrochen und alle Versand in dieser Liste wechseln zu Fertig.

    Die folgenden Abfragen werden verwendet:

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

    wobei $(curdate) das aktuelle Datum des Datenbankservers ist, $(bl) der Bezeichner der Meldung "Versandlogs", $(dl) ist der Bezeichner des Versands, Versand status 6 mit dem Status Ausstehend übereinstimmt Versand status 7 stimmt mit dem Status Abgebrochener Versand überein.

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

    wobei Versand state 95 mit dem Status Fertig und $(dl) mit dem Bezeichner des Versands übereinstimmt.

  5. Alle Fragmente (deliveryParts) veralteter Versand werden gelöscht und alle veralteten Fragmente der in Bearbeitung befindlichen Benachrichtigungselemente werden gelöscht. Massenlöschung wird für beide Aufgaben 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)
    

    wobei Versand state 95 mit dem Status Fertig, Versand state 85 mit dem Status Angehalten und $(curDate) mit dem aktuellen Serverdatum übereinstimmt.

Bereinigung von Mirrorseiten

Diese Aufgabe löscht die von Versänden verwendeten Webressourcen (Mirrorseiten).

  1. Zunächst wird die Liste der zu bereinigenden Versand mithilfe der folgenden Abfrage wiederhergestellt:

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

    wobei $(curDate) das aktuelle Serverdatum ist.

  2. Anschließend wird die Tabelle NmsMirrorPageInfo bereinigt, gegebenenfalls unter Verwendung der Kennung des zuvor wiederhergestellten Versands. 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)
    

    wobei $(dl) der Bezeichner des Versands ist.

  3. Dem Versand-Protokoll wird dann ein Eintrag hinzugefügt.

  4. Gereinigte Versand 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))
    

    wobei $(strIn) die Liste der Versand-IDs ist.

Bereinigen von Arbeitstabellen

Diese Aufgabe löscht aus der Datenbank alle Arbeitstabellen, die Versänden entsprechen, deren Status bearbeitet werden , Gestoppt oder Gelöscht.

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

    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 Workflows verwendeten Tabellen werden dann ausgeschlossen. Zu diesem Zweck wird die Liste der ausgeführten Versand mithilfe der folgenden Abfrage wiederhergestellt:

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

    wobei 0 der Wert ist, der mit dem Status Wird bearbeitet Versand übereinstimmt, entspricht 85 dem Status Gestoppt und 100 dem Status Gelöscht.

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

    DROP TABLE wkDlv_15487_1;
    

Bereinigung von durch Importe generierten Ablehnungen

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

  1. Massenlöschung erfolgt auf der xtkReject-Tabelle mit der folgenden Abfrage:

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

    wobei $(curDate) das aktuelle Serverdatum ist, ab dem der für die Option NmsCleanup_RejectsPurgeDelay definierte Zeitraum abgezogen wird (siehe Bereitstellungsassistent) und $(l) die maximale Anzahl der zu löschenden Datensätze ist.

  2. Alle verwaisten Ablehnungen werden dann mit 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 mit ihrem Identifer (lWorkflowId) und dem Verlauf (lHistory). Dadurch werden inaktive Tabellen gelöscht, indem die Aufgabe zur Bereinigung der Tabelle erneut ausgeführt wird. Die Bereinigung löscht auch alle verwaisten Arbeitstische (wkf% und wkfhisto%) der gelöschten Workflows.

HINWEIS

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

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

    SELECT iWorkflowId, iHistory FROM XtkWorkflow WHERE iWorkflowId<>0
    
  2. Diese Abfrage generiert die Liste von Workflows, die zum Löschen aller verknüpften Protokolle, fertigen Aufgaben und fertigen Ereignis verwendet wird. Dabei werden folgende Abfragen verwendet:

    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))
    

    wobei $(lworkflow) der Bezeichner des Workflows und $(log) der Bezeichner des Verlaufs ist.

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

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

    SELECT iWorkflowId FROM XtkWorkflow WHERE iWorkflowId<>0 AND iState<>20
    
  5. Jeder Workflow-Bezeichner wird dann wiederhergestellt, um den Namen der Tabellen zu finden, die von Workflows in Bearbeitung sind. Diese Namen werden von der Liste zuvor wiederhergestellter Tabellen ausgeschlossen.

  6. Verlaufstabellen vom Typ "inkrementelle Abfrage"werden mit den 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))
    

    wobei $(strbedingung) die Liste von Tabellen ist, die mit der wkfhisto%-Maske übereinstimmen.

  7. Die übrigen Tabellen werden mit der folgenden Abfrage gelöscht:

    DROP TABLE wkf15487_12;
    

Bereinigen von 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 Tabelle NmsGroup speichert die zu bereinigenden Gruppen (mit einem anderen Typ als 0). Das Präfix der Tabellennamen ist grp. Zur Identifizierung der zu reinigenden Gruppen wird folgende Abfrage verwendet:

SELECT iGroupId FROM NmsGroup WHERE iType>0"

Bereinigung von Besuchern

Diese Aufgabe löscht veraltete Datensätze mithilfe des Massenlöschens aus der Besucher-Tabelle. Veraltete Datensätze sind solche, deren letzte Änderung vor dem im Bereitstellungsassistenten definierten Erhaltungszeitraum liegt (siehe Bereitstellungsassistent). 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)

wobei $(tsDate) das aktuelle Serverdatum ist, von dem der für die Option NmsCleanup_VisitorPurgeDelay definierte Zeitraum abgezogen wird.

Bereinigung von NPAI

Mit dieser Aufgabe können Sie Datensätze löschen, die gültige Adressen enthalten, aus der Tabelle NmsAddress. Die folgende Abfrage dient zum Durchführen des Massenlöschens:

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

wobei status 2 mit dem Status Valid, $(tsDate1) mit dem aktuellen Serverdatum übereinstimmt und $(tsDate2) mit der Option NmsCleanup_LastCleanup übereinstimmt.

Bereinigung von Abonnements

Mit dieser Aufgabe werden alle vom Benutzer gelöschten Abonnement aus der Tabelle NmsSubscription entfernt, indem Massenlöschungen vorgenommen werden. Die folgende Abfrage wird verwendet:

DELETE FROM NmsSubscription WHERE iDeleteStatus <>0

Bereinigung von Trackinglogs

Diese Aufgabe löscht veraltete Datensätze aus den Protokolltabellen für Verfolgung und Webtracking. Veraltete Datensätze sind solche, die vor dem im Bereitstellungsassistenten definierten Erhaltungszeitraum liegen (siehe Bereitstellungsassistent).

  1. Erstens wird die Liste der Verfolgungstabellen mithilfe der folgenden Abfrage wiederhergestellt:

    SELECT distinct(sTrackingLogSchema) FROM NmsDeliveryMapping WHERE sTrackingLogSchema IS NOT NULL;
    
  2. Massenlöschung wird verwendet, um alle Tabellen in Liste zuvor wiederhergestellter Tabellen zu bereinigen. Die folgende Abfrage wird verwendet:

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

    wobei $(tsDate) das aktuelle Serverdatum ist, ab dem der für die Option NmsCleanup_TrackingLogPurgeDelay definierte Zeitraum abgezogen wird.

  3. Die Tabelle der Verfolgungsstatistiken wird mithilfe des Massenlöschens bereinigt. Die folgende Abfrage wird verwendet:

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

    wobei $(tsDate) das aktuelle Serverdatum ist, ab dem der für die Option NmsCleanup_TrackingStatPurgeDelay definierte Zeitraum abgezogen wird.

Bereinigung von Versandlogs

Mit dieser Aufgabe können Sie die in verschiedenen Tabellen gespeicherten Versandlogs bereinigen.

  1. Zu diesem Zweck wird die Liste der Versand-Protokoll-Schema mithilfe der folgenden Abfrage wiederhergestellt:

    SELECT distinct(sBroadLogSchema) FROM NmsDeliveryMapping WHERE sBroadLogSchema IS NOT NULL UNION SELECT distinct(sBroadLogExclSchema) FROM NmsDeliveryMapping WHERE sBroadLogExclSchema IS NOT NULL
    
  2. Bei der Verwendung von Mid-Sourcing wird in der Tabelle NmsBroadLogMid nicht auf die Versand-Zuordnung verwiesen. Das Schema nms:wideLogMid wird der durch die vorherige Abfrage wiederhergestellten Liste hinzugefügt.

  3. Der Arbeitsablauf Datenbankbereinigung bereinigt 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) 
    

    wobei $(tableName) der Tabellenname in der Liste der Schema und $(option) das für die Option NmsCleanup_BroadLogPurgeDelay definierte Datum ist (siehe Bereitstellungsassistent).

  4. Der Workflow überprüft schließlich, ob die Tabelle NmsProviderMsgId vorhanden ist. Wenn ja, werden alle veralteten Daten mit der folgenden Abfrage gelöscht:

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

    wobei $(option) mit dem für die Option NmsCleanup_BroadLogPurgeDelay definierten Datum übereinstimmt (siehe Bereitstellungsassistent).

Bereinigen der NmsEmailErrorStat-Tabelle

Diese Aufgabe löscht die NmsEmailErrorStat-Tabelle. Das Hauptdatum (coalesceErrors) definiert zwei Programm:

  • Beginn: Datum des nächsten Prozesses, der mit der Option ​NmsLastErrorStatColor oder dem neuesten Datum in der Tabelle übereinstimmt.
  • Enddatum: aktuelles Serverdatum.

Wenn das Enddatum des Beginns größer oder gleich dem Enddatum ist, findet kein Prozess statt. In diesem Fall wird die Meldung coalesceUpToDate angezeigt.

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

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

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

wobei $end und $Beginn die zuvor definierten Beginns- und Enddaten sind.

Wenn die Summe größer als 0 ist:

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

    "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 Meldung coalescingErrors wird angezeigt.

  3. Eine neue Verbindung wird erstellt, um alle zwischen dem Beginns- und dem Enddatum auftretenden Fehler zu löschen. Die folgende Abfrage wird verwendet:

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

    "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 durch die vorherige Abfrage wiederhergestellten Wert übereinstimmt.

  5. Die Variable Beginn wird mit den Werten des vorherigen Prozesses aktualisiert, um die Schleife zu beenden.

Die Schleife und die Aufgabe halten an.

Bereinigungen werden auf den Tabellen NmsEmailError und cleanupNmsMxDomain ausgeführt.

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 in der NmsEmailErrorStat-Tabelle NmsEmailError.

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 ohne verknüpften Datensatz in der Tabelle NmsEmailErrorStat aus der Tabelle NmsMxDomain.

Bereinigung von Vorschlägen

Wenn das Modul Interaktion installiert ist, wird diese Aufgabe ausgeführt, um die Tabellen NmsPropositionXxx zu bereinigen.

Die Liste der Propositionstabellen wird wiederhergestellt, und die Massenlöschung erfolgt auf jeder der folgenden Abfragen:

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

wobei $(option) das für die Option NmsCleanup_PropositionPurgeDelay definierte Datum ist (siehe Bereitstellungsassistent).

Bereinigen von Simulationen-Tabellen

Diese Aufgabe bereinigt verwaiste Simulationen (die nicht mehr mit einer Angebot-Simulation oder einer Versand-Simulation verknüpft sind).

  1. Zur Wiederherstellung der Liste von Simulationen, die bereinigt werden müssen, wird folgende Abfrage verwendet:

    SELECT iSimulationId FROM NmsSimulation WHERE iSimulationId<>0
    
  2. Der Name der zu löschenden Tabellen besteht aus dem Präfix wkSimu_ gefolgt vom Bezeichner der Simulation (z. B.: wkSimu_456831_aggr):

    DROP TABLE wkSimu_456831_aggr
    

Bereinigung des Prüfpfads

Die folgende Abfrage wird verwendet:

DELETE FROM XtkAudit WHERE tsChanged < $(tsDate)

wobei $(tsDate) das aktuelle Serverdatum ist, ab dem der für die Option XtkCleanup_AuditTrailPurgeDelay definierte Zeitraum ersetzt wird.

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 im Zusammenhang mit iOS und Android.

Statistische Aktualisierung und Optimierung der Datenspeicherung

Mit der Option XtkCleanup_NoStats können Sie das Verhalten des Datenspeicherung-Optimierungsschritts des Bereinigungs-Workflows steuern.

Wenn die Option XtkCleanup_NoStats nicht vorhanden ist oder der Wert 0 ist, wird die Datenspeicherung-Optimierung im ausführlichen Modus (VACUUM VERBOSE ANALYZE) auf PostgreSQL ausgeführt und die Statistik für alle anderen Datenbanken aktualisiert. Um sicherzustellen, dass dieser Befehl ausgeführt wird, überprüfen Sie die PostgreSQL-Protokolle. VACUUM gibt Zeilen im Format aus: INFO: vacuuming "public.nmsactivecontact" und ANALYZE geben Zeilen im Format aus: INFO: analyzing "public.nmsactivecontact".

Wenn der Wert der Option 1 ist, werden keine statistischen Aktualisierungen in einer Datenbank durchgeführt. Die folgende Protokollzeile wird in den Workflow-Protokollen angezeigt: Option 'XtkCleanup_NoStats' is set to '1'.

Wenn der Wert der Option 2 ist, wird die Datenspeicherung Analyse im ausführlichen Modus (ANALYZE VERBOSE) auf PostgreSQL ausgeführt und die Statistik für alle anderen Datenbanken aktualisiert. Um sicherzustellen, dass dieser Befehl ausgeführt wird, überprüfen Sie die PostgreSQL-Protokolle. ANALYZE gibt Zeilen im Format aus: INFO: analyzing "public.nmsactivecontact".

Abonnement-Bereinigung (NMAC)

Diese Aufgabe löscht alle Abonnement im Zusammenhang mit gelöschten Diensten oder Mobilanwendungen.

Zur Wiederherstellung der Liste von Broadlog-Schemas wird folgende Abfrage verwendet:

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

Die Aufgabe stellt dann die mit dem Link appSubscription verknüpften Tabellennamen wieder her und löscht diese Tabellen.

Dieser Bereinigungsarbeitsablauf löscht auch alle Einträge, bei denen deaktiviert = 1 ist und die seit dem in der Option NmsCleanup_AppSubscriptionRcpPurgeDelay festgelegten Zeitraum nicht aktualisiert wurden.

Informationen zur Datenbereingung-Sitzung

Diese Aufgabe löscht Informationen aus der sessionInfo-Tabelle. Es wird folgende Abfrage verwendet:

 DELETE FROM XtkSessionInfo WHERE tsexpiration < $(curdate) 

Datenbereingung abgelaufene Ereignis

Mit dieser Aufgabe werden die auf den Ausführungsinstanzen und auf einer Kontrollinstanz archivierten Ereignis gereinigt.

Datenbereingung Reaktionen

Diese Aufgabe löscht die Reaktionen (Tabelle NmsRemaMatchRcp), in denen die Hypothesen selbst gelöscht wurden.

Auf dieser Seite

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free