• Index: 95 percent or better
• Combined: 93 percent or better.
These objectives can vary but the important thing is to have objectives that can be used to measure the effectiveness of the LSR pools and the changes made. The index objective is higher because there usually are more I/O operations to the index component than to the data component. Most KSDS files have two or more index levels. So you would require two or more reads to the index component and only one read to the data component to locate a record.
Improving the hit ratio is usually a function of adding buffers to the particular size in question. The number of additional buffers depends on the amount of virtual and real storage available. Adding buffers to improve the look-aside hit ratio should concentrate on those buffers that have the highest request activity. For example, imagine that the 4KB and 20KB buffers reflect hit ratios of around 77 percent in the data pool. Suppose the 4KB buffer pool has 1.4M requests, while the 20KB buffer pool has 529KB requests. Both buffers should be improved. However, if there’s a shortage of virtual or real storage, then fixing the 4KB buffer would probably have a better effect on the overall LSR pool hit ratio. If there are sufficient resources available, then fix both. Determining the number of buffers to add to the pool (data or index) usually occurs by trial and error. You look at the different attainments and add a certain number to each of the buffer sizes that need adjustment.
LSR look-aside buffer hit ratios and percentages can be misleading. The look-aside percentage attained is for the buffer in the pool and not necessarily for the files that access the buffer. For example, a 4KB buffer may reflect a look-aside hit ratio of 85 percent. This particular buffer size may be used by many files in the pool. So, some of the files can have a better look-aside hit ratio percentage than the buffer attainment while other files may have a lower look-aside hit ratio percentage. Tuning the index buffer pools should take precedence over tuning the data pools because the index pool usually has more I/O activity. In addition, index CI sizes tend to be smaller than the data CI sizes. So, it’s possible that a smaller investment in virtual and real storage would be required to improve the hit ratio. Also, there are fewer index CIs than there are data CIs, so the reference patterns for index records would be more concentrated.
Tuning data buffers can vary by system because the search patterns for the data component are generally random and access is dispersed because of the size of the data component. Obtaining high hit ratios in the data component usually entails a large investment in virtual and real storage. Good data hit ratio candidates are files with a compressed access pattern that often reference the data, files with sequential read activity (browse), and files with read for update/rewrite and delete activity.
Extremely large files with random activity can have a negative effect on the data pool reference pattern. However, even though a data set has disperse access to the data, the index portion of this data set can obtain excellent look-aside hit ratios that more than justify the data set be allocated in LSR. Data sets with disperse access usually have three levels of indices, so you could receive hits on the index portion, which is three of the four I/O operations. VSAM files that have Share Options 4 specified should never be in the LSR pool because direct reads of the CI cause a reread from the disk to ensure we have the latest copy. This negates the look-aside capability of the LSR pool and tends to flush good buffers.
Once changes have been made, immediately measure the results after adding buffers to a pool. A good result is 3 to 5 percent look-aside improvement to justify the virtual and real storage investment being made for a particular buffer. If there’s little ROI, then consider reassigning these resources to another buffer or pool because resource availability has a limit. Finally, there’s a possibility of improving hit ratios by standardizing data CI sizes. Standard CI sizes will let you create large buffer pools of a limited number of CI sizes. This facilitates better resource usage.