Paolo Bruni, Hans Duerr, Daniel Leplaideur, Steve Wintle
International Technical Support Organization
www.redbooks.ibm.com
SG24-5462-00
International Technical Support Organization
Storage Management with DB2 for OS/390
September 1999
SG24-5462-00
Take Note!
Before using this information and the product it supports, be sure to read the general information in Appendix F,
“Special Notices” on page 239.
First Edition (September 1999)
This edition applies to Version 5 of DB2 for OS/390, Program Number 5655-DB2, and Version 1 Release 4 of
DFSMS/MVS, Program Number 5695-DF1, unless otherwise stated.
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. QXXE Building 80-E2
650 Harry Road
San Jose, California 95120-6099
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
Note to U.S Government Users - Documentation related to restricted rights - Use, duplication or disclosure is subject to restrictions
set forth in GSA ADP Schedule Contract with IBM Corp.
This redbook will help you tailor and configure DFSMS constructs to be used in a
DB2 for OS/390 environment. In addition, this redbook provides a broad
understanding of new disk architectures and their impact in DB2 data set
management for large installations.
This book addresses both the storage administrator and the DB2 administrator.
The DB2 administrator will find information on how to use DFSMS for managing
DB2’s data sets. The storage administrator will find information on the
characteristics of DB2 data sets and how DB2 uses the disks.
After introducing the overall topics of this book, we provide a summary of our
conclusions. This will be especially useful for readers responsible for organizing
and managing DB2 data in an installation.
The Team That Wrote This Redbook
This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization San Jose Center.
Paolo Bruni is a Data Management Specialist for DB2 for OS/390 at the
International Technical Support Organization, San Jose Center, where he
conducts projects on all areas of DB2 for OS/390. Paolo has been with IBM for 30
years and has been mostly working with data base management systems.
Hans Duerr is an independent database consultant, specializing in mainframe
databases, mainly DB2 for OS/390. He has 17 years of experience with DB2 and
has worked for 33 years with IBM in many different countries. He holds a degree
in Engineering from the Universidad Tecnica Federico Santa Maria, Valparaiso,
Chile. He has been an assignee to the ITSO and has published several red books
and conducted workshops in the data management area. Hans is currently based
in Madrid, Spain, from where he supports customers all over the world.
Daniel Leplaideur is a technical marketing support specialist at the EMEA ATSC
SSD Large System Disks in Mainz. He is based in Paris. Daniel joined IBM in
1967 as a mathematician to develop packages for customers. Since then he
worked in the field as Systems Engineer for large accounts. His current areas of
expertise are Large System Disks such as RVAs, Disaster/Recovery with XRC,
PPRC-GDPS, and DFSMS. He teamworks with EMEA local, ISC and Lab people
on ESPs and Disaster/Recovery projects.
Steve Wintle is a systems programmer working for General Electric (Information
Delivery Services division), and is based in the United Kingdom. He has 20 years
of experience in the MVS field. His areas of expertise include operations support
and storage management.
Thanks to the following people for their invaluable contributions to this project:
Mary Lovelace
Markus Muetschard
Hans-Peter Nagel
Alison Pate
To ru Ya ma za ki
International Technical Support Organization, San Jose Center
Ted Blank
John Campbell
Paramesh Desai
Ching Lee
Rick Levin
Roger Miller
Akira Shibamiya
Jim Teng
Horacio Terrizzano
Jeff Todd
Steve Turnbaugh
Jay Yothers
IBM Development, Santa Teresa
Bob Kern
Lee La Frese
IBM Development, Tucson
Jeffrey Berger
Bruce Mc Nutt
Paulus Usong
IBM Development, San Jose
Andrea Harris
Nin Lei
S/390 Teraplex Integration Center, Poughkeepsie
Eneo Baborsky
IBM Italy
Philippe Riou
IBM France
xviiiStorage Management with DB2 for OS/390
Martin Packer
IBM UK
John Burg
Nghi Eakin
IBM Gaithersburg
David Petersen
IBM Washington
Thanks to Elsa Martinez for administration support, Maggie Cutler and Yvonne
Lyon for technical editing, and Emma Jacobs for the graphics.
Comments Welcome
Your comments are important to us!
We want our redbooks to be as helpful as possible. Please send us your
comments about this or other redbooks in one of the following ways:
• Fax the evaluation form found in “ITSO Redbook Evaluation” on page 251 to
the fax number shown on the form.
• Use the electronic evaluation form found on the Redbooks Web sites:
For Internet users
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.
This book describes the exploitation of storage by DB2 for OS/390 (DB2). Two
major areas are analyzed:
1. DB2 and storage management
2. DB2 and storage servers
This chapter summarizes the major conclusions of this project.
2.1 DB2 and Storage Management
A detailed analysis of the different types of DB2 data sets shows that DFSMS can
automatically manage all of the data sets DB2 uses and requires. However, there
are considerations and choices that need to be made to tailor DFSMS to suit the
individual customer’s systems environment and organization.
In general, a large percentage of your data sets can be managed with DFSMS
storage pools, thus reducing the workload and the interaction of your DB2
database administrators (DBAs) and storage administrators. Only the most
critical data, as defined with service level agreements or as revealed by
monitoring, may require special attention.
2.1.1 Benefits of DFSMS
Using DFSMS, the DB2 administrator gains the following benefits:
• Simplified data allocation
• Improved allocation control
• Improved performance management
• Automated disk space management
• Improved data availability management
• Simplified data movement
See 4.4, “Benefits” on page 32 for more details.
Another very important benefit is that, with DFSMS, the DB2 environment is
positioned to take immediate advantage of available and future enhancements.
For example, the following enhancements are available today to DB2 with the
appropriate level of DFSMS:
•DFSMS1.4
• Space allocation failures are reduced with the support of a maximum
• Image copy with concurrent copy support for RAMAC Virtual Array
number of 255 extents per component of VSAM data set for multivolume
data sets (the limit is 123 data sets for a single volume allocation).
SnapShot.
•DFSMS1.5
• Support for 254 table space or index space partitions or pieces up to 64 GB
with the use of VSAM Extended Addressability for Linear Data Sets; also
4,000 TB support for LOBs.
• DB2 data sharing performance improvement for open/close of data sets
(especially beneficial during DB2 start-up) with Enhanced Catalog Sharing
(ECS); ECS reduces the path length and supports the ICF shared catalog
on the coupling facility.
You can check the Appendix section G.4, “Web Sites” on page 242 for sites on
DB2 and DFSMS reporting the most current information on the supported
functions.
2.1.2 Managing DB2 Data Sets with DFSMS
The DB2 adminstrator can use DFSMS to achieve all the objectives for data set
placement and design. DFSMS has the necessary flexibility to support everything
the DB2 administrator may want. There is no reason whatsoever for not taking
advantage of DFSMS for DB2 data sets.
To achieve a successful implementation, an agreement between the storage
administrator and the DB2 administrator is required so that they can together
establish an environment that satisfies both their objectives.
2.1.3 Examples for Managing DB2 Data Sets with DFSMS
Examples are shown to describe one possible way to manage DB2 data sets with
DFSMS. These examples are not supposed to be a recommendation. The
examples are shown to give an idea on the possibilities that DFSMS offers for
DB2. Each example is just one out of many choices of how a medium to complex
installation may approach the implementation of DB2 data sets with DFSMS.
Many installations may find a simpler implementation more adequate, while
others may want to have a more specific management than the one shown.
2.2 DB2 and Storage Servers
DB2 has some special requirements in the way its storage objects are defined
and utilized. Disk technology has evolved introducing RAID architecture, large
cache, virtual architecture. DBAs and storage administrators need to agree on
common actions in order to take advantage of the available enhancements.
2.2.1 Data Placement
With smaller disk devices, without cache, data locality was important for
performance, to reduce seek and rotation times. The new disk architectures, with
concepts like log structured files and with cache in the gigabyte sizes, have a
noticeable impact on database physical design considerations. Conventional
database design rules based on data set placement are becoming less important
and can be ignored in most cases.
2.2.2 Large Cache
Most storage servers with large cache (greater than 1 GB) ignore the bypass
cache or inhibit cache load requests from the application. They always use the
cache; however, they continue to take into account the specifications of usage
from the applications by just scaling down or up the track retention into the cache
for reuse.
6Storage Management with DB2 for OS/390
Installations having these devices could use sequential caching as an installation
option. Installations with a mixture of devices with large, small, or no cache can
benefit from the bypass cache option.
2.2.3 Log Structured File
Devices using the log structured file technique (like the RVA) do not maintain data
location during data updates. For these devices there exists a concept of logical
location of data, independent from the the physical location. The logical location
is used by the device to present the data to the application: the user sees a
contiguous extent on a 3390 volume, while the data is in reality scattered across
the LSF.
A REORG of a DB2 table space provides a logical sequence of records which
could not be corresponding to a physical sequence. This is a function of the
space management of the storage server.
Worrying about reorganizing data to reclaim space extents is now much less
critical with the new disk architecture. REORG does not need to be run in order to
reclaim fragmented space in this case, only to reestablish the clustering (logical)
sequence and the DB2 internal free space. When the DB2 optimizer chooses
sequential prefetch as a valid access path, the storage server detects the logical
sequential access and initiates pre-staging of the logically sequenced tracks into
cache, providing improvement to the I/O response time for the subsequent
prefetch accesses.
2.2.4 RAMAC Architecture
Disk architecture defines each volume in a logical way through tables. These tables
do an effective mapping between the logical view of the volume onto the disk array
with data and rotating parity physical disks. This means that each I/O operation takes
place to or from several physical disks. However, the host still views only the logical
volume topology, and it bases its optimizing and scheduling strategies on this view,
as it used to do with native 3380 and 3390.
2.2.5 SMS Storage Groups
Volume separation is easy when you have hundreds of volumes available. But
this separation is good only if your volumes have separate access paths. Path
separation is important to achieve high parallel data transfer rates.
Without DFSMS, the user is responsible for distributing DB2 data sets among
disks. This process needs to be reviewed periodically, either when the workload
changes, or when the storage server configuration changes.
With DFSMS, the user can distribute the DFSMS Storage Groups among storage
servers with the purpose of optimizing access parallelism. Another purpose could
be managing availability for disaster recovery planning. This can be combined
with the previous purpose by letting DFSMS automatically fill in these Storage
Groups with data sets, by applying policies defined in the automatic class
selection routines.
Changes to the topology of the Storage Group can be managed to minimize the
application outages. This can be done simply by adding new volumes to the
Storage Group, then managing the allocation enablement (opening it on new
Summary of Considerations7
volumes, closing it on volumes to be removed), and finally removing the volumes
you want to exclude from the Storage Group. All those functions can be
accomplished while the data is on line. Data sets that were unmovable,
never-closed, or never reallocated could be moved using remote copy
techniques, then, after a short outage, the critical application can be switched
onto the new volumes.
2.2.6 Performance Management
Monitoring I/O performance of DB2 requires also teamwork between DB2 and
storage administrators to adopt a common approach with tools of both disciplines
in analyzing performance situations. Performance monitoring should be done at
the Storage Group level to have a consistent action.
8Storage Management with DB2 for OS/390
Loading...
+ 244 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.