objective 1: what is “package stability” for? - segus · with db2 v8 ibm introduced a new...
TRANSCRIPT
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.
(refer to http://www-
01.ibm.com/support/docview.wss?rs=64&context=SSEPEK&q1=PK525
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.
(refer to http://www-
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.
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-
01.ibm.com/support/docview.wss?rs=64&context=SSEPEK&q1=PK525
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.
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).
42
For daily maintenance, PLANMGMT(BASIC) is recommended.
Note: PLANMGMT(EXTENDED) has the same effect from the second
execution on.
44
These are typical numbers in a daily REBIND after RUNSTATS
scenario.
Note: Most access paths are not changed during a REBIND after
RUNSTATS.
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