I got a question today from a friend who was trying “explain stmtcache all” on DB2 LUW and wondered why it was unrecognized. He had stumbled across this command while looking up the explain syntax in the DB2 online documentation and was lured in by its promises. What he didn’t notice was that this was in the DB2 for z/OS documentation, and that this command isn’t available in LUW.
Don’t get me started.
In the olden days, DB2 on the server and DB2 on the mainframe were two very different products, and no-one expected much compatibility. It took years after the OS/2 EE Database Manager rewrite for DB2 LUW to catch up to DB2 for z/OS’ level of sophistication. But DB2 LUW has come a very long way very quickly in recent years, and has adopted most of the important features previously only available from the mainframe. I’ve gotten pretty used to this.
But I’ll often hear of all this cool stuff in new versions of DB2 for z/OS, like in the version 10 beta that rolls out tomorrow. I expect new features to eventually appear in a subsequent LUW version, but sometimes they never do. Explain stmtcache all is one such example. In this case, architectural differences may mean that it will never come down from on-high, but it would be nice to have in LUW. Yes, I can loop through snap_stmts or top_dynamic_sql and do explain all for on each of the stmt_texts (I have scripts that do this), but this is slow. And changing the current explain mode is another option, but it’s rarely available and rarely efficient. It’s a dynamic SQL world now, and the kinds of trends you can spot by mining the snapshot tables (and presumably the dsn_statement_cache_table) are just too useful. So give us the best tools for it, even if we have to borrow them from the big iron.
Another related example is the stated plan to add access plan stability features for dynamic SQL (I don’t need it for static SQL, so I can skip the current PLANMGMT capabilities). But, alas, this is currently only being planned for… where? DB2 for z/OS, of course.