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

multinational companies to combine data from different sources. Unicode was developed to
solve the problem. By storing data in a single Unicode CCSID, text data from different
languages in different countries can be easily stored and managed.
DB2 V5 introduced the ability to create ASCII databases, table spaces and tables via the
CCSID ASCII clause. This gave you the choice to store your data in either EBCDIC or ASCII,
and DB2 would convert data between these encoding schemes where appropriate. DB2 V7
built upon that support, introducing support for Unicode objects. However, where EBCDIC
and ASCII conversions are done within DB2, DB2 V7 always relied on OS/390 Conversion
Services to handle Unicode conversion. The performance of Unicode conversion in DB2 V7,
with older levels of the operating system and zSeries hardware, was less than optimal. DB2
V8 enhances support for Unicode, and at the same time takes advantage of the faster
conversion provided by the current versions of z/OS services and zSeries processors.
When storing data into and retrieving data, DB2 converts the data from one CCSID to another
CCSID where necessary. Obviously, it is preferable that no conversion be carried out,
because conversion impacts performance. However, IBM has done considerable work to
improve conversion performance on zSeries. In this section, we discuss the recent
enhancements IBM have made to conversion and how they impact performance.
When does CCSID conversion occur?
CCSID conversion occurs whenever there is a mismatch between the CCSID of a source and
target string, such as between a host variable and its associated column. This conversion
support in DB2 has existed since DB2 began to support client/server connections in V2.3
between different EBCDIC CCSIDs. DB2 V5 began to support ASCII tables and ASCII host
variables, so CCSID conversion was expanded to include conversion between EBCDIC and
ASCII.
To perform these conversions (not involving Unicode), DB2 uses a translate table which is
stored in SYSIBM.SYSSTRINGS. We refer to this type of CCSID conversion as
SYSSTRINGS conversions.
The specific EBCDIC and ASCII CCSIDs used to store data by a DB2 system must be
specified in the DSNHDECP data only module, and they should not be changed. Starting in
V8, they cannot be changed. Within a single DB2 system, all EBCDIC tables have the same
EBCDIC CCSIDs and all ASCII tables have the same ASCII CCSIDs. In addition, numeric
columns and date/time columns are stored as binary fields, but they may involve CCSID
conversion when loading or unloading such fields using the EXTERNAL attribute. However,
the utilities always apply the EXTERNAL attribute to date/time fields.
DB2 V7 introduced the ability for user tables to be defined as Unicode by specifying “CCSID
UNICODE” on the database, table space or table definition. Within a Unicode table, CHAR
and VARCHAR columns are stored in UTF-8 format. GRAPHIC and VARGRAHIC columns
are stored in a Unicode table as UTF-16. Any CCSID conversion involving Unicode is called
Unicode conversion and is necessary whenever there is a mismatch between the CCSID of a
source and target string. DB2 V7 uses the z/OS Conversion Services exclusively for all
Unicode conversions, which can affect the CPU time substantially.
In V7 the DB2 Catalog remains in EBCDIC and all SQL statement parsing is still done in
EBCDIC. Therefore, for applications such as the Universal Java Driver that provide an SQL
statement in Unicode, DB2 must convert the statement to EBCDIC. Similarly, any incoming
metadata, such as package names and authorization ids, may also require conversion by
DB2.
One of the limitations of V7 is that you cannot join two tables that use different CCSIDs.
Another limitation is performance. V7 completely relies on the z/OS Unicode conversion
Chapter 4. DB2 subsystem performance 175