However, check the BINDTIME in SYSIBM.SYSPACKAGE after you run
this. The
last time I did, I discovered there were lots of packages that were
not
rebound without any error message or warning given. You can
rebind
packages from DB2I option 5 as well, but I've never used that.

Roland Schiradin

usually such a job will ends with RC8 becaue of bind errors.
However check the last lines because the REBIND statement can be
ended
with a strange msg like maximum number of lines or so. If memory
serve me right.

However, check the BINDTIME in SYSIBM.SYSPACKAGE after you run
this. The last time I did, I discovered there were lots of packages
that were not rebound without any error message or warning given.
You can rebind packages from DB2I option 5 as well, but I've never
used that.

Mark McCormack

< I am looking for a JCL job to rebind all of the DB2 packages
found in a
< specific DB2 subsystem. Does any one have a sample job to do
this?

Mark,

This reply comes several days after your post. I have been out of
the
office for a week. I hope it will still be of interest.

This job should do what you want. I have run this kind of thing to
rebind
after conversion to DB2v8. But I have never run it without
extra
predicates in the WHERE clause of the SQL stmt. In particular, I
select
based on OWNER or COLLID. I have also selected on VALID and/or
OPERATIVE.
You might also consider sysibm.syspackage column RELBOUND. 'L' =
bound
under DB2v8; 'K' = bound under DB2v7; blank = bound under DB2v6
or
earlier.

Rambabu Vanama

Is it necessary to do the REBIND after performing the REORG or
RUNSTATS? I
have always been thinking that we should perform Rebind after
the
Reorg/Runstats to see the effect of Reorg/Runstats. But I recently
heard
that it is not necessary to do the Rebind and could have negative
impact if
we do.

James Campbell

Necessary - in that will you get incorrect results if you do not
rebind - no. (Bugs excepted.)

Necessary - in that will you get improved performance - depends.
There are some
situations where people have carefully crafted binds to get optimal
response and a rebind
would undo the care; however it is also possible to get better
performance after a rebind.

Generally the ideal would be to re-bind into a dummy collection and
compare the
PLAN_TABLE stuff for the production and dummy entries. If they are
the same, you don't
need to rebind the production; if they are different, determine
which is better and act
accordingly. If this is after a RUNSTATS, you might find
undesirable access paths - which
might be the signal to do a reorg.

As the production stuff was, presumably, rebound after the previous
reorg there should be
little, if any change.

James Campbell

On 30 Nov 2006 at 9:43, Rambabu Vanama wrote:

> Is it necessary to do the REBIND after performing the REORG or
RUNSTATS? I
> have always been thinking that we should perform Rebind after
the
> Reorg/Runstats to see the effect of Reorg/Runstats. But I
recently heard
> that it is not necessary to do the Rebind and could have
negative impact if
> we do.
>
> Appreciate all your responses.
>
> -Rambabu Vanama
>

Larry Jardine

REBIND (only) when you want access paths to change. Otherwise,
why
bother?
Before you REBIND, make sure statistics are current: do
RUNSTATS.
Before you do RUNSTATS, make sure you will get "good" statistics:
REORG.

Put another way, for a heavy-loaded transaction environment with
mostly
static SQL:
- REORG frequently.
- Do RUNSTATS only after reorgs (or inline with the REORG).
- REBIND rarely (only when you want different access paths).

For dynamic SQL and environments where the data is very
volatile:
- Do RUNSTATS frequently.
- REORG as often as you can.
- REBIND doesn't apply for dynamic SQL.

Necessary - in that will you get incorrect results if you do not
rebind
- no. (Bugs excepted.)

Necessary - in that will you get improved performance - depends.
There
are some situations where people have carefully crafted binds to
get
optimal response and a rebind would undo the care; however it is
also
possible to get better performance after a rebind.

Generally the ideal would be to re-bind into a dummy collection
and
compare the PLAN_TABLE stuff for the production and dummy entries.
If
they are the same, you don't need to rebind the production; if they
are
different, determine which is better and act accordingly. If this
is
after a RUNSTATS, you might find undesirable access paths - which
might
be the signal to do a reorg.

As the production stuff was, presumably, rebound after the
previous
reorg there should be little, if any change.

James Campbell

On 30 Nov 2006 at 9:43, Rambabu Vanama wrote:

> Is it necessary to do the REBIND after performing the REORG
or
> RUNSTATS? I have always been thinking that we should perform
Rebind
> after the Reorg/Runstats to see the effect of Reorg/Runstats.
But I
> recently heard that it is not necessary to do the Rebind and
could
> have negative impact if we do.
>
> Appreciate all your responses.
>
> -Rambabu Vanama
>

-----------------------------------------
This e-mail may contain confidential or privileged information.
If
you think you have received this e-mail in error, please advise
the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna