(Originally posted 2005-06-13.)
For a number of years now we’ve been talking about the importance of DB2 Virtual Storage management. The real credit goes to John Campbell of the DB2 lab who pioneered this stuff.
We usually see DB2 Virtual Storage as an issue in 2 ways:
- A client presents with the problem and asks for our help in resolving it.
- We’re looking at a client’s data for some other reason and ascertain they need to look at Virtual Storage as well.
So I usually give the following Rule of Thumb: “If your DB2 Virtual Storage usage (as seen by SMF 30) exceeds 1GB, or your buffer pools exceed 512MB you probably need to pay attention to Virtual Storage.”
The main instrumentation for studying DB2 Virtual Storage is IFCID 225, produced by turning on Statistics Trace 6 and collecting SMF 102 records.
This record allows you to build a map of the DBM1 address space. (Actually it’s technically not a map but it does show the major subdivisions of memory.) We like to do a stacked bar through time (AKA “With Varying Load”). Then you can see the dynamics and work on reducing the major areas.
Today’s news is that, with APAR PQ99658 for Version 8 and (I think) Version 7, IFCID 225 is produced whenever Statistics Trace Class 1 is turned on. Which is pretty much always.
This corroborates my view that every DB2 subsystem should have it turned on all the time. It’s light and no-one has ever complained to me about turning it on.
Another change with this APAR is to drop the default value of STATIME from 30 minutes to a (rather more useful) 5 minutes. But note this means that you get more records. Yippee or ouch, depending on your perspective. I’m in the yippee camp on this one.
Finally the APAR says a cache of IFCID 225 data is kept internally so a dump can show the changes over time. Again a great help if a subsystem runs out of storage.