SMS Allocation behavior for DB2 datasets

Sameer Rana

SMS Allocation behavior for DB2 datasets

Advanced technology can do wonders in rendering performance benefits in ways never imagined before.
However too much technology can become a pain sometimes.
We are facing an issue that I would be interested in knowing how others cope with.

A lot of our legacy objects ( partitioned in many cases ) are allocated with 180,180 cylinders. While this strategy had worked well over the years, for the past few months we have seen a lot of Production objects notching up into 150+ extents, even though there is ample capacity within the storage pools. What we observed was the DB2 data sets continued taking extents in the already fragmented volumes which made it take smaller chunks than 180 cylinders thereby overshooting the number of extents. It never bothered to span across freer/empty volumes even though SMS had access to them. When we referred this issue to our storage team they insisted that SMS allocation routines have changed and to have your objects allocated on free unfragmented volumes you have to set a large primary and secondary ( 600+cyl,600+cyl ).
Has anyone faced this? Is there an SMS remedy for this? Is there any functionality or tuning parameter available within SMS to control extent allocation for large data sets to go to freer/empty volumes ( both primary and secondary extents ) without doing an alter tablespace priqty secqty and REORG?

We are running DB2 V8 NFM on zOS v1.10.
Your insights or experiences will be greatly appreciated.


* IDUG EMEA * Prague, Czech Republic * 14-18 November 2011 * http://IDUG.ORG/EMEA *
* If you are going to attend only one conference this year, this is it! *
How can you expand your staff or do succession planning in this economy?
Mentoring is a proven, economical, way to train the next generation of DB2 Users!

If you need to change settings, is the home of IDUG's Listserv