Workflows voor campagnes die vastzitten als gevolg van tijdelijke bloei van tabellen
Dit artikel verklaart waarom de werkschema tijdelijke lijsten waar niet verwijderd uit het gegevensbestand, die tot algemene vertraging van het platform leiden.
Beschrijving description
Een hybride klant (de marketinginstantie op locatie) ondervond problemen waarbij de workflows van de campagne constant vastzaten als gevolg van buitensporig tijdelijk tabelgebruik, wat leidde tot een hoog databasegebruik en workflowonderbrekingen.
De technische workflow voor het opschonen van de database werd uitgevoerd, maar de tijdelijke tabellen worden niet op de juiste wijze verwijderd.
Resolutie resolution
Het uitvoeren van de opschoonworkflow in de uitgebreide modus gaf geen duidelijke oorzaak en er was O&O bij betrokken. De klant werd gevraagd om de volgende bevelen op hun psql- gegevensbestand (als gebruiker van de Pdd van de Campagne) in werking te stellen en de volledige output te delen:
-
Werkstroomstatus:
SELECTEER iWorkflowId, sInternalName, sLabel, iState FROM XtkWorkflow WHERE iWorkflowId IN (id1, id2, id3); -
Verbindingsschema / Zoekpad:
SELECT current_user, current_schema(), current_setting('search_path') AS search_path; -
Workflowwerktabellen per schema:
SELECTEER schemaname, COUNT AS table_count FROM pg_tables WHERE tablename ZOALS 'wkf%' GROUP BY schemaname ORDER BY table_count DESC;
Nadat de resultaten werden gedeeld werd het waargenomen dat de opstelling van het klantengegevensbestand een douaneschema 'XYZ' gebruikt dat van de gebruikersbenaming UserNameABC van het gegevensbestandlogin verschilde. Specifiek:
current_user = UserNameABC
current_schema() / search_path = XYZ
En alle tijdelijke workflowtabellen stonden in schema 'XYZ'.
In een standaardopstelling, verblijven alle lijsten in het openbare schema. Het db schoonmaakwerkschema maakt een lijst van lijsten om te laten vallen door op het schema te filtreren dat uit de naam van gegevensbestandlogin (d.w.z. UserNameABC) en openbaar wordt afgeleid. Aangezien de lijsten in "XYZ"schema waren, vond de schoonmaakbeurt nooit hen en verwierp daarom nooit om het even welke werkschematabellen.
Om dit te verhelpen, werd de klant gevraagd om de dbSchema attributen aan het < dbcnx > element in ServerConf.xml uit te geven
< dbcnx … dbSchema="XYZ" …>
Voer vervolgens de server/cache opnieuw in en voer de opschoonworkflow uit.