Strange behaviour of TD Workload Managment after upgrading to 16.10

Database
Enthusiast

Strange behaviour of TD Workload Managment after upgrading to 16.10

We are having strange behaviour of TD Workload Managment after upgrading to 16.10, in particular with relation to requests having an unassigned (or null) workload.

 

Analysis has shown that 36% of all queries (after the introduction of TD16.10) now have an unassigned or null workload name. Prior to the upgrade only 0.61% of all queries had an unassigned or null workload name.

 

Has anyone been aware of this strange behaviour of TD Workload Managment?

 

Really appreciate your input.

 

Regards,

Vianh

 

 

2 REPLIES
Highlighted
Teradata Employee

Re: Strange behaviour of TD Workload Managment after upgrading to 16.10

Do the requests have a valid WDID?

It may be a reporting issue with finding a corresponding WDNAME, rather than a workload management issue.

Enthusiast

Re: Strange behaviour of TD Workload Managment after upgrading to 16.10

Hi Fred,

I really appreciate your quick response.

I was trying to run some queries to answer your question.

Here is what I have found

- Before the upgrade: I ran the query for a month of February

sel wdname, wdid, username, count(*)
from pdcrdata.dbqlogtbl_hst_v1500
where  (starttime) (date) between  '2018-02-01' and '2018-02-28'
and wdname is null
group by 1,2,3
;

The result set is only 11 rows. Yes, the WDID from the result set is invalid.

After the upgrade: I ran the query for a month of March since the completion of the upgrade.

sel wdname, wdid, username, count(*)
from dbc.dbqlogtbl
where  (starttime) (date) between  '2018-03-11' and '2018-03-31'
and wdname is null
group by 1,2,3
;

The result set returned a lot of rows having wdid is null and wdname is null.

I am puzzled about this. Do you have any ideas what may cause this issue?

In the meantime, I am still trying to understand the issue by looking into relevant documents.

Thanks and Regards, Vianh