Workflows de campagne bloqués en raison de la surcharge de la table temporaire
Cet article explique pourquoi les tables temporaires de workflow n'ont pas été supprimées de la base de données, ce qui a entraîné un ralentissement global de la plateforme.
Description description
Un client hybride (l’instance marketing on-premise) rencontrait des problèmes en raison desquels ses workflows Campaign étaient systématiquement bloqués en raison d’une utilisation excessive des tables temporaires, ce qui entraînait une utilisation élevée de la base de données et des interruptions des workflows.
Le workflow technique de nettoyage de la base de données était en cours d'exécution, mais les tables temporaires n'ont pas été supprimées normalement.
Résolution resolution
L’exécution du workflow de nettoyage en mode verbeux n’a pas fourni de cause première claire et la recherche et le développement ont été impliqués. Le client a été invité à exécuter les commandes suivantes sur sa base de données psql (en tant qu’utilisateur de la base de données Campaign) et à partager la sortie complète :
-
État du workflow :
SELECT iWorkflowId, sInternalName, sLabel, iState FROM XtkWorkflow WHERE iWorkflowId IN (id1, id2, id3); -
Schéma de connexion / chemin_recherche :
SELECT current_user, current_schema(), current_setting('search_path') AS search_path ; -
Tables de travail de workflow par schéma :
SELECT schemaname, COUNT AS table_count FROM pg_tables WHERE tablename LIKE 'wkf%' GROUP BY schemaname ORDER BY table_count DESC ;
Une fois les résultats partagés, il a été observé que la configuration de la base de données client utilise un schéma personnalisé « XYZ » différent du nom d'utilisateur de connexion à la base de données UserNameABC. Plus précisément :
current_user = UserNameABC
current_schema() / search_path = XYZ
Et toutes les tables temporaires du workflow se trouvaient dans le schéma « XYZ ».
Dans une configuration standard, toutes les tables résident dans le schéma public. Le workflow de nettoyage de la base de données répertorie les tables à déposer en filtrant sur le schéma dérivé du nom d'utilisateur (c'est-à-dire UserNameABC) et public de la base de données. Comme les tables se trouvaient dans le schéma « XYZ », le nettoyage ne les a jamais trouvées et n’a donc jamais supprimé aucune table de workflow.
Pour corriger ce problème, il a été demandé au client de modifier l'attribut dbSchema dans l'élément < dbcnx> du fichier ServerConf.xml
< dbcnx … dbSchema=« XYZ » …>
Exécutez ensuite le redémarrage de nlserver/apache, puis le workflow de nettoyage.