DBQL AMPCPUTime and TDWM Exception Abort


DBQL AMPCPUTime and TDWM Exception Abort

We are using TD 13.10

We have TDWM Exception to abort a session if the CPU consumed by the query is more than a threshold value.

In DBC.DBQLogTbl , the value of AMPCPUTime is very less than the threshold, while the value in  DBC.TDWMExceptionLog

for the session in Errortext column is above the threshold.

As a result , the session is getting aborted with Error 3156 Request aborted by TDWM. Exception criteria exceeded.

Can someone let me know the reason for difference in  result between the two.

Tags (1)

Re: DBQL AMPCPUTime and TDWM Exception Abort

In Teradata 13.10 (and as recent at TD 14) I believe the DBQL AMPCPUTime reported for queries that are aborted (TDWM exception or other errors) is typically what has been consumed prior to the step which the query aborted. For queries that abort during a series of parallel steps it may not include the CPU consumed by any of the parallel steps that completed prior to the query aborting. The value reported in the ErrorText often exceeds the threshold because the process that identifies exceptions and aborts offending queries ran after the query in question exceeded the threshold in TDWM/TASM.

If my memory serves correct the DBQL metrics should be improved in TD 15 or TD 15.10.

Re: DBQL AMPCPUTime and TDWM Exception Abort

Thanks Rob for the explaination:)

Re: DBQL AMPCPUTime and TDWM Exception Abort


I have a Prod like system where we are noticing too many exceptions on a specific user and many queries are getting aborted due to the exception defined on after N number CPU time (in ms). To let the concenr application team about the impact on the system, i have taken the data from TDWMExceptionLog and cocern date, and from ErrorText column how much of CPU wasted before that query aborted. And i ploted  a graph to shown them each day how much of CPU is wasted becuase of that user hitting exceptions. They are working on tuning those queries.

Here my question is, in SLES11 TASM is there anyother better solution on exception handling and analysis to see the impact in terms of the CPU wasted each time a query aborted due to an exception?