Objective 1: What is “PACKAGE STABILITY” for? - SEGUS · With DB2 V8 IBM introduced a new feature called plan stability. Since this feature doesn't do anything with plans, it

With DB2 V8 IBM introduced a new feature called plan stability. Since this

feature doesn't do anything with plans, it is now called package stability.

However, that doesn't help much to understand what it actually does and how

you can benefit from it. Within this presentation you'll get a detailed

introduction to an enhancement that helps you to manage your applications

performance when something affects your access path. Get detailed insights on

how to integrate it within your procedures including the important

prerequisites. Get the full picture to understand how to exploit it and be aware

of its strengths and weaknesses.

1

2

Objective 1: What is “PACKAGE STABILITY” for?

Learn what the new feature is about and how you can benefit from it.

Objective 2: Why do I need it?

Gain detailed information why this new feature was implemented.

Objective 3: What is it in detail and how does it affect…

– DB2 subsystem

– Access path

– Workflow

Get all pro's and con's how the new feature behaves in your

environment.

Objective 4: How can I use it for …

– DB2 Version Migration

– DB2 System Maintenance

– Daily Database Maintenance

Hands on experiences from three different areas explain step by step

how to use it.

Objective 5: Join this presentation to see what Package Stability can do

for you and what are the gotchas to look for.

3

When static SQL statements within a program are populated to DB2

(BIND the DBRM resulting from the pre compile step), the DB2

Optimizer creates an access path plan and stores it internally for

efficient execution. An access path is optimal for a query in

consideration of the characteristics of the referred objects. If these

characteristics change (e.g. a table contains more data than originally),

the access path should be updated to assure best performance. This

update is forced by a REBIND command.

Sometimes such an update is desired not because of changed

characteristics, but due to changes to the algorithms processing them.

4

This illustration shows all parts that lead to an access path plan (DB2

internal executable code to process a SQL query). A SQL query is

analyzed along with the characteristics of the objects that the query

addresses. The accuracy of characteristics is key to a good access

path, since DB2 behaves differently if a small or a large number of

records have to be processed. For higher efficiency, object

characteristics are not determined on the fly, but maintained in the DB2

catalog by the RUNSTATS utility. This explains why a good RUNSTATS

strategy is the starting point for good access paths.

Since V7 DB2 offers two repositories for object statistics. The Optimizer

only considers the Catalog Statistics that are updated and controlled by

the RUNSTATS utility.

The Real Time Statistics are updated on the fly whenever data changes

and is not considered for access path decisions.

5

Up to this slide the story seems to be pretty simple, once the DBA

assures good catalog statistics, the DB2 Optimizer assures a good

access path. But an access path decision for complex SQL statements

can be a real challenge. DB2 customers reported that the DB2

Optimizer sometimes changes an access path by REBINDing to the

worse. Usually the reason for such a “wrong” decision is not a

weakness of the Optimizer, but the statistics that are provided.

However, if a situation like this affects a critical transaction only once,

customers often decide not to REBIND anymore at all.

6

How can the access path degradation dilemma be solved?

Deciding not to REBIND any more at all may stabilize performance, but

only if the world stands still. If an object grows, the old access path

doesn‟t fit anymore and the performance goes to hell in a hand basket.

Then the REBIND based on most current statistics is the only thing that

fixes that. In addition, any enhancement that IBM implements to the

Optimizer code can not be exploited if the new algorithms don‟t get their

chance to prove what they could achieve.

But a REBIND isn‟t always the solution to fix a performance problem.

Just avoid giving it a try if you don‟t fully understand the reason for bad

performance.

The most efficient and reliable way is to ask the Optimizer before an

access path is updated. This can be accomplished by tools that are on

the market. Some of them allow full automation of REBIND and even

BIND management fully eliminating any further guesstimates with

access paths.

7

The bottom line is not whether or not to do REBINDs, but to have the

right procedure and knowledge to decide when to REBIND. Roger Miller

made this pretty clear in a wonderful poem, that may sound familiar to

you ;-)

8

There are three rules of thumb when we are talking about the

implementation of REBIND strategies:

1st REBIND when you migrate to a new DB2 version – IBM spends

enormous efforts to improve DB2 with each version. Make sure that you

not only pay for it, but also exploit this. In V8 , the recommendation was

to rebind in NFM. In V9 all access path improvements are already

available in CM. Keep in mind that IBM also recommends to do

RUNSTATS in V9 CM prior to rebinding everything, because there are

certain new statistics available in CM that are „smartly‟ used by the V9

Optimizer.

2nd REBIND after you applied Optimizer maintenance – when IBM ships

a fix for the Optimizer algorithms, it‟s not only applying the APAR. You

need to have this considered in the affected access paths.

3rd REBIND after you updated the DB2 catalog statistics – this

repository of your objects statistics is only for the Optimizer decisions. If

you don‟t tell the Optimizer that you updated these statistics (by the

RUNSTATS utility) you just waste CPU by gathering them.

9

So far so good, but what does this all have to do with Package

Stability?! Well we should REBIND in various situations although in

some rare cases an access path doesn‟t improve it degrades. Sadly

Package Stability doesn‟t fix this problem itself, but it gives you the

opportunity to fix it easily once it has happened.

Package Stability is an enhancement to the REBIND command.

Besides creating a new access path, it backs up the old one and allows

to fall back.

10

Package stability was introduced by IBM back in 2007, allowing you to

preserve multiple package copies by new options for the REBIND

PACKAGE command. It can be set on the system level for any further

REBIND or more granularly on an individual REBIND. Both allow a

subsequent switch back to an older copy. The enhancement became

available by APAR PK52523 in DB2 9 and is already available in

conversion mode.

(refer to http://www-

01.ibm.com/support/docview.wss?rs=64&context=SSEPEK&q1=PK525

23&uid=swg1PK52523&loc=en_US&cs=utf-8&lang=en)

11

The new feature is available when executing the

REBIND PACKAGE command and the REBIND TRIGGER PACKAGE

command. It supports regular packages as well as non-native or

external procedure. However, native SQL stored procedures and

REBIND PLAN is not supported.

12

An access path copy includes multiple data to be backed up:

• common statement text, authorization and access path itself (basically

DSNDB01.SPT01 data)

• individual dependencies of an access path resulting in individual

SYSIBM.SYSPACKDEP entries. The copies are marked as DTYPE = O

(Original copy of a package) or = P (Previous copy of a package).

Thus the visibility of access path backups in the DB2 catalog is

restricted to SYSPACKDEP. SYSPACKAGE, which shows a single

record for the access path and potential access path backups!

Matching Explain table data (PLAN_TABLE.BINDTIME =

SYSPACKAGE.BINDTIME) is only possible after switching. If you

cleanup PLAN_TABLE data, you may lose the corresponding

PLAN_TABLE data for the access paths that you switch back to.

Therefore, be careful and make sure you “develop special

procedures for packages using package stability” as strongly

recommended in the DB2 9 for z/OS: Packages Revisited Redbook

(sg247688).

Presence of extra package copies has NO effect on the running time of

applications. However, the backups are stored in the SPT01 directory

tablespace and can triple space requirements. The REBIND overhead is

specified by 10% - 40% if package stability is used.

12

13

Package Stability can be controlled in two ways. Subsystem wide, or

individually per REBIND. The feature does not allow to backup as much

access paths as you want, but only a maximum of three versions

(current, last and original). Thus existing backups will be replaced when

you execute subsequent REBINDs creating new backups.

Keep in mind that turning on package stability at the subsystem level

will result in 10% to 40% extra overhead for every REBIND.

14

Some keywords (OWNER, QUALIFIER, DBPROTOCOL, ENABLE,

DISABLE, PATH, PATHDEFAULT, and IMMEDWRITE) once used

during the BIND of a package can not be changed with a REBIND using

Package Stability. No matter if it is PLANMGMT(BASIC) or

PLANMGMT(EXTENDED).

If an attempt is made to change any of these options, DB2 will issue a

DSNTI216 error.

15

Once a backup was created, REBIND SWITCH allows you to restore a

prior access path. Depending on the backups that have been created,

the feature supports decision for which one of the prior backups should

be restored. Especially for mass processing wildcard support makes the

usage much easier. If a package matches the wildcard that doesn‟t

have a backup message DSNT217I tells you about this.

The restore overrides the current access path with the previous or

original one. An original access path created by REBIND EXTRENDED

will never be overwritten by a switch, but only by another REBIND

EXTENDED or the cleanup command FREE PLANMGMTSCOPE.

Schema changes that affect an access path can invalidate a backup.

Since this is only shown in SYSPACKAGES, the validity can only be

verified after switching to an access path backup.

16

To sum up what we have so far, the new REBIND command option

allows to backup existing access paths while you ask the DB2 optimizer

to generate a new one. Once a backup is created, you can fallback

when you encounter a performance degradation and a new option for

the FREE command allows you to clean up when a backup is no longer

needed.

17

Stepping back to see it from a broader perspective clarifies that this

does not help you to avoid access path degradations, but the feature

opens up easy fallback once you have encountered such a situation.

An EXTENDED REBIND assures that you can keep an original backup

while testing new access path variations by subsequent REBIND

BASIC runs. The following slides describe a couple of scenarios where

this opens up nice opportunities.

18

Now that we had a general introduction about package stability. The

next slides describe how this new feature can be used in different

situations, like REBINDs being executed after a DB2 version migration,

DB2 subsystem maintenance or situations where we want the DB2

optimizer to benefit from fresh statistics after a (REORG and)

RUNSTATS.

The first scenario we will address is a DB2 version migration like from

DB2 V8 to DB2 9.

19

Many customers asked themselves why they should REBIND their

plans and packages in a migration process. Since they already have to

manage the situation of going to a new DB2 release they don‟t want to

create even more potential problems by probably changing all their

applications access paths. However, there are several strong reasons

why you should REBIND!

The most obvious reason is that you may want to exploit what you paid

for and gain the optimizer improvements that IBM realized in the new

algorithm of the version you apply. This seems to be a nice-to-have

considering your efforts successfully implementing the new code in your

production environment, but there is even more to be aware of. Just by

going to a new version your SQLs performance can get worse, even

without rebinding. This is because each release may introduce a

revised format for the SQL runtime structures. While your packages

from prior releases will still run, there are performance overheads, since

DB2 has to translate these runtime structures.

Another performance regression of up to 10% results from loosing

internal SELECT processing optimization called SPROCs. These select

procedures allow to move rows faster, but they are version dependent

and are invalidated just by migrating. A REBIND can reestablish them

under the new version.

… so you may not only want to exploit enhancements like the virtual constraint

relief, but also keep your current performance by doing REBINDs in

conversion mode.

19

20

With every new release of DB2 new features are available. Some of the

new functions require a REBIND to recalculate SQL access paths.

Most of the new features regarding SQL access paths are already

available in DB2 V9 conversion mode (CM). Even the new

CLUSTERRATIO algorithm and the new statistic field called

DATAREPEATFACTORF is available with the RUNSTATS utility, which

measures density of underlying data for each index, is available in CM.

You can furthermore improve access path selection by specifying the

histogram statistics option in RUNSTATS. The histogram statistics

provide an equal-depth histogram of the data for the optimizer. It can

avoid inaccurate estimates resulting from gaps in the distribution of

data. Histogram statistics are also used to more accurately determine

equality of degree for parallel child tasks.

21

The DB2 9 for z/OS Performance Topics Redbook (SG 247473) can be

downloaded at

http://www.redbooks.ibm.com/abstracts/sg247473.html?Open.

22

To realize all enhancements to the optimizer under V9, the only thing

that needs to be done is a REBIND.

However, aren‟t REBINDs risky ??

23

IBMs recommendation regarding the REBIND strategy when migrating

to DB2 version 9 is to execute the REBIND already in conversion mode.

To benefit from all possible enhancements it is recommended to

execute an „extended“ RUNSTATS (more on this later in this

presentation) before the REBIND.

24

The pre-conditioning APAR PK52522 causes DB2 to delete old copies

of packages that are created via enabling APAR PK52523. These

copies are deleted when they become invalid as a result of changes

made to the database.



23&uid=swg1PK52522&loc=en_US&cs=utf-8&lang=en)

The PK80375 APAR adds a new DB2 subsystem parameter called

COMPRESS_SPT01 (YES or NO – NO is default) to DSN6SPRM that

can be used to indicate whether the SPT01 directory space should be

compressed. The setting can be changed online, but requires a

REORG. Be careful in a data sharing environment. All members of the

group require the APAR and should use the same setting for

COMPRESS_SPT01.


01.ibm.com/support/entdocview.wss?rs=64&context=SSEPEK&q1=PK8

0375&uid=swg1PK80375&loc=en_US&cs=utf-

8&lang=en&NotUpdateReferer=)

25

When executing the global REBIND after the migration you might use

the package stability EXTENDED feature to save the original V8 access

path permanently.

26

If you are not satisfied with a new access path after the migration you

can switch back to the V8 access path by doing a REBIND

SWITCH(ORIGINAL).

To cleanup unnecessary access path copies in the skeleton package

table, use the FREE PACKAGE command with option

PLANMGMTSCOPE(INACTIVE). This frees all except the active

package, while “PLANMGMTSCOPE(ALL)” frees everything.

27

Comparison of access path changes in a migration from DB2 V7 to V8

scenario shows that on a system with good statistics, the risk of

degraded access paths is lower than on a system without distribution

statistics.

28

In a V8 to V9 migration scenario, a well tuned online application showed

less access path degradation then a untuned batch application.

In our experience the better a DB2 system is tuned regarding SQL and

catalog statistics, the less is the risk of degraded access paths after a

migration.

29

This foil is self explanatory

30


31


32


33

34

DB2 users concerned about access path regressions seen after

REBIND PACKAGE command can use the new function to preserve

and restore old access paths. However, unless directed otherwise, the

function is not intended for use when DB2 Service recommends a

REBIND PACKAGE. *

*http://www-


23&uid=swg1PK52523&loc=en_US&cs=utf-8&lang=en

35

If you apply DB2 APARS or PTFs, it can make sense to create a

backup of your access paths during the first REBINDs after applying the

DB2 maintenance.

Especially if you apply a bunch of fixes, e.g. 2 or 4 times a year it is

recommended to use a similar process as used in the migration

scenario.

36


37


38

39

If you apply maintenance to your databases on a regular basis (daily,

weekly etc.), package stability BASIC may help you to be prepared for

degraded access paths and allow for an easier fallback.

Using PLANMGMT(BASIC) in your daily maintenance allows you to

keep your ORIGINAL access paths AND keep a backup of you previous

version just before the REBIND.

40

Some general information about REBINDs in the daily maintenance.

REBIND after RUNSTATS.

Package stability does not help with Auto REBINDs, so be careful when

you apply schema changes.

Consider the right time for a RUNSTATS (volatile problematic) and think

of your dynamic SQL (invalidation of the Dynamic Statement Cache).

41


42

For daily maintenance, PLANMGMT(BASIC) is recommended.

Note: PLANMGMT(EXTENDED) has the same effect from the second

execution on.

43


44

These are typical numbers in a daily REBIND after RUNSTATS

scenario.

Note: Most access paths are not changed during a REBIND after

RUNSTATS.

45

46

47

48

References:

Redbook SG 247688: DB2 9 for z/OS Packages Revisited http://www.redbooks.ibm.com/abstracts/sg247688.html

Redbook SG 247473: DB2 9 for z/OS Performance Topics http://www.redbooks.ibm.com/abstracts/sg247473.html

Redbook SG 247330: DB2 9 for z/OS Technical Overview

http://www.redbooks.ibm.com/abstracts/sg247330.html

Ulf Heinrich is the Director of Solutions Delivery at SOFTWARE

ENGINEERING GmbH. He specializes

in DB2 recovery issues and database maintenance, focusing on the growing

requirement for 24x7

operations and cost reduction. As a consultant at large customer sites, he has

implemented database

maintenance procedures and recovery strategies, and also experienced the

pitfalls of recovery scenarios

under real-world recovery pressure. His activities cover EMEA, as well as

North America through SEGUSs

U.S. subsidiary, SEGUS Inc. He’s involved in the development of SEGUSs

maintenance and recovery

solutions.

50

Documents

Objective 1: What is “PACKAGE STABILITY” for? - SEGUS · With DB2 V8 IBM introduced a new feature called plan stability. Since this feature doesn't do anything with plans, it