The maximum sort key length will also be increased from 16,000 to 32,704 with a maximum record length limit increased to 65,529, along with record lengths for sorts being restricted to 32k. DB2 10 will deliver partition by growth support for work files. And there are other improvements for work files; those will be a topic for a future article.
Note: Classic table space partitioning, a concept used since DB2 V1.1, will be deprecated in DB2 10.
There have been numerous warnings in previous versions of DB2 about the removal of private protocol. Well, it has finally happened. Private protocol will not be in DB2 10. Review APARs PK92339 and PK64045 to prepare for the removal of private protocol.
If you’re hoping you can avoid index REORGs, or perform them less frequently, DB2 10 addresses your wish at least partially with:
- List prefetch for index leaf pages
- Improved caching for non-leaf pages
- Sequential detection and index look-aside for parent key look-up on Referential Integrity (RI) inserts
- A new IFCID to track leaf page splits
- Bunches of REORG improvements and enhancements for everything else a REORG does.
All these enhancements are available in DB2 10 Conversion Mode (CM)—and there are other items on the list of utility improvements. Data set-level FlashCopy for COPY, REORG inline copy, and LOAD inline copy FLASH COPY backups can be used as input to RECOVER, COPYTOCOPY, DSN1COPY, and DSN1PRNT. A few new ZPARMs will help out, too.
A set of new stored procedures will use the new DB2 Admin Scheduler and facilitate automatic collection of statistics.
On the system side, checkpoint processing can now occur by both time and number of logs. Again, a few new ZPARMs will be useful. DISPLAY LOG will tell you what’s happening. You’ll also benefit from a command to dynamically add a new ACTIVE LOG to DB2. You won’t be able to dynamically delete a log, but adding one could be significant.
3. Concurrency improvements
The DB2 catalog function will be enhanced with support for changing catalog tables, not just adding more of them. Also, DB2 catalog capacity will be enhanced with more tables. Future catalog posters won’t be posters at all; they’ll be wall hangings for only large walls.
You’ll experience fewer performance bottlenecks with heavy workloads in DB2 10 due to reduced latching and system serialization contention and the use of 64-bit common storage to avoid Extended Common Service Area (ECSA) constraints. Parts of the DB2 catalog have been restructured so that DDL, BINDs, and PREPAREs can process without contending with each other. The restrictive size of the SPT01 has been addressed by using Large Objects (LOBs) for certain package parts. All this will be accomplished by: