It seems a long time since the universal tablespace type (UTS) was introduced in Db2 9 for z/OS, way back 2007. It had two flavours, partition by growth (PBG) and partition by range (PBR), both exploiting segmented organisation for improved space management. There have been many enhancements since the original implementation, too many to list here, with many restrictions being lifted.
So why should you take the risk of converting from your existing tablespace types – simple, segmented, class partitioned – to UTS? You will need to REORG the tablespace to materialise the pending DDL change, and deal with the associated packages being invalidated, and if you want to avoid access path changes, rely on APREUSE.
There are many reasons, too many to list all of them here, so this is my personal list, some general, some more specific:
- Incremental enhancements across the releases have made it easier to migrate to UTS non-disruptively. Virtually all of the capability you need for conversion is available given the on-going functionality delivered by continuous delivery in Db2 12 and Db2 13.
- IBM has announced that a future release of Db2 for z/OS will withdraw support for non-UTS tablespaces. If we assume it’s the next release of Db2, then you’ll need to complete UTS conversion within the lifetime of Db2 13. IBM can reasonably argue that customers have already had 17 years to convert to UTS.
- Improved space management arising from the segmented organisation of UTS tablespaces offers better performance for some types of applications compared to classic partitioned tablespaces.
- Support for CLONE tables provides an alternative to LOAD REPLACE for, for example, reference and lookup tables.
- Redirected recovery is only possible for UTS tablespaces. This is a tremendous capability allowing you to create PIT copies of the data, for forensic and diagnostic purposes, or to create a known safe copy of the data in the event of logical data corruption.
- You can insert a partition anywhere in the partitioning scheme with UTS. This can be vital in preventing outages when data skew causes some partitions to grow much more rapidly than others.
- Complementing that is the capability to increase DSSIZE on a partition-by-partition basis, as an immediate DDL change, without an outage.
- With the ability to convert from PBG to PBR and vice-versa, not only can you convert a PBG tablespace to a PBR one, but you can also change the partitioning key of a PBR tablespace in a single REORG.
Need help in converting your tablespace objects to UTS? Contact us.