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

Choosing between UTF-8 and UTF-16
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 non-performance
considerations. For example, since the collating sequences of UTF-8 and UTF-16 are
different, you can choose column types based on the desired collating sequence rather than
performance.
However, the major performance consideration when comparing UTF-8 to UTF-16 is the
amount of space used. The reason space is important is not just the cost of the space itself,
but also the impact that the space has on I/O bound utilities and queries, including the time to
recover, which affects data availability. Buffer pool hit ratios are also affected by space.
A UTF-8 character is variable length and can be 1 to 4 bytes in length, of which the first 128
code points match 7-bit ASCII. A UTF-8 character is used by DB2 to store CHAR or
VARCHAR columns. This is opposed to a character in UTF-16, which is 2 or 4 bytes. DB2
uses UTF-16 to store GRAPHIC or VARGRAPHIC columns. The first 128 code points match
UTF-8 and ASCII, while the rest have a different collating sequence.
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.
To reduce the space required by Unicode tables, you can use DB2 compression. With no DB2
compression and for alphanumeric characters, UTF-8 has the same space characteristics as
EBCDIC, however UTF-16 doubles the storage requirements. Compressed alphanumeric
UTF-16 strings use more storage than compressed alphanumeric UTF-8 strings, but the ratio
is generally much less than 2 to 1. Tests have shown this ratio can be less than 1.5 to 1.
Whether compression is used or not, the overall effect of Unicode on space usage depends
on the amount of text data versus non-text data.
CPU time can also be another consideration. Compression itself costs a lot of CPU time,
although its I/O benefits can outweigh the CPU costs. In some applications Unicode
conversion can be avoided, but if conversion must be done, it is best done by a remote client
in order to distribute the CPU overhead. If conversion must be done on the zSeries machine,
then you should consider what the dominant application CCSID will be. Generally, the choice
which tends to minimize space usage also tends to minimize CPU usage.
Choosing between fixed and variable length strings may also be another consideration.
Remember, the length of a UTF-8 string is unpredictable, unless the application limits the
characters to the common set and fixed length strings.
Consider, for example, a column that was defined as CHAR(1) in EBCDIC. If you try to insert
a multibyte UTF-8 character into CHAR(1), you get a -302 SQL error, because the data does
not fit into one byte. If you change the column definition to GRAPHIC(1), you need two bytes.
If you change the column definition to VARCHAR, you need 3 bytes in order to account for the
two-byte length field. Knowing that a field is restricted to alphanumeric characteristics allows
you to continue using CHAR(1).
It is especially good to avoid using variable length fields in indexes, especially nonpadded
indexes, since key comparisons of variable length fields are more expensive. On the other
hand, you should try to avoid padding costs with fixed length fields if Unicode conversion is
being done.
Remember, there is nothing stopping you from storing both UTF-8 and UTF-16 encoded data
in the same table.
Chapter 4. DB2 subsystem performance 183