Filter
Top Products
© 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 the first few years of its usage, DB2’s implicit definition of page sets through its
Storage Groups (STOGROUP) often replaced the more traditional method of
explicitly allocating VSAM data sets because of DB2’s simplicity and ease of use.
Database administrators worried 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 Storage Groups.
Until only few years ago, operators, storage managers, system programmers and
performance analysts had to interact frequently with the database administrators
in order to resolve issues related to DB2 data set management. Furthermore,
database administrators did not look favorably at SMS space management
because they felt that 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 archived logs).
Today, on one side we have a growing number of data warehousing types of
applications which require very large table spaces and query parallelism, causing
an explosion of the number of DB2 objects; on the other side we have more
flexible functions in SMS related products and innovative changes in the disk
architecture that can provide very useful functions for space and back-up
management. Most medium to large DB2 installations have to devote quite a
considerable amount of resources to the management of several thousand DB2
objects.
Furthermore, as processors and disk control units provide more 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 mostly asynchronous.
This implies that the criticality of data set placement is greatly reduced.
In this redbook, as a level set, first we examine DB2 data set and I/O
characteristics, then we look at the 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 sets relative to the applications with the highest service level
requirements, while the storage administrators 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 technology have on dealing with DB2 data.
Because of the necessity to monitor performance to avoid surprises, 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.