Throttle automatic runstats

[Norm]

If RUNSTATS is called directly, we can specify UTIL_IMPACT_PRI ORITY to
limit CPU consumption. For automatic runstats, there is no place to
specify this paramater. Will it use the DBM value of UTIL_IMPACT_LIM ?
Thanks in advance,
Norm

[Ian]

Norm wrote:

If RUNSTATS is called directly, we can specify UTIL_IMPACT_PRI ORITY to
limit CPU consumption. For automatic runstats, there is no place to
specify this paramater. Will it use the DBM value of UTIL_IMPACT_LIM ?

Norm,

With automatic stats, DB2 executes RUNSTATS in throttled mode, so it
will respect UTIL_IMPACT_LIM .

UTIL_IMPACT_PRI ORTY is there to assign relative priority when there
are multiple throttled utilities executing at the same time. The
default priority is 50. (i.e. if you just use UTIL_IMPACT_PRI ORITY
with no value to just turn throttling on).

Are you frequently executing mutiple utilities at the same time,
such that you need to control their relative priorities?

[Norm]

On May 19, 6:15 pm, Ian <ianb...@mobile audio.comwrote:

Norm wrote:

If RUNSTATS is called directly, we can specify UTIL_IMPACT_PRI ORITY to
limit CPU consumption. For automatic runstats, there is no place to
specify this paramater. Will it use the DBM value of UTIL_IMPACT_LIM ?

Norm,

With automatic stats, DB2 executes RUNSTATS in throttled mode, so it
will respect UTIL_IMPACT_LIM .

UTIL_IMPACT_PRI ORTY is there to assign relative priority when there
are multiple throttled utilities executing at the same time. The
default priority is 50. (i.e. if you just use UTIL_IMPACT_PRI ORITY
with no value to just turn throttling on).

Are you frequently executing mutiple utilities at the same time,
such that you need to control their relative priorities?

My misunderstandin g, I thought the
PRIORITY = UNTHROTTLED
in LIST UTILITIES was the current limit of CPU% a particular utility
was allowed. I had been expecting to see the value of UTIL_IMPACT_LIM
(50). Perhaps a "Max allowed CPU%" field would be useful.

The CPU was at 100% and a DB2 LIST UTILITIES showed a single automatic
runstats executing. There was a single table where SAP had done
massive deletes during an SAP Client delete. There were only 12 rows
left, but scattered across the tablespace. Selects against the table
were taking hours of time as asynchronous delete cleanup was going
on. A reorg of the table has resolved the issue.

Thanks for responding.

[Pierre StJ]

Here's the way this should work.
UTIL_IMPACT_LIM IT is a dbm parm. and controlsthe total amount of
resources one or many concurrent utilities may consume.
UTIL_IMPACT_PRI ORITY is a utility command parm. It is enforced only if
two or more utilities are running in the same db.
For RUNSTATS, if the command is automated, it means DB2 will determine
when it will run the other parms., of which UTIL_IMPACT_PRI ORITY is a
part, can be fixed by first storing the command in the
SYASIBM.SYSTABL ES col. for that TABNAME.
This is done using the PROFILE option when running the RUNSTATS
command.
From then on, DB2 should use that priority value whenever that command
is kaunched concurrently with anotherutility.
Note that other utilitues should have their priority set also.
Regards, Pierre.

>

Norm wrote:

If RUNSTATS is called directly, we can specify UTIL_IMPACT_PRI ORITY to
limit CPU consumption. *For automatic runstats, there is no place to
specify this paramater. *Will it use the DBM value of UTIL_IMPACT_LIM ?

Norm,

With automatic stats, DB2 executes RUNSTATS in throttled mode, so it
will respect UTIL_IMPACT_LIM .

UTIL_IMPACT_PRI ORTY is there to assign relative priority when there
are multiple throttled utilities executing at the same time. *The
default priority is 50. *(i.e. if you just use UTIL_IMPACT_PRI ORITY
with no value to just turn throttling on).

Are you frequently executing mutiple utilities at the same time,
such that you need to control their relative priorities?

My misunderstandin g, I thought the
PRIORITY = UNTHROTTLED
in LIST UTILITIES was the current limit of CPU% a particular utility
was allowed. *I had been expecting to see the value of UTIL_IMPACT_LIM
(50). *Perhaps a "Max allowed CPU%" field would be useful.

The CPU was at 100% and a DB2 LIST UTILITIES showed a single automatic
runstats executing. *There was a single table where SAP had done
massive deletes during an SAP Client delete. *There were only 12 rows
left, but scattered across the tablespace. *Selects against the table
were taking hours of time as asynchronous delete cleanup was going
on. *A reorg of the table has resolved the issue.

Thanks for responding.- Hide quoted text -

- Show quoted text -