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

More documents

Recommendations

Info

4.6.2 Conclusion We can conclude that there is some increase in IRLM CPU caused by moving from V2.1 to V2.2, generally compensated by the Locking Protocol Level 2 enhancements in a data sharing environment. In a non-data sharing environment, the increase in CPU usage by the IRLM address space is included in the accounting. By maintaining its lock structures in private storage above the 2 GB bar, the IRLM is able to manage many more locks than before. This enables DB2 to manage locks at a smaller granularity, resulting in less lock contention. 4.6.3 Recommendations 4.7 Unicode Since IRLM V2.2 can manage many more locks than IRLM V2.1, you may consider increasing NUMLKTS (maximum number of locks per table space before lock escalation occurs) or NUMLKUS (number of lock per user before a resource unavailable occurs). Because the lock structures no longer reside in ECSA, considerable ECSA storage is now freed up in V8 and can be used by other subsystems (such as WebSphere) and other applications. This is good news for MVS Systems Programmers. Since the space required to maintain each individual lock has increased, some large DB2 installations, such as large SAP R/3 environments, should consider a MEMLIMIT of 4 GB for their IRLM. However, the same rules apply for the storage areas that move above the 2 GB bar in DBM1. Make sure there is enough real storage to back this up. V8 vastly improves DB2’s support for Unicode and lifts many of the limitations that existed in V7. For example, when DB2 has been migrated to V8 new-function mode, the DB2 catalog is converted to Unicode. In addition all the SQL statements must be parsed as Unicode, even in CM, while DB2 V8 NFM allows you to combine different encoding schemes, CCSIDs, in the same SQL statement. As a result, DB2 now must perform much more code page conversion than ever before, which potentially impacts performance. In this section we discuss the major improvements that have occurred in converting to and from Unicode. These improvements come from three major sources; improvements in the zSeries processor hardware, improvements in the z/OS Conversion Services, and optimization inside DB2 V8. For details, see the new manual DB2 UDB Internationalization Guide available from: http://www.ibm.com/software/data/db2/zos/v8books.html Another source of information is the article titled “Unicode Performance in DB2 for z/OS”, by Jeffrey Berger and Kyoko Amano, published in The IDUG Solutions Journal Volume 11 Number 2. DB2 V8 supports three types of encoding schemes: EBCDIC, which is used by mainframe environments, ASCII, which is used by Unix and Windows environments, and more recently, Unicode. We identify the character set for a language by a numeric CCSID. A CCSID encoding scheme consists of a single byte character set (SBCS), and optionally a double byte character set (DBCS) along with a mixed character set. Over time each geography developed their own EBCDIC or ASCII encoding schemes. The variety of CCSIDs made it very difficult for 174 DB2 UDB for z/OS Version 8 Performance Topics
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
Page 1:
ibm.com/redbooks Front cover DB2 UD
Page 4 and 5:
Note: Before using this information
Page 6 and 7:
2.5.3 Increased number of deferred
Page 8 and 9:
4.5.2 Conclusion . . . . . . . . .
Page 10 and 11:
7.4.1 ODBC Unicode support . . . .
Page 12 and 13:
x DB2 UDB for z/OS Version 8 Perfor
Page 14 and 15:
3-48 Consistency query - 31 New . .
Page 16 and 17:
xiv DB2 UDB for z/OS Version 8 Perf
Page 18 and 19:
8-5 CF Request Batching - DB2 CPU .
Page 20 and 21:
xviii DB2 UDB for z/OS Version 8 Pe
Page 22 and 23:
Trademarks The following terms are
Page 24 and 25:
Added information The following APA
Page 26 and 27:
► Added reference to June 15, 200
Page 28 and 29:
Michael Parbs is a DB2 Specialist w
Page 30 and 31:
Hugh Smith Jim Teng John Tobler Yoi
Page 32 and 33:
xxx DB2 UDB for z/OS Version 8 Perf
Page 34 and 35:
1.1 Overview 1.1.1 Architecture IBM
Page 36 and 37:
- Column data type changes can be d
Page 38 and 39:
1.1.3 Data warehouse 1.1.4 Performa
Page 40 and 41:
Volatile (or cluster) tables, used
Page 42 and 43:
In this chapter we anticipate the a
Page 44 and 45:
2.1.3 I/O time 2.1.4 Virtual storag
Page 46 and 47:
► The performance benchmarks for
Page 48 and 49:
application that can have great pot
Page 50 and 51:
Because you can significantly incre
Page 52 and 53:
The possible increase in thread foo
Page 54 and 55:
2.5.9 Unicode parser Important: Con
Page 56 and 57:
You can keep the DBRMs in EBCDIC fo
Page 58 and 59:
Macro Parameter Old value New value
Page 60 and 61:
28 DB2 UDB for z/OS Version 8 Perfo
Page 62 and 63:
► Parallel sort enhancement Paral
Page 64 and 65:
Characteristics of the host variabl
Page 66 and 67:
3.1.4 Performance Update 10 rows us
Page 68 and 69:
► Complexity of the fetch. The fi
Page 70 and 71:
► More rows per one SQL statement
Page 72 and 73:
3.2.1 Creating MQTs MQTs compared t
Page 74 and 75:
Special register CURRENT REFRESH AG
Page 76 and 77:
the materialized query table. If it
Page 78 and 79:
Figure 3-9 MQTs and short running q
Page 80 and 81:
► The elapsed time is 22 times sm
Page 82 and 83:
Figure 3-13 Regrouping on MQT resul
Page 84 and 85:
EVE.EXT = 'ADD BILL' AND EVE.TXC =
Page 86 and 87:
Star Schema Figure 3-15 Star schema
Page 88 and 89:
merge joins and work file usage. DB
Page 90 and 91:
Star join access path without a spa
Page 92 and 93:
3.3.4 Performance Sparse index for
Page 94 and 95:
V8 Star Join Access Path Figure 3-2
Page 96 and 97:
3.3.5 Conclusion Star join workload
Page 98 and 99:
. SELECT * FROM PAOLO.TORDER WHERE
Page 100 and 101:
But not all mismatched numeric type
Page 102 and 103:
V8 shows that PL is joined with CV
Page 104 and 105:
Query performance problem Lack of m
Page 106 and 107:
3.5.1 Performance SORTDEVT SYSDA IN
Page 108 and 109:
3.5.2 Conclusions Figure 3-31 Acces
Page 110 and 111:
Mismatched data types SELECT COUNT(
Page 112 and 113:
3.7.1 Performance In V8 the paralle
Page 114 and 115:
3.7.2 Conclusions Example 3-9 Multi
Page 116 and 117:
3.8.2 Performance We show three exa
Page 118 and 119:
3.8.3 Conclusion The measurements s
Page 120 and 121:
100 Inserts activated trigger 100 t
Page 122 and 123:
3.10.2 Conclusion 100 Inserts activ
Page 124 and 125:
stores the selected columns from ea
Page 126 and 127:
While there is no optimistic lockin
Page 128 and 129:
FETCH FROM Figure 3-45 FETCH syntax
Page 130 and 131:
► Measurement data collected with
Page 132 and 133:
application has decidedly higher Cl
Page 134 and 135:
Static updatable cursor You can see
Page 136 and 137:
Multi-row FETCH with a static curso
Page 138 and 139:
3.12.5 Conclusion Multi-row FETCH a
Page 140 and 141:
While, for or SELECT ... FROM ...
Page 142 and 143:
3.14.2 Conclusion Percent reduction
Page 144 and 145:
3.15.1 Installation commands. Of co
Page 146 and 147:
Figure 3-47 Explain of the old cons
Page 148 and 149:
in ms = 1 and the CPU cost is 16 se
Page 150 and 151:
Figure 3-50 Suggested RUNSTATS stat
Page 152 and 153:
Looking at the explanation, we can
Page 154 and 155:
The Plug-In Options screen of Stati
Page 156 and 157: Before the introduction of MQTs, DB
Page 158 and 159: 126 DB2 UDB for z/OS Version 8 Perf
Page 160 and 161: ► Larger VSAM CI sizes: DB2 V8 in
Page 162 and 163: 4.1.1 Performance support caused al
Page 164 and 165: Regression is about 5% better than
Page 166 and 167: The results indicate no significant
Page 168 and 169: Important: 4.1.2 Conclusion If you
Page 170 and 171: However, the combined impact of oth
Page 172 and 173: Frees up space below the bar for ot
Page 174 and 175: from the hiperpools, they were not
Page 176 and 177: So, we advise you to not overalloca
Page 178 and 179: See 4.3, “Monitoring DBM1 storage
Page 180 and 181: Table 4-4 System storage configurat
Page 182 and 183: Stack 11356 21033 85% 8648 19799 12
Page 184 and 185: KB 600 500 400 300 200 100 0 Figure
Page 186 and 187: For the same buffer pool size and o
Page 188 and 189: 4.2.3 Conclusion Nondistributed per
Page 190 and 191: Important: With PTFs UK04394 (DB2 V
Page 192 and 193: - DATASPACE BP CONTROL BLOCKS = 0 M
Page 194 and 195: The EXTENDED REGION SIZE (MAX) is t
Page 196 and 197: RDS OP POOL (MB) N/A RID POOL (MB)
Page 198 and 199: As you can now appreciate, it is im
Page 200 and 201: Megabytes A V7 Customer DBM1 Thread
Page 202 and 203: 4.5.1 Performance The most buffer p
Page 204 and 205: 4.6.1 Performance maintained in a 2
Page 208 and 209: service for Unicode conversions, an
Page 210 and 211: overcome this, when DB2 Connect is
Page 212 and 213: INSERT HV1 1200 HV2 1200 SELECT HV1
Page 214 and 215: AIX C-program Conversion Routines P
Page 216 and 217: 4.7.1 Performance The improvements
Page 218 and 219: In October 2003, a new enhancement
Page 220 and 221: UseServerEncoding data source prope
Page 222 and 223: 4.8.1 Performance 4.8.2 Conclusion
Page 224 and 225: Multilevel security with row-level
Page 226 and 227: ► The security level that defines
Page 228 and 229: DB2 must call RACF for this dominan
Page 230 and 231: 4.9.2 Conclusion The CPU increase c
Page 232 and 233: 4.10.1 Performance VSAM does not kn
Page 234 and 235: 4.10.2 Conclusion 4.10.3 Striping A
Page 236 and 237: 5 4 3 2 1 0 9109TLLB 4 Parallel DB2
Page 238 and 239: --------------------------- -------
Page 240 and 241: This message is completed with the
Page 242 and 243: This enhancement is introduced by P
Page 244 and 245: This record is activated by: -START
Page 246 and 247: an online transaction with very sim
Page 248 and 249: 216 DB2 UDB for z/OS Version 8 Perf
Page 250 and 251: 5.1 System level point-in-time reco
Page 252 and 253: BACKUP SYSTEM During backup DB2 rec
Page 254 and 255: Figure 5-1 FRBACKUP PREPARE elapsed
Page 256 and 257:
Figure 5-4 BACKUP SYSTEM FULL measu
Page 258 and 259:
5.1.2 Conclusion The BACKUP SYSTEM
Page 260 and 261:
Figure 5-7 shows the sliding scale
Page 262 and 263:
Maybe you have implemented a space
Page 264 and 265:
For dynamically prepared queries, D
Page 266 and 267:
► CHAR(8) to VARCHAR(8) ► CHAR(
Page 268 and 269:
Before ALTER INDEX add column, a ta
Page 270 and 271:
30 25 20 15 10 Figure 5-12 FETCH CP
Page 272 and 273:
Percent of index pages Avg. Index L
Page 274 and 275:
300 250 200 time in seconds 150 100
Page 276 and 277:
REORG REBALANCE We executed and mea
Page 278 and 279:
5.4 Volatile table 5.4.1 Conclusion
Page 280 and 281:
If explicit clustering for a table
Page 282 and 283:
Load table of 20M rows, 10 partitio
Page 284 and 285:
Times in seconds 20 18 16 14 12 10
Page 286 and 287:
RUNSTATS INDEX PARTITION of a DPSI
Page 288 and 289:
Note that when the qualified partit
Page 290 and 291:
► “NO” - Values in such colum
Page 292 and 293:
5.6.10 Support for more than 245 se
Page 294 and 295:
6.1 Online CHECK INDEX Online CHECK
Page 296 and 297:
SORTOUT DD UNIT=SYSDA,SPACE=(CYL,(5
Page 298 and 299:
- SORT 6 indexes in parallel - CHEC
Page 300 and 301:
make DB2 take the maximum paralleli
Page 302 and 303:
6.3 LOAD and UNLOAD delimited input
Page 304 and 305:
6.3.2 Conclusion We measured the CP
Page 306 and 307:
Options for cardinality and distrib
Page 308 and 309:
► Number of column groups: 1 ►
Page 310 and 311:
cases is the total time of RUNSTATS
Page 312 and 313:
6.4.5 Conclusion Statistics Advisor
Page 314 and 315:
goals for end-user services. We sho
Page 316 and 317:
alanced across all members. With th
Page 318 and 319:
method. Prior to DB2 V8 those array
Page 320 and 321:
when compared to DB2 V7. At the ser
Page 322 and 323:
7.2.2 Performance - Distributed cli
Page 324 and 325:
Recommendation If you currently do
Page 326 and 327:
► The DB2 Universal JDBC type 4 D
Page 328 and 329:
WebSphere z/OS - DB2 z/OS V8 - Serv
Page 330 and 331:
DB2 Universal Type 4 Driver - JDBC
Page 332 and 333:
Use DB2 Connect when a high amount
Page 334 and 335:
JCC Type 4 Direct 4:3 Concentration
Page 336 and 337:
The SYSIBM.INDOUBT table and the pa
Page 338 and 339:
Batch updates A batched update is a
Page 340 and 341:
Example In DB2 V8 SQL/XML publishin
Page 342 and 343:
INSERT INTO PUB_TAB(DOC) SELECT XML
Page 344 and 345:
7.5.3 Conclusion The new XML publis
Page 346 and 347:
A second role of the managed server
Page 348 and 349:
7.6.3 Performance The following inf
Page 350 and 351:
318 DB2 UDB for z/OS Version 8 Perf
Page 352 and 353:
Impact on coupling facility: You do
Page 354 and 355:
Table 8-1 shows extracts from DB2 P
Page 356 and 357:
and secondary GBP structures have t
Page 358 and 359:
DB2 member already has the table sp
Page 360 and 361:
8.2.1 Performance We ran a number o
Page 362 and 363:
esolve any contention. This extra a
Page 364 and 365:
There is also no need to use RELEAS
Page 366 and 367:
Table 8-12 DB2 I/O CI Limit Removal
Page 368 and 369:
8.5 Miscellaneous items In this sec
Page 370 and 371:
DB2 V8 improves Restart Light. If i
Page 372 and 373:
Page 374 and 375:
9.1 Unicode catalog DB2 for z/OS su
Page 376 and 377:
that all applications are converted
Page 378 and 379:
- CLASST: Specifies the threshold a
Page 380 and 381:
From these measurements we observe
Page 382 and 383:
Class 1 CPU time (MSEC) 200 150 100
Page 384 and 385:
dynamic statement cache. If activat
Page 386 and 387:
that everything is ready. This step
Page 388 and 389:
Table Number of rows SYSDATABASE 75
Page 390 and 391:
In Figure 9-7 we describe the perfo
Page 392 and 393:
Old - Query 5 New - Query 5 CPU (se
Page 394 and 395:
Query 35 36 Old DSNTESQ CPU 1 hr 1
Page 396 and 397:
10.1 DB2 Estimator DB2 Estimator V8
Page 398 and 399:
- REAL AND AUXILIARY STORAGE This i
Page 400 and 401:
Another use is during back out of a
Page 402 and 403:
In DB2, the IBM Data Encryption too
Page 404 and 405:
The utilities ran on a G7 Turbo wit
Page 406 and 407:
time Figure 10-1 DB2 HPU vs. UNLOAD
Page 408 and 409:
DSNTIAUL with multi-row fetch The r
Page 410 and 411:
A.1 Maintenance for DB2 V8 The APAR
Page 412 and 413:
APAR # Area Text PTF and Notes PQ88
Page 414 and 415:
Page 416 and 417:
APAR # Area Text PTF and Notes PK21
Page 418 and 419:
Page 420 and 421:
Page 422 and 423:
Page 424 and 425:
Page 426 and 427:
B.1 DB2 PE Storage Statistics trace
Page 428 and 429:
Storage heading Description 24 BIT
Page 430 and 431:
Page 432 and 433:
C.1 DB2 SQL PA additional reports N
Page 434 and 435:
|is the last matching predicate. Ap
Page 436 and 437:
|ANL6052I *** NOTE: | |This index i
Page 438 and 439:
PREDICATE ANALYSIS ----------------
Page 440 and 441:
D.1 DB2 EXPLAIN EXPLAIN describes t
Page 442 and 443:
Table D-2 PLAN_TABLE contents and b
Page 444 and 445:
Column Type Content SORTC_ORDER BY
Page 446 and 447:
Column Type Content OPTHINT CHAR(8)
Page 448 and 449:
D.1.3 DSN_FUNCTION_TABLE You can us
Page 450 and 451:
Example: D-1 Creating DSN_STATEMENT
Page 452 and 453:
Column Type Content BIND_QUALIFIER
Page 454 and 455:
Page 456 and 457:
ICF integrated catalog facility ICF
Page 458 and 459:
► DB2 UDB for z/OS V8: Through th
Page 460 and 461:
Page 462 and 463:
character set 174 CHECK DATA 262 CH
Page 464 and 465:
Equi-join predicates 54, 402 Equiva
Page 466 and 467:
MINSTOR 145-146 Mismatched data typ
Page 468 and 469:
PQ84160 378, 387 PQ85764 387 PQ8584
Page 470 and 471:
Sort tree nodes 144 SORTDATA 268 SO
Page 472 and 473:
306 Universal Driver for SQLJ and J
Page 474 and 475:
Page 476:
DB2 UDB for z/OS Version 8 Performa
show all

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?