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

4.10.1 Performance
VSAM does not know the DB2 page size, nor the fact that DB2 chains the VSAM CIs to make
up its “logical” page size. VSAM I/Os cannot span cylinder boundaries or data set extent
boundaries. So, we can see by Table 4-12 that if we have a DB2 page size of 32 KB, VSAM
can write 22.5 32 KB DB2 pages per cylinder, (15 X 1.5). A 32 KB DB2 page can therefore
span a cylinder boundary and therefore span DASD volumes. This is not a problem since DB2
chains the physical pages and guarantees the data integrity by ensuring all 8 VSAM pages
are written correctly.
Since a 32 KB DB2 “logical” page can span DASD volumes, restrictions exist in V7 that
Concurrent Copy cannot support 32 KB pages and striping of objects with a page size > 4 KB
is not supported for DB2 data sets. In V7, striping is only allowed to 4 KB page sets and
Concurrent Copy is not allowed for 32 KB table spaces. Concurrent Copy can copy the two
volumes at different points in time; however, a single DB2 32 KB “logical” page can span
these two DASD volumes. A DB2 page should not be allowed to span a CA boundary and in
the case of striping, a CI cannot span a cylinder.
Now, we see what has changed in V8. Consider Table 4-13, which describes the relationship
between DB2 V8 page sizes and VSAM CI sizes.
Table 4-13 DB2 V8 - Sizes in KB (usable track size 48 KB for 3390)
DB2 page size VSAM CI size VSAM physical
block size
VSAM now deals with the 4 different CI sizes, and, knowing the track size, now allows CI size
equal to page size. VSAM writes the CI in a physical block of the same size as the page, but
splits the 32 KB CI over two blocks of 16 KB in order not to waste space due track size (48
KB). It fits the 32 KB CIs 1.5 per track. VSAM also takes care of spanning track boundaries
and operates I/O at the CI level. A 16 KB block is wasted every 15 tracks (CA size) because
the CI cannot span a CA boundary. This is a small price to pay, now that VSAM is aware of
the DB2 page size.
Now VSAM can guarantee a DB2 page does not span CAs and therefore DASD volumes.
The new CI sizes reduce integrity exposures, and relieve restrictions on concurrent copy (of
32 KB objects) and the use of striping (of objects with a page size > 4 KB). It also resolves
small integrity exposure with the Split Mirror solution using FlashCopy on 32 KB pages (SAP)
if at the extent border. A DB2 page now is always written in a single I/O and is totally
contained in the same extent and the same device (even if striping is used).
What happens to I/O performance if we increase the VSAM CI size from 4 KB, to 8 KB, to 16
KB? Preliminary measurements show that large CIs are beneficial for FICON channels and
storage controllers for table space scans. Table 4-14 shows I/O service times on a ESS 800
for 4 KB, 8 KB, 16 KB and 32 KB page sizes, respectively.
200 DB2 UDB for z/OS Version 8 Performance Topics
Blocks per track DB2 pages per
track
4 4 4 12 12
8 8 8 6 6
16 16 16 3 3
32 32 16 3 1.5