You can use SQL statements in member DSNTESD to verify
that the group buffer pool caching operates correctly.
Procedure
To verify that the group buffer pool operates correctly:
- Run SPUFI on more than one data sharing member, using member
DSNTESD as the input data set.
Specify AUTOCOMMIT=YES on the SPUFI panel.
Run SPUFI on the different members serially, a few seconds apart if possible. (The runs must be close enough together to avoid having Db2 close the page set because of infrequent updates. The amount of time before Db2 switches the page set from read-write to read-only after the last update is specified by the PCLOSET subsystem parameter setting. See RO SWITCH TIME field (PCLOSET subsystem parameter).
By running the SQL statements serially, Db2 detects inter-Db2 read/write interest on the table space and index and uses the group buffer pool.
- Verify that ITEM_COUNT increases by five after each run.
- Issue the following command to determine whether the table
space and index are using the group buffer pool:
DIS DB(DSN8D13A) SPACENAM(DSN8S13S,XPARTS) LOCKS
If the P-lock state is IX or
SIX, then the table space and index are group buffer pool dependent,
which is the correct state.
- Issue the following command to display the statistics for
GBP0:
DIS GBPOOL(GBP0) GDETAIL
In the group detail statistics, look for non-zero values
in the READS and WRITES values of the display. This indicates that Db2 is using the group buffer pool
successfully for caching.