Workflow de limpeza do banco de dados

Introdução

O fluxo de trabalho Database cleanup acessível pelo nó Administration > Production > Technical workflows permite que você exclua dados obsoletos para evitar o crescimento exponencial do banco de dados. O workflow é acionado automaticamente sem a intervenção do usuário.

Configuração

A limpeza do banco de dados está configurada em dois níveis: no scheduler de fluxo de trabalho e no assistente de implantação.

Scheduler de fluxo de trabalho

Por padrão, o fluxo de trabalho Database cleanup é configurado para start diariamente às 4h00. O scheduler permite alterar a frequência de acionamento do fluxo de trabalho. As seguintes frequências estão disponíveis:

• Several times a day
• Daily
• Weekly
• Once

Assistente de implantação

O Deployment wizard, acessado pelo menu Tools > Advanced, permite que você configure por quanto tempo os dados são salvos. Os valores são expressos em dias. Se esses valores não forem alterados, o fluxo de trabalho usará os valores padrão.

Os campos da janela Purge of data coincidem com as seguintes opções. Eles são usados por algumas tarefas executadas pelo fluxo de trabalho Database cleanup:

• Rastreamento consolidado: NmsCleanup_TrackingStatPurgeDelay (consulte Limpeza de logs de rastreamento)

• Logs do delivery: NmsCleanup_BroadLogPurgeDelay (consulte Limpeza de logs do delivery)

• Logs de rastreamento: NmsCleanup_TrackingLogPurgeDelay (consulte Limpeza de logs de rastreamento)

• Delivery excluídos: NmsCleanup_RecycledDeliveryPurgeDelay (consulte Limpeza de delivery a serem excluídos ou reciclados)

• Importar rejeitos: NmsCleanup_RejectsPurgeDelay (consulte Limpeza de rejeitos gerados por importações)

• Perfis do visitante: NmsCleanup_VisitorPurgeDelay (consulte Limpeza de visitantes)

• Apresentações da oferta: NmsCleanup_PropositionPurgeDelay (consulte Limpeza de proposições)

  OBSERVAÇÃO

  O campo Offer propositions só está disponível quando o módulo Interação está instalado.

• Eventos: NmsCleanup_EventPurgeDelay (consulte eventos expirados de Limpeza)

• Eventos arquivados: NmsCleanup_EventHistoPurgeDelay (consulte eventos expirados de Limpeza)

  OBSERVAÇÃO

  Os campos Events e Archived events só estarão disponíveis se o módulo Centro de Mensagens estiver instalado.

• Trilha de auditoria: XtkCleanup_AuditTrailPurgeDelay (consulte Limpeza da trilha de auditoria)

Todas as tarefas executadas pelo fluxo de trabalho Database cleanup são descritas na seção a seguir.

Tarefas executadas pelo fluxo de trabalho de limpeza do Banco de Dados

Na data e hora definidas no scheduler do fluxo de trabalho (consulte O scheduler), o motor de workflow start o processo de limpeza do banco de dados. A limpeza do Banco de Dados se conecta ao banco de dados e executa as tarefas na sequência mostrada abaixo.

Listas para excluir a limpeza

A primeira tarefa executada pelo fluxo de trabalho Database cleanup exclui todos os grupos com o deleteStatus != 0 do atributo NmsGroup. Os registros ligados a esses grupos e que existem em outras tabelas também são excluídos.

1. As listas a serem excluídas são recuperadas usando o seguinte query SQL:

   SELECT iGroupId, sLabel, iType FROM NmsGroup WHERE iDeleteStatus <> 0 OR tsExpirationDate <= GetDate() 
   

2. Cada lista tem vários links para outras tabelas. Todos esses links são excluídos em massa usando o seguinte query:

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

   em que $(relatedTable) é uma tabela relacionada a NmsGroup e $(l) é o identificador da lista.

3. Quando a lista é do tipo "Lista", a tabela associada é excluída usando o seguinte query:

   DROP TABLE grp$(l)
   

4. Cada lista de tipo Select recuperada pela operação é excluída usando o seguinte query:

   DELETE FROM NmsGroup WHERE iGroupId=$(l) 
   

   em que $(l) é o identificador da lista

Limpeza de delivery a serem excluídos ou reciclados

Esta tarefa limpa todos os delivery a serem excluídos ou reciclados.

1. O fluxo de trabalho Database cleanup seleciona todos os delivery para os quais o campo deleteStatus tem o valor Yes ou Recycled e cuja data de exclusão é anterior ao período definido no campo Deleted deliveries (NmsCleanup_RecycledDeliveryPurgeDelay) do assistente de implantação. Para obter mais informações, consulte Assistente de implantação. Esse período é calculado em relação à data atual do servidor.

2. Para cada servidor mid-sourcing, a tarefa seleciona a lista de delivery a serem excluídos.

3. O fluxo de trabalho Database cleanup exclui logs do delivery, anexos, informações sobre mirrores page e todos os outros dados relacionados.

4. Antes de excluir o delivery para boas, o fluxo de trabalho remove as informações vinculadas das seguintes tabelas:

   • Na tabela de exclusão de delivery (NmsDlvExclusion), é usado o seguinte query:

     DELETE FROM NmsDlvExclusion WHERE iDeliveryId=$(l)
     

     em que $(l) é o identificador do delivery.

   • Na tabela de cupom (NmsCouponValue), é usado o seguinte query (com exclusões em 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)
     

     em que $(l) é o identificador do delivery.

   • Nas tabelas de log de delivery (NmsBroadlogXxx), as exclusões em massa são executadas em lotes de 20.000 registros.

   • Nas tabelas de apresentação da oferta (NmsPropositionXxx), as exclusões em massa são executadas em lotes de 20.000 registros.

   • Nas tabelas de log de rastreamento (NmsTrackinglogXxx), as exclusões em massa são executadas em lotes de 20.000 registros.

   • Na tabela de fragmentos do delivery (NmsDeliveryPart), as exclusões em massa são executadas em lotes de 500.000 registros. Esta tabela contém informações de personalização sobre as mensagens restantes a serem entregues.

   • Na tabela do fragmento de dados do mirror page (NmsMirrorPageInfo), as exclusões em massa são executadas em lotes de 20.000 registros para partes do delivery expiradas e para partes concluídas ou canceladas. Esta tabela contém informações de personalização sobre todas as mensagens usadas para gerar mirrores page.

   • Na tabela de pesquisa de mirrores page (NmsMirrorPageSearch), as exclusões em massa são executadas em lotes de 20.000 registros. Esta tabela é um índice de pesquisa que fornece acesso às informações de personalização armazenadas na tabela NmsMirrorPageInfo.

   • Na tabela de log do processo em lote (XtkJobLog), as exclusões em massa são executadas em lotes de 20.000 registros. Esta tabela contém o log de delivery a serem excluídos.

   • Na tabela de rastreamento de URL do delivery (NmsTrackingUrl), o seguinte query é usado:

     DELETE FROM NmsTrackingUrl WHERE iDeliveryId=$(l)
     

     em que $(l) é o identificador do delivery.

     Esta tabela contém os URLs encontrados nos delivery a serem excluídos para permitir seu rastreamento.

5. O delivery é excluído da tabela delivery (NmsDelivery):

   DELETE FROM NmsDelivery WHERE iDeliveryId = $(l)
   

   em que $(l) é o identificador do delivery.

Delivery usando mid-sourcing

O fluxo de trabalho Database cleanup também exclui delivery nos servidores mid-sourcing.

1. Para fazer isso, o fluxo de trabalho verifica se cada delivery está inativo (com base em seu status). Se um delivery estiver ativo, ele será interrompido antes de ser excluído. A verificação é realizada executando o seguinte query:

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

   em que $(l) é o identificador do delivery.

2. Se o valor do status for Start pending, In progress, Recovery pending, Recovery in progress, Pause requested, Pause in progress ou Paused (valores 51, 55, 61, 62, 71, 72, 75), o delivery será parado e a tarefa limpará as informações vinculadas.

Limpeza de delivery expirados

Esta tarefa interrompe delivery cujo período de validade expirou.

1. O fluxo de trabalho Database cleanup cria a lista de delivery que expiraram. Esta lista inclui todos os delivery expirados com um status diferente de Finished, bem como delivery recém-parados com mais de 10.000 mensagens não processadas. O query a seguir é usado:

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

   em que modo de delivery 1 corresponde ao modo Mass delivery, state 51 corresponde ao estado Start pending, state 85 corresponde ao estado Stopped e o maior número de logs do delivery atualizados em massa no servidor delivery é igual a 10.000.

2. O fluxo de trabalho então inclui a lista de delivery expirados recentemente que usam mid-sourcing. Os delivery para os quais nenhum logs do delivery foi recuperado por meio do servidor mid-sourcing são excluídos.

   O query a seguir é usado:

   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. O query a seguir é usado para detectar se a conta externa ainda está ativa ou não, para filtrar delivery por data:

   SELECT iExtAccountId FROM NmsExtAccount WHERE iActive<>0 AND sName=$(providerName)
   

4. Na lista de delivery expirados, logs do delivery cujo status é Pending, alterne para Delivery cancelled e todos os delivery nessa lista alternam para Finished.

   Os seguintes query são usados:

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

   em que $(curdate) é a data atual do servidor de banco de dados, $(bl) é o identificador da mensagem de logs do delivery, $(dl) é o identificador do delivery, o status do delivery 6 corresponde ao status Pending e delivery o status 7 corresponde ao status Delivery cancelled.

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

   em que estado do delivery 95 corresponde ao status Finished, e $(dl) é o identificador do delivery.

5. Todos os fragmentos (deliveryParts) de delivery obsoletos são excluídos e todos os fragmentos obsoletos de delivery de notificação em andamento são excluídos. A exclusão em massa é usada para ambas as tarefas.

   Os seguintes query são usados:

   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)
   

   em que estado do delivery 95 corresponde ao status Finished, estado do delivery 85 corresponde ao status Stopped e $(curDate) é a data atual do servidor.

Limpeza de mirrores page

Essa tarefa exclui os recursos da Web (mirrores page) usados pelos delivery.

1. Em primeiro lugar, a lista de delivery a serem expurgados é recuperada usando o seguinte query:

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

   em que $(curDate) é a data atual do servidor.

2. A tabela NmsMirrorPageInfo é então limpa, se necessário usando o identificador do delivery recuperado anteriormente. A exclusão em massa é usada para gerar os seguintes query:

   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)
   

   em que $(dl) é o identificador do delivery.

3. Uma entrada é então adicionada ao log de delivery.

4. Os delivery expurgados são então identificados, para evitar a necessidade de reprocessá-los mais tarde. O seguinte query é executado:

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

   em que $(strIn) é a lista de identificadores de delivery.

Limpeza de tabelas de trabalho

Essa tarefa exclui do banco de dados todas as tabelas de trabalho que correspondem a delivery cujo status é Being edited, Stopped ou Deleted.

1. A lista de tabelas com nomes começando com wkDlv_ é recuperada primeiro com o seguinte 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'
   

2. As tabelas usadas por workflows em andamento são excluídas. Para fazer isso, a lista de delivery em andamento é recuperada usando o seguinte query:

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

   onde 0 é o valor que corresponde ao status Being edited do delivery, 85 corresponde ao status Stopped e 100 corresponde ao status Deleted.

3. As tabelas que não forem mais usadas serão excluídas usando o seguinte query:

   DROP TABLE wkDlv_15487_1;
   

Limpeza de rejeitos gerados pelas importações

Esta etapa permite excluir registros para os quais todos os dados não foram processados durante a importação.

1. A exclusão em massa é realizada na tabela XtkReject com o seguinte query:

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

   em que $(curDate) é a data do servidor atual a partir da qual subtrairmos o período definido para a opção NmsCleanup_RejectsPurgeDelay (consulte Assistente de implantação) e $(l) é o número máximo de registros a eliminar em massa …

2. Todos os rejeitos órfãos são depois excluídos usando o seguinte query:

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

Limpeza de instâncias de fluxo de trabalho

Esta tarefa limpa cada instância do fluxo de trabalho usando seu identificador (lWorkflowId) e histórico (lHistory). Ele exclui tabelas inativas executando a tarefa de limpeza da mesa de trabalho novamente. A limpeza também exclui todas as tabelas de trabalho órfãs (wkf% e wkfhisto%) de workflows excluídos.

1. Para recuperar a lista de workflows a serem excluídos, é usado o seguinte query:

   SELECT iWorkflowId, iHistory FROM XtkWorkflow WHERE iWorkflowId<>0
   

2. Este query gera a lista de workflows que serão usados para excluir todos os registros vinculados, tarefas concluídas e eventos concluídos, usando os seguintes query:

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

   onde $(lworkflow) é o identificador do fluxo de trabalho e $(lhistory) é o identificador do histórico.

3. Todas as tabelas não usadas são excluídas. Para essa finalidade, todas as tabelas são coletadas graças a uma máscara de tipo wkf% usando o seguinte 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'
   

4. Em seguida, todas as tabelas usadas por uma instância de fluxo de trabalho pendente são excluídas. A lista de workflows ativos é recuperada usando o seguinte query:

   SELECT iWorkflowId FROM XtkWorkflow WHERE iWorkflowId<>0 AND iState<>20
   

5. Cada identificador de fluxo de trabalho é recuperado para localizar o nome das tabelas usadas pelos workflows em andamento. Esses nomes são excluídos da lista de tabelas recuperadas anteriormente.

6. As tabelas de histórico de atividades do tipo "query incremental" são excluídas usando os seguintes 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))
   

   em que $(strcondition) é a lista de tabelas que correspondem à máscara wkfhisto%.

7. As tabelas restantes são excluídas usando o seguinte query:

   DROP TABLE wkf15487_12;
   

Limpeza de logons de fluxo de trabalho

Esta tarefa exclui os logons do fluxo de trabalho usando o seguinte query:

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

Limpeza de tabelas de trabalho órfãs

Esta tarefa exclui tabelas de trabalho órfãs vinculadas a grupos. A tabela NmsGroup armazena os grupos a serem limpos (com um tipo diferente de 0). O prefixo dos nomes das tabelas é grp. Para identificar os grupos a serem limpos, é usado o seguinte query:

SELECT iGroupId FROM NmsGroup WHERE iType>0"

Limpeza de visitantes

Esta tarefa exclui registros obsoletos da tabela de visitantes usando a exclusão em massa. Os registros obsoletos são aqueles para os quais a última modificação é anterior ao período de conservação definido no assistente de implantação (consulte Assistente de implantação). O query a seguir é usado:

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

em que $(tsDate) é a data atual do servidor, a partir da qual subtraímos o período definido para a opção NmsCleanup_VisitorPurgeDelay.

Limpeza de NPAI

Esta tarefa permite que você exclua registros que correspondem a endereços válidos da tabela NmsAddress. O query a seguir é usado para executar a exclusão em massa:

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

em que status 2 corresponde ao status Valid, $(tsDate1) é a data atual do servidor e $(tsDate2) corresponde à opção NmsCleanup_LastCleanup.

Limpeza do subscrição

Esta tarefa limpa todas as subscrições excluídas pelo usuário da tabela NmsSubscription, usando exclusão em massa. O query a seguir é usado:

DELETE FROM NmsSubscription WHERE iDeleteStatus <>0

Limpeza de logs de rastreamento

Esta tarefa exclui registros obsoletos das tabelas de log de rastreamento e de rastreamento da Web. Os registros obsoletos são os anteriores ao período de conservação definido no assistente de implantação (consulte Assistente de implantação).

1. Primeiro, a lista das tabelas de log de rastreamento é recuperada usando o seguinte query:

   SELECT distinct(sTrackingLogSchema) FROM NmsDeliveryMapping WHERE sTrackingLogSchema IS NOT NULL;
   

2. A exclusão em massa é usada para expurgar todas as tabelas na lista de tabelas recuperadas anteriormente. O query a seguir é usado:

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

   em que $(tsDate) é a data atual do servidor a partir da qual subtraímos o período definido para a opção NmsCleanup_TrackingLogPurgeDelay.

3. A tabela de estatísticas de rastreamento é limpa usando a exclusão em massa. O query a seguir é usado:

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

   em que $(tsDate) é a data atual do servidor a partir da qual subtraímos o período definido para a opção NmsCleanup_TrackingStatPurgeDelay.

Limpeza de logs do delivery

Essa tarefa permite que você expurgue os logs do delivery armazenados em várias tabelas.

1. Para essa finalidade, a lista dos schemas de log de delivery é recuperada usando o seguinte query:

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

2. Ao usar o mid-sourcing, a tabela NmsBroadLogMid não é referenciada nos mapeamentos de delivery. O schema nms:wideLogMid é adicionado à lista recuperada pelo query anterior.

3. O fluxo de trabalho Limpeza do banco de dados elimina dados obsoletos de tabelas anteriormente recuperadas. O query a seguir é usado:

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

   em que $(tableName) é o nome de cada tabela na lista de schemas, e $(option) é a data definida para a opção NmsCleanup_BroadLogPurgeDelay (consulte Assistente de implantação).

4. Finalmente, o fluxo de trabalho verifica se a tabela NmsProviderMsgId existe. Em caso afirmativo, todos os dados obsoletos serão excluídos usando o seguinte query:

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

   em que $(opção) corresponde à data definida para a opção NmsCleanup_BroadLogPurgeDelay (consulte Assistente de implantação).

Limpeza da tabela NmsEmailErrorStat

Esta tarefa limpa a tabela NmsEmailErrorStat. O programa principal (coalesceErrors) define duas datas:

• Data do start: data do próximo processo que corresponde à opção ​​NmsLastErrorStatCoalesceoption ou a data mais recente na tabela.
• Data de término: data atual do servidor.

Se a data de start for maior ou igual à data de término, nenhum processo ocorrerá. Nesse caso, a mensagem coalesceUpToDate é exibida.

Se a data do start for anterior à data de término, a tabela NmsEmailErrorStat será limpa.

O número total de erros na tabela NmsEmailErrorStat, entre as datas do start e final, é recuperado usando o seguinte query:

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

em que $end e $start são as datas de start e término definidas anteriormente.

Se o total for maior que 0:

1. O query a seguir é executado para manter somente erros além de um determinado limite (que é igual 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"
   

2. A mensagem coalescingErrors é exibida.

3. Uma nova conexão é criada para excluir todos os erros que ocorreram entre as datas de start e término. O query a seguir é usado:

   "DELETE FROM NmsEmailErrorStat WHERE tsDate>=$(start) AND tsDate<$(end)"
   

4. Cada erro é salvo na tabela NmsEmailErrorStat usando o seguinte 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))"
   

   em que cada variável corresponde a um valor recuperado pelo query anterior.

5. A variável start é atualizada com os valores do processo anterior para concluir o loop.

O ciclo e a tarefa param.

As limpas são executadas nas tabelas NmsEmailError e cleanupNmsMxDomain.

Limpeza da tabela NmsEmailError

O query a seguir é usado:

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

Este query exclui todas as linhas sem registros vinculados na tabela NmsEmailErrorStat da NmsEmailError.

Limpeza da tabela NmsMxDomain

O query a seguir é usado:

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

Este query exclui todas as linhas sem um registro vinculado na tabela NmsEmailErrorStat da tabela NmsMxDomain.

Limpeza de proposições

Se o módulo Interaction estiver instalado, esta tarefa será executada para expurgar as tabelas NmsPropositionXxx.

A lista das tabelas de proposições é recuperada e a exclusão em massa é realizada em cada uma delas, usando o seguinte query:

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

em que $(opção) é a data definida para a opção NmsCleanup_PropositionPurgeDelay (consulte Assistente de implantação).

Limpeza de tabelas de simulação

Esta tarefa limpa tabelas de simulação órfãs (que não estão mais vinculadas a uma simulação de oferta ou a uma simulação de delivery).

1. Para recuperar a lista das simulações que exigem limpeza, é usado o seguinte query:

   SELECT iSimulationId FROM NmsSimulation WHERE iSimulationId<>0
   

2. O nome das tabelas a serem excluídas é composto pelo prefixo wkSimu_ seguido pelo identificador da simulação (por exemplo: wkSimu_456831_aggr):

   DROP TABLE wkSimu_456831_aggr
   

Limpeza da trilha de auditoria

O query a seguir é usado:

DELETE FROM XtkAudit WHERE tsChanged < $(tsDate)

em que $(tsDate) é a data do servidor atual a partir da qual o período definido para a opção XtkCleanup_AuditTrailPurgeDelay é substracto.

Limpeza de Nmsaddress

O query a seguir é usado:

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)

Este query exclui todas as entradas relacionadas ao iOS e Android.

Atualização de estatísticas e otimização de armazenamentos

A opção XtkCleanup_NoStats permite controlar o comportamento da etapa de otimização do armazenamento do fluxo de trabalho de limpeza.

Se a opção XtkCleanup_NoStats não existir ou se seu valor for 0, isso executará a otimização do armazenamento no modo detalhado (VACUUM VERBOSE ANALYZE) no PostgreSQL e atualizará as estatísticas em todos os outros bancos de dados. Para verificar se esse comando é executado, verifique os logs do PostgreSQL. O VACUUM emitirá linhas no formato: INFO: vacuuming "public.nmsactivecontact" e o ANALYZE produzirão linhas no formato: INFO: analyzing "public.nmsactivecontact".

Se o valor da opção for 1, a atualização de estatísticas não será executada em nenhum banco de dados. A seguinte linha de log será exibida nos logs do fluxo de trabalho: Option 'XtkCleanup_NoStats' is set to '1'.

Se o valor da opção for 2, isso executará a análise do armazenamento no modo detalhado (ANALYZE VERBOSE) no PostgreSQL e atualizará as estatísticas em todos os outros bancos de dados. Para verificar se esse comando é executado, verifique os logs do PostgreSQL. O ANALYZE emitirá linhas no formato: INFO: analyzing "public.nmsactivecontact".

Limpeza de subscrição (NMAC)

Esta tarefa exclui quaisquer subscrições relacionadas a serviços ou aplicativos móveis excluídos.

Para recuperar a lista de schemas de catálogo, é usado o seguinte query:

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

Em seguida, a tarefa recupera os nomes das tabelas vinculadas ao link appSubscription e exclui essas tabelas.

Este fluxo de trabalho de limpeza também exclui todas as entradas em que idisabled = 1 que não foram atualizadas desde a hora definida na opção NmsCleanup_AppSubscriptionRcpPurgeDelay.

Informações da sessão de limpeza

Essa tarefa limpa as informações da tabela sessionInfo, o seguinte query é usado:

 DELETE FROM XtkSessionInfo WHERE tsexpiration < $(curdate) 

Limpeza de eventos expirados

Essa tarefa limpa os eventos recebidos e armazenados nas instâncias de execução e os eventos arquivados em uma instância de controle.

Reações limpezas

Essa tarefa limpa as reações (tabela NmsRemaMatchRcp) nas quais as hipóteses foram excluídas.