TASM issues

Database
Enthusiast

TASM issues

Hi,

Query on TASM. If we configure a group to have a MAXIMUM CPU utilisation of 60 Seconds, we would expect the query to migrate over to the next group when it reaches 60 Seconds.

Why then do we see queries running and consuming more than 60 seconds (sometimes up to 1 hours worth of CPUTIME) before migrating. We can see this in viewpoint, looking in DBQL only show the startingbands and ending bancds.

This is causing serious confusion to our TASM rules here, and we don't want to increase the concurrency of the group to allow more in as queries have a tendancy to migrate up through the groups, due to bad optimiser guessing incorrectly placing the queries in the short running query groups when they actully turn out to be long running queries. Therefore we have legitimate short running queries being help up by queries that should not be there.

anyone else seen this?

Random
Tags (3)
3 REPLIES
Enthusiast

Re: TASM issues

Hi,

i have solved this issue. TASM will check each job at the end of each step, or at the delaytime setting set in the TASM manager. Ours was set high, and only checking every 10 minutes.

This meant that long running steps may run for 10 minutes unchecked consuming loads of CPU and blocking the queue for others.

Random
Enthusiast

Re: TASM issues

It takes some time to absorb TASM :-)
Teradata Employee

Re: TASM issues

In which version of TD are you ?
how many period have you defined ?
If you have serveral regulation periods, you must specify degradation rules of workloads for each period. I observe the same behavior of TASM in a V2R6.2 system and solve the problem by defining workload change rules for each period of time.