470,591 Members | 1,658 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,591 developers. It's quick & easy.

Automatic Backup/Reorg/Runstats Evaluation - How do you force a new evaluation cycle?

Hi:

I'm testing DB2's new automated maintenance feature and, so far it
seems to accomplish what it is instructed to do, but we (DBA's) have no
control on when the evaluation cycle is going to happen nor when the
utilities are set to execute.

We only supply 'time ranges' for DB2 to operate upon. What I want is a
means to 'force' a new evaluation period (i.e. I'm creating and loading
new tables and I want to force a new evaluation cycle so that my
database/tables are considered for automated BACKUP/REORG/RUNSTATS).

Keep in mind that I'm testing these new features and.... yes, I know
that I can explicitly submit these utilities if I really need them.
Please save me advice...

Thanks in advance !!

Enrique Valdez

Dec 29 '05 #1
2 3875
If you have a full control over the automat -- than it is manual :-)

If you set the automated maintenance then you employ the database
manager as your dba. You should trust your dba or you should do it by
yourself.

If the table has been significantly modified and it would be wise to
recollect statistics, than db2 marks "statistics should be collected
for that table". The actual statistics collection takes place in next
available maintenance window (and you have control over that).

In that case database manager is so wise to come into conclusion
"statistics should be collected for that particular object, because
probably different query execution plan would be better for that
data". When you consider manual statistics collection you usually do
not track data changes -- you just collect the statistics when you want
(eg. low system utilization), but you don't know if your action might
have any influence on the optimizer.

If your system is over utilized and you have walking maintenance window
than switch to manual gear box, as all sport drivers do.
-- Artur Wronski

Dec 30 '05 #2
Artur (and group members):

I've read your answer, gave it a second thought and I will rephrase it.

I know that I have the 'manual' options to submitting the utilities
and, as a 'seasoned' DBA, this is what I always tell my customers to
do.
But it's not the utilities that I'm worried about, but the new
automation features.

As a DB2 technical support person, I'm usually contacted by my
customers (being them internal or external) asking me several
questions.
In this particular issue, they may contact me to explain why their DB2
instance's utilities are not executing automatically (at least they are
not being executed as frequently as they want or with a specific
timing).

This is precisely what I'm studying now. How to govern/control the new
automation features.
I've seen that there's a SYSTOOLS.POLICY table that contains
information regarding these automated tasks (Backup, Reorg, Runstats)
and I'm wondering if there are any means to 'touch' this table (or any
other DB2 object) that would influence/control the automation features.

Almost all the automated job/task scheduling software products that I
had the opportunity to deal with had the chance to submit a 'RUN NOW'
command to activate any given scheduled task to execute immediately,
regardless of its schedule.
This is what I'm looking for.

I hope that I'm making my point now. Better yet, I hope that the
group's members get my point.

Thanks in advance

Enrique Valdez
Certified DB2 UDB for z/OS v8.1 Database Administrator

Jan 3 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by raqfg | last post: by
1 post views Thread by hikums | last post: by
6 posts views Thread by Gert van der Kooij | last post: by
3 posts views Thread by andy.standley | last post: by
4 posts views Thread by db2group88 | last post: by
1 post views Thread by Michel Esber | last post: by
3 posts views Thread by Norm | last post: by
1 post views Thread by satish mullapudi | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.