Buffer Management › Planning Database Buffers › How Many Pages Should a Buffer Contain?

How Many Pages Should a Buffer Contain?

Minimum Number of Pages

The minimum number of pages in a buffer is three. However, a value of at least five is recommended to avoid excessive database I/O operations and to reduce contention among transactions for space in the buffer.

Maximum Number of Pages

The maximum number of pages is constrained only by available memory resources. However, if you allocate too many pages, you may degrade performance by increasing the amount of virtual paging performed by the operating system.

Choosing an Optimum

Choosing an optimum number of pages comes with experience gained from tuning your database. However, if most files in the DMCL use a common buffer, a rule of thumb indicates that the number of buffer pages should be at least three times the maximum number of anticipated concurrent database transactions.

Manage the Size of the Buffer Dynamically in Response to Need

Once a database is in operation under the central version, you can dynamically change the number of pages in the central version buffer with a DCMT VARY BUFFER statement. By changing the size dynamically, you can determine the optimum size for the buffer by monitoring the buffer utilization ratio, which is described in 18.3, “Tuning Buffers for Performance".

Local Mode vs. Central Version Specifications

You can size a buffer differently for local mode and central version use. This feature allows you to optimize use of memory resources. For example, you could specify that a particular buffer will hold 100 pages when used in local mode and 500 pages when used under the central version. Under local mode, the buffer is smaller because it supports only a single application; under the central version, the buffer is larger because it supports multiple, concurrent applications.

Initial and Maximum Allocations Under the Central Version

Buffers defined to run under the central version can be assigned an initial number of pages and a maximum number of pages. Depending on the amount of system activity, you can use the DCMT VARY BUFFER command to change the number of pages in the buffer; for example, use the DCMT VARY BUFFER command to increase the number of buffer pages during peak system usage or to reduce the number of buffer pages at other times.

You Can Use JCL to Increment Size of Local Mode Buffer

At z/OS sites, you may want to increase the size of the buffer for a specific application, such as loading a database. You can do this without modifying the buffer definition by specifying additional buffer pages in the BUFNO parameter of the JCL statement identifying a file associated with the buffer. At runtime, CA IDMS/DB acquires storage for the buffer equal to the number of pages specified in the DMCL's buffer definition plus the value assigned to BUFNO for each file associated with the buffer.

Buffers and File Caching

In certain operating systems, you can cache database files in a separate storage area called a cache. There are two types of caching available:

• Memory caching in which files are cached in a dataspace or in z-storage (storage above the 64-bit address line)
• Shared caching in which files are cached in a coupling facility.

Note: For more information about how to enable file caching and the options available in different operating systems, see DMCL Statements.

If a file is cached, CA IDMS reads database pages from the cache into the database buffer. If it modifies the database page, CA IDMS writes the modified page back to disk and to the cache. One advantage of a cache is a reduction in the number of I/Os to the file. Another advantage is that you may be able to reduce the number of pages in your buffer pool, relying on the cache to hold pages while not in use.

Memory caching provides larger caching capabilities than database buffers (even those allocated above the 16-megabyte line). However, you must have sufficient expanded storage on your machine to support the use of memory caching. Without adequate storage, the paging overhead associated with the system can increase significantly.

If using a coupling facility cache, you must have enough coupling facility space to hold the most frequently accessed pages, to make its use worthwhile. An additional advantage of a coupling facility cache is that it can be shared by more than one central version.

File caching is not available for native VSAM files.

Using Batch LSR for VSAM Files

At z/OS sites, VSAM database files can make use of IBM's Batch Shared Resources Subsystem (Batch LSR) by specifying the SUBSYS JCL parameter. At runtime, CA IDMS/DB opens the VSAM database file and the VSAM Batch LSR subsystem converts the buffer management technique to LSR processing and allows the buffer pool to be created in hyperspace. Batch LSR is also supported for native VSAM files.

Batch LSR Improves Performance for Actively Used Files

By using Batch LSR, you can reduce the number of pages in the buffer associated with the file in your DMCL because VSAM and the Batch LSR subsystem can create a large buffer pool in hyperspace which will minimize the number of I/Os. This feature offers performance improvements for files that are actively used.

SUBSYS Subparameters

Use of the Batch LSR subsystem and the number and location of the buffers is controlled by use of the SUBSYS JCL parameter and its subparameters. Use the MSG=I subparameter to display the batch LSR subsystem messages on the job log. Do not use DEFERW=YES because it could affect the integrity of your database in the event of a system failure.