- Using more table spaces (60 new catalog table spaces)
- Using partition by growth table spaces
- Implementing row-level locking for some catalog tables
- Allowing real online REORG (SHRLEVEL CHANGE) and CHECK against the catalog.
You can avoid some REORG issues with the catalog if you get rid of the links in the catalog tables that used to use them. DB2 is also going to use more Character LOBs (CLOBs) and Binary LOBs (BLOBs) for catalog columns with long strings as well as manage the catalog tables using more DB2-managed System Managed Storage (SMS)-controlled DB2 table spaces. Catalog conversion will occur during Enabling New Function Mode (ENFM).
2. Enable 10 times the users by avoiding memory constraints
Up to 90 percent of storage for thread processing is now above the 2GB bar. This should give most customers the ability to run five to 10 times the number of threads in a single subsystem.
This change impacts many things, one of which is Logical Partition (LPAR) consolidation. Although data sharing’s major benefit is availability, many customers have moved to multiple data sharing members to spread their users across multiple LPARs. Even in DB2 9, you were pressed to run more than 500 to 700 users in a single DB2 address space. If you needed more users, you had to move to data sharing; the more users, the more data sharing members were required. Of course, reducing LPARs reduces complexity and cost and things can be easier to monitor and manage, Nevertheless, data sharing is still a great availability feature and useful if you have high-availability requirements.
1. CPU reductions for transactions, queries, and batch
DB2 lab staff members have said DB2 10 provides the best reduction in CPU for transactions and batch in more than 20 years. The lab expects most customers to see about a 5 to 10 percent reduction in CPU times when they install DB2 10 CM. Once DB2 10 is installed and customers start to take advantage of the new functionality and enhancements in NFM, they should see additional memory and CPU usage reductions.
What Isn’t Included
It’s only fitting to also mention what’s being removed with DB2 10. This list, which may grow or shrink, assumes an upgrade from DB2 9 to DB2 10. If upgrading from V8 to DB2 10, there are additional items that will be removed that are listed in the DB2 9 Installation Guide (GC18-9846):
- Private protocol won’t be supported, so it’s time to move to Distributed Relational Database Architecture (DRDA). The REXX tool in DB2 9 can help you identify and convert all objects still using private protocol.
- If you have any old packages that were bound at DB2 V5 or before, they won’t work in DB2 10 and, if detected, will be automatically rebound.
- EXPLAIN tables created before V8 are no longer supported; all EXPLAIN tables will also use UNICODE.
- XML Extender is no longer supported; you can use pureXML.
- DB2 10 will no longer support plans having directly bound Database Request Modules (DBRMs). Planning should start as soon as possible to move off the old style plans that use DBRMs. There should be maintenance in DB2 9 to help with migration from DBRMs bound directly into plans.
- ACQUIRE(ALLOCATE) packages won’t be supported; use ACQUIRE(USE) instead.
- DSNCHKR is no longer supported for managing DB2 catalogs.
- Compression on table space SPT01 isn’t supported.
DB2 10 offers many valuable enhancements, but there’s still much more to talk about that’s not mentioned or fully detailed here. Clearly, few data servers can top DB2’s efficiency, resilience, and growth potential.
To learn more about DB2 10 and monitor its evolution, visit www.ibm.com/software/data/db2/zos/db2-10/. This will be an interesting year for DB2. Once GA is announced, the excitement will continue. Stay tuned!