A lista de tabelas a serem mantidas depende da versão do Adobe Campaign, da forma como você a usa e da configuração do modelo de dados.
A lista a seguir contém apenas as tabelas mais sujeitas a fragmentação. Os impactos são os seguintes:
Nome da tabela |
Tamanho |
Tipo principal de atividade |
Comentários |
---|---|---|---|
NmsDelivery |
Pequeno |
Atualizações |
Há um registro por ação de delivery. Um único registro pode ser atualizado várias vezes para refletir o progresso do delivery, de modo que os índices nesta tabela tendem a fragmentar rapidamente. |
NmsDeliveryPart |
Médio |
Inserções, atualizações, exclusões |
Tabela de trabalho na qual os registros são inseridos durante a preparação do delivery. Eles são atualizados durante o delivery e finalmente excluídos após a conclusão do delivery. Essa tabela tende a fragmentar rapidamente, mesmo que seu tamanho médio seja bastante limitado. |
NmsMirrorPageInfo |
Grande |
Inserções, exclusões |
Essa tabela contém as informações necessárias para gerar mirror pages personalizadas. Ele contém um campo de memorando (CLOB) e, como tal, tenderá a ser muito grande. O volume é diretamente proporcional ao histórico de mirror pages mantidas. |
NmsDeliveryStat |
Médio |
Inserções, atualizações, exclusões |
Esta tabela contém estatísticas sobre o processo de delivery. Seus registros são atualizados regularmente. |
NmsAddress |
Médio |
Atualizações, inserções |
Esta tabela contém informações sobre endereços de email. Ele é frequentemente atualizado como parte do processo de quarentena (os registros são criados no primeiro erro de delivery, atualizados quando os contadores são alterados e excluídos assim que o delivery é bem-sucedido). |
XtkWorkflow |
Pequeno |
Atualizações |
Há um registro por instância de workflow, portanto, poucos registros. No entanto, o quadro é atualizado regularmente para refletir o status e o progresso. |
XtkWorkflowTask |
Pequeno |
Inserções, atualizações, exclusões |
Cada execução de uma atividade de workflow leva à criação de um registro nesta tabela. O mecanismo de limpeza os exclui depois que expiram. |
XtkWorkflowEvent |
Pequeno |
Inserções, atualizações, exclusões |
Cada transição ativada entre tarefas em um workflow leva à criação de um registro nesta tabela. O mecanismo de limpeza os exclui depois que expiram. |
XtkWorkflowJob |
Muito pequeno |
Inserções, atualizações, exclusões |
Essa tabela é específica do mecanismo de workflow. Ele permite o envio de comandos para workflows (Start, Stop, Pause, por exemplo). Embora seja pequena, essa tabela é considerada durante a limpeza de tabelas transacionais vinculadas a workflows. |
NmsBroadLog |
Maior |
Inserções, atualizações, exclusões |
Esta é a maior mesa do sistema. Há um registro por mensagem enviada, e esses registros são inseridos, atualizados para rastrear o status do delivery e excluídos quando o histórico é removido. |
NmsTrackingLog |
Grande |
Inserções, exclusões |
Os logs de rastreamento são inseridos e excluídos quando o histórico é removido, mas não são atualizados. |
NmsBroadlogMsg |
Pequeno |
Atualizações |
Esta tabela contém informações usadas para qualificar erros SMTP. Ele é relativamente pequeno, mas será atualizado em grande escala, portanto, os índices nesta tabela tendem a fragmentar rapidamente. |
NmsEmailErrorStat |
Médio |
Inserções, atualizações, exclusões |
Esta tabela contém os agregados em erros SMTP classificados por domínio. Ele contém inicialmente informações detalhadas que são agregadas pela tarefa de limpeza quando ela se torna desatualizada. |
NmsBroadLogMid (em uma instância mid-sourcing) |
Grande |
Inserções, atualizações, exclusões |
Somente quando a instância 5.10 (ou posterior) é usada como uma instância de mid-sourcing. Esta é uma das maiores tabelas no banco de dados. Há um registro por mensagem enviada, e esses registros são inseridos, atualizados para rastrear o status do delivery e excluídos quando o histórico é removido. Ao usar o mid-sourcing, a recomendação é limitar o histórico (geralmente menos de dois meses), de modo que essa tabela permanece razoável em termos de tamanho (menos de 30 milhões de linhas, data+index), mas é muito importante recriá-la ocasionalmente. |
NmsBroadLogRcp (quando a tabela NmsRecipient é usada) |
Grande |
Inserções, atualizações, exclusões |
Esta é a maior mesa do sistema. Há um registro por mensagem enviada, e esses registros são inseridos, atualizados para rastrear o status do delivery e excluídos quando o histórico é removido. Observe que na versão 5.10, essa tabela é menor que o equivalente na 4.05 (NmsBroadLog), pois o texto da mensagem SMTP é fatorado na tabela NmsBroadLogMsg na versão 5.10. No entanto, continua sendo essencial reindexar essa tabela regularmente (a cada duas semanas para começar) e recriá-la completamente de tempos em tempos (uma vez por mês ou quando o desempenho é afetado). |
YyBroadLogXxx (quando uma tabela de recipient externo é usada) |
Grande |
Inserções, atualizações, exclusões |
Igual a NmsBroadLogRcp, mas com uma tabela de recipient externa. Adapte Yy e Xxx com os valores no mapeamento do delivery. |
NmsTrackingLogRcp (quando a tabela NmsRecipient é usada) |
Grande |
Inserções, exclusões |
Os logs de rastreamento são inseridos e excluídos quando o histórico é removido, mas não são atualizados. O volume depende da duração da retenção de dados. |
YyTrackingLogXxx (quando a tabela de recipient externo é usada) |
Grande |
Inserções, exclusões |
Igual a NmsTrackingLogRcp, mas com uma tabela de recipient externa. Adapte Yy e Xxx com os valores usados no mapeamento do delivery. |
NmsBroadLogRtEvent (instância de execução do Centro de Mensagens) |
Grande |
Inserções, atualizações, exclusões |
Semelhante às outras tabelas de broadlog, mas com o NmsRtEvent em vez de NmsRecipient. |
NmsTrackingLogRtEvent( Instância de execução do Centro de Mensagens) |
Grande |
Inserções, exclusões |
Semelhante às outras tabelas trackingLog, mas com a tabela NmsRtEvent em vez de NmsRecipient. |
NmsRtEvent (instância de execução do Centro de Mensagens) |
Grande |
Inserções, atualizações, exclusões |
Tabela que contém a fila de eventos do Centro de mensagens. O status desses eventos é atualizado pelo Centro de Mensagens à medida que são processados. As exclusões são realizadas durante a limpeza. Recomendamos que você recrie regularmente o índice desta tabela e recrie-o. |
NmsEventHisto (instância de controle do Centro de Mensagens) |
Grande |
Inserções, atualizações, exclusões |
Semelhante a NmsRtEvent. Esta tabela arquiva cada evento de todas as instâncias de execução. Ele é usado por um processo em tempo real, apenas por relatórios. |
NmsMobileApp |
Muito pequeno |
Inserções, atualizações, exclusões |
Tabelas que incluem aplicativos móveis e sua configuração. |
NmsAppSubscriptionRcp |
Grande |
Inserções, atualizações |
Tabela que inclui os identificadores de dispositivos móveis (endereços) usados para enviar a notificação (semelhante a uma tabela de recipients). |
NmsBroadLogAppSubRcp |
Grande |
Inserções, atualizações, exclusões |
Semelhante às outras tabelas de broadlog, mas com o NmsappSubscriptionRcp em vez de NmsRecipient. |
NmsTrackingLogAppSubRcp |
Grande |
Inserções, exclusões |
Semelhante às outras tabelas trackingLog, mas com a tabela NmsappSubscriptionRcp em vez de NmsRecipient. |
XtkSessionInfo |
Pequeno |
Inserções, exclusões |
Tabela que inclui sessões do usuário. O número de inserções e exclusões é muito importante. |
Além da lista acima, as tabelas que contêm os criados pelos clientes (que não existem no modelo de dados do Adobe Campaign) durante a configuração da plataforma também podem estar sujeitas a fragmentação, especialmente se forem atualizadas com frequência durante os procedimentos de carregamento ou sincronização de dados. Essas tabelas podem fazer parte do modelo de dados padrão do Adobe Campaign (por exemplo, NmsRecipient). Nesse caso, cabe ao administrador da plataforma Adobe Campaign realizar uma auditoria do modelo específico de banco de dados para localizar essas tabelas personalizadas. Essas tabelas não são necessariamente mencionadas explicitamente em nossos procedimentos de manutenção.