La Database cleanup flusso di lavoro accessibile tramite Administration > Production > Technical workflows node, consente di eliminare i dati obsoleti per evitare la crescita esponenziale del database. Il flusso di lavoro viene attivato automaticamente senza l’intervento dell’utente.
La pulizia del database è configurata su due livelli: nella pianificazione del flusso di lavoro e nella procedura guidata di distribuzione.
Per ulteriori informazioni sulla pianificazione, consulta questa sezione.
Per impostazione predefinita, la Database cleanup il flusso di lavoro è configurato per iniziare ogni giorno alle 4 del mattino. La pianificazione consente di modificare la frequenza di attivazione del flusso di lavoro. Sono disponibili le seguenti frequenze:
Al fine di Database cleanup per avviare il flusso di lavoro alla data e all’ora definite nella pianificazione, è necessario avviare il motore del flusso di lavoro (wfserver).
La Deployment wizard, accessibile tramite Tools > Advanced consente di configurare per quanto tempo vengono salvati i dati. I valori sono espressi in giorni. Se tali valori non vengono modificati, il flusso di lavoro utilizza i valori predefiniti.
I campi Purge of data la finestra coincide con le seguenti opzioni. Vengono utilizzati da alcune delle attività eseguite da Database cleanup flusso di lavoro:
Tracciamento consolidato: NmsCleanup_TrackingStatePurgeDelay (fare riferimento a Pulizia dei registri di tracciamento)
Log di consegna: NmsCleanup_BroadLogPurgeDelay (fare riferimento a Pulizia dei registri di consegna)
Registri di tracciamento: NmsCleanup_TrackingLogPurgeDelay (fare riferimento a Pulizia dei registri di tracciamento)
Consegne eliminate: NmsCleanup_RecycledDeliveryPurgeDelay (fare riferimento a Pulizia delle consegne da eliminare o riciclare)
Rifiuti di importazione: NmsCleanup_RejectsPurgeDelay (fare riferimento a Pulizia dei rifiuti prodotti dalle importazioni)
Profili dei visitatori: NmsCleanup_VisitorPurgeDelay (fare riferimento a Pulizia dei visitatori)
Proposte di offerta: NmsCleanup_PropositionPurgeDelay (fare riferimento a Pulizia delle proposte)
La Offer propositions è disponibile solo quando il campo Interazione modulo installato.
Eventi: NmsCleanup_EventPurgeDelay (fare riferimento a Pulizia degli eventi scaduti)
Eventi archiviati: NmsCleanup_EventHistoPurgeDelay (fare riferimento a Pulizia degli eventi scaduti)
La Events e Archived events i campi sono disponibili solo se Centro messaggi modulo installato.
Audit trail: XtkCleanup_AuditTrailPurgeDelay (fare riferimento a Pulizia della pista di controllo)
Tutte le attività eseguite da Database cleanup il flusso di lavoro è descritto nella sezione seguente.
Alla data e all’ora definite nella pianificazione del flusso di lavoro (consulta Programmatore), il motore del flusso di lavoro avvia il processo di pulizia del database. La pulizia del database si connette al database ed esegue le attività nella sequenza riportata di seguito.
Se una di queste attività ha esito negativo, quelle successive non vengono eseguite.
Query SQL con un LIMITE vengono eseguiti ripetutamente fino a quando tutte le informazioni non vengono elaborate.
La prima attività eseguita da Database cleanup il flusso di lavoro elimina tutti i gruppi con deleteStatus != 0 attributo dal NmsGroup. Vengono inoltre eliminati i record collegati a tali gruppi e presenti in altre tabelle.
Gli elenchi da eliminare vengono recuperati utilizzando la seguente query SQL:
SELECT iGroupId, sLabel, iType FROM NmsGroup WHERE iDeleteStatus <> 0 OR tsExpirationDate <= GetDate()
Ogni elenco include diversi collegamenti ad altre tabelle. Tutti questi collegamenti vengono eliminati in blocco utilizzando la seguente query:
DELETE FROM $(relatedTable) WHERE iGroupId=$(l) IN (SELECT iGroupId FROM $(relatedTable) WHERE iGroupId=$(l) LIMIT 5000)
dove $(relatedTable)
è una tabella correlata a NmsGroup e $(l)
è l'identificatore dell'elenco.
Quando l’elenco è un elenco di tipo "Elenco", la tabella associata viene eliminata utilizzando la seguente query:
DROP TABLE grp$(l)
Ogni Seleziona l'elenco dei tipi recuperato dall'operazione viene eliminato utilizzando la seguente query:
DELETE FROM NmsGroup WHERE iGroupId=$(l)
dove $(l)
è l'identificatore dell'elenco
Questa attività elimina tutte le consegne da eliminare o riciclare.
La Database cleanup seleziona tutte le consegne per le quali il deleteStatus il campo ha il valore Yes o Recycled e la cui data di cancellazione è precedente al periodo definito nel Deleted deliveries (NmsCleanup_RecycledDeliveryPurgeDelay) della procedura guidata di distribuzione. Per ulteriori informazioni, consulta Procedura guidata di distribuzione. Questo periodo è calcolato in relazione alla data corrente del server.
Per ogni server di mid-sourcing, l'attività seleziona l'elenco delle consegne da eliminare.
La Database cleanup il flusso di lavoro elimina i registri di consegna, gli allegati, le informazioni della pagina speculare e tutti gli altri dati correlati.
Prima di eliminare definitivamente la consegna, il flusso di lavoro elimina le informazioni collegate dalle tabelle seguenti:
Nella tabella di esclusione della consegna (NmsDlvExclusion), viene utilizzata la seguente query:
DELETE FROM NmsDlvExclusion WHERE iDeliveryId=$(l)
dove $(l) è l’identificatore della consegna.
Nella tabella delle cedole (NmsCouponValue), viene utilizzata la seguente query (con eliminazioni di massa):
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)
dove $(l)
è l’identificatore della consegna.
Nelle tabelle dei registri di consegna (NmsBroadlogXxx), le eliminazioni di massa vengono eseguite in batch di 20.000 record.
Nelle tabelle delle proposte di offerta (NmsPropositionXxx), le eliminazioni di massa vengono eseguite in batch di 20.000 record.
Nelle tabelle dei registri di tracciamento (NmsTrackinglogXxx), le eliminazioni di massa vengono eseguite in batch di 20.000 record.
Nella tabella dei frammenti di consegna (NmsDeliveryPart), le eliminazioni di massa vengono eseguite in batch di 500.000 record. Questa tabella contiene informazioni di personalizzazione sui messaggi rimanenti da consegnare.
Nella tabella dei frammenti di dati della pagina speculare (NmsMirrorPageInfo), le eliminazioni di massa vengono eseguite in batch di 20.000 record per le parti di consegna scadute e per quelle finite o annullate. Questa tabella contiene informazioni di personalizzazione su tutti i messaggi utilizzati per generare pagine mirror.
Nella tabella di ricerca della pagina speculare (NmsMirrorPageSearch), le eliminazioni di massa vengono eseguite in batch di 20.000 record. Questa tabella è un indice di ricerca che fornisce accesso alle informazioni di personalizzazione memorizzate in NmsMirrorPageInfo tabella.
Nella tabella del registro del processo batch (XtkJobLog), le eliminazioni di massa vengono eseguite in batch di 20.000 record. Questa tabella contiene il registro delle consegne da eliminare.
Nella tabella di tracciamento degli URL di consegna (NmsTrackingUrl), viene utilizzata la seguente query:
DELETE FROM NmsTrackingUrl WHERE iDeliveryId=$(l)
dove $(l)
è l’identificatore della consegna.
Questa tabella contiene gli URL trovati nelle consegne da eliminare per abilitarne il tracciamento.
La consegna viene eliminata dalla tabella di consegna (NmsDelivery):
DELETE FROM NmsDelivery WHERE iDeliveryId = $(l)
dove $(l)
è l’identificatore della consegna.
La Database cleanup il flusso di lavoro elimina anche le consegne sui server di mid-sourcing.
A questo scopo, il flusso di lavoro controlla che ogni consegna sia inattiva (in base al suo stato). Se una consegna è attiva, verrà interrotta prima di essere eliminata. Il controllo viene eseguito eseguendo la seguente query:
SELECT iState FROM NmsDelivery WHERE iDeliveryId = $(l) AND iState <> 100;
dove $(l) è l’identificatore della consegna.
Se il valore dello stato è Start pending , In progress , Recovery pending , Recovery in progress , Pause requested , Pause in progress oppure Paused (valori 51, 55, 61, 62, 71, 72, 75), la consegna viene interrotta e l'attività elimina le informazioni collegate.
Questa attività interrompe le consegne il cui periodo di validità è scaduto.
La Database cleanup crea l’elenco delle consegne scadute. Questo elenco include tutte le consegne scadute con uno stato diverso da Finished , così come ha interrotto di recente le consegne con oltre 10.000 messaggi non elaborati. Viene utilizzata la seguente query:
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 ))
dove delivery mode 1
corrisponde a Mass delivery modalità, state 51
corrisponde a Start pending stato, state 85
corrisponde a Stopped e il numero più alto di log di consegna aggiornati in massa sul server di consegna è uguale a 10.000.
Il flusso di lavoro include quindi l’elenco delle consegne scadute di recente che utilizzano il mid-sourcing. Sono escluse le consegne per le quali non sono ancora stati recuperati log di consegna tramite il server di mid-sourcing .
Viene utilizzata la seguente query:
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))
La seguente query viene utilizzata per rilevare se l’account esterno è ancora attivo o meno, per filtrare le consegne per data:
SELECT iExtAccountId FROM NmsExtAccount WHERE iActive<>0 AND sName=$(providerName)
Nell’elenco delle consegne scadute, registri di consegna il cui stato è Pending , passa a Delivery cancelled e tutte le consegne in questo elenco passano a Finished .
Vengono utilizzate le seguenti query:
UPDATE $(BroadLogTableName) SET tsLastModified=$(curdate), iStatus=7, iMsgId=$(bl) WHERE iDeliveryId=$(dl) AND iStatus=6
dove $(curdate)
è la data corrente del server di database, $(bl)
è l’identificatore del messaggio dei registri di consegna, $(dl)
è l’identificatore di consegna, delivery status 6
corrisponde a Pending lo stato e delivery status 7
corrisponde a Delivery cancelled stato.
UPDATE NmsDelivery SET iState = 95, tsLastModified = $(curdate), tsBroadEnd = tsValidity WHERE iDeliveryId = $(dl)
dove delivery state 95
corrisponde a Finished lo stato e $(dl)
è l’identificatore della consegna.
Tutti i frammenti (deliveryParts) delle consegne obsolete vengono eliminate e tutti i frammenti obsoleti delle consegne di notifica in corso vengono eliminati. L'eliminazione di massa viene utilizzata per entrambe queste attività.
Vengono utilizzate le seguenti query:
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)
dove delivery state 95
corrisponde a Finished status, delivery state 85
corrisponde a Stopped lo stato e $(curDate)
è la data corrente del server.
Questa attività elimina le risorse web (pagine mirror) utilizzate dalle consegne.
Innanzitutto, l’elenco delle consegne da eliminare viene recuperato utilizzando la seguente query:
SELECT iDeliveryId, iNeedMirrorPage FROM NmsDelivery WHERE iWebResPurged = 0 AND tsWebValidity IS NOT NULL AND tsWebValidity < $(curdate)
dove $(curDate)
è la data corrente del server.
La NmsMirrorPageInfo viene quindi eliminata, se necessario utilizzando l’identificatore della consegna recuperata in precedenza. L’eliminazione di massa viene utilizzata per generare le query seguenti:
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
dove $(dl)
è l’identificatore della consegna.
Viene quindi aggiunta una voce al registro di consegna.
Vengono quindi individuate le consegne sollecitate, per evitare di doverle rielaborare in un secondo momento. Viene eseguita la seguente query:
UPDATE NmsDelivery SET iWebResPurged = 1 WHERE iDeliveryId IN ($(strIn))
dove $(strIn)
è l’elenco degli identificatori di consegna.
Questa attività elimina dal database tutte le tabelle di lavoro che corrispondono alle consegne il cui stato è Being edited , Stopped o Deleted .
Elenco delle tabelle con nomi che iniziano con wkDlv_ viene recuperato prima con la seguente query (postgresql):
SELECT relname FROM pg_class WHERE relname LIKE Lower('wkDlv_') ESCAPE E'\\' AND relkind IN ('r','v') AND pg_get_userbyid(relowner)<>'postgres'
Le tabelle utilizzate dai flussi di lavoro in corso vengono quindi escluse. A questo scopo, l’elenco delle consegne in corso viene recuperato utilizzando la seguente query:
SELECT iDeliveryId FROM NmsDelivery WHERE iDeliveryId<>0 AND iDeleteStatus=0 AND iState NOT IN (0,85,100);
dove 0
è il valore che corrisponde al Being edited stato della consegna, 85
corrisponde a Stopped lo stato e 100
corrisponde a Deleted stato.
Le tabelle non più utilizzate verranno eliminate utilizzando la seguente query:
DROP TABLE wkDlv_15487_1;
Questo passaggio ti consente di eliminare i record per i quali non sono stati elaborati tutti i dati durante l’importazione.
L'eliminazione di massa viene effettuata sul XtkReject tabella con la seguente query:
DELETE FROM XtkReject WHERE iRejectId IN (SELECT iRejectId FROM XtkReject WHERE tsLog < $(curDate)) LIMIT $(l)
dove $(curDate)
è la data corrente del server da cui sottraggiamo il periodo definito per il NmsCleanup_RejectsPurgeDelay (fai riferimento a Procedura guidata di distribuzione) e $(l)
è il numero massimo di record da eliminare in massa.
Tutti i rifiuti orfani vengono quindi eliminati utilizzando la seguente query:
DELETE FROM XtkReject WHERE iJobId NOT IN (SELECT iJobId FROM XtkJob)
Questa attività elimina ogni istanza del flusso di lavoro utilizzando il relativo identificatore (lWorkflowId) e la cronologia (Cronologia). Elimina le tabelle inattive eseguendo nuovamente l'attività di pulizia della tabella di lavoro. La pulizia elimina anche tutte le tabelle di lavoro orfane (wkf% e wkfhisto%) dei flussi di lavoro eliminati.
La frequenza di eliminazione della cronologia viene specificata per ogni flusso di lavoro nel Storia nei giorni (valore predefinito 30 giorni). Questo campo si trova nella Esecuzione scheda delle proprietà del flusso di lavoro. Per ulteriori informazioni al riguardo, consulta questa sezione.
Per recuperare l’elenco dei flussi di lavoro da eliminare, viene utilizzata la seguente query:
SELECT iWorkflowId, iHistory FROM XtkWorkflow WHERE iWorkflowId<>0
Questa query genera l’elenco dei flussi di lavoro che verranno utilizzati per eliminare tutti i registri collegati, le attività completate e gli eventi completati, utilizzando le query seguenti:
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))
dove $(lworkflow)
è l’identificatore del flusso di lavoro e $(lhistory)
è l'identificatore della cronologia.
Tutte le tabelle non utilizzate vengono eliminate. A tal fine, tutte le tabelle vengono raccolte grazie a un wkf% digita la maschera utilizzando la seguente query (postgresql):
SELECT relname FROM pg_class WHERE relname LIKE Lower('wkf%') ESCAPE E'\\' AND relkind IN ('r','v') AND pg_get_userbyid(relowner)<>'postgres'
Vengono quindi escluse tutte le tabelle utilizzate da un’istanza di flusso di lavoro in sospeso. L’elenco dei flussi di lavoro attivi viene recuperato utilizzando la seguente query:
SELECT iWorkflowId FROM XtkWorkflow WHERE iWorkflowId<>0 AND iState<>20
Ogni identificatore del flusso di lavoro viene quindi recuperato per trovare il nome delle tabelle utilizzate dai flussi di lavoro in corso. Questi nomi sono esclusi dall'elenco delle tabelle precedentemente recuperate.
Le tabelle della cronologia delle attività di tipo "query incrementale" sono escluse utilizzando le seguenti query:
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))
dove $(strcondition)
è l’elenco delle tabelle che corrispondono al wkfhisto% maschera.
Le tabelle rimanenti vengono eliminate utilizzando la seguente query:
DROP TABLE wkf15487_12;
Questa attività elimina gli accessi al flusso di lavoro utilizzando la seguente query:
DELETE FROM XtkWorkflowLogin WHERE iWorkflowId NOT IN (SELECT iWorkflowId FROM XtkWorkflow)
Questa attività elimina le tabelle di lavoro orfane collegate ai gruppi. La NmsGroup in tabella vengono memorizzati i gruppi da pulire (con un tipo diverso da 0). Il prefisso dei nomi delle tabelle è grp. Per identificare i gruppi da pulire, viene utilizzata la seguente query:
SELECT iGroupId FROM NmsGroup WHERE iType>0"
Questa attività elimina i record obsoleti dalla tabella dei visitatori utilizzando l’eliminazione di massa. I record obsoleti sono quelli per i quali l'ultima modifica è precedente al periodo di conservazione definito nella procedura guidata di distribuzione (fare riferimento a Procedura guidata di distribuzione). Viene utilizzata la seguente query:
DELETE FROM NmsVisitor WHERE iVisitorId IN (SELECT iVisitorId FROM NmsVisitor WHERE iRecipientId = 0 AND tsLastModified < AddDays(GetDate(), -30) AND iOrigin = 0 LIMIT 20000)
dove $(tsDate)
è la data corrente del server, dalla quale sottrarremo il periodo definito per il NmsCleanup_VisitorPurgeDelay opzione .
Questa attività ti consente di eliminare i record che corrispondono a indirizzi validi dalla NmsAddress tabella. La seguente query viene utilizzata per eseguire l'eliminazione di massa:
DELETE FROM NmsAddress WHERE iAddressId IN (SELECT iAddressId FROM NmsAddress WHERE iStatus=2 AND tsLastModified < $(tsDate1) AND tsLastModified >= $(tsDate2) LIMIT 5000)
dove status 2
corrisponde a Valid status, $(tsDate1)
è la data corrente del server, e $(tsDate2)
corrisponde a NmsCleanup_LastCleanup opzione .
Questa attività elimina tutte le sottoscrizioni eliminate dall'utente dal NmsSubscription tabella, con eliminazione di massa. Viene utilizzata la seguente query:
DELETE FROM NmsSubscription WHERE iDeleteStatus <>0
Questa attività elimina i record obsoleti dalle tabelle di registro di tracking e di webtracking. I record obsoleti sono quelli precedenti al periodo di conservazione definito nella procedura guidata di distribuzione (fare riferimento a Procedura guidata di distribuzione).
Innanzitutto, l'elenco delle tabelle di log di tracking viene recuperato utilizzando la seguente query:
SELECT distinct(sTrackingLogSchema) FROM NmsDeliveryMapping WHERE sTrackingLogSchema IS NOT NULL;
L'eliminazione di massa viene utilizzata per eliminare tutte le tabelle nell'elenco delle tabelle recuperate in precedenza. Viene utilizzata la seguente query:
DELETE FROM NmsTrackingLogRcp WHERE iTrackingLogId IN (SELECT iTrackingLogId FROM NmsTrackingLogRcp WHERE tsLog < $(tsDate) LIMIT 5000)
dove $(tsDate)
è la data corrente del server da cui sottraggiamo il periodo definito per il NmsCleanup_TrackingLogPurgeDelay opzione .
La tabella delle statistiche di tracciamento viene eliminata utilizzando l’eliminazione di massa. Viene utilizzata la seguente query:
DELETE FROM NmsTrackingStats WHERE iTrackingStatsId IN (SELECT iTrackingStatsId FROM NmsTrackingStats WHERE tsStart < $(tsDate) LIMIT 5000)
dove $(tsDate)
è la data corrente del server da cui sottraggiamo il periodo definito per il NmsCleanup_TrackingStatePurgeDelay opzione .
Questa attività ti consente di eliminare i registri di consegna memorizzati in varie tabelle.
A questo scopo, l’elenco degli schemi di log di consegna viene recuperato utilizzando la seguente query:
SELECT distinct(sBroadLogSchema) FROM NmsDeliveryMapping WHERE sBroadLogSchema IS NOT NULL UNION SELECT distinct(sBroadLogExclSchema) FROM NmsDeliveryMapping WHERE sBroadLogExclSchema IS NOT NULL
Quando si utilizza l'mid-sourcing, la funzione NmsBroadLogMid nelle mappature di consegna non viene fatto riferimento alla tabella. La nms:wideLogMid lo schema viene aggiunto all'elenco recuperato dalla query precedente.
La Pulizia del database quindi elimina i dati obsoleti dalle tabelle recuperate in precedenza. Viene utilizzata la seguente query:
DELETE FROM $(tableName) WHERE iBroadLogId IN (SELECT iBroadLogId FROM $(tableName) WHERE tsLastModified < $(option) LIMIT 5000)
dove $(tableName)
è il nome di ciascuna tabella dell’elenco degli schemi, e $(option)
è la data definita per NmsCleanup_BroadLogPurgeDelay (fai riferimento a Procedura guidata di distribuzione).
Infine, il flusso di lavoro controlla se il NmsProviderMsgId tabella esistente. In tal caso, tutti i dati obsoleti vengono eliminati utilizzando la seguente query:
DELETE FROM NmsProviderMsgId WHERE iBroadLogId IN (SELECT iBroadLogId FROM NmsProviderMsgId WHERE tsCreated < $(option) LIMIT 5000)
dove $(option)
corrisponde alla data definita per NmsCleanup_BroadLogPurgeDelay (fai riferimento a Procedura guidata di distribuzione).
Questa attività pulisce la NmsEmailErrorState tabella. Il programma principale (coalesceErrors) definisce due date:
Se la data di inizio è maggiore o uguale alla data di fine, non verrà eseguita alcuna procedura. In questo caso, il coalesceUpToDate viene visualizzato un messaggio.
Se la data di inizio è precedente alla data di fine, la NmsEmailErrorState il tavolo è pulito.
Numero totale di errori nel NmsEmailErrorState tra le date di inizio e di fine viene recuperata utilizzando la seguente query:
SELECT COUNT(*) FROM NmsEmailErrorStat WHERE tsDate>= $(start) AND tsDate< $(end)
dove $end
e $start
sono le date di inizio e di fine definite in precedenza.
Se il totale è maggiore di 0:
Viene eseguita la seguente query per mantenere solo gli errori oltre una determinata soglia (che è uguale a 20):
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
La coalescingErrors viene visualizzato il messaggio.
Viene creata una nuova connessione per eliminare tutti gli errori che si sono verificati tra le date di inizio e di fine. Viene utilizzata la seguente query:
DELETE FROM NmsEmailErrorStat WHERE tsDate>=$(start) AND tsDate<$(end)
Ogni errore viene salvato nel NmsEmailErrorState tabella utilizzando la seguente query:
INSERT INTO NmsEmailErrorStat(iMXIP, iPublicId, tsDate, iTotalConnections, iTotalErrors, iTimeoutConnections, iRefusedConnections, iAbortedConnections, iFailedConnections, iMessageErrors) VALUES($(lmxip ), $(lpublicId ), $(tsstart ), $(lconnections ), $(lconnectionErrors ),$(ltimeoutConnections ), $(lrefusedConnections ), $(labortedConnections ), $(lfailedConnections ), $(lmessageErrors))
dove ogni variabile corrisponde a un valore recuperato dalla query precedente.
La start viene aggiornata con i valori del processo precedente per completare il ciclo.
Il ciclo e l'attività si fermano.
Le operazioni di pulizia vengono eseguite in NmsEmailError e cleanupNmsMxDomain tabelle.
Viene utilizzata la seguente query:
DELETE FROM NmsEmailError WHERE iMXIP NOT IN (SELECT DISTINCT iMXIP FROM NmsEmailErrorStat)
Questa query elimina tutte le righe senza record collegati nel NmsEmailErrorState dal NmsEmailError tabella.
Viene utilizzata la seguente query:
DELETE FROM NmsMxDomain WHERE iMXIP NOT IN (SELECT DISTINCT iMXIP FROM NmsEmailErrorStat)
Questa query elimina tutte le righe senza un record collegato nel NmsEmailErrorState dalla tabella NmsMxDomain tabella.
Se la Interazione il modulo è installato, questa attività viene eseguita per eliminare il NmsPropositionXxx tabelle.
L'elenco delle tabelle delle proposte viene recuperato e l'eliminazione di massa viene eseguita su ognuna di esse, utilizzando la seguente query:
DELETE FROM NmsPropositionXxx WHERE iPropositionId IN (SELECT iPropositionId FROM NmsPropositionXxx WHERE tsLastModified < $(option) LIMIT 5000)
dove $(option)
è la data definita per NmsCleanup_PropositionPurgeDelay (fai riferimento a Procedura guidata di distribuzione).
Questa attività pulisce le tabelle di simulazione orfane (che non sono più collegate a una simulazione di offerta o a una simulazione di consegna).
Per recuperare l’elenco delle simulazioni che richiedono la pulizia, viene utilizzata la seguente query:
SELECT iSimulationId FROM NmsSimulation WHERE iSimulationId<>0
Il nome delle tabelle da eliminare è costituito dal wkSimu_ Prefisso seguito dall’identificatore della simulazione (ad esempio: wkSimu_456831_aggr):
DROP TABLE wkSimu_456831_aggr
Viene utilizzata la seguente query:
DELETE FROM XtkAudit WHERE tsChanged < $(tsDate)
dove $(tsDate) è la data corrente del server a partire dalla quale il periodo definito per XtkCleanup_AuditTrailPurgeDelay viene sottratta.
Viene utilizzata la seguente query:
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)
Questa query elimina tutte le voci relative ad iOS e Android.
La XtkCleanup_NoStats consente di controllare il comportamento della fase di ottimizzazione dello storage del flusso di lavoro di pulizia.
Se la XtkCleanup_NoStats l’opzione non esiste o, se il valore è 0, esegue l’ottimizzazione dello storage in modalità dettagliata (VACUUM VERBOSE ANALYZE) su PostgreSQL e aggiorna le statistiche su tutti gli altri database. Per verificare che questo comando sia eseguito, controlla i log PostgreSQL. VACUUM genera linee nel formato: INFO: vacuuming "public.nmsactivecontact"
e ANALYZE genera le linee nel formato: INFO: analyzing "public.nmsactivecontact"
.
Se il valore dell’opzione è 1, l’aggiornamento delle statistiche non viene eseguito su alcun database. Nei registri del flusso di lavoro viene visualizzata la seguente riga di registro: Option 'XtkCleanup_NoStats' is set to '1'
.
Se il valore dell’opzione è 2, questo eseguirà l’analisi dello storage in modalità dettagliata (ANALYZE VERBOSE) su PostgreSQL e aggiornerà le statistiche su tutti gli altri database. Per verificare che questo comando sia eseguito, controlla i log PostgreSQL. ANALYZE genera linee nel formato seguente: INFO: analyzing "public.nmsactivecontact"
.
Questa attività elimina tutti gli abbonamenti relativi ai servizi eliminati o alle applicazioni mobili.
Per recuperare l’elenco degli schemi di registro di trasmissione, viene utilizzata la seguente query:
SELECT distinct(sBroadLogSchema) FROM NmsDeliveryMapping WHERE sBroadLogSchema IS NOT NULL
L'attività recupera quindi i nomi delle tabelle collegate al appSubscription collega ed elimina queste tabelle.
Questo flusso di lavoro di pulizia elimina anche tutte le voci in cui idisabled = 1 che non sono state aggiornate dall'ora impostata nel NmsCleanup_AppSubscriptionRcpPurgeDelay opzione .
Questa attività elimina le informazioni dal sessionInfo tabella, viene utilizzata la seguente query:
DELETE FROM XtkSessionInfo WHERE tsexpiration < $(curdate)
Questa attività pulisce gli eventi ricevuti e memorizzati nelle istanze di esecuzione e gli eventi archiviati in un'istanza di controllo.
Questo compito pulisce le reazioni (tabella NmsRemaMatchRcp) in cui sono state soppresse le ipotesi.