I have recently been involved with trialing and testing our space monitor software on DB2 z/OS.
It was originally designed many moons ago to monitor the size of the secondary extents that DB2 was using and to issue dynamically on-the-fly an ALTER SECQTY to guarantee that the maximum size of the object was reached *before* you ran out of extents.
Now you might be wondering “What’s that got to do with the price of beef?”
Because, as we all know, DB2 V8 introduced a “sliding scale” to the size of the secondary extents so that it could also guarantee that a dataset hit its maximum size *before* you ran out of extents.
So what’s interesting here?
Simply put – both solutions are great until you actually hit the wall!
When you get to the maximum number of datasets – Who is gonna help you??? If it is 01:00 on Saturday morning and your critical production tablespace has got its maximum of 32 datasets – what are you going to do??? Could you actually get the REORG through before prime time starts on Monday morning?? Or what happens when partition 26 completely fills up?
IFCIDs to the rescue!
This is where our tool SAX (Space Assurance Expert) comes in handy. It is a STC that runs 24×7 catching the IFCIDs that DB2 spits out whenever a dataset issues a request for an extent. What it then does is the “clever” bit if you like! Using the DB2 Catalog SAX determines the exact make-up of the object being extended and can use two levels of warning percentages to start triggering alarm bells way, way before it all goes pear-shaped!
Here is my little “ready-reckoner” for Linear Dataset Allocations :
Object type: TABLESPACE ! Maximum number of data sets
-----------------------------+----------------------------
LOB tablespaces ! 254
-----------------------------+----------------------------
Non-partitioned tablespaces ! 32
-----------------------------+----------------------------
Partitioned tablespaces ! 1 (Percent used check)
-----------------------------+----------------------------
Partitioned By Growth ! MAXPARTITIONS. LPS check if
tablespaces ! more than one. If on last
! partition then percent used.
-----------------------------+----------------------------
Object type: INDEX ! Maximum number of data sets
-----------------------------+----------------------------
Non-partitioned indexes on ! MIN ( 4096 , 2 power 32 /
tablespace with LARGE, ! ( DSSIZE / TS PGSIZE))
DSSIZE, or more than 64 ! Eg: 128 GB DSSIZE with
Partitions ! 8 KB Tablespace Page
! gives 256 Pieces (datasets)
! Or 4 GB DSSIZE with
! 4 KB Tablespace Page
! gives 4096 Pieces (datasets)
-----------------------------+----------------------------
Non-partitioned indexes ! 32
otherwise !
-----------------------------+----------------------------
Partitioned indexes ! 1 (Percent used check)
-----------------------------+----------------------------
Understand PBG space definitions
Here you can see that it is not as easy as it used to be and you must also make sure you understand PBG space definitions. We allow two percentages and use them in two different ways
1) The number of datasets that have been allocated
2) The used space with a linear dataset
The second is also used if it is a PBG with MAXPARTITIONS 1 (e.g. The DB2 Catalog) or if the partition being extended is the last allowable partition.
These warnings are issued as WTOs and can easily be picked up by system automation tools to open job tickets or send e-mails to alert DBAs days or weeks before the system stops working.
Watch the number of extents
What I have also seen is that the number of extents is sometimes getting very large indeed! One customer had numerous datasets with over 4,000 extents! Now we all know that no-one knows where data is really stored on the modern disk sub-systems but still… I would schedule a reorg at say 1,000 extents! The number of extents changed a *long* time ago in z/OS 1.7 to raise it from 255 to 7,257 spread over 59 volumes *but* still limited to 123 extents per volume. This little nugget of information is *very* important if you are thinking of going down the “one huge EAV volume for all my data” road (These disks can have up to 262,668 cylinders or about 223GB!) as the extents per volume is still there!
In comparison the good old MOD-3s had 3,339 cylinders and 3GB of space.
So what I want to tell you this month is:
1) Check your Linear Dataset Allocations – Are you banging your head on the wall yet?
2) Implement a methodology to warn you in advance!
Buying our software is the smart route of course!
3) Talk with your storage personnel about space and space management on a regular
basis.
Finally, our SAX also checks and alerts if your SMS storage groups start getting full.
This is especially handy for your DB2 10 NF Catalog, Copy Pools and Work Storage groups.
As usual any questions or comments are welcome,
TTFN Roy Boxwell
Senior Software Architect