DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

NFM in data sharing because some data sharing-related enhancements are automatically
taken advantage of in NFM. Most of the improvement can be attributed to the new locking
protocol level 2. For more information on improvements in NFM for data sharing
environments, see Chapter 8, “Data sharing enhancements” on page 319.
The real performance difference in NFM comes from the ability to exploit new functions not
available in CM, for example, materialized query tables.
2.6.1 Plans and packages
2.6.2 DB2 catalog
There is overhead in NFM for plans, packages, and DBDs. The representations of these
objects are different between DB2 V7 and V8. The costs come from having to reformat control
structures to match the release and in converting between EBCDIC and Unicode.
Once you are in NFM, DB2 BIND and REBIND write plans and packages to the DB2 catalog
and directory in Unicode.
Whenever DB2 accesses plans, packages, or DBDs that are not in DB2 V8 format, DB2 must
expend some extra CPU to convert them into DB2 V8 format. This is always true in CM, but
continues to be true even in NFM. In order for the plan or package to reside in the catalog in
DB2 V8 format, but most important, to enable all DB2 functions, you just do a rebind or a bind.
Important: To get around any reformatting costs and enable DB2 V8 functions (such as
NOT PADDED and index only access, the additional ability to use indexes, MQTs, IS NOT
DISTINCT, and more), rebind your plans and packages in V8 NFM.
When you migrate to NFM, the catalog changes from EBCDIC to Unicode. The conversions
happen in ENFM, and it is an important difference for a few customers. A few customers stay
in ENFM, even though all catalog tables are in Unicode. Some may fall back from NFM to
ENFM. The other significant difference is the capability of running during ENFM.
Important: Once you are in NFM, the collating sequence of the DB2 catalog changes
since the catalog is now converted to Unicode. You may get different results when using
range predicates against the DB2 catalog.
Other incompatibilities are described in the Premigration activities section of the DB2 UDB for
z/OS Version 8 Installation Guide, GC18-7418-02.
For instance, In NFM, an identifier that was valid in DB2 V7 might be flagged as too long in
DB2 V8 and you receive message DSNH107I (during precompilation) or SQLCODE -107
(otherwise).
The first 128 code points of Unicode match the ASCII code page, so the ordering is different
when you use an ORDER BY in an SELECT against the catalog.
2.6.3 Precompiler NEWFUN option
Whenever a plan or package, whose last BIND was prior to DB2 V8 NFM, is rebound, DB2
converts the EBCDIC to Unicode before proceeding. This is always true in CM, and continues
to be true even in NFM. To alleviate this cost, the plan or package must be bound with a
DBRM produced by the precompiler using NEWFUN(YES). The default for NEWFUN
switches to YES from NO for the precompiler once you switch to NFM.
Chapter 2. Performance overview 23