IT Process Automation

  • 1.  Query Database operator timeout execution action

    Posted Oct 05, 2018 09:05 AM

    Hi,

     

    I have a question about the Query database operator in PAM. 

    If we have a query running for a long time, having defined a timeout within the operator - with the execution action either as 'Abort' or 'Abandon', we still see the query active in the SQL processes within Activity Montor in SMSS.

     

    We don't want the SQL transaction/query to continue if we leave the Query Database operator - is 'Abort' the setting that should abort the query - which it by name indicates? We had 'Abandon' in our production environment on a SQL operator. It caused the query to continue after the timeout had occured and the only way of abort the query was to stop the PAM service on the server. We could not kill it in SMSS and neither could we find any operator active in the Operators list, but the process (containing more than just that Query Database operator) had continued and finished so the Query Database "ran by itself" somehow.

     

    Would like to know what you think about this.

    Thanks in advance!



  • 2.  Re: Query Database operator timeout execution action
    Best Answer

    Broadcom Employee
    Posted Oct 08, 2018 09:00 AM

    Robin,

    To begin with, the 'Timeout' actions are purely activities within the engine.  There is no functionality to stop whatever action the Operator is waiting on.    If an operator reaches a timeout designed into the process will execute any post execution code then take the timeout exit point if one has been set. 

     

    This is more likely an issue with your query itself that needs to be looked into.   If you run your query outside of Process Automation, how long does it run and does it complete?

    Within the Process, if you remove the timeout, does the query eventually complete?   How long does it take?

     

     

    The best practice for database queries is to ensure that your query is as focused as it can be.  You should not be querying for large result sets or doing any wildcard type general searches.     

     

     

     

    That being said, the database connection thread should not have been held open and should not have prevented killing the query at the database.    This could be a problem that we need to look into further if you would like to open a support ticket we can review.