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

► In memory work file which caches the data and index keys in a dedicated virtual memory
pool
Star join performance is dependent on the circumstances. Your mileage may vary.
3.3.6 Recommendations
The size of the in memory work file can be set on the installation panel DSNTIP8, parameter
STAR JOIN MAX POOL.
The in memory data caching for star join is most effective when the schema contains
snowflakes. Therefore, for the users whose star schema is highly normalized and has many
snowflakes, a larger pool size would be recommended (for example, 256 MB), particularly
when the DB2 subsystem is dedicated to star schema workloads. This virtual storage is
above the 2 GB bar and the real storage use is limited to only the pages touched, so there
should be no significant penalty for those not using star joins and potentially much greater
benefit for those using star joins.
Note: An unfiltered snowflake may not be materialized in V8 in contrast to V7 where all
snowflakes were materialized into work files.
The sparse index support in inside-out phase and part of the new star join access path
selection logic are included in APAR PQ61458 applicable to V7.
After migrating to DB2 V8, specify adequate amounts of memory for maximum pool size in
DSNZPARM SJMXPOOL to gain the benefit of in memory work files in a dedicated virtual
memory pool for star join.
3.4 Stage 1 and indexable predicates
Figure 3-24 shows one example of the execution of one SQL using index and shows the
difference between Stage 1 and Stage 2 predicates, where Stage 1 predicates can be
resolved sooner, without involving complex analysis.
The SELECT statement reads all orders from the table TORDER that has order number
between 15000 and 17000. DB2 specifies the use of the index on column ORDERNO starting
at key value 15000. DB2 uses the index tree to find the leaf page containing the value 15000
and scans forward until it accesses the leaf page containing the value 17000. Then it stops
the scan. GETPAGEs are issued for each index page referenced.
In complex SQL statements with multiple predicates, they are applied in the sequence:
1. Matching index predicate
2. Other index key predicates applied
3. All other stage 1 predicates
4. All stage 2 predicates
If the predicate is applied in the earlier stage, the performance is improved. If the predicate is
used as an argument for a matching index, DB2 does not need to read data pages not
satisfying the predicate. On the other hand, if the predicate is stage 2, DB2 has to read rows
that do not satisfy the predicate and send them to further analysis.
Chapter 3. SQL performance 65