DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

Note: If you want to empty the PLAN_TABLE, you must use the DELETE statement, just
as you would for deleting rows from any table. You also can use the DROP TABLE
statement to drop the PLAN_TABLE completely. The action of binding, rebinding or
executing another SQL statement does not replace or delete rows from the PLAN_TABLE.
D.1.1 DSN_PLAN_TABLE
The table can be created by the statements contained in member name DSNTESC of the
DB2 sample library. DB2 tools also create or update your PLAN_TABLE when needed.
Let us look at the evolution of the PLAN_TABLE in Table D-1.It is a way to see the evolution of
DB2.
Table D-1 PLAN_TABLE columns by release
DB2 release Columns in
PLAN_TABLE
V1 25
V1R2 28
V2 30
V3 34
V4 43
V5 46
V6 49
V7 51
V8 58
Note: When you execute EXPLAIN using DB2 Performance Expert in V8 for the first time,
DB2 PE advises you that your PLAN_TABLE is old and updates it for you.
Of course, the 58-column format gives you the most information. If you alter an existing
PLAN_TABLE to add new columns, in general specify the columns as NOT NULL WITH
DEFAULT, so that default values are included for the rows already in the table. However, as
you can see in Table D-2, there are some exceptions, certain columns do allow nulls. Do not
specify those columns as NOT NULL WITH DEFAULT.
Table D-2 describes the PLAN_TABLE, giving a small description of each column and a brief
history of DB2 evolution. If you want more information about it, refer to DB2 UDB for z/OS
Version 8 Administration Guide, SC18-7413.
Note: There are some objects for which accesses are not described by EXPLAIN. They
are, for example, the access to LOB values, which are stored separately from the base
table, and access to parent or dependent tables needed to enforce referential constraints,
SQL for routines (triggers, functions, or stored procedures), and explicit access to
SECLABELs for row level security.
Appendix D. EXPLAIN and its tables 409