These scenarios describe common situations for which you
might want to compare access plans.
Identify SQL performance changes due to adding, removing, or modifying SQL statements
Typically, when SQL statements are added, removed, or modified
in a source program, you must rebind the related DB2 package by running the BIND command
with the ACTION(REPLACE) suboption. Running this
command might change the access plan for the SQL statements and affect
performance.
Identify SQL performance changes due to release migration
A release migration could be a DB2 version-to-version upgrade (such as migrating
from DB2 for z/OS Version
9 to DB2 for z/OS Version
10) or a DB2 maintenance level
upgrade (such as applying an APAR or a PTF). A release migration might
introduce new features and change the behavior of the DB2 SQL optimizer. Rebinding a DB2 package after a release migration might change
the access plan for the SQL statements and affect performance.
Identify SQL performance changes due to running RUNSTATS utility
You can run the RUNSTATS utility to
collect current statistics on tables and indexes in a DB2 for z/OS subsystem.
Running this utility provides the optimizer with the most accurate
information with which to generate the best access plan.
Identify SQL performance changes due to applying tuning recommendations
After applying tuning recommendations, such as recommendations
from the Statistics Advisor or the Index Advisor, you can compare
access plans for a tuned workload. By using different EXPLAIN snapshots,
you can validate that the SQL statements in the tuned workload have
been optimized.