For a specific tablespace generate all the rebind commands for relevant pkgs & plans

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Dale Franklin - 28 May 2004 22:42 GMT

This should be a rather ROUTINE procedure for you DBAs.

I keep hearing at technical conferences and user groups the phrase
"then rebind all your plans and packages" (after reorg, load, &
runstats, etc). Obviously those plans and packages that need
rebinding are only those packages & plans relevant to the tablespace
just processed. How do I find out? (I'm on DB2 v7, MVS)

I've read five (5) 6-pound books on DB2 (cover-to-cover) written by
prominent DB2 experts in the field and NONE of them cover something
this ROUTINE. I've spent hours in the ADMIN guide and can't find
anything about how to identify and generate the necessary commands to
rebind plans and packages for SPECIFIC tables in a SPECIFIC
tablespace.

Without using 3rd party tools, where is this documented in the IBM
manuals There are some examples about finding specific plans &
packages (for certain dates, etc) but none for this routine procedure.

Many thanks!

Reply to this Message

Mark A - 28 May 2004 23:19 GMT

> This should be a rather ROUTINE procedure for you DBAs.
>
[quoted text clipped - 16 lines]
>
> Many thanks!

You can check the following catalog tables documented in SQL Reference (and
other manuals):

SYSIBM.SYSPLANDEP
SYSIBM.SYSPACKDEP

However, keep in mind that frequent rebinds are usually not necessary unless
the data has significantly changed (or and index is added). Even with a load
resume, if you are adding 25% more data to the table, and the table already
has a lot of rows, and the distribution of the new data is similar to the
existing data, it is unlikely that a rebind will make any difference after a
new runstats.

With a reorg, the you usually can do a runstats and rebind one time after
the reorg, and not repeat the runstats/rebind after every reorg (unless the
data has significantly changed).

Some people prefer to do a runstats a little after a reorg. For example, if
you reorg a table once per week, then a runstats 2 days after the reorg may
be more representative of the average condition of the data during the week
in between reorgs.

Reply to this Message