August 3, IBM announced the end of service (EoS) for DB2 for z/OS Version 8 in IBM announcement letter 910-169 here in the US. That announcement letter states that DB2 for z/OS Version 8 (5625-DB2) , DB2 for z/OS Version 8 Value Unit Edition (VUE) (5697-N29), and DB2 Utilities Suite for z/OS Version 8 (5655-K61) will all be going out of service on April 30, 2012.
DB2 10 supports migration from DB2 9 NFM or from V8 NFM. IBM estimates that about one customer in five migrated using a skip version technique for V5 to V7, and they anticipate a similar number will go from V8 to 10. Why is the migration project for skipping larger? Well, testing and rollout are only a little bit bigger than a single version migration (due to the additional features of 2 versions instead of 1). But education and remediation work will probably be close to double. A good project plan estimate is about 150% of a single release migration. Timing is crucial here; if the project is delayed too long not only will you miss out on improvements in DB2 9 that could have been implemented, but if you extend past April 30, 2012, you may need to pay for extended service on DB2 V8.
Also deprecated are: -- XML Extender [change to use pureXML data type] -- DB2 MQ XML user-defined functions and stored procedures [change to XML functions] -- DB2 Management Clients (DB2 Administration Server, Control Center, and Development Center) are deprecated. IBM's new management client direction for DB2 is Data Studio.
CATDDACL , CATDMGCL , and CATDSTCL data class, management class, and storage class SMS parameters. STATCLUS parameter, also on macro DSN6SPRM, specifies the type of clustering statistics RUNSTATS collects. The default, and recommendation, is ENHANCED clustering statistics which should result in an improved CLUSTERRATION formula. STATCLUS was added to DB2 in DB2 9 on installation panel DSNTIP6 and removed form the panel becoming an opaque parameter in DB2 10. SEQCACH on the macro DSN6SPRM controls whether DB2 prefetch uses sequential access for reading the cache on a 3990 controller. The default is SEQ , use sequential access, BYPASS tells DB2 prefetch to bypass the cache. The recommended setting is SEQ, the default.
By granting the EXPLAIN privilege on an authid or role, you are giving that authid or role the ability to: -- do an EXPLAIN on an SQL statement specifying the keywords ALL/PLAN, STMTCACHE ALL, STMTCACHE STMTID, STMTCACHE STMTTOKEN, and MONITORED STMTS, --issue the SQL statements PREPARE and DESCRIBE TABLE, -- perform a BIND specifying EXPLAIN(ONLY) and SQLERROR(CHECK), -- and explain dynamic SQL statements executing under the new special register CURRENT EXPLAIN MODE = EXPLAIN .
In previous releases of DB2 for z/OS, query performance might be impacted if the DB2 optimization process overestimates the filtering of a predicate, which can occur if the literal value is not known. For example, when the predicate is a range predicate, when data is distributed non-uniformly, or when using host variables or parameter markers. Now, when two indexes have a close cost estimate, the DB2 optimization process considers the uncertainty of matching and screening predicates when choosing the most efficient index. The DB2 optimization process might choose an index with a slightly higher cost estimate than another index, if that index will be more cost-effective.
INCREMENTAL REBINDS DB2 incrementally rebinds the statements that use parallelism after migration to Version 10. Incremental rebinds can cause performance degradation, so you should manually rebind those statements. You can run a query in job DSNTIJPM before you migrate to determine which statements can use parallelism, and are therefore candidates for incremental rebinds. You should consider rebinding those statements after migration, as soon as your Version 10 system is stable. After you migrate to Version 10, you can also run a performance trace, class 3 or class 10 for IFCID 357, to identify the plans and packages that contain static SQL queries that use parallelism, and therefore need to be rebound. THREAD CONSTRAINT RELIEF The goal for DB2 10 for z/OS is for as much as 90% of the DBM1 address space and the DDF address space to be running above the bar. This can result in the ability to run much more concurrent work in a single subsystem and to run from five to ten times more concurrent threads. For instance, if your configuration and application mix can support 500 concurrent threads on a single subsystem on DB2 9, you should be able to support as many as 5000 concurrent threads on a single subsystem with DB2 10. Thread constraint relief requires rebinding your programs.
DB2 best practices web page. These best practices present advice on the optimal way to use DB2 for z/OS to satisfy key business data processing needs. These presentations and articles are authored by leading experts in IBM's development and consulting teams. https://www.ibm.com/developerworks/data/bestpractices/db2zos/