Oh, yes, I almost forgot to post about my presentation on Monday. I spoke at a vendor-sponsored presentation for NEON Enterprise Software. The topic was on Change Management for DB2 Access Paths - and it is an important topic to consider. Although my presentation was followed by a product pitch for NEON's BindImpact Expert, the topic warrants consideration, product or not.
Basically, the thrust of the presentation is that more focus needs to be applied to managing DB2 access paths. We implement strict change management procedures on every other change we make in the mainframe environment: program changes, system software changes, PTFs, etc. But with access paths it is move the DBRM to production and BIND. We don't move access paths, we create new ones on the fly in the production world. Is this any way to work?
The result of this situation is that many sites often BIND once, and then never REBIND for fear of introducing degraded access paths. This is an unfortunate situation. Basically, what this does is penalize EVERY statement because we are worried about 2 or 3 statements that might degrade.
I know these two things seem at odds with one another: that is, we need change management but we also need to keep REBINDing. And they are. But the proper response is NOT to stop all REBINDs, the proper response is to introduce methods and procedures for implementing a change management discipline. And that is where the NEON solution comes in.
'Nuff said, for now...