Filter
Top Products
Disk Environment Overview 101
9.5.6 Sequential Data Striping
Sequential data striping provides the opportunity for significant improvement in
sequential processing performance by allowing data to be spread across multiple
devices that are accessed concurrently
transparently to the applications. With
sequential data striping, the data transfer rate may be substantially higher than
the individual device is capable of sustaining.
Sequential data striping is provided as a capability of DFSMS/MVS and it is
available only for DFSMS-managed data sets.
Sequential data striping is currently a capability for BSAM and QSAM. Sequential
data striping should be considered for the sequential processing component of
critical batch jobs, as it may well provide a reduction in elapsed time for those
jobs, and it may spread workload onto several paths: it smoothes the intensive
sequential I/O activity.
DFSMS 1.5.0 extends striping to the data component of VSAM KSDSs, ESDSs,
RRDSs, and VRRDSs (no striping for LDSs yet).
Allocating such VSAM data sets and requesting extended format in the Data
Class as striping with sustained data rate in MB/sec in the Storage Class allows
striped I/O to the data component. VSAM creates the data component in writing
the next control interval to the next stripe in a wraparound way and interspersed
among a stripe group. When sequentially reading, VSAM creates and drives as
many I/O operations independent of each other as the number of available
stripes. Therefore the data aggregate rate for a single data component is
determined by multiplying the transfer rate between control unit and CPU by the
number of stripes.
Sequential data striping works as described above for sequential processing and
when the data is processed for nonshared resources (NSR). Striped I/O does not
apply for direct processing. Direct processing reads only one CI at a time, as do
local shared resource (LSR) and global shared resource (GSR). Record level
sharing (RLS) is also excluded from striped I/O processing. Neither KSDSs with
key ranges nor the IMBED attribute qualify for striping.
The maximum number of stripes is 16. If more than one stripe is forced to use the
same storage path, I/O processing has to complete before the next I/O is started
for another stripe.
When dealing with very large DB2 table spaces to be scanned sequentially,
performance can be greately improved by utilizing partitions and query
parallelism. In DB2 environments, sequential data striping is today of some
interest for log archiving onto disk, or could be considered for some utility work
file activity, or to improve performance for some large standard image copies. A
more widespread usage can be envisioned (for instance to improve the bandwith
on active logs) as soon as striping becomes applicable to VSAM LDS and DB2
introduces its exploitation.