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

DB2 V8 improves Restart Light. If indoubt units of recovery (UR) exist at the end of restart
recovery, DB2 now remains running so that the indoubt URs can be resolved. After all the
indoubt URs have been resolved, the DB2 member that is running in LIGHT(YES) mode will
shut down and can be restarted normally.
A DB2 member that has been started with LIGHT(YES) that remains active to resolve indoubt
URs will still not accept any new connection requests, except those that originate from
connection names that have indoubt URs.
If DDF is normally active, Restart Light will also start DDF to facilitate the resolution of any
distributed indoubt URs. However, no new DDF connections are allowed. Only resynch
requests will be allowed from DB2 clients.
This enhancement to Restart Light has the potential to benefit both the availability and
performance of applications that are still running on other active DB2 members.
For example, you do not have to bring DB2 up a second time to resolve any indoubt threads
and remove any retained locks held by those indoubt threads. (Remember that under V7,
DB2 would terminate immediately after a successful restart, when it is started in light mode.)
Potentially more retained locks are released faster, making the data protected by those
retained locks available sooner for applications that are running on other active DB2
members.
8.5.4 Change to close processing for pseudo close
In data sharing, any table space or index which has remained in a read-only state with no
activity for a period of time longer than the pseudo-close interval (PCLOSET DSNZPARM) will
be physically closed. This is done in an attempt to reduce data sharing overhead (the object
can become non-GBP-dependent if it is closed on all but one member), but it has the
disadvantage of requiring that the next access to the object must go through dynamic
allocation and data set open again. This can be a significant amount of overhead, particularly
if a large number of objects are accessed at the same time after a period of inactivity (for
example, at the beginning of the business day).
DB2 V8 now honors the CLOSE YES or NO attribute of the table space or index. The physical
close will now only take place for CLOSE YES objects, while CLOSE NO objects may remain
open indefinitely. This allows you to control the behavior on an object-level basis; formerly, the
only means of control was through the pseudo-close DSNZPARMs, and lengthening the
pseudo-close interval to keep data sets open could have other undesirable effects.
There is no performance impact in a data sharing environment when you specify CLOSE
YES. However CLOSE NO does have an impact. No really means no now, in a data sharing
environment. If you want things to behave as they did prior to DB2 V8, (in a data sharing
environment), you need to alter your CLOSE NO objects to CLOSE YES.
Consider CLOSE NO for objects that you estimate to be GBP-dependent most of the time and
you do not want the extra open/close overhead associated with CLOSE YES. For objects that
are infrequently GBP-dependent, CLOSE YES will likely provide better performance. Once
GBP-dependent, CLOSE NO objects will stay GBP-dependent until either DSMAX is hit and
all CLOSE YES objects have been closed or until the CLOSE NO objects are manually closed
as a result of a DB2 command or a DB2 shutdown.
This enhancement is also made available in DB2 V6 and V7 by PTF UQ74866 for APAR
PQ69741.
338 DB2 UDB for z/OS Version 8 Performance Topics