Performance benefits of data tables

This section contains Diagnosis, Modification, or Tuning Information.

Performance of a CICS-maintained data table

If all the data and index records of a file are completely contained in an LSR pool, defining the file as a CICS®-maintained data table does not reduce DASD I/O activity. There is, however, considerable potential for reduction in CPU consumption. Also, you might be able to reduce the number of buffers in the LSR pool.

If the file is not completely contained in an LSR pool, using a CICS-maintained data table could result in reductions in both DASD I/O activity and CPU consumption.

The saving of CPU consumption for a CICS-maintained data table, compared with a VSAM KSDS resident in a local shared resource (LSR) pool, depends on the application usage.

Performance of a user-maintained data table

After the loading of a user-maintained data table, DASD I/O activity is eliminated from all data table operations, so the saving of CPU consumption compared with a VSAM KSDS resident in an LSR pool is considerable.

Storage use

Shared data tables provide efficient use of data in memory. This means that considerable performance benefits are achieved at the cost of some additional use of storage.

This overview of the use of storage assumes that you understand the distinction between various types of storage, such as real and virtual storage, and address space and data space storage.

SDT uses virtual storage as follows:

Converting a file into a shared data table could lead to an increased use of real storage, but the use of real storage for VSAM LSR buffers might be reduced if few updates are made. Also, an application that currently achieves high performance by replicating read-only tables in each CICS region might be able to make large storage savings by sharing a single copy of each table.

Start of changeA data table maintains its own storage within the data space. It maintains free space, and reuses it when appropriate. When a 128KB frame is emptied and freed, it goes back on a free chain for that particular data table. Other data tables within the data space cannot reuse that frame; only the data table to which it was originally allocated can reuse it. For example, if a data table grows to 1G, then all the records are deleted from that data table, the data table still owns 1G of data space storage. No other data table can use that storage until the owning data table is deleted or destroyed.End of change

Start of changeThe most efficient utilization of data space storage happens when the number of records written to each data table is approximately equal to the number of deletes from that data table, so that the size of the data table remains a constant. In this situation, the amount of storage allocated to data tables is close to the amount of storage actually in use.End of change

Start of changeWhen new data table applications are introduced, it can be helpful to monitor the storage allocated and storage in use for each data table, to ensure that you do not reach the 2G limit on the size of the data space. The readings for storage allocated show the storage owned by each data table, which will not be given up until the data table is deleted. The readings for storage in use show how much of the allocated storage is actually in use. The CICS sample statistics program DFH0STAT provides this information. DFH0STAT is described in the CICS Performance Guide.End of change

Related concepts
Planning to use data tables
Selecting files for use as data tables
Security checking for data tables
Shared data tables support on different releases of CICS
Preparing to use shared data tables support
[[ Contents Previous Page | Next Page Index ]]