19.06.2013 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

overcome this, when <strong>DB2</strong> Connect is interfacing with <strong>DB2</strong> <strong>for</strong> z/<strong>OS</strong> V7, <strong>DB2</strong> Connect sends<br />

the data in Unicode (by default). If you still require the data to be sent in ASCII instead of<br />

Unicode, then you may set the DISABLEUNICODE=1 parameter. DISABLEUNICODE is<br />

specified in the db2cli.ini file. Older z/<strong>OS</strong> systems were slow to convert Unicode so it was<br />

desirable to specify DISABLEUNICODE=1. Otherwise, installations migrating from <strong>DB2</strong> <strong>for</strong><br />

z/<strong>OS</strong> V6 to V7 would experience an increase in class 2 CPU time. Only <strong>for</strong> Java Applications<br />

was it preferable not to specify DISABLEUNICODE=1.<br />

This per<strong>for</strong>mance problem goes away with z/<strong>OS</strong> 1.4, because now Unicode conversion is<br />

faster than ASCII conversion. Furthermore, if the database is actually stored in Unicode,<br />

setting DISABLEUNICODE adds Unicode conversions to the class 2 CPU time.<br />

In the above example, the <strong>DB2</strong> Connect properties file indicates DISABLEUNICODE=1,<br />

which prevents <strong>DB2</strong> Connect from sending data as Unicode. The data sent on INSERTS is in<br />

ASCII. The DBM1 address space converts the ASCII data to Unicode.<br />

For the SELECT statement, <strong>DB2</strong> Connect on the client converts the data from Unicode back<br />

to ASCII. Only those conversions done by the DIST address space are counted as class 2<br />

CPU time.<br />

Class 2 CPU time is unaffected by the conversions done by the client, but if the client is<br />

running locally on z/<strong>OS</strong>, the CPU time <strong>for</strong> conversions done by the client may be part of class<br />

1 CPU time. Conversions done by a non-z/<strong>OS</strong> client do not use zSeries mainframe resources.<br />

Figure 4-14 shows the effect of not disabling Unicode in <strong>DB2</strong> Connect, which is the default.<br />

C-program<br />

INSERT<br />

HV1 943<br />

HV2 943<br />

SELECT<br />

HV1 943<br />

HV2 943<br />

<strong>DB2</strong> Connect V8<br />

Conversion<br />

Routines<br />

Figure 4-14 CCSID conversion - Remote application - 2<br />

In this case, <strong>DB2</strong> Connect sends all data as 1208, no matter what the type of column is. The<br />

<strong>DB2</strong> <strong>for</strong> z/<strong>OS</strong> conversions <strong>for</strong> CHAR columns disappear. However, there is a double<br />

conversion <strong>for</strong> GRAPHIC columns, but only the second conversion is done by <strong>DB2</strong> <strong>for</strong> z/<strong>OS</strong>.<br />

178 <strong>DB2</strong> <strong>UDB</strong> <strong>for</strong> z/<strong>OS</strong> <strong>Version</strong> 8 Per<strong>for</strong>mance <strong>Topics</strong><br />

DisableUnicode=0<br />

AIX z/<strong>OS</strong><br />

DRDA<br />

Common<br />

Layer<br />

DDF<br />

<strong>DB2</strong> <strong>for</strong> z/<strong>OS</strong><br />

DBM1<br />

1208 COLC<br />

1200 COLG<br />

1208 COLC<br />

1200 COLG

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!