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

ISCAN
(Mat)
3.3.3 Sparse index
In memory work file (IMWF)
S
Outside-in
SCAN
IMWF
In-memory
workfiles
Figure 3-16 In memory work file - Description
NLJ NLJ
NLJ
SCAN ISCAN SCAN
S S
IMWF
Dimension D (Time)
D (Store)
SALES
(300M)
Inside-out
NLJ +
IMWF
The in memory work file is used for caching the data and index keys in a dedicated virtual
memory pool. If IMWF fails (for whatever reason), sparse index on the work file is used.
IMWF characteristics:
► IMWF reduces contention on the work file buffer pool
► IMWF reduces CPU and work file I/O
► The memory pool is created only when star join is enabled
► Can specify the maximum pool size via DSNZPARM SJMXPOOL
► SJMXPOOL is changeable from 0 to 1024 MB.
– 20 MB is the default
– Memory pool is allocated at execution time above the bar
► Exact amount of required space is allocated
► The pool contains only the join column and the columns selected
► Binary search via in memory index keys
► If the dedicated pool cannot be allocated or the space in it becomes insufficient to store
the data, the traditional sparse index is used; that is, a work file is created.
In this section we describe the implementation of a sparse index on the work file during star
join execution. The difference between a normal and a sparse index is in the regular index
there is one entry for each row in the table and in the sparse index there is one entry for
several rows that have the same key. Sparse index was first introduced in DB2 V4 for
uncorrelated IN subqueries.
► In DB2 V7 sparse index can only be used during INSIDE-OUT processing
► In DB2 V8 in both inside-out and outside-in, but only if IMWF cannot be used
IMWF
NLJ
SCAN
IMWF
Dim Dim Dim Dim Dim
NLJ
ISCAN
Dimension
Chapter 3. SQL performance 57