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

4.7.2 Conclusion
The enhancements we have seen in DB2 V8, z/OS Conversion Services and the z990
hardware dramatically improve Unicode conversion performance.
Prior to the z/OS Conversion Services improvement (HC3), Unicode conversion to EBCDIC
was always slower than ASCII conversion to EBCDIC, but this is not true with HC3. In V7
Unicode conversion is about 20% faster than ASCII conversion. In addition, V8 major Unicode
conversion is about 12% faster than ASCII conversion, but minor conversion is much faster
still.
The cost of conversion can affect the total CPU time of your application. As an example,
consider a table space scan of 1 million rows with no predicates or indexes. On the z900 with
V8, the table space scan used 18.6 CPU seconds when there was no conversion, and 63.3
CPU seconds for major conversion. In other words, 67% of the time was spent doing
conversion. For this study, each major conversion used 2.3 microseconds and was 25 times
faster.
4.7.3 Recommendations
Although DB2 V8 can run on z/OS 1.3, we recommend you migrate to at least z/OS 1.4, to
take advantage of the enhancements that have been made to the z/OS Conversion Services.
Notice that z/OS 1.3 was out of service as of March 31, 2005. In addition, migrating to current
hardware brings performance improvements to the z/OS Conversion Services.
When choosing to store data in a Unicode database, you have a choice of using either UTF-8
(CHAR) or UTF-16 (GRAPHIC). This choice includes both performance and nonperformance
considerations. However, the major performance consideration when comparing UTF-8 to
UTF-16 is the amount of space used. CPU time can also be another consideration. Obviously
compression itself costs a lot of CPU time, although its I/O benefits may outweigh the CPU
costs. Choosing between fixed and variable length strings can also be a consideration. The
decision between UTF-8 and UTF-16 therefore has the potential to have a real impact on
application performance.
We recommend you closely consider the type of data you will be storing in DB2 and choose
UTF-8 (CHAR) or UTF-16 (GRAPHIC) depending on the characteristics of the data. UTF-8 is
efficient for text that is predominantly English alphanumeric while UTF-16 is more efficient for
Asian characters.
In addition, there are big advantages to limiting the data to single byte characters, so that
minor conversion can succeed. However, we do not think you run the risk of compromising
your application design in order to take advantage of DB2 minor conversion techniques. In
any event, using multi-byte characters does not impact performance if Unicode conversion is
unnecessary.
Some customers who use DB2 Connect to connect to DB2 for z/OS have been using
DISABLEUNICODE=1 to tell DB2 Connect to send the data to DB2 for z/OS in ASCII rather
than Unicode. In the past, converting from ASCII to EBCDIC was much less expensive than
converting from Unicode to EBCDIC. However now in z/OS 1.4, Unicode conversion is faster
than ASCII conversion. Furthermore if the database is stored in Unicode, setting
DISABLEUNICODE adds Unicode conversion times to the class 2 CPU times. We therefore
recommend you not to set the DISABLEUNICODE parameter when you are using DB2
Connect to connect to DB2 V8.
Since the Universal Driver does not need DB2 Connect, the DISABLEUNICODE parameter is
not generally applicable. Instead, the Universal Type 4 Driver supports a new
Chapter 4. DB2 subsystem performance 187