©Copyright IBM Corp. 1999 3
Chapter 1. Introduction
Auxiliary storage management in the DB2 environment for the MVS platform has,
so far,been mainly the responsibility of the database administrators.
In thef irstfew years of its usage, DB2’s implicit definition of page sets through its
Storage Groups (STOGROUP)often replaced the more traditional method of
explicitlyallocating VSAM data sets because of DB2’s simplicity and ease of use.
Database administratorsworried about separation of critical data sets, like data
from indexes,data from log, copies of log and BSDS, spreading workfiles,
through the usage of multiple Storage Groups and the careful association of
volumes to StorageGroups.
Until onlyfew years ago, operators, storage managers, system programmers and
performance analysts had to interactf requentlywith the database administrators
in order to resolve issues relatedt o DB2 data set management. Furthermore,
database administratorsdid notlook favorablyat SMS space management
because they feltthat it interfered with the hand-placement of critical DB2 data
sets; SMS usage was limited to some hierarchical management of backup data
sets (image copies and archivedlogs).
Today, on one side we have a growingnumber ofdata warehousing types of
applicationswhich require very large table spaces and query parallelism, causing
an explosion of the number of DB2 objects; on the other side we have more
flexiblefunctions in SMS related products and innovative changes in the disk
architecture that can providever y usefulf unctions forspace and back-up
management. Most medium to large DB2 installations have to devotequite a
considerableam ountof resources to the management of several thousand DB2
objects.
Furthermore, as processors and disk control units providemore capacity and
more memory,DB2 exploits its larger buffer pools as a second level of cache for
I/O execution,reducing the I/O frequency and making it m ostlyasynchronous.
This implies that the criticalityof data set placement is greatly reduced.
In this redbook, as a levelset, first we examine DB2 data set and I/O
characteristics,then we look atthe main concepts and functions of SMS, and
then at the recent evolution of storage servers (disks).
We then provide a mapping of the possible applicability of SMS for all but the
most critical applications.This allows the database administrators to concentrate
on DB2 data setsrelative to the applications with the highest service level
requirements, whilethe s torageadministrators can use SMS to simplify disk use
and control.
We finally look at the impact that large cache and the virtual architecture of the
current disk technologyhave on dealing with DB2 data.
Because of the necessity to monitor performance to avoidsur prises, we also
show how to look at DB2 and I/O performance tools output from the overall
storage management perspective.Several examples are reported in the
appendixes.