Testing group buffer pool caching

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:

  1. 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. Start of changeThe 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).End of change

    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.

  2. Verify that ITEM_COUNT increases by five after each run.
  3. Issue the following command to determine whether the table space and index are using the group buffer pool:

    Begin general-use programming interface information.

    DIS DB(DSN8D12A) SPACENAM(DSN8S12S,XPARTS) LOCKS

    End general-use programming interface information.

    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.

  4. Issue the following command to display the statistics for GBP0:

    Begin general-use programming interface information.

    DIS GBPOOL(GBP0) GDETAIL

    End general-use programming interface information.

    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.