Nah, not really! Well at least I hope not! The problem lies with all of the old baggage we carry around with us all the time. Humans, and computers, are pretty bad at simply „forgetting“. Things just keep popping up and annoying us at the most inopportune moments…
What can you do about it?
Well, you can check out how your Db2 subsystems are looking to deal the the „computer part“. Your brain, on the other hand, is sadly a little bit too much for a Db2 newsletter!
What are the problems?
The number one problem with Db2 system migrations, is the deprecated features that are still firmly nailed to their perches but are 100% dead. They will not cause a problem today, or tomorrow, but at some point they will start to smell… and I mean smell really bad!
Tell me more!
Here’s a list of all the deprecated (and semi-deprecated) items that should be checked and verified at your site:
- Use of SYNONYMS
- Use of HASH objects
- Use of segmented spaces
- Use of classic partitioned objects (not using table based partitioning)
- Use of simple spaces
- Use of six byte RBA
- Use of BRF
- Use of LARGE objects (This is semi-deprecated)
Anything else?
Well yes! You could also check how many empty implicit databases you have and how many empty tablespaces you have while you are checking your subsystem out. While you are scanning, it could also be cool to list out all the Db2 sub-system KPIs, and what about seeing how many tables you actually have in multi-table tablespaces that, at some point, must also be migrated off into a UTS PBG or UTS PBR tablespace?
We do it all!
Our little program does all of this for you. It runs through your Db2 Catalog in the blink of an eye and reports all of the data mentioned above.
What does it cost?
Nothing – It is our freeware for 2020/2021 and you only have to be registered on our website to request it along with a password to run it.
How does it look?
Here is an example output from one of my test systems here in Düsseldorf:
Db2 Migration HealthCheck V1.0 for DC10 V12R1M507 started at
2020-11-23-12.12.10
Lines with *** are deprecated features
Number of DATABASES : 594
# of empty DATABASES : 237
# of implicit DATABASES : 385
# of empty implicit DATABASES: 207
Number of TABLESPACES : 5258
of which HASH organized : 0
of which PARTITIONED CLASSIC : 18 ***
# Partitions : 218 ***
of which SEGMENTED : 1507 ***
of which SIMPLE : 3 ***
of which LOB : 152
of which UTS PBG : 3525
# Partitions : 3531
of which UTS PBR : 19
# Partitions : 1161
of which XML : 34
Number of tablespaces as LARGE : 8 ***
Number of empty tablespaces : 28
Number of BRF table partitions : 0
Number of multi-table TSs : 55
# of tables within these : 239
Number of ACCELERATOR ONLY : 0
Number of ALIASes : 5428
Number of ARCHIVEs : 0
Number of AUXs : 147
Number of CLONEs : 3
Number of GTTs : 235
Number of HISTORYs : 2
Number of MQTs : 1
Number of TABLEs : 5230
Number of VIEWs : 43
Number of XMLs : 34
Number of SYNONYMs : 1 ***
Number of Indexes : 23243
of which HASH : 0
of which type 2 : 23210
# of partitioned IXs : 6
# Partitions : 160
of which DPSI : 18
# Partitions : 164
of which PI : 15
# Partitions : 1138
Number of table partitions : 6606
of which DEFINE NO : 2848
of which six byte RBA <11 NFM: 0
of which six byte RBA Basic : 0
of which ten byte RBA : 3759
of which unknown RBA : 2847
Number of index partitions : 24666
of which DEFINE NO : 20140
of which six byte RBA <11 NFM: 0
of which six byte RBA Basic : 0
of which ten byte RBA : 4527
of which unknown RBA : 20139
Number of STOGROUPS : 10
Number of VOLUMES : 0
Number of PLANs : 54
Number of PACKAGES (total) : 6053
Number of PACKAGES (distinct) : 545
Number of SQL statements : 441833
Db2 Migration HealthCheck V1.0 for DC10 V12R1M507 ended at
2020-11-23-12.12.12
Db2 Migration HealthCheck ended with RC: 0
Any line with *** at the end means that you have something to do at some point in the future. The names of all the found objects are written to DD card DEPRECAT so you can then start building a „to do“ list. I would start now to slowly „fix“ all of these before it is 03:00 in the morning, someone is migrating to Db2 14 FL 608 and it all goes horribly wrong…
What’s wrong with LARGE?
This is not actually deprecated but any tablespaces marked as LARGE tend to also not have a valid DSSIZE in them. This is fine if you have built a CASE construct to derive the value from the tablespace definition. But what you should do is an ALTER and a REORG to „move“ the LARGE to a „proper“ tablespace. IBM and 3rd Party Software vendors hate having to remember that ancient tablespaces are still out there!
All on my own?
Naturally not! For example, after all the ALTERs have been done, a lot of the spaces are simply in Advisory REORG pending status and you could use our RealtimeDBAExpert (RTDX) software to automatically generate the required REORGs to action the changes.
Synonyms??
Well, you can do them all yourself by reading one of my older newsletters – just remember to watch out for the GRANTs afterwards.
How many deprecated objects do you have?
I would love to get screenshots of the output at your sites which I would then all sum up and publish as an addendum to this newsletter. Just so that people can see how many Parrots we all have pining for the fjords!
TTFN
Roy Boxwell