Bereitgestellt vom IBM DB2 Hotline News Service:

CLOSE DDL parameter and data sharing systems

Problem

I understand that the CLOSE DDL parameter has an additional implication for data sharing systems. Can you explain what it is and how I choose whether or not to use CLOSE YES or CLOSE NO?

Solution

Let us start with a quick overview of how the CLOSE parameter interacts with the DSMAX parameter. When the number of open data sets reaches 99% of your DSMAX value, DB2® closes 300 data sets or 3% of the value of DSMAX, whichever number of data sets is less. Data sets with CLOSE YES will be selected to be closed first. CLOSE NO data sets are closed only when less than 300 or 3% of DSMAX CLOSE YES data sets are available to be closed. The interaction between CLOSE and DSMAX is the same, regardless of whether you are in a data sharing environment or not.

In a DB2 data sharing environment, the CLOSE parameter is also considered by DB2 to determine how to handle open data sets on members with read only interest in them. In a data sharing environment, DB2 attempts to close data sets on members with read only interest in them to reduce the amount of time data sets are in the GBP-dependent state. By reducing the number and duration of GBP-dependent data sets, data sharing overhead should also be reduced.

Prior to PQ27637 (DB2 V4 and DB2 V5 and V6 without PQ27637), in a DB2 data sharing environment, DB2 would physically close pagesets/partitions when all of the following conditions are true:

They were defined with CLOSE YES

They had not been accessed within the pseudo-close interval

(PCLOSEN/PCLOSET)

The member held a page set share P-lock

With PQ27637, the pseudo close logic was extended to both CLOSE YES and CLOSE NO data sets in a data sharing environment.

With PQ27637 (prior to PQ69741) in a data sharing environment, even CLOSE NO data sets were often closed regardless of whether or not DSMAX was ever reached. There was no way to assure a data set would stay open in a data sharing environment unless there was always at least one data sharing member with read/write interest in it. Customers would often use very large values of PCLOSEN and PCLOSET in an attempt to keep their data sharing data sets from being closed, but this solution has some negative consequences.

With PQ69741, CLOSE NO really means CLOSE NO, even in a data sharing environment. Now customers have the flexibility of using CLOSE YES for the benefits of reduced data sharing overhead and CLOSE NO for the benefits of reduced data set open overhead.

For more details, see the APAR text for PQ69741. This situation represents the current interaction between the CLOSE parameter and pseudo close logic in DB2 data sharing.

The following information is a short excerpt from the APAR text:

Performance considerations for PQ69741 in data sharing environment.

CLOSE(YES) - no impact.

CLOSE(NO) - No really means no now, with this apar, in a

datasharing environment.   If you want things to behave as

they did prior to this apar (in a datasharing environment), you need to change your CLOSE(NO) objects to CLOSE(YES).

Consider CLOSE(NO) for objects that you expect 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 can have an effect on the amount of datasharing overhead experienced for objects defined as CLOSE(NO).  Users will need to consider datasharing overhead vs. open/close overhead and tune appropriately using the

CLOSE() parameter.

Related information

PQ69741