This entry was originally published on 2014-07-20

By Gareth Jones.

Many customers experience problems when allocating large datasets, because the datasets often end up being allocated in many extents. This can affect performance and availability as high frequency extent allocation or in extreme cases lead to extent allocation failure. The following is a partial rework of information provided by John Campbell, IBM DB2 for z/OS Distinguished Engineer, in response to a real customer problem.

At a high level, the recommended best practice for managing large datasets is for customers to use both Space Constraint Relief and Extent Constraint Removal. That is the easy part of the answer. The difficult part is understanding the implication of setting PRIQTY=-1 for large objects.

In terms of volume maintenance, the vast majority of customers do not DEFRAG their volumes; sometimes this is just impossible because of 24x7 operations, but sometimes customers do not even know they need to. Consider the impact, if you have fragmented volumes, and DB2 is using the sliding scale of secondary allocation. DB2 might, for example, allocate 7 cylinders, and then work out it needs to allocate 8 cylinders on the next allocation using the sliding scale, but the volume is so fragmented that another extent has to be found as the adjacent space does not hold 8 cylinders, therefore resulting in many extents.

If you find yourself in this situation, there are some questions you need to answer and consideratiobs to take into account:

• What 3390 model type are you emulating? You might be struggling to obtain a PRIQTY of 36000, for example, which might seem quite big but is only 500 cylinders and is not, in fact, very large. This opens up the possibility that you are still emulating 3390 Mod-3s, which are, by today's standards, very small. The larger the logical model size you are emulating, the less of an issue finding 500 cylinders should be.
• What is the HIGH specification in ISMF for the SMS Storage Group? Many customers are using 99% and forcing datasets to go multi-volume, causing additional DB2 performance degradation because of the additional synchronous request to the ICF catalog for each new volume used.
• Are there enough volumes in the SMS Storage Group? Many customers are running their systems lean and mean, and do not have enough logical volumes. Even if they understand that, they are often unwilling to add more volumes because of the cost.
• What DSSIZE you use indicates how many extents it will take to get to that 500 cylinder point, via a gradual slide or stepping stone.
• For many customers there will be a 90/10 split for small vs. large data sets. If you assume 300 cylinders as the dividing line (this is an arbitrary value used for purposes of this discussion), then 90% of objects would be below 300 cylinders and 10% of the objects above. It would therefore make sense to provide two SMS Storage Groups, one for small objects, and one for large objects. The 'large' pool should have some additional logical volumes as a 'buffer' for doing such things as parallel Online REORGs. This way the small objects don't introduce fragmentation into the Storage Pool for the large data sets, and therefore would cause many fewer problems. The problem with PRIQTY -1 or a value very low is that it will not trigger the Storage Group ACS routine to allocate the datasets in the 'large' pool, because the allocations are based on an initial space allocation which is too small. You could take individual data sets or a set of them and have the ACS routines place them specifically in the 'large' pool, but that would be a manual approach. An alternative is if the installation to allow DBAs to specify one of the SMS classes on the CREATE/ALTER STOGROUP, the Storage Administrator can then code the Storage Group ACS routine so as assign the datasets into a specific special class and into the 'large' pool based on the class name provided. This takes away the manual effort and gives more control to DBAs.

When John was helping design sliding secondary allocation, he never envisaged PRIQTY=SECQTY=-1 to be a 'one size fit all' approach to be used for all objects. If you know the allocation for an object will be large, a common approach is to allocate 1000 cylinders primary, and 100 cylinders secondary if there is enough room. This is true for Online REORG of large objects as well as those that do not use REUSE or ALTER of the space before the REORG. In this case DB2 Data Space Manager will go through the slide scale all over again, so a 2900+ cylinder 2GB data set slides from the beginning even though we know what the potential high end size will be.

Be aware that every time a new extent is taken there is a synchronous request to the VTOC, plus the performing of the sliding scale calculation, and if the object goes multi-volume then add the additional synchronous request for the ICF catalog to add a new volume. Very few customers see this performance impact.

So in summary, I will make the following recommendations:

• Enable both Space Constraint Relief and Extent Constraint Removal. For more information, see z/OS DFSMSdfp Storage Administration, SC23-6860-01.
• Have a segregated SMS Storage Group with additional volumes for large allocations.
• Use larger emulated logical volumes.
• Use a reasonable value for the ISMF Storage Group HIGH value. For more information, see z/OS DFSMS Implementing System-Managed Storage, SC23-6849-00.