Advanced Technical Support (ATS), Americas

DB2 and Storage Management, a Guide to Surviving a Perfect Marriage BWDB2UG December 2005
John Iczkovits [email protected]

December 2005
IBM Corporation 2005

2005 IBM Corporation

Intent of this Presentation

This presentation is not intended to make DB2 professionals into Storage Administrators, rather to educate DB2 professionals on major storage related items that impact them. Please keep in mind that your Storage Administrator probably does not know as much about DB2 as you do. They are typically also busy with other products, such as: MVS, IMS, CICS, open edition, etc. Common ground is needed to discuss how DB2 uses storage.
IBM Corporation 2005

For more detailed information see Data Integrity with DB2 UDB for z/OS SG24-7111

IBM Corporation 2005

Agenda

- Skipping through IBM Disk history - Disk Architecture - DFSMS Basics for DB2 Professionals - Utilities - FAQ - References IBM Corporation 2005

Skipping through IBM Disk history How did we get here?

1956

1965

1970

1975

1980

1989

First Disk 350 5-20 MB Total storage

2314 Up to 10 GB Total storage

3330 Up to 1.6 GB Storage per box

3350 635 MB Per unit

3380 10 GB Per string

3390 22.7 GB Per unit

IBM Corporation 2005

RAMAC Array Direct Access Storage Device (DASD) and the RAMAC Array Subsystem - 1994

RVA = RAMAC Virtual Array (1997)

IBM Corporation 2005

RVA - 1997

Up to 840 GB of information storage Virtual Disk Architecture - What it buys you

Enables compression
(different on other IBM boxes)

Hot spot avoidance Dynamic configuration RAID write penalty avoidance 3380 and/or 3390 emulated in one box

Enables performance Enables SnapShot (1997) Reduces IOSQ

Simplifies operations and management

IBM Corporation 2005

RVA - 1997

There is no fixed physical to logical mapping. The RVA dynamically maps functional volumes to physical drives. This mapping structure is contained in a series of tables stored in the RVA control unit.
IBM Corporation 2005

 IBM Corporation 2005

IBM Enterprise Storage Server code named "Shark" - 1999

Scalable from 420GB to 55.9 TB FlashCopy Supports PAV and MA Large cache structures and sophisticated caching algorithms Different than RVA, but still using disk array concept.

IBM Corporation 2005

10

IBM TotalStorage DS8000 Series - 2004

Different than RVA and ESS, but still using disk array concept. Capacity scales linearly from 1.1 TB up to 192 TB FlashCopy Supports PAV and MA With the implementation of the POWER5 Server Technology in the DS8000 it is possible to create storage system logical partitions (LPAR)s, that can be used for completely separate production, test, or other unique storage environments Sequential Prefetching in Adaptive Replacement Cache (SARC) Sophisticated, patented algorithms to determine what data should be stored in cache based upon the recent access and frequency needs of the hosts Prefetching, which anticipates data prior to a host request and loads it into cache Self learning algorithms to adaptively and dynamically learn what data should be stored in cache based upon the frequency needs of the hosts SARC provides up to a 25% improvement of the I/O response time in comparison to the LRU algorithm.
IBM Corporation 2005

11

Disk Architecture

IBM Corporation 2005

12

RAID (Redundant Arrays of Inexpensive Disks) Technology- Disk Type Dependent

RAID RAID RAID RAID RAID RAID RAID RAID

0 - data striping without parity 1 - dual copy 2 - synchronized access with separate error correction disks 3 - synchronized access with fixed parity disk 4 - independent access with fixed parity disk 5 - independent access with floating parity 6 - dual redundancy with floating parity 10 (DS8000 and some ESS) - RAID 0 + RAID 1, no parity

Parity is additional data, internal to the RAID subsystem, that enables a RAID device to regenerate complete data when a portion of the data is missing. Parity works on the principle that you can sum the individual bits that make up a data block or byte across separate disk drives to arrive at an odd or even sum.
IBM Corporation 2005

13

Parallel Access Volumes (PAV) - ESS "Shark" and DS8000

Multiple PAVs

UCBs per logical volume

allow simultaneous access to logical volumes by multiple users or jobs from one system. are simultaneous

Reads Writes

to different domains are simultaneous to same domain are serialized or sharply reduces IOSQ

Writes

Eliminates High

I/O activity, particularly to large volumes (3390 mod 9, 27, and 54) greatly benefits from the use of PAV. GOAL mode management of dynamic PAVs. Static PAVs do not require WLM. Dynamic PAVs and Priority I/O Queueing recommended. paths or channels for a volume is nothing new, but multiple UCBs (MVS IBM Corporation 2005 addresses) for a volume is.

WLM

Multiple

14

Multiple Allegiance (MA) - ESS "Shark" and DS8000

Similar

to PAV, however for more than one LPAR. Unlike PAV, MA is automatically turned on with your IBM disk. I/Os are queued in the

Incompatible

ESS/DS8000
Compatible

I/O (no extent conflict) can run in parallel boxes guaranty data integrity

ESS/DS8000 No

special host software required, however: Host software changes can improve global parallelism (limit extents) system throughput

Improved

Different

workloads have less impact on each other

Useful for Data Sharing!

15

Reduces

PEND time (device busy)

IBM Corporation 2005

VSAM Data Striping - ESS, DS8000, and some RVA

Spreads

the data set among multiple stripes on multiple control units (this is the difference from hardware striping which is within the same disk array) equal amount of space is allocated for each stripe

An

Striped

VSAM data sets are in extended format (EF) and internally organized so that control intervals (CIs) are distributed across a group of disk volumes or stripes. V8 now allows striping for all page types, while V7 only allows striping for 4K pages. See APAR PQ53571 For issues with objects greater than 4K pages prior to DB2 V8.
DB2

Greater

rate for sequential I/O for DB2 active log data sets

Recommended I/O

striping is beneficial for those cases where parallel partition I/O is not possible. For example: segmented tablespace, work file, non partitioning indexes, LOBs, etc.
IBM Corporation 2005

16

Sequential Data Striping

Recommendations
Stripe all possible objects that are input or output for utilities when the associated table space is striped. For example (when the associated table space is striped):
Stripe the image copy data sets Stripe input files for LOADs, etc.

Only disk data sets can be striped.

IBM Corporation 2005

17

FAQ Checkpoint

Is this really a DB2 problem or a disk I/O problem?

I

am a DB2 professional, why should I care about RMF reports, PAVs, MAs, etc.? Doesn't my Storage Administrator deal with all of that?
You

may be partially correct. However, your DB2 data resides on disk. If you do not receive data in a timely manner, then it becomes your problem. All the DB2 EXPLAINs in the world will not clue you into disk related problems. installations will review RMF data for disk performance. Discuss with your Storage Administrator and/or performance team (if one exists) how frequent periodic really is. You may find the answer to be daily, quarterly, or never. Never is not a good idea, quarterly may not be frequent enough. your Storage Administrator and/or performance team know your concerns? They may be tracking 5,000 disk volumes, in which case YOUR volumes may not be their top priority, although it is yours. Is your installation reviewing volumes only above specific disk thresholds?
IBM Corporation 2005

Periodically

Does

18

Disk Cache - Why Storage Administrators think we are unfriendly! page 1 of 2

- at a very high level
Illustration does not include Data Sharing with GBP dependent data, disk perspective is still the same.

UPDATE IBM.JOHN SET SALARY = SALARY + 5000 WHERE NAME='JOHN';

Disk cache
DB200A DB200B DB200C DB200D

DB2 Buffer Pools

Data in buffer pool?

NO

Data in disk cache?

NO

Find data on disk. Read data

YES

YES

Stage data into disk cache

Stage data into buffer pool

Based on DB2 checkpoint or buffer pool thresholds: DB2 destages updated data back down to cache. DB2 sees this as a disk write, even though the write is to cache. Data at this time may or may not remain in the buffer pool depending on why data was destaged. Data is also written to the NVS (Non Volatile Storage) part of the disk controller that is battery backed. If the controller crashes, data is not lost. Based on disk thresholds, cache destages data back down to disk.
19

DB2updates IBM Corporation 2005 data

Disk Cache - Why Storage Administrators think we are unfriendly! page 2 of 2 SELECT * FROM IBM.JOHN; Read only operations do not require data to be destaged to cache.
From a conceptual point, the function of cache and buffer pools are similar. From a storage perspective, DB2 data is typically considered unfriendly because of the relatively low reuse of data in cache. DB2 will use the data residing in the buffer pool when available. It may not require the data in disk cache at all. Read from cache is exponentially faster than from disk. No need to go to disk, find the data, and bring it back through cache. Just because your buffer pool casts out data, it does not mean that it is no longer retained in cache. Newer disk controllers have very large cache sizes and can retain data for longer periods. In DB2 V8. You can allocate very large buffer pools, as long as they are backed by real storage.
IBM Corporation 2005

20

Data IBM disk controllers bring into cache:

Data access is determined through the controllers adaptive
cache.

Random read
record or block staging (page) partial track staging (from the page requested until the end of the track) full track staging Adaptive cache will determine which of the three will be used based on previous use of data whereby anything from as small as one page, or as large as from the page until the end of the cylinder plus the next cylinder will be read in.

Sequential prefetch full track staging prefetch from the page up to the end of the cylinder plus the next cylinder (extent boundary). Actual operation is done on extent boundaries or stage group (an internal construct, depends on rank dimensions). See ZPARM section for SEQCACH.
IBM Corporation 2005

21

CCHH (Cylinder Head) for newer disk

Messages will still show CCHH information for newer disk (RVA, ESS, DS8000). For example: LISTCAT output EXTENTS: LOW-CCHH-----X'079D0000' HIGH-CCHH----X'07AC000E'

CCHH
IEHLIST utility with FORMAT option
EXTENTS NO LOW(C-H) 0 0 1 HIGH(C-H) 0 1 NO LOW(C-H) 1 0 12 HIGH(C-H) 0 14

DSNU538I RECOVER ERROR RANGE OF DSN=dataset name ON VOLUME=volser FROM CCHH=Xcccchhhh TO CCHH=Xcccchhhh CONTAINS PHYSICAL ERROR The disk controller itself will track allocations between the VTOC and where data really resides. Data sets no longer really reside at the CCHH reported.
IBM Corporation 2005

22

Volume Fragmentation - z/OS 1.6 DFSMSdss - page 1 of 3

Because

of the nature of allocation algorithms as well as the frequent creation, extension, and deletion of data sets, the free space on disk volumes become fragmented. This results in:
Inefficient An

use of disk space degradation caused by excessive disk arm movement

increase in space-related abends

Performance An RVA,

increase in the time required for functions that are related to direct access device space management (DADSM) ESS, and DS8000 no longer require volume DEFRAGs!?

The

box itself works differently; the box needs to be DEFRAGed very infrequently (RVA). Individual volumes no longer require DEFRAGs. This is not the case. disk technology is still tied to the old flavor of VTOC.

New

Periodic

DEFRAGs on highly fragmented volumes are still recommended.

IBM Corporation 2005

23

Volume Fragmentation - z/OS 1.6 DFSMSdss - page 2 of 3

ISMF Volume option
VOLUME FREE SERIAL SPACE -(2)-- ---(3)--PTS005 370529 PTS002 414522 % FREE (4)13 15 ALLOC SPACE ---(5)--2400971 2356978 FRAG INDEX -(6)508 537 LARGEST EXTENT ---(7)--24182 23241 FREE EXTENTS --(8)-180 121

ISPF 3.4 Display VTOC Information for volume PTS005

Volume . : PTS005 Unit . . : 3390 Volume Data Tracks . : %Used . : Trks/Cyls: VTOC Data Tracks . : %Used . . : Free DSCBS: Free Space Size . . : Largest . : Free Extents . : Tracks 6,696 437 180 Cyls 393 28

// DSN=TABLE.SPACE.IC, DISP=(NEW,CATLG), VOL=SER=PTS002, SPACE=(CYL,(250,25)) will this allocation work? Find out later in this presentation!

50,085 86 15

75 22 2,962

ISPF 3.4 Display VTOC Information for volume PTS002

Volume . : PTS002 Unit . . : 3390 Volume Data Tracks . : %Used . : Trks/Cyls: VTOC Data Tracks . : %Used . . : Free DSCBS: Free Space Size . . : Largest . : Free Extents . : Tracks 7,491 420 121 Cyls 462 27

50,085 85 15

75 30 2,641

Note the low amount of largest free space. There are extent issues for large data sets!

IBM Corporation 2005

24

Volume Fragmentation - z/OS 1.6 DFSMSdss - page 3 of 3

Solution

- run DEFRAG
free space on volumes

Consolidates Relocates Storage

data set extents on a disk volume to reduce or eliminate free space fragmentation Administrators can use data set FlashCopy V2 for ESS and DS8000 devices or SnapShot for RVAs to provide much faster DEFRAG operations. - Your Storage Administrator may want to use the FRAGMENTATIONIndex keyword. Start the value for FRAGI at 250 and determine if it needs to go lower. FRAGI(250) will only DEFRAG the volume if the fragmentation index is 250 or above.

Recommendation

Drawback:
DEFRAG

processing locks the VTOC (through the RESERVE macro) and the VVDS. The DEFRAG function also serializes on data sets through ENQ or dynamic allocation. What effect will this have on your DB2 data?

BEWARE!

In order to run a DEFRAG, the volume must be offline to all LPARs except for the one running the DEFRAG. The only alternative for a 7x24 installation is to not execute DEFRAGs and add volumes as needed.
CONSOLIDATE keyword attempts to consolidate data set extents and perform extent reduction for data sets that occupy multiple extents. Discuss this with your Storage Administrator! More information later in this presentation.
IBM Corporation 2005

The

25

What Storage Administrators look for in RMF DASD Reports - Four Stages of an I/O Operation
What is causing poor I/O response times?

IOSQ
Device is busy by this z/OS, no PAV UCB aliases are available

PEND
- Device reserved from another system - CMR (CoMmand Reply) delay - SAP overhead - Old causes

DISCONNECT
- Read cache miss -Reconnect miss (ESCON) - Synchronous remote copy - Multiple Allegiance or PAV write extent conflicts - Sequential write hits, rate is faster than controller can accept - CU busy

CONNECT
Channel data and protocol transfer

I/O Response time = IOSQ Time + Pending Time + Connect Time + Disconnect Time IOSQ: Time waiting for the device availability in the z/OS operating system. Pending: Time from the SSCH instruction (issued by z/OS) till the starting of the dialog between the channel and the I/O controller. Disconnect: Time that the I/O operation already started but the channel and I/O controller are not in a dialog. Connect: Time when the channel is transferring data from or to the controller cache or exchanging control information with the controller about one I/O operation.
IBM Corporation 2005

26

RMF Report - What Storage Administrators Look For

RMF - DEV Device Activity 14:48:42 I=35% DEV STG GRP VOLSER NUM SGDB2 CB390 DB200A 9034 CBSM03 9035 WAS600 901F ACTV RESP IOSQ -DELAY- PEND DISC CONN %D %D RATE TIME TIME CMR DB TIME TIME TIME UT RV 2.2 15.9 6.0 3.29 12.04 0.1 0.1 0.5 0 0 0.2 0.0 14.0 24 0

PAV 4 1 4*

LCU

0018 22.058 24.5 0.6 0.5 0.0 0018 0.023 0.7 0.0 0.0 0.0 0018 17.12 14.2 0.0 0.0 0.0

mmm, interesting!

Problem: High disconnect time disk hot spots (in this scenario) Investigate: Did your Storage Administrator front load the disk box? In other words, were your many disk volumes assigned in device order, all within an LSS? This is a relatively common technique. Solution: Swap more active DB2 volumes with less active non DB2 volumes in another LSS. Other solutions are possible. -This applies to newer DASD types as well, but less of an issue with the DS8000. -Just one case where you can dramatically increase DB2 performance without doing anything with DB2. LSS (Logical SubSystem) - controls a set of devices. Disk controllers contain one or more LSSes.
IBM Corporation 2005

27

Ballpark I/O time per page - are you hitting home runs?
Sequential Read or Write 3390, Ramac1, Ramac2 Ramac3, RVA2 ESS E20/ESCON ESS F20/ESCON ESS F20/FICON ESS 800/FICON 4K page 1.6 to 2ms 32K page 14ms Random Read 4K page 20ms 32K page 30ms

0.6 to 0.9ms 0.3 to 0.4ms 0.25 to 0.35ms 0.13 to 0.2ms 0.09 to 0.12ms

6ms 3ms 2ms 1.5ms 1ms

20ms 10ms 10ms 10ms 5ms

30ms 15ms 15ms 15ms 10ms

Sequential based on prefetch whereby one I/O can read in multiple pages. Pages are contiguous, no skip sequential.
IBM Corporation 2005

28

Sequential numbers are also based on pages being in cache, while random reads from disk.

Performance Notes
For 8K and 16K page, interpolate from 4K and 32K page numbers. For skip sequential read or write, i.e. reading or writing of pages which are not contiguous, the time would be somewhere between sequential and random and depends on the distance between pages read or written. I/O time for sequential read or write is prorated on a per page basis, since multiple pages can be read or written by one Start I/O. Read I/O time tends to be faster than write I/O; eg use 1.6 to 1.8ms seq read and 1.8 to2 ms seq write for 3390. Random read I/O time would go down if cache hit.
Formula: We obtained the time per page by dividing an average wait time for one prefetch or deferred write i/o from accounting class 3 by the number of pages read or written. "Sequential read or write" column represents the case in which all pages read or written are contiguous, not skip sequential.
IBM Corporation 2005

29

Disk Space Numbers - 3390 Emulated Volumes

Model 3390-1 3390-2 3390-3 3390-9 * 3390-27 * 3390-54 * Cylinders 1113 2226 3339 10017 32760 65520 Tracks 16695 33390 50085 150255 491400 982800
Bytes/Volume

946 MB 1.89 GB 2.83 GB 8.51 GB 27.84 GB 55.68 GB

Bytes/Track ** 56664 56664 56664 56664 56664 56664

* Storage Administrators refer to 3390 mod 9, 27, and 54 as large-volume support 10017 cylinders, 32760 cylinders, and 65520 cylinders respectively. Mod 54 support can be found in the 2107device PSP bucket. ** Bytes per track refers to the device capacity only. The actual allocation for a DB2 LDS data set is 48 KB, not the total of 56 KB. This allows for 12 - 4K DB2 pages to be allocated per track. Why larger disk sizes? - reduces issues with MVS addresses (maximum number of devices met) - simpler management of storage
IBM Corporation 2005

30

DB2 Device Response Times 60 3390-3 vs. 6 Large Volumes (mod 27)

DB2 Transaction/Query Response Times 60 3390-3 vs. 6 Large Volumes (mod 27)

2095

3505

2101

3535

286

479

286

481

Total I/O rates per second

Total Transaction rates per second

Q = Query response time T = Transaction response time
IBM Corporation 2005

Tests run using Dynamic PAV

31

Extent Consolidation z/OS 1.5 plus

Consolidates adjacent extents for DB2 LDS - VSAM data sets when extending on the same volume. Automatic and requires no action on your part If the extents are adjacent, the new extent is incorporated into the previous extent. 1st extent tracks (seen on ISPF 3.4 Data set level listing) will show allocations more than the primary when extents are adjacent to the primary (see example in two pages). LDS must be SMS managed. There is a dfp limit of 123 extents per volume. Extent consolidation continues even when an LDS exceeds what would have been 123 extents. For example, my allocation is PRIQTY 720 SECQTY 720 which is 1 cylinder primary and secondary and we have an open volumes so that we do not run into another data set, if you insert 190 cylinders worth of data, you will not stop at 123 cylinders for the volume, rather allocate the 190 cylinders and have 1 extent. When extent consolidation is in effect in z/OS V1.5 the secondary space allocation quantity can be smaller than specified or calculated by the sliding scale based on the physical extent number. PTF UQ89517 for APAR PQ88665 corrects this problem by using the logical extent number together with the sliding scale.
IBM Corporation 2005

32

Allocate 10 cylinder primary for VSAM object DSNB, due to volume fragmentation largest cylinder chucks available are 4,3,3. What happens to extents: Prior to allocation: Cylinder 15 head 0 Cylinder 19 head 0 Cylinder 22 head 0 Cylinder 31 head 0 cylinder 18 head cylinder 21 head cylinder 30 head cylinder 33 head 14 (4 cylinders) 14 (3 cylinders) 14 (9 cylinders) 14 (3 cylinders)

Free space

extent

Free space

extent

extent

DSNA

Free space

extent

Non SMS post allocation: Cylinder 15 head 0 Cylinder 19 head 0 Cylinder 22 head 0 Cylinder 31 head 0 cylinder 18 head cylinder 21 head cylinder 30 head cylinder 33 head 14 (4 cylinders) 14 (3 cylinders) 14 (9 cylinders) 14 (3 cylinders)
extent extent extent extent

DSNB

DSNB

DSNA

DSNB

SMS z/OS 1.5 and after, post allocation: Cylinder 15 head 0 Cylinder 19 head 0 Cylinder 22 head 0 Cylinder 31 head 0 cylinder 18 head cylinder 21 head cylinder 30 head cylinder 33 head 14 (4 cylinders) 14 (3 cylinders) 14 (9 cylinders) 14 (3 cylinders)
extent 1 for DSNB extent
IBM Corporation 2005

extent 2 for DSNB

DSNB

DSNB

DSNA

DSNB33

Example extend a data set until you must jump over another data sets extent
CREATE TABLESPACE JOHN PRIQTY 48 SECQTY 48
1st extent tracks . : 1 Secondary tracks Current Allocation Allocated tracks . : 1 . : 0

CREATE TABLE JOHN (ISPF 3.4 Data set listing)

1st extent tracks . : 4 Secondary tracks Current Allocation Allocated tracks . : 4 . : 0

Insert 1,500 rows into JOHN (ISPF 3.4 Data set listing)
1st extent tracks . : 6 Secondary tracks Current Allocation Allocated tracks . : 6 . : 0

Allocated extents . : 1

Allocated extents . : 1

Allocated extents . : 1

After many more inserts into JOHN

1st extent tracks . : 26 Secondary tracks Current Allocation Allocated tracks . : 26 . : 0

Many more inserts into JOHN and extend onto new volume
1st extent tracks . : 28 Secondary tracks Current Allocation Allocated tracks . : 42 . : 0

LISTC showed throughout:

SPACE-TYPE---------TRACK SPACE-PRI--------------1 SPACE-SEC--------------1 TRACKS/CA--------------1
EXTENTS: TRACKS----------------28 TRACKS----------------14

Allocated extents . : 1

Allocated extents . : 2

28 tracks 1 extent
EXTENTS NO 0 LOW(C-H) 17 2

14 tracks 1 extent

IEHLIST LISTVTOC FORMAT HIGH(C-H) NO IBM Corporation 2005 18 14 1 LOW(C-H) 519 0 HIGH(C-H) 34 519 13

PRIQTY and SECQTY are based on KB, so we can specify the following (allocations are slightly higher when DSVCI=YES, and you are allocating a 32K page): 1 track = 48 (see previous page) 1 cylinder =720 (15 tracks * 48 KB per track) <=above 672 is allocated in cylinders due to CA If PRIQTY>1 cylinder and SECQTY<1 cylinder, secondary rounded up to 1 cylinder (CA 1 cyl) If PRIQTY<1 cylinder and SECQTY>1 cylinder, allocations in tracks, not cylinders (CA<1 cyl) Conversions (4K tables, will vary when DSVCI=YES and you are allocating CI greater than 4K, see next page) : PRIQTY to the number of cylinders=PRIQTY/720 PRIQTY to the number of pages = PRIQTY/4 Disk Space Allocations and Extents Number of pages to cylinders = pages/180 Number of pages to PRIQTY=pages*4 Maximum disk volumes a data set can reside on - 59 (dfp limitation) Maximum number of volumes in a DB2 STOGROUP - 133 (DB2 limitation) Maximum size of a VSAM data set is 4GB unless it is defined with a data class that specifies extended format with extended addressability (dfp limitation). However: Maximum simple or segmented data set size - 2 GB Largest simple or segmented data set size - 64 GB (32 data sets * 2 GB size limit) Maximum extents for simple or segmented table space - 8160 (32 data sets * 255 extents per data set) see next page for z/OS 1.7 extent change Maximum size of a partition created with LARGE keyword - 4 GB Maximum size of a partition created with DSSIZE keyword - 64 GB (depending on page size) Largest table or table space - 128 TB (32K partitioned table * (32 GB*4096 parts or 64 GB*2048 parts)) 35 IBM Corporation 2005 CREATE INDEX with the PIECESIZE keyword can allocate smaller data sets

Extents: Non-VSAM Non-VSAM PDS

Disk Space Recommendations (even with newest technology)

(e.g.: image copies), non-extended format data sets: up to 16 extents on each volume (e.g.: image copies), extended format data sets, up to 123 extents per volume

(e.g.: DB2 libraries) up to 16 extents - one volume max (see FAQ section) up to 123 extents - one volume max

PDSE VSAM

data sets, up to 255 extents prior to z/OS 1.7 per component, but only up to 123 extents per volume per component (123 extents per volume in z/OS 1.7 as well). Starting with z/OS 1.7 theoretical new maximum extents for SMS managed VSAM objects (Data Class Extent Constraint Removal must be set to YES):
123

extents per volume * 59 volumes (both dfp limitations per component) = 7,257 extents

Striped Allocate

VSAM data sets, up to 4080 extents per data component (16 stripes (volumes) max for VSAM*255 extents per stripe). With z/OS 1.7 the 255 extents maximum is removed for SMS managed components. objects on cylinder boundary SQL SELECT and INSERT performance

Improved 2x

improvement relative to track allocation still matter:

Extents For

performance of objects with small secondary allocations (e.g. 1 track), increase the secondary quantity for small objects to avoid many multiple extents, which will cause significant performance penalties. running out of extents for all size data sets DSVCI=YES 32 KB CI over two blocks of 16 KB in order not to waste space due to track usage (48 KB)
DB2 page size 4 8 16 32 VSAM CI size V7/V8 4 4/8 4/16 4/32 VSAM physical blocks per track block size V7/V8 V7/V8 4 12 4/8 12/6 IBM Corporation 2005 4/16 12/3 4/16 12/3 DB2 pages per tracks 12 6 3 1.5

Avoid With

splits A

16 KB block is not used every 15 tracks (CA size) because the CI cannot span a CA boundary

36

Recommendations (even with newest technology) DB2Disk V8 Space with DSVCI=YES for 32K pages 1 cylinder CA

Track 1 16K 16K

Track 2 16K 16K

Track 15 16K 16K Not Used

16K 16K Without DSVCI=YES 1 cylinder CA Track 1

4K 4K 4K 4K 4K 4K 4K 4K 4K 4K 4K 4K DB2 page size 4 8 16 32

Track 2
4K 4K 4K 4K 4K 4K 4K

Track 15
4K 4K 4K 4K 4K

4K 4K

Lose 16K (2.2%) every 15th track, but we will give it back, see ZPARM section.

No data integrity issue, a page can not span volumes! This is what makes the BACKUP SYSTEM utility work without QUIESCE!

4K VSAM CI size 4K V7/V8 4 4K 4K 4/8 4/16 4K 4/32

4K VSAM physical blocks per track 4K block size V7/V8 V7/V8 4 12 4K 4/8 12/6 4K IBM Corporation 2005 4/16 12/3 4K 4/16 12/3

Since CISIZE is 4K extending row to the next cylinder is not pages per an DB2 issues. This however could tracks cause a data 12 integrity problem if the next 6 extent spans to a 37 3 new volume (backup and striping 1.5 issues)!

APAR - PQ53571 (BELOW DB2 V8!)

00C20111

Explanation: An attempt was made to access a data set with a page size of 8K, 16K or 32K that is defined with multiple stripes. DB2 does not permit 8K, 16K or 32K page size data sets to be striped because partial writes cannot always be detected.

System Action: A resource not available code is returned to the user. This reason code and the data set name are made available to the user in the SQLCA. IBM Corporation 2005
38

Simplified data allocation

Improved allocation control

Improved performance management

DFSMS Basics for DB2 Professionals

Automated disk space management Improved data availability management Simplified data movement
IBM Corporation 2005

39

Managing Data With SMS

No SG info!

ISPF 3.4 Data Set General Data Management class Storage class . Volume serial . Device type . . Data class . . .

listing: . . . . . . . . . . : : : : : MCDB2 SCDB2 DB2810 3390 DCDB2

ACS (Automatic Class Selection) Routines

What does it look like? What are its requirements? Where is it placed?

Data Class

Storage Class

Management Class

Storage Group
40

ACS routines invoked in order (DC,SC,MC,SG)

IBM Corporation 2005

Data Set Separation - Part of the SMS Base Configuration

Allows

you to designate groups of data sets which are to be physically separated

For

DB2, you may want to consider using this technique for the BSDS and active log data sets. This is an availability benefit for DB2. attempts to allocate the data sets behind different physical control units data set separation profile must be provided

SMS

A

Cannot

be used with non-SMS-managed data sets or with full volume copy utilities such as PPRC. Alternatives:
Create Break

the data set before PPRC is established

the pair after it is established, create the data set, then reestablish the pair

IBM Corporation 2005

41

Interesting Data Class (z/OS 1.6) Information for DB2 Professionals

A

collection of allocation and space attributes - for new data sets only, e.g. - LRECL, BLKSIZE, space, etc. be used for SMS or non SMS managed data sets VSAM and sequential data sets

Can For

Used

for allocating extended addressable (EA) - allocate and access VSAM data sets more than 4 GB in size, extended format (EF - used in conjunction with EA), striped data sets, and PDSEs
Recommendations

- Have the Storage Administrator set only the required DB2 LDSes (table spaces and index spaces) to extended format, this will avoid any EF overhead if not required. FICON recommendation only (not ESCON)! Issue is resolved (MIDAW) with z9 and z/OS 1.6 + PTFs. data sets do not have the same performance penalty, so you may want your Storage Administrator to set all allowable sequential DB2 data sets to EF. At this time. archive log data sets can not be EF managed, unless you use a tool, such as IBMs Archive Log Accelerator. space constraint relief for VSAM and sequential data sets avoids many X37 abends

Sequential

Provides SMS It

can be set up to allocate a percentage of the requested quantity if not enough space is available. This option is not available for data sets using Guaranteed Space.

is possible to set up SMS whereby the 5 extent rule is bypassed for initial allocation, as well as when extending a data set to a new volume. and non-VSAM multistriped data sets do not support space constraint relief. However, singlestriped VSAM and non-VSAM data sets can use space constraint relief. for data sets to be multi volumed - e.g. image copy data sets certain VSAM data sets to exceed the 255 extent limit, see Extent Constraint Removal
IBM Corporation 2005

VSAM Allows Allows

42

Interesting Storage Class (z/OS 1.6) Information for DB2 Professionals - page 1 of 2
Separates

data set performance objectives and availability from physical storage it does not represent any physical storage, but rather provides the criteria that SMS uses in determining an appropriate location to place a data set. determines at this time if a data set is SMS managed or not. Ones that are not do not continue down the ACS routines and stop here. Performance Objectives: Response (MSR) times

SMS

Defining

MilliSecond
Each

device type and model has a predetermined MSR capability Use or non use of disk cache, and performance requirements if used Sustained Data Rate (SDR) - extended format data sets using striping, for VSAM as well as physical sequential the algorithm is for the number of stripes. Defining Availability Determine if the data set is eligible for RAID and/or dual copy volumes Defining Accessibility Point-in-time copy, using either concurrent copy, virtual concurrent copy, or FlashCopy (for ESS and DS8000) Defining the Guaranteed Space Attribute (honor volser request) Not recommended for DB2 user data sets, especially when using PAV and MA (avoids MOST hot spots). DB2 BSDS and active log data sets can still be hand placed using guaranteed space for availability as opposed to performance, even when using PAV and MA. Also review the SMS data set separation profile with your Storage Administrator.
IBM Corporation 2005

43

Interesting Storage Class (z/OS 1.6) Information for DB2 Professionals - page 2 of 2
Other

Specs

Allowance

for multi-tiered SG (Storage Group) - see Storage Group section for additional information if PAV volumes should be part of the Storage Group selection - see Storage Group section for additional information

Determine

Recommendations:
If

your installation has a mix of all types, models, and configurable disk:
Determine

if specific targeted response time rates are required, as well as such things as RAID, and guaranteed space. example: If your installation is all ESS and DS8000, you may not need to worry about these attributes for performance when using PAVs and MA. Place your BSDS and active log data sets on the fastest devices possible (DS8000), leaving your DB2 user data on the ESS. down with your Storage Administrator and determine the best use of data and technology. Do not assume that your Storage Administrator understands DB2 as well as you do.
IBM Corporation 2005

For

Sit

44

Interesting Management Class (z/OS 1.6) Information for DB2 Professionals - page 1 of 3
A

management class is a list of data set migration, backup and retention attribute values, as well as expiration criteria which uses DFSMShsm and DFSMSdss. Some issues to consider are:
Requirements Migration Retention

for releasing over-allocated space

requirements criteria of expired data sets of backup

Treatment Frequency Number

of backup versions of backup versions versions

Retention Number Retain Retain Retain Retain Copy

only version only version unit extra versions extra versions unit data group (GDG) information
IBM Corporation 2005

serialization

Generation

45

Interesting Management Class (z/OS 1.6) Information for DB2 Professionals - page 2 of 3
Recommendations:
BEWARE!

If your Storage Administrator has turned on the 'Partial Release Attribute', DFSMShsm may compress any created VSAM data sets in extended format not using the guaranteed space attribute.

Discuss

with your Storage Administrator the 'GDG Management Attributes' if you are creating GDGs for such things as image copies. Determine how many GDGs should be retained on disk. the SMS Management Class expiration date for DB2 archive logs with the ZPARM value for ARCRETN. DB2 does not automatically expire archive logs. Follow this recommendation only if another product, such as RMM is not already expiring the data for you. the SMS Management Class expiration date for image copy data sets with the DB2 utility MODIFY DELETE date. DB2 does not automatically expire image copy data sets. Follow this recommendation only if another product, such as RMM is not already expiring the data for you. in mind DR situations! ABARS may be used to backup your applications ML1 and ML2 data sets if required.
IBM Corporation 2005

Match

Match

Keep

46

Interesting Management Class (z/OS 1.6) Information for DB2 Professionals - page 3 of 3

ML2

Space Management Activities - DFSMShsm

Level 0 - user volume where data is migrated from ML1 (Migration Level 1) - DFSMShsm owned disk where data can be migrated. Data can then remain on this volume or further migrate to ML2. ML2 (Migration Level 2) - DFSMShsm owned tape or disk (traditionally tape) where data can be migrated to either from ML1 or directly from level 0. Discuss with your Storage Administrator which approach works best for you.
IBM Corporation 2005

47

Interesting Storage Group (z/OS 1.6) Information for DB2 Professionals - page 1 of 3
SMS

uses the Storage Class attributes, volume and Storage Group SMS status, MVS volume status, and available free space to determine the volume selected for the allocation. functions to migrate data sets, backup (data sets incrementally), and dump (volume level) are decided at the Storage Group level.
For

DFSMShsm

Recommendations:

production DB2 environments, do not allow DFSMShsm to migrate or backup (data set level) table spaces or index spaces. However, depending on your installation's backup and recovery scenarios, you may want DFSMShsm to dump (full volume) your volumes, even while DB2 is up. It is much better though if DB2 is down if at all possible. My recommendation for non production environments is the same as for production environments. However, some installations will allow data to be migrated. If you decide to allow for migration, keep in mind ZPARM values for RECALL and RECALLD. Some considerations are: How many objects need to be recalled at the same time? How many objects reside on the same DFSMShsm ML2 tape? Will serial recalls complete in a timely manner?
IBM Corporation 2005

48

Interesting Storage Group (z/OS 1.6) Information for DB2 Professionals - page 2 of 3

SGDB2
High Low
DB200A

Migration and Allocation Thresholds - high and low values

High and low values are set for all volumes in a Storage Group
- If set to 75% for example, it will level all allocations to avoid volumes greater than 75% full - If set to 75%, then it allows for 25% growth in extents -Recommendation, start at 75% and then review -Also used to determine if volume migration will be executed LOW - Used for disk volume migration threshold - Controls the low threshold by percentage of volume that eligible data sets can be migrated, thereby reducing stress on DFSMShsm - e.g., set low value to 50%, migrate after 100 days and now 90% of volume is eligible, only migrate down to 50% - Recommendation, For image copy volumes that need to totally empty all data sets to allow for space for the next image copy run, set the low value 0. Otherwise, set the value higher to reduce the stress on DFSMShsm for 49 IBM Corporation 2005 migration

SGDB2
High Low
DB200B

HIGH - Used for disk volume allocation threshold

SGDB2
High Low
DB200C

Same Storage Group

Interesting Storage Group (z/OS 1.6) Information for DB2 Professionals - page 3 of 3
Extend
Data

SG Name:

sets can be extended from one Storage Group to another, if there is insufficient amount of storage in the primary group. extended SG name can also be an overflow Storage Group. Storage Group:

An

Overflow
An

overflow Storage Group is used when non overflow Storage Groups are above their thresholds. overflow storage group may also be specified as an extended storage group.

An

Discuss Be

with your Storage Administrator if using extended and/or overflow Storage Groups will help you.
aware of where your DB2 data sets are allocated. Review periodically for space related problems and inclusion for SnapShot and FlashCopy operations!
POOL BACKUP STORAGE GROUP - used starting in DB2 V8 to allow new BACKUP function.
IBM Corporation 2005

COPY

50

Multi-Tiered Storage Groups

Specify

Multi-Tiered SG Y in the Storage Class

Example: SET

&STORGRP = 'SG1', 'SG2', 'SG3'

Result: SMS If If If

selects volumes from SG1 before SG2 or SG3.

all enabled volumes in SG1 are over threshold, then SMS selects from SG2. all enabled volumes in SG2 are over threshold, then SMS selects from SG3. all volumes are over threshold, then SMS selects from the quiesced volumes in the same order.

IBM Corporation 2005

51

Why Isn't My Volume Primary? - One example of why my data was allocated to a volume I did not expect

Volume was rejected.

Volume would exceed high threshold.

Storage class accessibility value. Storage class availability value. Data class extended format value.

Volume or storage group is quiesced.

VTOC index is broken or disabled.

Volume does not meet MSR requirement.

Non-zero IART specified in storage class

Controller IMLed online to MVS.

Insufficient volumes in storage group.

SMS can be set up to allow for volumes to be selected as primary, secondary, tertiary, or rejected. Discuss further with the Storage Administrator.
IBM Corporation 2005

52

Differences Between DB2 STOGROUP and SMS Storage Group

DB2 STOGROUP
Different STOGROUPs can share the same disk volume(s) VOLSERs are specific

SMS Storage Group

One disk volume can only belong to one SMS Storage Group Recommendation - code VOLUMES("*") to allow for SMS management. Avoid Guaranteed Space and specific VOLSERs where possible since this defeats the purpose of SMS.

SYSIBM.SYSVOLUMES has a row for each volume in column VOLID Limited to management of 133 volumes Volume selection based on free space

When created with VOLUMES("*") SYSIBM.SYSVOLUMES has an * for column VOLID No volume limit Volume selection based on SMS algorithms

IBM Corporation 2005

53

Copy Pools - BACKUP Command (DB2 V8)

Copy Pool
DSN$DB1P$LG DSN$DB1P$DB

Pool Storage Groups

SGDB2LOG SGDB2CAT SGDB2DAT

Copy Pool Backup Storage Groups

DBP1BKUP

A copy pool is a defined set of pool storage groups that contain data that DFSMShsm can backup and recover collectively, using fast replication. DFSMShsm manages the use of volume-level fast replication functions, such as FlashCopy and SnapShot. Provides point-in-time copy and recovery services. DSN$locn-name$cp-type, DSN and $ are required, locn-name is the DB2 location name, cp-type is the copy pool type. DB is for database. LG is for logs. For example: DB2 DB1P would have copy pools named DSN$DB1P$DB for the database copy pool and DSN$DB1P$LG for the log copy pool. BACKUP command records entry in BSDS, as well as the DFSMShsm 54 IBM Corporation 2005 BCDS.

ZPARMs Relating to Storage Management

IBM Corporation 2005

55

MGEXTSZ - Sliding Secondary Allocation Size (DB2 V8) - page 1 of 4

Applies Tries

to DB2 managed pagesets

to avoid VSAM maximum extent limit errors

Can

reach maximum dataset size before running out of extents. Beware of heavily fragmented volumes, which may impede this feature. This is less of an issue in z/OS 1.7 where an LDS can have 7,257 extents. The sliding secondary rule can exceed 255 extents when Extent Constraint Removal is turned on in z/OS 1.7.

Requires

ZPARM value MGEXTSZ in DSN6SYSP be set to YES, since the default is set to NO. It is set during the DB2 install in panel DSNTIP7 under OPTIMIZE EXTENT SIZING.
Starting

with DB2 V8, sliding secondary is effect whether you specify YES or NO. These values are relate to PRIQTY and SECQTY, or no PRIQTY and SECQTY rather using ZPARM TSQTY=0 and IXQTY=0 (or a mixture of both). What YES or NO refers to:
YES

when allocating a new data set for a new piece (after A001) the primary and secondary allocation will be last size calculated by the sliding secondary of the previous piece. The maximum allocation will not exceed 127 cylinders for objects 16GB or below, and 559 cylinders for objects 32 or 64GB. example, A001 hits the 2GB limit and DB2 now needs to create the A002 data set. A001s last allocation based on sliding scale was 79 cylinders, A002 will be created with a primary and secondary allocation of 79 cylinders.
For

NO

When specifying a value for PRIQTY and SECQTY the new data set (created after A001) will have the same allocation as A001 for primary and secondary and therefore take on the characteristics of A001s PRIQTY and SECQTY. If PRIQTY and SECQTY were not specified then the allocation works as documented in YES above.
IBM Corporation 2005

56

MGEXTSZ - Sliding Secondary Allocation Size (DB2 V8) - page 2 of 4

Uses cylinder allocation

Default PRIQTY
1 cylinder for non-LOB tablespaces and indexes 10 cylinders for LOB tablespaces

Can be used for:

New pagesets: No need for PRIQTY/SECQTY values Existing pagesets: Execute SQL to ALTER PRIQTY/SECQTY values to -1 plus schedule a REORG

PRIQTY honored if used. SECQTY can be used and if higher than what DB2 calculates for an extent for sliding secondary, it will be used, otherwise DB2 calculated number is used.
IBM Corporation 2005

57

MGEXTSZ - Sliding Secondary Allocation Size (DB2 V8) - page 3 of 4

Two

sliding scales will be used depending on the maximum dataset size. The first 127 extents are allocated in increasing size, and the remaining extents are allocated based on the initial size of the data set:
For For

32 GB and 64 GB data sets, each extent is allocated with a size of 559 cylinders.

data sets that range in size from less than 1 GB to 16 GB, each extent is allocated with a size of 127 cylinders.

Maximum

dataset size determined based on DSSIZE, LARGE and PIECESIZE and defaults.

BEWARE!

If your Storage Administrator has set up a LARGE DB2 Storage Group, using this technique will probably not work well, unless you explicitly specify a large enough PRIQTY instead of DB2 implicitly specifying one.

Advantages:
Minimizes It

the potential for wasted space by increasing the size of secondary extents slowly at first prevents very large allocations for the remaining extents, which would likely cause fragmentation. does not require users to specify SECQTY values when creating and altering table spaces and index spaces.

It It

is theoretically possible to always reach maximum data set size without running out of secondary extents. helpful for users of ERP/CRM vendor applications, which have many small data sets that can grow rapidly IBM Corporation 2005
58

Particularly

MGEXTSZ - Sliding Secondary Allocation Size (DB2 V8) page 4 of 4

Sliding Scale for less than 1 GB to 16 GB
140 120 E x t e n tS iz e( C Y L S ) 100 80 60 40 20 0 Extent Number

Maximum allocation of secondary extents

Max DS size Max Alloc in in GB Cylinders 1 2 4 Sliding Scale for 32 GB and 64 GB 8 16 127 127 127 127 127 559 559

Extents to reach full size 54 75 107 154 246 172 255

600 500 E x t e n tS iz e( C Y L S ) 400 300 200 100 0 Extent Number

32 64

IBM Corporation 2005

59

TSQTY and IXQTY (DB2 V8) DB2 V6 and V7 by the PTF for APAR PQ53067
Specifies

the amount of space in KB for the primary space allocation quantity for DB2-managed table spaces (TSQTY) and indexes (IXQTY) which are created without the USING clause.

It

uses cylinder allocation. The default values are set to 0, which means:
Default
1

PRIQTY and SECQTY

cylinder for non-LOB tablespaces and indexes 10 cylinders for LOB tablespaces Autonomic

selection of data set extent sizes with a goal of preventing extent errors before reaching maximum data set size - use with sliding secondary allocation. heavy over-allocation and waste of excessive space.

Prevents Can

also result in better performance of mass inserts, prefetch operations, as well as LOAD, REORG and RECOVER utilities. honored if used.
IBM Corporation 2005

PRIQTY

60

DSVCI - Support for VSAM Control Interval (CI) Greater than 4K (DB2 V8) - page 1 of 2
Support

for CI sizes of 8, 16, and 32 K table spaces. For indexes, only 4K pages are supported. ZPARM value DSVCI in DSN6SYSP be set to YES, which is the default. It is set during the DB2 install in panel DSNTIP7 under VARY DS CONTROL INTERVAL. for DB2 managed as well as user managed DB2 table spaces. DB2 install procedure provides JCL that will convert user defined DB2 catalog table spaces to proper CI sizes during ENFM. User managed table spaces require manual IDCAMS CI change. in NFM for corresponding page sizes of table spaces, which will not take effect until after a LOAD or REORG of the table space. CI sizes:
integrity exposures

Requires

Supported

Activated New

Reduce

Relieves

some restrictions on concurrent copy (of 32K objects) and the use of striping (of objects with a page size > 4K). reduce elapsed time for table space scans

Potentially I/O

bound executions benefit with using larger VSAM CI sizes, including COPY and REORG.
IBM Corporation 2005

61

DSVCI - Support for VSAM Control Interval (CI) Greater than 4K (DB2 V8) - page 2 of 2
Striped

VSAM data sets are in extended format (EF) and internally organized so that control intervals (CIs) are distributed across a group of disk volumes or stripes. A CI is contained within a stripe. your non 4K buffer pool sizes to accommodate new CI sizes.

Increase Some

test results: page measurement with 16K instead of 4K CI

16K

for non EF (Extended Format) datasets +70% for EF datasets EF getting nearly equivalent to non EF in data rate performance Some table spaces may have negative results - test and verify
LISTCAT

+40%

results (SPACE does not change for 8K and 16K table spaces, just

32K):
after

CREATE TABLESPACE to a 4K buffer pool with PRIQTY 72000:

CISIZE--------------4096 PHYREC-SIZE---------4096 PHYRECS/TRK-----------12 SPACE-TYPE------CYLINDER SPACE-PRI------------100

after

CREATE TABLESPACE to a 32K buffer pool with DSVCI=YES: PRIQTY 72000

CISIZE-------------32768 PHYREC-SIZE--------16384 PHYRECS/TRK------------3 SPACE-TYPE------CYLINDER SPACE-PRI------------103

DB2 V7 32K, PRIQTY 72000 CISIZE--------------4096 PHYREC-SIZE---------4096 PHYRECS/TRK-----------12 SPACE-TYPE------CYLINDER SPACE-PRI------------100

62

Notice, DB2 adds the 2.2% IBM Corporation 2005 overhead for you!

SEQCACH
Determine for prefetch if BYPASS or SEQ(uential) is used for cache. Although BYPASS is an acceptable ZPARM value, we no longer bypass cache for the DS8000, ESS, or RVA. 3990 was the last controller to honor BYPASS. BYPASS for DS8000, ESS, or RVA will use sequential detect while SEQ will use explicit command. SEQ (explicit) puts tracks on the accelerated list and starts prestaging for next I/O. Operations are done on extent boundaries or stage group (an internal construct, depending on rank dimensions). Explicit reacts faster and can end sooner than using the detect mechanism (BYPASS). BYPASS (sequential detect) stages data to the end of a stage group (an internal construct, depending on rank dimensions). Recommendation change SEQCACH to SEQ. NOTE BYPASS is the default.
IBM Corporation 2005

63

SEQPRES
Utility cache option. Recommendation set to YES. Default is NO.

IBM Corporation 2005

64

SVOLARC - Single VOLume ARChive - PQ49360

DB2

allocates up to 15 volumes for archive log data sets to allow for space extension onto other volumes.
Problem:

For some SMS users who use guaranteed space for archive log data sets, DB2 may request primary allocation of up to 15 volumes (which it may not need) thereby causing space related problems. include: Message DSNJ103I with ERROR STATUS=970C0000, SMS REASON CODE=00004336 or REASON CODE=00004379 Consider changing to SVOLARC=YES if you want SMS to only allocate one volume to avoid this situation when using guaranteed space.

Symptoms

Solution:

IBM Corporation 2005

65

UNIT and UNIT2 - for DB2 Archive Log Data Sets

It

can be set to the same UNIT type. However, beware of the following:
Problem: Storage

many installations set UNIT and UNIT2 to a disk unit, VTS or use TMM. is allocated to a Storage Group that DFSMShsm sweeps hourly to ML1 or

Administrator sets ACS routines whereby:

ARCHLOG1

ML2. ARCHLOG2 is allocated to a Storage Group that DFSMShsm migrates once every 24 hours. If they stay on ML1 or eventually migrate to ML2, their final residence can land on the same volume which can be a single point of failure. When ML2 tapes are set to MOD (typical scenario): can tear and become unusable Tape can be misfiled by Operator or Tape Librarian Tape is maliciously lost or destroyed Solutions: DFSMShsm to backup the archive data sets before migrating Duplex your ML2 tapes may be an issue after tapes are recycled, then may result in a single point of failure again down the line Transmit a copy of at least one set to another site Split UNIT and UNIT2 between 2 device types, e.g. one to disk, one to tape Use ABARS to copy one of the archives from ML1 or ML2 NOTE: This can happen to any dual copied data set, including image copies. Dual copy data sets residing on VTS or when using TMM can also have a single point of failure. Discuss your requirements with your Storage Administrator,
IBM Corporation 2005

Tape

Allow

66

 IBM Corporation 2005

67

CHECK INDEX and FlashCopy

When using SHRLEVEL CHANGE in DB2 V8:
Drains all writers and forces the buffers to disk for the specified object and all of its indexes Invokes DFSMSdss to copy the specified object and all of its indexes to shadow data sets Enables read-write access for the specified object and all of its indexes Runs CHECK INDEX on the shadow data sets

Note: DFSMSdss uses FlashCopy Version 2 if available. Otherwise, DFSMSdss might take a long time to copy the object, and the time during which the data and indexes have read-only access might increase.
IBM Corporation 2005

68

 IBM Corporation 2005

69

DB2 and SMS

I

hear that DB2 does not work with SMS, is that true?
When

SMS was first introduced many years ago there were some recommendations not to use SMS for DB2 data sets. This recommendation was rescinded about a year or two after SMS was first announced. So, yes, you can fully use DB2 with SMS.

I

hear that my DB2 user data can be SMS managed only and not the system data, is that true?
The

short answer is no. All DB2 data can be SMS managed. As a matter of fact, if you want to use DB2 V8 system level backup and restore, SMS is required for user as well as system data sets.

IBM Corporation 2005

70

Now that my volumes are SMS managed, do I still need to worry about space issues?
Yes.

Your likelihood of getting that 2 a.m. call or visit to your executives office for a chat regarding an outage is greatly reduced. HOWEVER, there are some issues to deal with:
Is

the space you were provided sufficient?

Are

there any unexpected increases that now makes it insufficient? How do I track this now? Who deals with these issues, the Storage Administrator or me?
OK,

I am happy with the space I have, but am I getting the disk performance that will make my customer happy?

These

issues are highly dependent on your relationship with your Storage Administration group.
IBM Corporation 2005

71

Now that my volumes are SMS managed, how can I tell what my volume names are, how much space I have left and how much space I have used?
First, find out what your Storage Group names are. Then, here are some things you can use to find out what the volume names are:
ISMF, option 6 - Storage Group, enter the Storage Group, and enter LISTVOL for a command. You must have Storage Administrator rights in ISMF to do this!
VOLUME FREE SERIAL SPACE -(2)-- ---(3)--CBSM01 2598244 CBSM02 2408773 CBSM03 2566481 % FREE (4)94 87 93 ALLOC SPACE ---(5)--173256 362727 205019 FRAG INDEX -(6)71 40 39 LARGEST EXTENT ---(7)--2112449 2223675 2327430 FREE EXTENTS --(8)-17 24 16

If you know the volser, you can use ISPF 3.4 with option V. You will not see Storage Group information, just volume information:
Volume . : CBSM02 Unit . . : 3390 Volume Data Tracks . : %Used . : Trks/Cyls: VTOC Data Tracks . : %Used . . : Free DSCBS: Free Space Size . . : Largest . : Free Extents . : Tracks 43,530 40,185 24 Cyls 2,898 2,679

50,085 13 15

12 12 531

You can also use DCOLLECT through ISMF or execute IDCAMS. A sample REXX for the output is available in ISMF under Enhanced ACS Management then under SMS Report Generation.
IBM Corporation 2005

72

Any other way I can figure out what volsers are in my Storage Group and what LPARs they are attached to?
If you have SDSF authority to issue MVS commands:
D SMS,SG(CB390),LISTVOL IGD002I 10:54:27 DISPLAY SMS 404 STORGRP CB390 TYPE POOL SYSTEM= 1 2 3 4 5 6 7 8 + + + + + + + +

VOLUME UNIT SYSTEM= 1 2 3 4 5 6 7 8 STORGRP NAME CBSM01 9025 + + + + + + + + CB390 CBSM02 9034 + + + + + + + + CB390 CBSM03 9035 + + + + + + + + CB390 ***************************** LEGEND ***************************** . THE STORAGE GROUP OR VOLUME IS NOT DEFINED TO THE SYSTEM + THE STORAGE GROUP OR VOLUME IS ENABLED - THE STORAGE GROUP OR VOLUME IS DISABLED * THE STORAGE GROUP OR VOLUME IS QUIESCED D THE STORAGE GROUP OR VOLUME IS DISABLED FOR NEW ALLOCATIONS ONLY Q THE STORAGE GROUP OR VOLUME IS QUIESCED FOR NEW ALLOCATIONS ONLY > THE VOLSER IN UCB IS DIFFERENT FROM THE VOLSER IN CONFIGURATION SYSTEM 1 = SYSA SYSTEM 2 = SYSB SYSTEM 3 = SYSC SYSTEM 4 = SYSD SYSTEM 5 = SYSE SYSTEM 6 = SYSF SYSTEM 7 = SYSG SYSTEM 8 = SYSPLEX1
IBM Corporation 2005

73

How many Storage Groups should I have in my production environment? The answer of course is: It depends! Here are my recommendations - page 1 of 2
Production

should have its own storage group for DB2 table spaces and indexes separate from all other environments.
Start

with at least 3 separate Storage Groups - if you will use the DB2 V8 BACKUP and RESTORE SYSTEM (requires z/OS 1.5) you are required to have separate Storage Groups for the BSDS and active log data sets from all other data. The three categories are:
DB2

Catalog and Directory objects BSDS and active log data sets DB2 user data
Discuss

ICF catalog placement strategies with your Storage Administrator in regards to different recovery scenarios.

Place

the sort (DSNDB07) data sets on a separate volume from the above if not using PAV and/or MA.
IBM Corporation 2005

74

How many Storage Groups should I have in my production environment? The answer of course is: It depends! Here are my recommendations - page 2 of 2
Newer

disk devices that use PAV, MA., etc. typically do not require data and indexes on separate volumes. Older versions on the other hand, may benefit by the separation (still watch for hot spots). For separate Storage Groups: Use a unique data set naming convention separating data and indexes which will be resolved by the Storage Group ACS routine for correct placement. Use ZPARM values for SMSDCFL and SMSDCIX, in macro DSN6SPRM. These hidden ZPARM values provide SMS with one Data Class for data (SMSDCFL) and another for indexes (SMSDCIX) which will be resolved by the Storage Group ACS routine for correct placement. Provide a Storage Group for your archive log data sets. Recovery using archive log from disk is much faster than tape for parallel recoveries where several logs reside on the same tape. The exception to this is when archive logs are stored on DFSMShsm tapes (aside from recall time). In this case, make sure the Storage Group can handle additional logs. Provide a Storage Group for image copy data sets. Recoveries from image copy data sets residing on disk will be much faster for parallel operations because there is no need to serialize image copy data sets if stacked on the same tape.
Determine

realistically how many archive log and image copy data sets are required for recovery situations and size the volumes in your Storage Groups accordingly.
IBM Corporation 2005

75

How many Storage Groups should I have in my nonproduction environment? The answer of course is: It depends! Here are my recommendations:
For

non production, it depends on the requirements for:

Performance Backup Types

and recovery

of environments, i.e. sandbox, development, test, ERP and non-ERP, etc.

Amount

of data in each environment

Separation

of environments will depend on business requirements. You may want to stay with the production strategy or you may want to combine some or all of the Storage Groups for the above environments.
IBM Corporation 2005

76

Consolidating to large volumes - mod 27 or 54

My

Storage Administrator just told me that they are putting in mod 54s, and instead of my current 15 mod 3 volumes, they are trading me up to one volume with the capacity of a little bit more than 19 mod 3s. That sounds like a great deal, is there anything I need to consider?
Although

VSAM data sets can have up to 255 extents (increased in z/OS 1.7), there is a limitation of 123 extents per volume. This means that extending past 123 extents will not be possible with just one volume, so you will never grow beyond this point. This is true for other object types as well, such as extended format sequential data sets, which similar to VSAM will allow 123 extents per volume. you currently backing up (full volume dump) your volumes? There will be a lack of parallelism. There will be one very large dump instead of up to 20 dumps in parallel. How long will this function take? This is true for other operations, such as DEFRAG, etc. the amount of time it takes to FlashCopy a volume. Again, similar to the dump issue, your copies will not be in parallel.
77

Are

Consider

IBM Corporation 2005

Did that DEFRAG allocation example work or fail?

Back
//

in the DEFRAG section, we had an example:

DSN=TABLE.SPACE.IC, DISP=(NEW,CATLG),VOL=SER=PTS002,SPACE=(CYL,(250,25)) PTS002, has 462 free cylinders. However, the largest free extent is only 27 cylinders, and the remaining free extents are the same size or smaller.

Volume

Results:
Non

SMS allocation: It failed! Dealing with the 5 extents for primary allocation rule, even if there are 5 extents of 27 cylinders, the result would be:

(5 extents * 27 cylinders = 135 cylinders) for the primary allocation, almost half the space required. DEFRAGing this volume would probably combine enough free extents to accommodate the space request. allocation - it depends (Space relief is not valid for multi striped data sets):

SMS

Failure

again if the guaranteed space attribute is set to YES with no space constraint relief. Same scenario as above. Success when the guaranteed space attribute is set to YES with space constraint relief on. However, you may run out of extents trying to get the 250 cylinders if the allocation is for a non EF data set. Success when the guaranteed space attribute is set to NO and there are other volumes in the Storage group that can accommodate the allocation, otherwise failure.
IBM Corporation 2005

78

How did these space allocations happen?

I created an image copy data set as SPACE=(CYL,(1000,100)), I expected 1400 cylinders and 5 extents when multi volume, and I got 2300 cylinders with 5 extents, what happened? Did your data set use the guaranteed space attribute? Yes, well SMS is working as designed, since in this scenario the primary allocation is propagated to the next volume when it went multi volume. Extents are as follows - VOL1=1000,100 VOL2=1000,100,100 I image copied a 800 track table space, by mistake the output was TRK(1,1), but the allocation worked, how did that happen? Did your Storage Administrator assign EF for your image copy data sets? So long as there are at least 7 volumes with enough free space, the data set can spread up to 123 extents (as opposed to 16 extents non EF) on each volume. The end result will be a sequential data set with 800 extents. This is not a great way of doing business, but there is no outage.
IBM Corporation 2005

79

My Storage Administrator is seeing a lot of disk write bursts. Is there anything I can do to help?
Your Storage Administrator will see this in an RMF Cache Volume Detail report as DFW Bypass. For newer DASD, this is actually a DASD Fast Write retry and no longer a bypass. What this means is that NVS (Non Volatile Storage) is being flooded with too many writes. The controller will retry the write in anticipation that some data in NVS has been offloaded. For RAMAC devices the solution was to lower VDWQT to 0 or 1. This will cause high DBM1 SRM CPU time May no longer be needed for ESS and DS8000 devices. Test and verify settings. For very large buffer pools with many data sets, consider lowering VDWQT to 0 or 1. May work well for ESS and DS8000 as well. The tradeoff is still higher DBM1 SRM CPU time. Test and retest! Validate such things as Class 3 times.
IBM Corporation 2005

80

REORG of LOBs
I

have a LOB that is in many extents, I REORGed it and there was no space reduction. Is there a problem with z/OS or DB2?
REORG There

of LOBs does not redefine your LOBs

are only 3 phases that get executed - UTILINIT, REORGLOB, and UTILTERM.

REORG

is done in place. It does not unload and reload any data. What does happen is that REORG removes imbedded free space, and attempts to make LOB pages contiguous. of LOBs help increase the effectiveness of prefetch. - After the REORG is complete, stop the object and use a dfp utility for extent reduction. E.g.: Use DFSMShsm to migrate and recall the LOB. Verify the number of extents, then start the object.

REORG

Recommendation

IBM Corporation 2005

81

I have heard about PDSEs, do I need them and what are they? Do they need to be SMS managed?
PDSEs Before

are SMS managed data sets (non SMS possible, partial APAR list OW39951) DB2 V8, there were no requirements for PDSEs. The following are required starting with V8:
ADSNLOAD ADSNLOD2 SDSNLOAD SDSNLOD2

ISPF 3.4 data set listing for DB2 V8 Data Set Name . . . . : DSN810.SDSNLOAD Organization . . . : PO Data set name type : LIBRARY

Recommendation:

Use PDSEs for load libraries that contain stored procedures. This reduces the risk of out of space conditions due to adding or updating members. This is true for DB2 V7 as well. are like a PDS, but much better!:
of directory blocks are unlimited.

PDSEs
Up

to 123 extents (instead of 16 for PDSes). Cannot extend beyond one volume. not require periodic compression to consolidate fragmented space for reuse.

Number Does

There

is no need to recreate PDSEs when the number of members expands beyond the PDSs available directory blocks.
IBM Corporation 2005

82

How did this happen? I have 90 cylinders primary, 12 cylinders secondary, 63 extents, but 25530 tracks allocated?
CREATE

TABLESPACE PRIQTY 64800 SECQTY 8640 some time and space ... ALTER TABLESPACE SECQTY 20000 more rows, trip extents
ISPF 3.4 listing Tracks XT Device --------------------------------------------------------RI1.DSNDBD.A020X7KR.CKMLPR.I0001.A001 25530 63 3390 LISTCAT output: ALLOCATION SPACE-TYPE------CYLINDER SPACE-PRI-------------90 SPACE-SEC-------------12

After

Add No

REORG afterwards information correct information is not! with 63 extents

HI-A-RBA------1254850560 HI-U-RBA------1113292800

DB2 MVS

primary+(secondary*(extents-1))=space 90+(12*(63-1))=834 cylinders, 12510 tracks, not 25530!

CYL(90,12)
should

This case is not a disk fragmentation issue. After the ALTER, DB2 knows the allocation converted exception - fragmentation to CYL(90,28). However, MVS still thinks it is CYL(90,12) until redefined by a process such as BEWARE Storage Administrators! What you REORG without a REUSE. PRIQTY and SECQTY see is not always what you get! is actually what DB2 uses, not CYL(90,12).

be 12510 tracks

IBM Corporation 2005

83

I understood the last chart, but how did I actually get LESS space then I requested?
When The

your Storage Administrator has set up a Data Class with the following attributes: space constraint relief attribute on, and with the request for a percentage for space reduction, your data set allocated can actually be less than requested . This can happen if your volume does not have enough space.

E.g.,

4K object, created with PRIQTY 72000 (100 cylinders), the Data Class space constraint was set up to allow 10% reduction, you had one volume with 92 cylinders remaining. Results:
The

DB2 catalog will still show the equivalent of PRIQTY 72000. The actual MVS allocation will be 90 cylinders or the equivalent of PRIQTY 64800.
IBM Corporation 2005

84

When Storage Administrators talk about catalogs, are they talking about the DB2 catalog?
Generally, Storage

the answer here is no.

Administrators view the term catalog as the ICF catalog which they typically maintain. sure that when you or your Storage Administrator use the term catalog it is specifically stated which one, this will avoid needless confusion, errors, and arguments.
IBM Corporation 2005

Make

85

I am migrating my DB2 to V8, is there anything I need to tell my Storage Administrator?

It

depends on how your Storage Administrator set up the ACS routines for the DB2 data set names. If they are looking at the low level qualifier of your DB2 data set name and you plan on using partitions above the V7 limit of 254, then the answer is yes. The LLQ in DB2 V8 will have the following pattern:
A001-A999 B000-B999 C000-C999 D000-D999 E000-E096

for partitions 1 through 999 for partitions 1000 through 1999 for partitions 2000 through 2999 for partitions 3000 through 3999 for partitions 4000 through 4096

Your

Storage Administrator may need to change some reporting programs as well.

IBM Corporation 2005

86

My Storage Administrator tells me they are going to move disk volumes around during the day while DB2 is up. Don't I need to do online REORGs to do that?
Using

online REORGs to accomplish this task can still be used, however, this can be very disruptive and time consuming for a DBA. are some products on the market, such as Piper from IBM, that will actually do volume migration while DB2 is still up. Piper may be a less disruptive, time consuming, and error prone way of accomplishing the task that would have required additional Storage management changes followed by online REORGs. Using this type of product is a win - win for both the DBA and Storage Administrator.
Some

There

Using

other products include TDMF from Amdahl and FDR/PAS

IBM Corporation 2005

87

Since I am a DB2 professional, I get all of my space related information from the DB2 catalog. Should I consider something different?
It

depends on what you are looking for:

you are not executing frequent (perhaps daily) RUNSTATS or STOSPACE, then you could be looking at some very outdated information that you can not depend on. you need more current information, consider using something like DCOLLECT and an interpretive report for the information as a replacement for what you are currently using. Samples are available for the DCOLLECT and report in ISMF. Use of processes outside of DB2 will reduce the stress on DB2, even when using shadow DB2 catalog information. It will also provide more up to date information.

If

If

IBM Corporation 2005

88

My Storage Administrator told me they recreated my DB2 data sets with high extents. They are now as low as 1 extent per data set. Are there any issues?
Storage

Administrators have a number of ways of causing extent reduction, thereby potentially bringing back a data set in 1 extent, among them:
DFSMShsm DFSMSdss DEFRAG

MIGRATE and RECALL functions

COPY or DUMP and RESTORE functions

with the CONSOLIDATE keyword

Using Do

Such functions as DFSMSdss COPY may be much faster than running REORGs. you have SQL that uses the DB2 catalog to report on extents? This can potentially be a problem. You may be redoing REORGs unnecessarily since the move was done outside of DB2 and DB2 does not know about it. *** NOTE the EXTENTS column in the RTS will only be updated once an update or applicable utility is run for the object. A simple start after extent reduction or a read based on SELECT will not update the EXTENTS column (same issue as the catalog). you use high extents as a tool to review issues with clustering indexes? This can potentially be a problem. Review IBM Corporation 2005 CLUSTERRATIOF more closely.

Do

89

Is it possible to lose just one or a few volumes with newer disk?

Yes,

although it is extremely rare to lose just one or a few volumes instead of an entire disk controllers worth. Because of this (there are other reasons), I run a daily disk report by volume for my DB2 objects. Some things to think about if something does go wrong:
What
All

Recommendation:

was on the volume I lost?

indexes? Maybe I can just rebuild them Part of one application or part of a partition data set, it MIGHT not be too bad then My new mod 54 with ALL of my data? Find out what your alternatives are. There hopefully are some based on the architecture you have built in for this type of event. Etc. - This gets into a much bigger discussion which we do not have time for now. So,

do I care if my data sets are multi volume?

Yes,

based on the information above. Lots of multi volume data sets can cause you lots of additional restores if a piece of your data resided on the crashed volume.
IBM Corporation 2005

90

My index keeps on growing and tripping extents, even after deletes. What's wrong with DB2? How can I control the extent growth?
This

one is actually a DB2 issue concerning pseudo deleted entries in your index, not a Storage management issue:
For

an index, deleted keys are marked as pseudo deleted.

Actual

cleaning up will not occur except during certain processes. An example would be before a page split. CPU cost of an index scan - Every time a SQL statement makes a scan of an index, it has to scan all entries in the index. This includes pseudo deleted entries that have not yet been removed.

High

You

can calculate the percentage of RIDs that are pseudo deleted based on the values of PSEUDO_DEL_ENTRIES and CARDF in SYSINDEXPART:
(PSEUDO_DEL_ENTRIES/CARDF)*100

Recommendation

- REORG INDEX, if the percentage of pseudo deleted entries is greater than 10% for non Data Sharing and 5% for Data Sharing.
IBM Corporation 2005

91

I hear that DB2 compression will reduce my disk space, and I will have better I/O and buffer pool hits. Do I now compress everything?
Do

not compress small table spaces.

Are

you really tight on CPU? Keep in mind that compression will add a small amount of extra CPU cycles. DSN1COMP. Find out what you will be saving. If it is below 40%, it is probably not worth it. found 5,000 table spaces I can compress, can I start now?
DB2

Run

I

V7 No. You will hit a VSTOR issue. It is just too much to compress. Try to start out with a much smaller number and review your DBM1 VSTOR usage. The compression dictionary is still below the 2 GB bar. V8 Yes, only if you can fully back the compression dictionary with real storage. The compression dictionary is now above the 2 GB bar.

DB2

IBM Corporation 2005

92

I hear about SnapShot, FlashCopy versions 1 and 2, and TimeFinder, what's the difference between all of these? (at a very high level)
SnapShot

(RVA only) can quickly move data from the source device to the target device.

SnapShot Data

is snapped (quickly copied) directly from the source location to the target location. (ESS and DS8000) - versions 1 and 2

FlashCopy

FlashCopy

V1 requires the entire source volume and target volume to be involved in a FlashCopy relationship. FlashCopy V1 relationships do not allow any other FlashCopy relationships to exist on either the source or target volume. Version 2 enhances the FlashCopy function by providing an alternative method to copying an entire source volume to a target volume:
Multiple

FlashCopy

FlashCopy relationships are allowed on a volume. Track relocation is possible because when copying tracks the target tracks do not need to be in the same location on the target volume as on the source volume. The restriction that a FlashCopy target and source volume must be in the same logical subsystem (LSS) in an ESS is removed. However, FlashCopy must still be processed in the same ESS. 10x faster than FlashCopy V1. TimeFinder - EMC Hardware
similar for

in concept to FlashCopy for EMC

IBM Corporation 2005

more information see, http://www.emc.com/products/software/timefinder.jsp

93

I have FlashCopy and/or SnapShot Technology, can it help if I want to clone my DB2s?
YES!

Check out redbook: SAP on DB2 for z/OS and OS/390: DB2 System Cloning SG24-6287 are some products that will allow you to clone systems, such as Mainstar Volume Conflict Resolution (VCR). VCR allows you to clone data within the LPAR you are cloning from.

There

IBM Corporation 2005

94

Now it is time to sit down with your Storage Administrator for an exchange of ideas
Ask

your Storage Administrator for a copy of their procedures as it pertains to DB2. Review the document with your Storage Administrator to understand the concepts.

Discuss

with your Storage Administrator your installations mix of hardware and software. How do they work and how can they work best for DB2? Keep in mind such things as DR requirements which, for the most part, are not discussed in this presentation. with your Storage Administrator the concepts you have seen in this presentation. Are there any options you can take advantage of that are not currently being used?

Discuss

Exchange

information with your Storage Administrator about how DB2 works and find out more about your storage. The more you know about each others technology, the better DB2 and MVS in general will perform and continue their happy marriage together.
IBM Corporation 2005

95

References - page 1 of 2
Data DB2 DB2 DB2 DB2

Integrity with DB2 UDB for z/OS SG24-7111 V8 Administration Guide SC18-7413 V8 Installation Guide GC18-7418 V8 SQL Reference SC18-7426 V8 Utility Guide and Reference SC18-7427 Report Reference SC18-7978

DB2PE DB2

UDB for z/OS Version 8: Everything You Ever Wanted thing to Know, ... and More SG24-6079 UDB for z/OS Version 8 Performance Topics SG24-6465 for z/OS and OS/390 Version 7 Performance Topics SG24-6129 for z/OS and OS/390 Version 7 Selected Performance Topics SG24-6894

DB2 DB2 DB2

Effective

zSeries Performance Monitoring using Resource Measurement Facility (RMF) SG24-6645 Management with DB2 for OS/390 SG24-5462

Storage z/OS z/OS IBM

1.6 DFSMS: Implementing System-Managed Storage SC26-7407 1.6 DFSMSdfp Storage Administration Reference SC26-7402

RAMAC Array Introduction GC26-7012 Recovery with DB2 UDB for z/OS SG24-6370 96

Disaster z/OS

V1R6.0 DFSMS Advanced Copy Services SC35-0428

IBM Corporation 2005

References - page 2 of 2
z/OS z/OS z/OS z/OS

V1R6.0 DFSMS: Using DFSMSdfp in the z/OS V1R6.0 Environment SC26-7473 V1R6.0 DFSMS Access Method Services for Catalogs SC26-7394 V1R6.0 DFSMShsm Storage Administration Reference SC35-0422 V1R6.0 DFSMSdss SAG SC35-0423 Software Support for IBM Enterprise Storage Server SC26-7318

DFSMS/MVS IBM IBM The

Enterprise Storage Server SG24-5465 RAMAC Virtual Array SG24-4951 IBM TotalStorage DS8000 Series: Concepts and Architecture SG24-6452 V1R6.0 RMF Performance Management Guide SC33-7992z/OS V1R6.0 V1R6.0 RMF Report Analysis SC33-7991 V1R6.0 RMF User's Guide SC33-7990 V1R6.0 DFSMS: Using Data Sets SC26-7410 V1R7.0 DFSMS: Using Data Sets SC26-7410

z/OS z/OS z/OS z/OS z/OS IBM

System z9 109 Technical Introduction SG24-6669

IBM

TotalStorage Enterprise Storage Server Large Volume Support Performance Evaluation and Analysis - White Paper

http://www.ibm.com/ibm/history/exhibits/storage/storage_photo.html http://www.ibm.com/ibm/history/exhibits/storage/storage_profile.html http://www.ibm.com/ibm/history/exhibits/storage/storage_basic.html

IBM Corporation 2005

97