Q and A

Asked and Answered

In your column " When Less is More ," why not place the table in question in its own tablespace? Then it could be attached to its own bufferpool and sized according the table data? This way there would be no need to change applications.

Robert Catterall responds:

Your solution would virtually eliminate disk I/O activity and would reduce CPU cost (as an I/O operation consumes some CPU cycles); however, there is still the CPU expense associated with executing SELECT statements to retrieve data from the table. Generally speaking, this is a rather small expense on a per-SELECT basis, but when a small table is accessed in read mode with great frequency, the cost of the many SELECT statements can be rather significant in the aggregate. In some such cases, it can be advantageous to copy the data from the DB2 table to an in-memory, out-of-DB2 data storage area, and have programs access the data from this storage area. A CICS data table is an example of such an in-memory, out-of-DB2 storage area. When you aren't using CICS, you could copy the data into a different in-memory area.

People have done this, with positive results, in non-mainframe server environments. The key consideration is the programming effort required to replace SELECTs against the table with accesses to the in-memory storage area and ensure that changes made to the data (for example, updates) are synchronized between the in-memory storage area and the source DB2 table.

If the savings in CPU time is worth the programming effort, you may have a winning proposition.

See a complete archive of reader/author Q&As .