VSAM Tuning into the '90s
by Jaqui Lynch
Boston College
Abstract
VSAM tuning is a topic of growing importance as VSAM becomes a more integral part of the CICS and MVS environments. This paper addresses areas such as file allocation, freespace, CISIZEs, REPLICATE and IMBED, SHROPTIONS, shared resources, BATCHLSR, Hiperbatch, BUFFERSPACE, CI and CA splits, some miscellaneous options and a tuning methodology. Although the major focus of this paper is VSAM Tuning as it applies in the MVS and CICS environments, many of the principles can also be applied to VSE.
It is important to remember that the aim of tuning is to improve performance within the constraints of the existing environment, and that to a certain extent this requires a choice of tradeoffs - performance versus DASD space, and program performance versus resource (CPU, storage...) usage. It is also important to acknowledge that tuning is an investment and requires a significant amount of resource, both human and machine time. Tuning should be an ongoing process with a pre-defined methodology, not just a fix for deteriorating performance.
The basic methodology used for tuning is:
a) Setting objectives
b) Monitoring current performance
c) Implementing changes
d) Reviewing the impact of the changes
e) Interpreting and documenting
Before embarking on a VSAM Tuning exercise it pays to make sure that MVS is reasonably well tuned. There is no point in tuning one file when MVS and CICS are themselves constrained or poorly tuned. Remember it pays to take a top down approach and to change the simple and often obvious things first. The 20/80 rule is well worth remembering.
FILE ALLOCATION
Use of Cylinders
Whenever possible use cylinders for data. This allows the use of multitrack channel programs, which require fewer excps, and assists with CA preformat. If allocation is done in cylinders, then the CAsize is always 1 cylinder, and this helps any CI splits go faster as the heads are positioned over that cylinder. Use of cylinders has the following benefits:
It is important when calculating space that enough space is left for CIDFs, RDFs and freespace. The major disadvantage of allocating in cylinders is that CA splits will take longer. However, be aware that usage of a small data CIsize and a large CAsize can cause an oversized index CIsize, and the reverse can cause an underutilized index CI.
Extents
To avoid DASD fragmentation and seek activity, it is important to keep the number of extents to a minimum, preferably one. This is particularly important for the index. If there are a lot of splits it is important to reorganize the files to reduce the seek activity as logical and physical order will no longer be the same. It is also important that any extent request can be allocated in 5 or fewer extents, otherwise the define will fail or strange errors will occur later. This area needs to be watched closely as the maximum number of extents for a VSAM file is 123.
Keyranges
If there is a large on-line environment it may be advisable to define data across volumes depending on Keyranges. This puts ranges of keys and the data on certain packs. Be certain that backups and restores are synchronized though.
Freespace
Freespace is specified as Freespace(a b), where a is the percentage of freespace in each CI and b is the percent of free CIs in each CA. Use of freespace reduces CI/CA splits if used properly. Insufficient or excessive freespace can degrade performance and overutilize DASD. If there is insufficient freespace, then CI/CA splits will degrade sequential processing as the dataset will not be stored in physical sequence. An excessive amount will cause DASD space to be wasted due to the reduction of the effective blocking factor of the data. Also, extra I/O will be required to transfer partially filled CIs in sequential processing.
When allocating freespace ensure that the record size plus the length of RDFs and CIDFs is taken into account. If there is an even distribution of inserts then it is best to specify the majority as CI freespace and a little CA freespace. IF it is uneven then a little CI freespace and a lot of CA freespace.
CI Sizes
Small data cisizes reduce wasted data transfers as VSAM always reads a CI. If processing is random or dynamic, a large CI is hopelessly inefficient and, for on-line, is very bad for response. For files primarily accessed by CICS, the best data CIsizes are 2k or 4k. When using a large CISZ , I/O operations are reduced if multiples of 4096 are used. Also note that on CKD, CIs are stored as physical records with inter record gaps, which should be taken into account when estimating response times. For direct access on-line files, a CISZ such as 2k or 4k should be used, and for sequential/mixed access a larger CISZ should be used.
Care should be taken that the CISZ chosen won't result in lots of unused space due to record length - If the CISZ is 2048 and the record length is 700 then only 1400 bytes can be used for data, 10 for CIDFs and RDFs, and the last 598 bytes will be wasted. A CIDF is 4 bytes and there is one per CI, and an RDF is 3 bytes. For fixed length there are 2 RDFs per CI, and for variable, the worst case is 1 RDF per record.
Do not allow the index CISZ to default if LSR pools are being used, or if the keys for the index have a bad compression ratio (front or rear). For LSR pools ensure that the Index CIs are not going into the same pools as the data. Keep in mind that a large CISZ and a large CASZ will require fewer index records.
Replicate and Imbed
Without replicate and Imbed, data CAs and CIs can be stored in different places on the disk from the index. This means that several I/Os are required for each access.
With Imbed and noreplicate, each data CA has its sequence set record at the front of the CA. If the CASZ is 1 cylinder then the sequence set is maintained on the 1st track of the cylinder. If the CASZ is less than 1 cylinder then one track is added to the CASZ. Thus, it costs 1 track per CA as the sequence set is written around the track as often as possible. Rotational delay is reduced as the r/w arm is placed above the sequence set and data. However, index updates cause an overhead as each copy of the sequence set has to be updated. Sequential processing benefits immensely from Imbed.
With replicate and noimbed, all data CAs and indexes are separate. Each higher level index is written as often as possible on a track. This option uses a lot of extra space and also requires extra I/O for index updates. If using this option the index should be allocated in cylinders and imbed should also be used. Better value can be obtained from the judicious choice of buffers. Since sequential processing only uses the sequence set, then replicate is of no value for sequential processing.
In general, imbed alone should be used, and then only for active datasets that are allocated in cylinders and are bigger than 20 or so cylinders. The general recommendation is that Replicate should rarely be used and then only with Imbed. Replicate and imbed should not be used for SCD (semiconductor disk) or cache, as they will waste space on the SCD or in the cache.
SHROPTIONS
Shroptions are not only an integrity parameter, but also a performance one. Normally shr(1,3) is used for files and (2,3) for AIXs and files that have AIXs or need to be shared. Shr(3) is an option that leaves integrity up to the coders, and shr(4) is a performance killer.
With shr(4) limitations are placed on the files in an attempt to help: jobs can't add to the end of the file(no appends, new extents or new CAs), there can be no CAsplits, the CI containing the high-key RBA can't split and enqs and deqs must be issued to maintain integrity. The file also can't take advantage of VSAM readahead or buffers, as the buffers for the data and sequence set are always refreshed if the file is opened for direct processing.
SHARED RESOURCES
Until ESA, shared resources were only available in certain applications such as CICS, now there are also the options of Hiperbatch and Batch LSR. Local Shared Resources allows for the concurrent use by multiple VSAM datasets of control blocks and buffers, thus reducing the total Virtual Storage required and the number of I/Os. A bufferpool is built and buffers are allocated to datasets as required. Virtual storage is reduced because one pool of channel programs, I/O control blocks and buffers is shared among all VSAM datasets. This can help reduce paging, if the processor is storage constrained.
LSR does not always result in less I/O. Datasets with the same CISZ can share the same bufferpool. The buffer will always be checked for each I/O request before getting a CI from DASD (Buffer lookaside). If the index and data cisizes are not isolated, then data will be forever forcing out the index buffers and I/O will be done anyway. It is also important that pool sizes are set to actual CIsizes for the files. VSAM will use any buffer pool that equals the CI size or, failing that, any that are larger. This can cause wasted space. If the LSR pool is big enough then Imbed and Replicate should be avoided as they can slow down the rewriting of the index records if a CI or CA split occurs.
LSR is designed to support multiple medium to low activity datasets with the same pool of buffers. Don't mix extremely volatile files into pools with other files as the buffers will be refreshed too often. Sequential processing doesn't perform as well, because sequential readahead is not permitted. VSAM readahead is only available for a KSDS if it is NSR, as LSR will only read one CI at a time. The first browser benefits the most, as he gets all spare data buffers until he finishes. High browse activity CICS files should be NSR so they can use VSAM readahead. Transactions that do "get for update" without ending browse should also use NSR, as lockouts will occur if LSR is used.
While allocation of buffers increases the probability that an I/O request for a CI will be found, excessive allocation will increase the requirements for Virtual Storage and CPU Utilization to manage the buffer pools. (An LRU algorithm is used to manage the buffers.) Careful monitoring of CICS statistics (buffer waits, etc) is needed to avoid this.
BUFFER SPACE
There are three places that bufferspace can be coded - on the JCL AMP=, in the program's ACB and in the define. That is also the order in which they are searched. Coding on the JCL gives far more flexibility as it is easier to change. Use the Bufni and Bufnd options rather than Bufsp. When Bufsp is used, the way the buffers are allocated depends on options specified at open time. Remember to increase region size if using buffering as the impact to the private area could terminate your program.
Use of excessive buffers can result in paging if the processor is real storage constrained, and may negate the effects of VSAM readahead. It can also increase CPU utilization due to the overhead of managing the buffers. As each bufferpool begins on a page boundary, sufficient buffers should be allocated to fill a page (4096k) in MVS.
Be careful using buffers in CICS as VSAM tries to use all buffers before reusing any. With too many buffers, page faults may occur which kills CICS response. It is better to allow a few buffer waits (these lock out 1 user) as a page fault locks out the whole region.
With Bufni, the first buffer is assigned to the sequence set, but it can be overwritten by other index records.
Some basic calculations:
#seq. set records = data hi-used RBA / (data CISZ x data ci/ca)
#index set records = total index records - seq. set records
CISZ =4096 - cyls 3380= 150 ci/ca set Bufni to 151 (add 1 for seq. set).
140 ci/ca if imbed so use Bufni=141
cyls 3390= 180 ci/ca set Bufni to 181
168 ci/ca if imbed so use bufni=169
CI AND CA SPLITS
When a CI is full and there is no room for a new record to be inserted, a CI split is performed. Half of the CI is left behind and the other half is moved to a never-before-used CI in the same CA. RDFs and CIDFs are also taken care of. This operation will take place in buffers if they are available, but physical I/O is still required. If a CA or the sequence set fills up, a CA split is caused. The sequence set will cause this to happen even if the CA is almost empty. If the file is allocated in cylinders then the CA splits will be reading and writing a cylinder at a time. A CA split does not reorganize the CIs so they will be in a different logical and physical sequence.
A CI split causes I/O to the index, sequence set (read), old CI, new CI and a sequence set update. A CA split causes at least 5 I/Os - each CI in the new CA is formatted, the sequence set is created, the index set is updated and half the CIs are moved one at a time. Each CI that is moved requires at least 1 I/O. The catalog is also updated and allocation processing takes place. On top of this any AIX's in the upgrade set will be updated.
In order, from best to worst, the scenarios are: no CI or CA splits, CI splits, CA splits, CA splits that require secondary extents (needs I/O to the catalog, Vtoc and VVDS).
ESA RELATED TOPICS - HIPERBATCH, BATCH LSR, CAS AND CICS/ESA
Catalog Management
There are several major changes that affect VSAM performance in the ESA environment. The internal structure of the BCS and VVDS change so that SMS can be implemented and temporary VSAM datasets can now be used. One item that can have a very negative impact on performance is the use of multi-level aliases (up to 4 levels). Modifying this parameter once it has been set up can result in down- time and performance problems while datasets are redistributed.
The In-Storage catalog mechanism within the Catalog Address Space is now optional and can be activated and deactivated via the modify command. Selected records can now also be cached into a catalog data space cache instead of ISC. This works very well utilizing VLF, but requires that appropriate PTFs be applied to avoid problems with Cross System Updates.
Hiperbatch and Batch LSR
Batch LSR and Hiperbatch are implemented via apar OY24097 and provide a performance boost for direct or random processing. Batch LSR enables the implementation of VSAM LSR to any application. It requires that the BLSR subsystem be defined and that JCL be modified. If Hiperspace buffers are used then it is highly recommended that the job be made nonswappable, as the buffers are ESO (expanded storage only) and are not backed by DASD, so the Hiperspace would be lost if the job was swapped out.
Hiperbatch permits the retention and sharing in ESO Hiperspaces of QSAM and VSAM files. There are two types of Hiperbatch Hiperspaces - retained and nonretained, each one having its own method of population and deactivation. Hiperbatch is only available for QSAM sequential and VSAM NSR sequential processing and datasets are made eligible for processing using either DLF or your security system. Hiperbatch should not be used for files that will be updated by more than one CICS or by CICS and Batch at the same time, as integrity cannot be ensured.
CICS
It is now possible to have multiple LSR pools and to dedicate specific pools to indexes. Wherever possible, 4k CIsizes should be used as there is now a Hiperspace LSR buffer which is addressed in 4K units. This buffer is defined in the FCT and is a fixed area of expanded storage set aside to page LSR buffers so that they don't page to disk. This is extremely useful for datasets with a high locality of reference and high read activity. Shr(4) files should still use NSR.
CICS Data tables allow loading the contents of a VSAM file into storage and accessing it there. This is only effective for files accessed via full key direct reads. Entry Q500334 in IBMINFO discusses the fact that the pathlength to satisfy fullkey reads is reduced to 1/5 that of LSR buffers when using data tables.
MISCELLANEOUS OPTIONS AND PARAMETERS
Erase
Overwrites the dataset with binary zeroes when it is deleted. It increases the time required for a delete and should only be used where absolute security is needed. Catalog lockups can also be experienced using the erase option as the job will ENQ the catalog while the zeros are being written.
Mass Inserts
This is the most efficient mode to use, and causes VSAM to be in sequential mode when inserting many records into a KSDS. The physical write of a record is delayed until the CI is filled and freespace is maintained. Also splits occur at the point of insertion rather than the middle of the CI, and subsequent splits are avoided as only free CIs are used if sequential mode continues.
Alternate Indexes
Eliminate the use of AIXs with frequently updated base clusters. Whenever the base is updated, all the indexes need modification and this causes I/O - at least 2 extra I/O operations per AIX whenever a key is added, deleted or changed in the base. At least keep the number of AIXs to a minimum. It is also important to note that AIXs that are opened via the path will not be implicitly verified by DFP.
Enqs
When a gethold of any form is performed, be aware that VSAM enqs on the CI, and thus the whole CI is unavailable to others the whole time the enq is valid. It pays to issue enqs as late as possible and deqs as early as possible.
Writecheck
Adds a full rotation per I/O, as a device does a full rotation and rereads each previously written record. This is no longer a default as current technology is far superior to the 2314s it was initially designed to work on.
Speed/Recovery
Recovery causes each CA to be preformatted before use with "end-of-file" records. This CA preformat allows the reload to restart at the point of failure. Speed reduces I/O by eliminating this CA preformat. This option only applies to the initial load of the file, as VSAM always processes in recovery mode after loading. A significant performance boost is gained at load time by changing from the default of recovery to speed for the data component.
Seed Records
Don't initialize files with a high values record as this has been shown to cause many splits. A low values record is better.
MONITORING
If a file is open to CICS, the information on the file in the catalog is not updated until the file is closed. If CICS fails, then the information is not updated and will be incorrect until the file is reloaded. This is important to keep in mind when monitoring VSAM files as it is important to know whether the catalog statistics being reviewed are valid, or not. The following details some of the fields in the Listcat to monitor and some simple calculations that can be used. It is also possible to calculate an I/O factor for a file to monitor changes - this is done by doing a Listcat before CICS or the job runs and another straight after and performing the following calculations: Using the before and after listings for both components (data and index), subtract the before value from the after value for records retrieved, records deleted, and records updated, and add the differences together to get an activity total - also subtract the before excps from the after excps. Now divide the excps by the activity total to get the I/O factor. The I/O factor should be less than 1.
Fields to Watch
SUMMARY
With the advent of DFP and on-line applications, VSAM has become an integral part of the operating system. Judicious use of certain parameters can cause a major variation in performance seen and can lead to dramatic improvements in response time. Specific areas that give major benefits include controlling CA and CI sizes, controlling extents, use of imbed, correct use of freespace, correct buffering and use of shared resources, use of speed instead of recovery and avoiding splits. The most important lesson to learn is that the defaults may not be what is desired, and that VSAM files need to be monitored carefully.
VARIOUS APARS FROM IBM
OY07931 VSAM LSR CPU reductions
Q500334 Discussion on Datatables path lengths
OY28155 Hiperbatch Monitor
OY24097 Implements Batch LSR
Compiled and edited by Jaqui Lynch
Last revised June 5, 1995