Storage Management with DB2 for OS/390
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.
© Copyright International Business Machines Corporation 1999. All rights reserved
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.
Contents
Figures ......................................................xi
Tables .......................................................xv
Preface .....................................................xvii
The Team That Wrote This Redbook . ..................................xvii
CommentsWelcome ...............................................xix
Part 1. Introduction and Summary ...................................................1
Chapter 1. Introduction..........................................3
Chapter 2. Summary of Considerations ............................5
2.1 DB2 and Storage Management ..................................5
2.1.1 Benefits of DFSMS .......................................5
2.1.2 Managing DB2 Data Sets with DFSMS . .......................6
2.1.3 Examples for Managing DB2 Data Sets with DFSMS . ............6
2.2 DB2andStorageServers......................................6
2.2.1 DataPlacement..........................................6
2.2.2 LargeCache............................................6
2.2.3 LogStructuredFile.......................................7
2.2.4 RAMACArchitecture......................................7
2.2.5 SMS Storage Groups . . . ..................................7
2.2.6 Performance Management .................................8
Part 2. DB2 and System Managed Storage ............................................9
Chapter 3. DB2 Storage Objects .................................11
3.1 DB2Overview..............................................11
3.2 DB2DataObjects...........................................11
3.2.1 TABLE ...............................................12
3.2.2 TABLESPACE..........................................12
3.2.3 INDEX................................................13
3.2.4 INDEXSPACE..........................................13
3.2.5 DATABASE............................................13
3.2.6 STOGROUP...........................................13
3.3 Creating Table Spaces and Index Spaces. . . ......................13
3.3.1 DB2 Defined and Managed ................................14
3.3.2 User Defined and Managed................................14
3.4 DB2SystemTableSpaces....................................15
3.4.1 TheDB2CatalogandDirectory.............................15
3.4.2 The Work Database .....................................15
3.4.3 SYSIBM.SYSCOPY......................................16
3.4.4 SYSIBM.SYSLGRNX ....................................16
3.5 DB2ApplicationTableSpaces .................................17
3.6 DB2RecoveryDataSets .....................................17
3.6.1 BootstrapDataSets.....................................17
3.6.2 Active Logs ............................................18
3.6.3 Archive Logs ...........................................19
3.6.4 ImageCopies..........................................20
3.6.5 OtherCopies...........................................22
© Copyright IBM Corp. 1999 iii
3.7 OtherDB2DataSets........................................22
3.7.1 DB2LibraryDataSets...................................22
3.7.2 DB2TemporaryDataSets................................22
3.8 DB2DataSetsNamingConventions............................22
3.8.1 Table Space and Index Space Names ....................... 23
3.8.2 BSDSNames.......................................... 23
3.8.3 ActiveLogNames......................................23
3.8.4 ArchiveLogandBSDSBackupNames......................24
3.8.5 ImageCopyNames.....................................24
Chapter 4. System Managed Storage Concepts and Components...... 25
4.1 Background ...............................................25
4.2 Evolution................................................. 25
4.3 DFSMS/MVS Components ................................... 26
4.3.1 DFSMSdfp............................................26
4.3.1.1ISMFfortheEndUser ...................................26
4.3.1.2ISMFfortheStorageAdministrator..........................27
4.3.2 DFSMSdss ...........................................27
4.3.2.1Functionality ...........................................27
4.3.2.2Filtering...............................................28
4.3.2.3ConvertingDatatoSMS..................................28
4.3.3 DFSMShsm...........................................28
4.3.3.1SpaceManagement .....................................29
4.3.3.2 Availability Management . . ................................30
4.3.4 DFSMSrmm...........................................31
4.3.5 DFSMSopt............................................31
4.3.6 SMFRecords42(6).....................................32
4.4 Benefits . . . ...............................................32
Chapter 5. Storage Management with DFSMS ...................... 35
5.1 Introduction ...............................................35
5.1.1 BaseConfiguration .....................................35
5.1.2 ClassandStorageGroupDefinitions........................36
5.2 AutomaticClassSelectionRoutines ............................36
5.3 SMSClasses..............................................38
5.3.1 DataClass............................................38
5.3.1.1Description ............................................38
5.3.1.2 Planning for Implementation ...............................39
5.3.2 StorageClass .........................................39
5.3.2.1Description ............................................39
5.3.2.2 Planning for Implementation ...............................40
5.3.3 Management Class . .................................... 41
5.3.3.1Description ............................................41
5.3.3.2 Planning for Implementation ...............................41
5.3.4 StorageGroup.........................................43
5.3.4.1Description ............................................43
5.3.4.2 Planning for Implementation ...............................44
5.3.4.3 Mapping Devices to Storage Groups for Performance ...........45
5.4 Naming Standards. .........................................46
5.5 Examples ................................................46
Chapter 6. Managing DB2 Databases with SMS.....................47
6.1 SMS Examples for DB2 Databases .............................47
6.1.1 UsingISMFtoDisplaySMSConstructs......................47
iv Storage Management with DB2 for OS/390
6.1.2 SMSDataClass........................................47
6.1.3 SMSStorageClass......................................48
6.1.4 SMS Management Class. .................................49
6.1.5 SMS Storage Groups . . . .................................50
6.1.6 DB2 STOGROUPs and SMS Storage Groups . .................52
6.1.7 Assigning SMS Classes to DB2 Table Spaces and Index Spaces . . .53
6.1.8 Table Space and Index Space Names for SMS.................56
6.1.9 Managing Partitioned Table Spaces with SMS .................56
6.2 User Databases ............................................57
6.2.1 Online Production Databases . . ............................58
6.2.1.1StorageClasses........................................58
6.2.1.2 Management Classes. . ..................................58
6.2.2 Batch Production Databases. . . ............................58
6.2.2.1StorageClasses........................................58
6.2.2.2 Management Classes. . ..................................58
6.2.3 Data Warehouse Databases . . . ............................58
6.2.3.1StorageClasses........................................59
6.2.3.2 Management Classes. . ..................................59
6.2.4 Development and Test Databases...........................59
6.2.4.1StorageClasses........................................59
6.2.4.2 Management Classes. . ..................................59
6.2.5 Summary..............................................59
6.3 DB2 System Databases ......................................60
6.3.1 Catalog and Directory Databases ...........................60
6.3.1.1StorageClasses........................................61
6.3.1.2 Management Classes. . ..................................61
6.3.2 Work Database . . .......................................61
6.3.2.1StorageClasses........................................61
6.3.2.2 Management Classes. . ..................................61
6.3.3 Summary..............................................61
Chapter 7. Managing DB2 Recovery Data Sets with SMS..............63
7.1 SMSExamplesforDB2RecoveryDataSets ......................63
7.1.1 SMSDataClass........................................63
7.1.2 SMSStorageClass......................................63
7.1.3 SMS Management Class. .................................64
7.1.4 SMS Storage Groups . . . .................................65
7.1.5 AssigningSMSClassestoDB2RecoveryDataSets.............66
7.2 BSDS ....................................................67
7.2.1 StorageClass..........................................67
7.2.2 Management Class ......................................67
7.2.3 StorageGroup .........................................68
7.2.4 ACSExample..........................................68
7.3 Active Logs ................................................68
7.3.1 StorageClass..........................................69
7.3.2 Management Class ......................................69
7.3.3 StorageGroup .........................................69
7.3.4 ACSExample..........................................69
7.4 Archive Logs. . . ............................................69
7.4.1 StorageClass..........................................71
7.4.2 Management Class ......................................71
7.4.3 StorageGroup .........................................71
7.4.4 ACSExample..........................................71
7.5 ImageCopies..............................................71
v
7.5.1 StorageClass .........................................72
7.5.2 Management Class . .................................... 72
7.5.3 StorageGroup.........................................73
7.6 Summary.................................................73
Chapter 8. Converting DB2 to Systems Managed Storage ............75
8.1 Overview................................................. 75
8.2 Advantages of SMS Managing DB2 Data.........................75
8.3 SMS Management Goals. ....................................76
8.4 PositioningforImplementation.................................77
8.4.1 Prerequisite Planning....................................77
8.4.2 ServiceLevelAgreement.................................78
8.5 ConversionProcess ........................................78
8.5.1 Sequence . . . .........................................78
8.5.2 Methodology . ......................................... 79
8.5.2.1ConversionWindow .....................................79
8.5.2.2DataMovement.........................................79
8.5.2.3TailorOnlineConversion..................................79
8.5.2.4 Contingency Time Frame . ................................80
8.5.3 SMSImplementation....................................80
8.5.4 PostImplementation .................................... 81
8.6 DFSMSFIT...............................................81
8.7 NaviQuest................................................81
Part 3. DB2 and Storage Servers ..................................................83
Chapter 9. Disk Environment Overview ...........................85
9.1 EvolutionofDiskArchitecture .................................85
9.1.1 3380 and 3390 Volumes . . . ..............................85
9.1.2 Arrays...............................................85
9.1.3 Log Structured File and SnapShot . .........................86
9.1.4 VirtualVolumes........................................88
9.2 DiskControlUnits..........................................89
9.2.1 StorageServer ........................................89
9.2.2 StorageDevices .......................................90
9.2.3 Logical Control Unit . ....................................90
9.3 Cache Management ........................................90
9.3.1 TrackCaching.........................................91
9.3.2 ReadRecordCaching...................................91
9.3.3 WriteRecordCaching(Quickwrite) ......................... 92
9.3.4 Sequential Caching . .................................... 92
9.3.5 NoCaching—BypassCache ..............................92
9.3.6 No Caching—Inhibit Cache Load . . .........................92
9.3.7 DB2CacheParameters(DSNTIPE).........................92
9.3.8 Dynamic Cache Management Enhancement ..................92
9.4 Paths and Bandwidth Evolution . . ..............................93
9.5 Capabilities ...............................................93
9.5.1 DualCopy............................................93
9.5.2 ConcurrentCopy.......................................94
9.5.3 VirtualConcurrentCopy..................................95
9.5.4 RemoteCopy..........................................95
9.5.4.1PPRC ................................................96
9.5.4.2GeographicallyDispersedParallelSysplex....................97
vi Storage Management with DB2 for OS/390
9.5.4.3 Extended Remote Copy ..................................99
9.5.5 Compression..........................................100
9.5.6 Sequential Data Striping . ................................101
Chapter 10. DB2 I/O Operations.................................103
10.1 AvoidingI/OOperations....................................103
10.2 DataReadOperations .....................................104
10.2.1 NormalRead.........................................104
10.2.2 Sequential Prefetch....................................104
10.2.3 DynamicPrefetch .....................................105
10.2.4 ListPrefetch .........................................105
10.2.5 Prefetch Quantity .....................................105
10.2.6 Data Management Threshold . ...........................106
10.2.7 Sequential Prefetch Threshold ...........................107
10.3 DataWriteOperations......................................107
10.3.1 Asynchronous Writes . . ................................107
10.3.2 Synchronous Writes . . . ................................108
10.3.3 ImmediateWriteThreshold..............................108
10.3.4 Write Quantity . . ......................................108
10.3.5 Tuning Write Frequency ................................108
10.4 LogWrites ..............................................111
10.4.1 Asynchronous Writes . . ................................112
10.4.2 Synchronous Writes . . . ................................112
10.4.3 Writing to Two Logs....................................112
10.4.4 Two-PhaseCommitLogWrites...........................112
10.4.5 ImprovingLogWritePerformance.........................114
10.5 Log Reads . . . ...........................................115
10.5.1 ImprovingLogReadPerformance.........................116
10.5.2 ActiveLogSize.......................................117
Chapter 11. I/O Performance and Monitoring Tools .................119
11.1 DB2PMOverview.........................................119
11.1.1 Accounting I/O Information . . . ...........................120
11.1.1.1I/OOperations ....................................... 120
11.1.1.2 I/O Suspensions ...................................... 121
11.1.2 StatisticsI/OInformation................................121
11.1.2.1DataI/OOperations...................................121
11.1.2.2LogActivity..........................................122
11.1.3 PerformanceI/OInformationandI/OActivity.................123
11.2 RMFMonitoring ..........................................124
11.2.1 RMF Report Analysis . . ................................125
11.2.1.1 Cache Subsystem Activity Reports . . . ....................125
11.2.1.2DirectAccessDeviceActivityReport......................128
11.2.2 Using RMF Reports....................................132
11.2.2.1ResourceLevelAnalysis...............................132
11.2.2.2 RMF Reporting at Storage Group Level....................133
11.2.2.3ToolsProvidingMoreIn-DepthAnalysisthanRMF...........133
11.2.2.4 Spreadsheet Tools for RMF Analyzis. . .................... 133
11.2.2.5 Global View of a DB2 I/O by DB2 PM and RMF .............134
11.3 IXFPMonitoring ..........................................135
11.3.1 Device Performance Reports. . ...........................136
11.3.2 Cache Effectiveness Report . . ...........................137
11.3.3 Space Utilization Report ................................138
vii
Chapter 12. Case Study....................................... 141
12.1 DB2CaseStudyAnalysis ..................................141
12.1.1 General Analysis . . ...................................141
12.1.1.1ElapsedandCPUTime.................................141
12.1.1.2SQLStatements......................................141
12.1.1.3 Time Not Accounted ...................................143
12.1.2 DataAccess ........................................144
12.1.3 Suspend Times . . . ...................................145
12.1.3.1 Synchronous I/O . .....................................145
12.1.3.2AsynchronousReadI/O ................................146
12.1.3.3I/ORate.............................................146
12.1.4 Conclusions......................................... 147
12.2 StorageServerAnalysis ...................................147
12.2.1 RMFViews .........................................147
12.2.1.1DeviceActivityReportAnalysis...........................149
12.2.1.2 I/O Queuing Activity Report Analysis ......................149
12.2.1.3 Channel Path Activity Report Analysis . . . ..................150
12.2.1.4 Cache Subsystem Activity Reports Analysis.................151
12.2.2 IXFPView.......................................... 152
12.2.2.1DevicePerformanceOverallSummary.....................152
12.2.2.2 Cache effectiveness Overall Summary . . . ..................153
12.2.2.3SpaceUtilizationSummary..............................153
12.3 CaseStudySummary .....................................154
Part 4. Appendixes ............................................................159
Appendix A. Test Cases for DB2 Table Space Data Sets ..............161
A.1 TestEnvironment..............................................161
A.2 Partitioned Table Space, DB2 Defined, Without SMS ..................162
A.2.1 Create EightSTOGROUPs..................................162
A.2.2 Create the Database . . .....................................162
A.2.3 CreatetheTableSpace.....................................163
A.2.4 DisplayaVolume..........................................163
A.3 Partitioned Table Space, User Defined, Without SMS..................164
A.3.1 DEFINECLUSTERfor16Partitions ...........................164
A.3.2 CREATESTOGROUP......................................164
A.3.3 CREATEDATABASE ......................................164
A.3.4 CREATETABLESPACE....................................164
A.3.5 DisplayaVolume..........................................165
A.4 DB2TableSpacesUsingSMS,ExistingNames......................165
A.4.1 StorageClasses...........................................166
A.4.2 Management Class . . . .....................................167
A.4.3 StorageGroup............................................169
A.4.4 ISMFTestCases..........................................171
A.4.5 UpdatingtheActiveConfiguration.............................172
A.4.6 DB2Definitions ...........................................172
A.4.7 DataSetAllocationResults..................................173
A.5 DB2 Table Spaces Using SMS, Coded Names .......................174
A.5.1 StorageClass ............................................174
A.5.2 Management Class . . . .....................................175
A.5.3 Storage Groups ...........................................175
A.5.4 DB2Definitions ...........................................177
A.5.5 DataSetAllocationResults..................................177
viii Storage Management with DB2 for OS/390
A.6 Partitioned Table Space Using SMS Distribution . ....................178
A.6.1 Define VolumestoSMSStorageGroup .......................179
A.6.2 ACSRoutines............................................179
A.6.3 DB2Definitions...........................................179
A.6.4 DataSetAllocationResults..................................180
A.7 Partitioned Table Spaces Using SMS, User Distribution. . . .............181
A.7.1 CreateStorageGroups..................................... 181
A.7.2 ACSRoutines............................................182
A.7.3 DB2Definitions...........................................183
A.7.4 DataSetAllocationResults..................................183
Appendix B. Test Cases for DB2 Recovery Data Sets ................185
B.1 BSDSandActiveLogs.........................................185
B.1.1 SMSStorageClass........................................185
B.1.2 SMS Management Class . . ................................. 186
B.1.3 StorageGroup............................................ 187
B.1.4 ISMFTestCases .........................................188
B.1.5 DataSetAllocationResults..................................189
B.2 Archive Logs .................................................191
B.2.1 StorageClass............................................191
B.2.2 Management Class . .......................................192
B.2.3 StorageGroup............................................ 193
B.2.4 DataSetAllocationResults..................................193
B.3 ImageCopies ................................................ 194
B.3.1 StorageClass............................................195
B.3.2 Management Class . .......................................196
B.3.3 StorageGroup............................................ 197
B.3.4 DataSetAllocationResults..................................197
Appendix C. DB2 PM Accounting Trace Report .....................201
Appendix D. DB2 PM Statistics Report............................. 205
Appendix E. Disk Storage Server Reports..........................223
Appendix F. Special Notices......................................239
Appendix G. Related Publications.................................241
G.1 International Technical Support Organization Publications ............. 241
G.2 RedbooksonCD-ROMs........................................241
G.3 OtherPublications.............................................242
G.4 WebSites................................................... 242
How to Get ITSO Redbooks.....................................243
IBM Redbook Fax Order Form ....................................... 244
List of Abbreviations ..........................................245
Index .......................................................247
ITSO Redbook Evaluation ......................................251
ix
x Storage Management with DB2 for OS/390
Figures
1. CreatingaSTOGROUPDefinedTableSpace ........................14
2. UserDefinedTableSpace:Step1—DefinetheCluster .................14
3. UserDefinedTableSpace:Step2—DefinetheTableSpace ............15
4. InstallationPanelforSizingDB2SystemObjects......................16
5. DB2LogandItsDataSets........................................19
6. ImageCopySHRLEVELREFERENCE..............................20
7. ImageCopySHRLEVELCHANGE.................................21
8. ISMFPrimaryOptionMenuforEndUsers............................26
9. ISMFPrimaryOptionMenuforStorageAdministrators..................27
10. DFSMShsm Components ........................................29
11. ImplementinganSMSConfiguration................................36
12. ACSRoutineExecutionProcess...................................37
13. SMSConstructRelationship ......................................38
14. DisplayaDataClass ............................................48
15. Data Class DCDB2 .............................................48
16. DisplayofStorageGroupSGDB20.................................52
17. VolumesinStorageGroupSGDB20................................53
18. ACS Routine Extract Using Table and Index Name Filter List .............55
19. Example VSAM Definition of one BSDS . . ...........................67
20. Example VSAM Definition of One Active Log .........................69
21. Archive Log Installation Panel DSNTIPA . . ...........................70
22. RAMAC3 Drawer Logical Volume Mapping ...........................86
23. LSFConcept1.................................................87
24. LSFConcept2.................................................87
25. Snapshot Overview .............................................88
26. SchemaofaBackupwithConcurrentCopy ..........................94
27. VirtualConcurrentCopyOperationSteps............................95
28. ProfileofaPPRCWrite..........................................96
29. Time Sequenced I/Os . . . ........................................97
30. GDPSArchitecture..............................................98
31. XRCDataFlow ............................................... 100
32. StorageHierarchy .............................................104
33. DB2PMAccountingTraceBufferPoolReportExtract.................. 109
34. DB2 PM Statistic Report Buffer Pool Reads .........................110
35. DB2 PM Statistic Report Buffer Pool Writes .........................110
36. DisplayBufferPoolDataSetStatistics .............................111
37. LogRecordPathtoDisk ........................................113
38. Two-Phase Commit with Dual Active Logs ..........................113
39. MinimumActiveLogDataSetDistribution...........................115
40. InstallationPanelDSNTIPL......................................115
41. LogStatisticsinaSampleDB2PMStatisticsReport ..................118
42. ScopeofPerformanceAnalysisTools..............................119
43. InstallationPanelDSNTIPN......................................120
44. DB2 PM Accounting, Buffer Pool Section . ..........................121
45. DB2PMStatistics,BufferPoolReadOperationsSection...............122
46. DB2PMStatistics,LogActivitySection.............................123
47. BufferPoolSectionfromI/OActivitySummaryReport .................124
48. Cache Subsystem Activity Status and Overview Reports . . .............127
49. Cache Subsystem Activity Device Overview Report ...................127
50. DirectAccessDeviceActivityReport...............................129
© Copyright IBM Corp. 1999 xi
51. I/OQueuingActivityReport.......................................131
52. Channel Path Activity Report: LPAR Mode. . . ........................132
53. DB2I/O......................................................135
54. IXFPDevicePerformanceSubsystemSummaryReport................137
55. IXFP Cache Effectiveness Subsystem Summary Report ................138
56. IXFPSpaceUtilizationSubsystemReport...........................139
57. DB2 PM Accounting, Class 1 and Class 2 Sections . . ..................142
58. DB2 PM Accounting, SQL DML Section .............................142
59. DB2 PM Accounting, SQL DCL Section .............................143
60. DB2 PM Accounting, Parallel Query Section . ........................143
61. DB2 PM Statistics, Global DDF Activity Section .......................144
62. DB2 PM Accounting, BP2 Section . . ...............................144
63. DB2 PM Accounting, BP4 Section . . ...............................145
64. DB2 PM Accounting Class 3 Times . ...............................145
65. DB2 PM Accounting Highlights ....................................146
66. DB2 PM Accounting Buffer Pool Summary. . . ........................147
67. Reducing the RMF Data to Analyze . ...............................148
68. Case Study RMF Direct Access Device Activity Report Extract...........149
69. Case Study RMF I/O Queuing Activity Extract ........................150
70. Case Study RMF Channel Path Activity Extract .......................150
71. Case Study RMF Cache Subsystem Activity Extracts ..................151
72. CaseStudyIXFPDevicePerformanceCaseSummaryExtract...........152
73. CaseStudyIXFPCacheEffectivenessOverallExtract .................153
74. CaseStudyIXFPSpaceUtilizationSummaryExtract ..................154
75. DB2PMI/OSummary...........................................155
76. DeviceActivitySummary ........................................155
77. CacheActivitySummary.........................................156
78. IXFPSummary................................................156
79. CaseStudyI/OFlows...........................................157
80. DiskVolumeConfigurationUsedintheTestEnvironment...............161
81. TestCase1-CREATESTOGROUP...............................162
82. TestCase1-CREATEDATABASE................................162
83. TestCase1-CREATETABLESPACE .............................163
84. TestCase1-DisplayofVolumeRV1CU0...........................163
85. TestCase2-DEFINECLUSTER..................................164
86. TestCase2-CREATESTOGROUP...............................164
87. TestCase2-CREATETABLESPACE .............................165
88. TestCase2-DisplayofVolumeRV2CU1...........................165
89. TestCase3-ISMFStorageClassDefinition.........................166
90. TestCase3-StorageClassRoutineExtract.........................167
91. TestCase3-ISMFManagementClassDefinition.....................168
92. Test Case 3 - Management Class Routine Extract. . . ..................168
93. TestCase3-ISMFPoolStorageGroupDefinition ....................169
94. TestCase3-StorageGroupRoutineExtract ........................169
95. TestCase3-ISMFStorageGroupVolumeDefinition..................170
96. TestCase3-DFSMSdssCONVERTVJCL..........................170
97. TestCase3-DFSMSdssCONVERTVOutput........................171
98. Test Case 3 - ISMF Test against the ACDS . . ........................171
99. Test Case 3 - ISMF Test against the Updated SCDS. ..................172
100.Test Case 3 - CREATE STOGROUP ...............................172
101.Test Case 3 - CREATE DATABASE Extract . ........................173
102.Test Case 3 - CREATE TABLESPACE Extract .......................173
103.Test Case 3 - ISPF Data Set List Display............................173
xii Storage Management with DB2 for OS/390
104.Test Case 3 - IDCAMS LISTCAT Display Extract . ....................174
105.Test Case 4 - Storage Class Routine Extract ........................176
106.Test Case 4 - Management Class Extract. ..........................176
107.Test Case 4 - IDCAMS LISTCAT Extract . ..........................178
108.Test Case 5 - ISMF Volume List Display. . ..........................179
109.Test Case 5 - CREATE DATABASE ...............................179
110.Test Case 5 - CREATE TABLESPACE Extract. . . .................... 180
111.Test Case 5 - ISPF Data Set List of Table Space Partitions .............180
112.Test Case 5 - ISMF Storage Group Volume Display...................181
113.Test Case 5 - IDCAMS LISTCAT Display Extract . ....................181
114.Test Case 6 - ISMF Storage Group List . . ..........................182
115.Test Case 6 - Storage Group ACS Routine Extract.................... 183
116.Test Case 6 - CREATE TABLESPACE Extract. . . .................... 184
117.Test Case 6 - ISMF Data Set List Extract . ..........................184
118.ISMF Storage Class Definition for BSDS and Active Logs . .............186
119.Storage Class Routine Extract for BSDS and Active Logs . .............186
120.Management Class Routine Extract for BSDS and Active Logs . . . .......187
121.Storage Group Routine Extract for BSDS and Active Logs . .............188
122.ISMF Test Result for BSDS (1) . . .................................188
123.ISMF Test Result for BSDS (2) . . .................................189
124.IDCAMS Definition Extract for BSDS............................... 189
125.ISPF Data Set List of BSDS’s . . . .................................190
126.SYSPRINT Messages Extract for Active Log IDCAMS Definition . . .......190
127.ISPF Data Set List of Active Logs................................. 191
128.Storage Class Routine Incorporating Archive Logs....................192
129.Management Class Routine Incorporating Archive Logs. . . .............192
130.Storage Group Routine Incorporating Archive Logs ................... 193
131.SYSLOG Message Ouput Extract for Archive Logs ...................193
132.ISPF Data Set List of Archive Logs ................................194
133.IDCAMS LISTCAT of Management Class Comparison for Archive Logs . . . 194
134.Storage Class Routine Extract Incorporating Image Copies ............195
135.Management Class Routine Extract Incorporating Image Copies . . .......196
136.Storage Group Routine Extract Incorporating Image Copies ............197
137.JCL for Image Copy Allocation . . ................................. 198
138.Image Copy Allocation JES Output Messages . . . ....................198
139.ISPF Data Set List of Image Copies ............................... 199
140.IDCAMS LISTCAT Extract of Image Copy Data Sets ..................199
xiii
xiv Storage Management with DB2 for OS/390
Tables
1. Summary of Partition and Partitioned Table Space Sizes . . ..............12
2. DB2 Image Copy with and without Concurrent Copy....................21
3. Table Space and Index Space Names...............................23
4. BSDSNames..................................................23
5. ActiveLogDataSetNames.......................................23
6. ArchiveLogandBSDSBackupNames..............................24
7. SampleImageCopyNames ......................................24
8. DataClassAttributes............................................39
9. StorageClassAttributes .........................................40
10. Management Class Attributes . . . ..................................42
11. StorageGroupAttributes.........................................45
12. SMSStorageClassesforDB2Databases............................49
13. SMS Management Classes for DB2 Databases . . .....................50
14. Relating SMS Storage and Management Classes to Storage Groups ......51
15. SMS Storage Groups for DB2 Databases . ...........................51
16. Table Space and Index Space Names with SMS Codes . . . ..............56
17. Examples of SMS Class Usage for DB2 User Databases . . ..............60
18. DB2 System Database Requirements ...............................61
19. SMSStorageClassesforRecoveryDataSets........................64
20. Management Classes for Recovery Data Sets . . . .....................65
21. Relating SMS Storage and Management Classes to Storage Groups ......66
22. SMSStorageGroupsforDB2RecoveryDataSets.....................66
23. StorageGroupsforDB2RecoveryDataSets.........................73
24. Number of Pages Read Asynchronously in One Prefetch Request . .......106
25. Maximum Pages in One Write Operation. . ..........................108
26. Trace Requirement for the I/O Activity Reports . . . ....................124
27. RVASpaceUtilizationComparison................................153
28. TestCase3-StorageGroupVolumes .............................170
29. TestCase4-StorageGroupVolumes .............................175
30. TestCase5-StorageGroupVolumes .............................179
31. TestCase6-StorageGroupVolumes .............................182
32. BSDSandActiveLogs-StorageGroupVolumes ....................187
33. ArchiveLogs—StorageGroupVolumes ............................ 193
34. ImageCopies—StorageGroupVolumes............................197
© Copyright IBM Corp. 1999 xv
xvi Storage Management with DB2 for OS/390
Preface
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.
© Copyright IBM Corp. 1999 xvii
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
xviii Storage 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
For IBM Intranet users http://w3.itso.ibm.com/
• Send us a note at the following address:
redbook@us.ibm.com
http://www.redbooks.ibm.com/
xix
xx Storage Management with DB2 for OS/390
Part 1. Introduction and Summary
© Copyright IBM Corp. 1999 1
2 Storage Management with DB2 for OS/390
Chapter 1. Introduction
Auxiliary storage management in the DB2 environment for the MVS platform has,
so far, been mainly the responsibility of the database administrators.
In the first few years of its usage, DB2’s implicit definition of page sets through its
Storage Groups (STOGROUP) often replaced the more traditional method of
explicitly allocating VSAM data sets because of DB2’s simplicity and ease of use.
Database administrators worried about separation of critical data sets, like data
from indexes, data from log, copies of log and BSDS, spreading workfiles,
through the usage of multiple Storage Groups and the careful association of
volumes to Storage Groups.
Until only few years ago, operators, storage managers, system programmers and
performance analysts had to interact frequently with the database administrators
in order to resolve issues related to DB2 data set management. Furthermore,
database administrators did not look favorably at SMS space management
because they felt that it interfered with the hand-placement of critical DB2 data
sets; SMS usage was limited to some hierarchical management of backup data
sets (image copies and archived logs).
Today, on one side we have a growing number of data warehousing types of
applications which require very large table spaces and query parallelism, causing
an explosion of the number of DB2 objects; on the other side we have more
flexible functions in SMS related products and innovative changes in the disk
architecture that can provide very useful functions for space and back-up
management. Most medium to large DB2 installations have to devote quite a
considerable amount of resources to the management of several thousand DB2
objects.
Furthermore, as processors and disk control units provide more capacity and
more memory, DB2 exploits its larger buffer pools as a second level of cache for
I/O execution, reducing the I/O frequency and making it mostly asynchronous.
This implies that the criticality of data set placement is greatly reduced.
In this redbook, as a level set, first we examine DB2 data set and I/O
characteristics, then we look at the main concepts and functions of SMS, and
then at the recent evolution of storage servers (disks).
We then provide a mapping of the possible applicability of SMS for all but the
most critical applications. This allows the database administrators to concentrate
on DB2 data sets relative to the applications with the highest service level
requirements, while the storage administrators can use SMS to simplify disk use
and control.
We finally look at the impact that large cache and the virtual architecture of the
current disk technology have on dealing with DB2 data.
Because of the necessity to monitor performance to avoid surprises, we also
show how to look at DB2 and I/O performance tools output from the overall
storage management perspective. Several examples are reported in the
appendixes.
© Copyright IBM Corp. 1999 3
4 Storage Management with DB2 for OS/390
Chapter 2. Summary of Considerations
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.
© Copyright IBM Corp. 1999 5
• 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.
6 Storage 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 Considerations 7
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.
8 Storage Management with DB2 for OS/390
Part 2. DB2 and System Managed Storage
© Copyright IBM Corp. 1999 9
10 Storage Management with DB2 for OS/390
Chapter 3. DB2 Storage Objects
This chapter represents an introduction to DB2 for OS/390 (DB2 throughout this
redbook) for the storage administrators interested in understanding the different
types of data related objects used in a DB2 environment. Special emphasis is
placed on the data sets managed directly by DB2.
3.1 DB2 Overview
DB2 is a database management system based on the relational data model.
Many customers use DB2 for applications which require good performance
and/or high availability for large amounts of data. This data is stored in data sets
directly associated to DB2 table spaces and distributed across DB2 databases.
Data in table spaces is often accessed through indexes; indexes are stored in
index spaces.
Data table spaces can be divided into two groups: system table spaces and user
table spaces. Both of these have identical data attributes. The difference is that
system table spaces are required to control and manage the DB2 subsystem and
the user data. The consequence of this is that system table spaces require the
highest availability and some special consideration. User data cannot be
accessed without system data or with obsolete system data.
In addition to the data table spaces, DB2 requires a group of traditional data sets,
not associated to table spaces, that are used by DB2 in order to provide the
appropriate high level of data availability, the back-up and recovery data sets.
Proper management of these data sets is required to achieve this objective.
In summary, the three main data set types in a DB2 subsystem are:
1. DB2 back-up and recovery data sets
2. DB2 system table spaces
3. DB2 user table spaces
3.2 DB2 Data Objects
DB2 manages data by associating it to a set of DB2 objects. These objects are
logical objects. Some of these objects have a physical representation on storage
devices. The DB2 data objects are:
•TABLE
•TABLESPACE
• INDEX
• INDEXSPACE
• DATABASE
• STOGROUP
A complete description of all DB2 objects and their implementation can be found
in the DB2 for OS/390 Administration Guide, SC26-8957, in Section 2. Designing
a database.
© Copyright IBM Corp. 1999 11
3.2.1 TABLE
3.2.2 TABLESPACE
All data managed by DB2 is associated to a table. The data within the table is
organized in columns and rows, and this represents the minimum unit of data that
can be identified by the user.
The table is the main object used by DB2 applications. The SQL DML used by
application programs and end users directly references data in tables.
A table space is used to store one or more tables. A table space is physically
implemented with one or more data sets. Table spaces are VSAM linear data sets
(LDS). Because table spaces can be larger than the largest possible VSAM data
set, a DB2 table space may require more than one VSAM data set.
One of three different types of table spaces may be chosen for a specific table:
1. Simple (normally containing one table)
2. Segmented (containing one or more tables)
3. Partitioned (containing one, often large, table)
4. LOB (large object, new type of table space introduced with DB2 V6).
The maximum size of simple and segmented table spaces is 64 GB,
corresponding to the concatenation of up to 32 data sets, each of up to 2 GB in
size.
A single LOB column can be 2 GB, and the collection of all LOB values for a
given LOB column can be up to 4000 TB.
Table 1 on page 12 summarizes the partition and partitioned table space sizes for
different versions of DB2.
Table 1. Summary of Partition and Partitioned Table Space Sizes
DB2 Version Number of Partitions Maximum Size Total Maximum Size
V4* 1to16 4GB 64GB
17 to 32 2 GB 64 GB
33 to 64 1 GB 64 GB
V5** 254 4 GB 1,016 GB
V6*** 254 64 GB 16,256 GB
Note: * For a maximum total of 64 GB
Note: ** Requires LARGE parameter in CREATE TABLESPACE
Note: *** Requires DFSMS/MVS 1.5 and SMS-managed table space
Up to DB2 V4 the total maximum size of a partitioned table space is 64 GB.
Starting with DB2 V5, with the introduction of the LARGE parameter at creation
time, partitioned table spaces may have a total size of 1,016 GB, corresponding
to up to 254 partitions each with a data set size of 4 GB.
12 Storage Management with DB2 for OS/390
3.2.3 INDEX
3.2.4 INDEXSPACE
3.2.5 DATABASE
DB2 V6 has increased the maximum size of a partitioned table space to almost
16 TB, increasing the maximum data set size to 64 GB. This is supported only if
they are defined and managed with DFSMS 1.5.
A table can have zero or more indexes. An index contains keys. Each key may
point to one or more data rows. The purpose of indexes is to establish a way to
get a direct and faster access to the data in a table. An index with the UNIQUE
attribute enforces distinct keys and uniqueness of all rows in the referenced
table. An index with the CLUSTER attribute can be used to establish and
maintain a physical sequence in the data.
An index space is used to store an index. An index space is physically
represented by one or more VSAM LDS data sets.
When a non-partitioning index needs to be split across multiple data sets in order
to improve I/O performance, these particular type of data sets are called PIECEs.
DB2 V5 has introduced the capability of defining up to 128 pieces with a
maximum size of 2 GB. DB2 V6 and DFSMS 1.5 increase the limit to 254 pieces
of up to 64 GB.
A database is a DB2 representation of a group of related objects. Each of the
previously named objects has to belong to a database. DB2 databases are used
to organize and manage these objects. Normally a database is the association of
table spaces and index spaces used by an application or a coherent part of an
application.
3.2.6 STOGROUP
A DB2 Storage Group (STOGROUP) is a list of storage volumes. STOGROUPs
are assigned to databases, table spaces or index spaces when using DB2
managed objects. DB2 uses STOGROUPs for disk allocation of the table and
index spaces.
Installations that are SMS managed can define STOGROUP with VOLUMES(*).
This specification implies that SMS assigns a volume to the table and index
spaces in that STOGROUP. In order to do this, SMS uses ACS routines to assign
a Storage Class, a Management Class and a Storage Group to the table or index
space.
3.3 Creating Table Spaces and Index Spaces
Table and index spaces can be created in one of two ways:
• DB2 defined and managed
• User defined and managed
See the DB2 for OS/390 Administration Guide, SC26-8957, Chapter 2, Section
2-7, "Designing Storage Groups and Managing DB2 Data Sets", for a detailed
explanation on this subject.
DB2 Storage Objects 13
DB2 defined and managed spaces should be the choice by default. It is the easier
of these solutions and is adequate for most table and index spaces in the majority
of situations.
User defined table spaces provide more control of the data set placement and all
VSAM definition options are available. Examples of where user defined table
spaces may be required are:
• Table spaces that require specific DFSMS classes
• Table spaces with critical performance and availability requirements
• (In general, table spaces with special requirements)
3.3.1 DB2 Defined and Managed
Figure 1 on page 14 shows an example of a DB2 defined table space. The
CREATE TABLESPACE resolves the physical allocation and defines this table
space to DB2. The STOGROUP DSN8G610 defines a set of volumes for the data
set and PRIQTY specifies the size in KB. Indexes are created with a CREATE
INDEX statement. The CREATE INDEX statement defines both the index and the
associated index space. The CREATE INDEX also loads the index with entries
that point to the data (index rows) unless the DEFER YES parameter is specified.
CREATE TABLESPACE PAOLOR11
IN DSN8D61A
USING STOGROUP DSN8G610
PRIQTY 20
SECQTY 20
ERASE NO
LOCKSIZE ANY LOCKMAX SYSTEM
BUFFERPOOL BP0
CLOSE NO
CCSID EBCDIC;
Figure 1. Creating a STOGROUP Defined Table Space
3.3.2 User Defined and Managed
Two steps are required to create user defined table spaces or index spaces.
1. The physical allocation is done with an IDCAMS DEFINE CLUSTER; this is
shown in Figure 2 on page 14.
DEFINE CLUSTER -
( NAME(DB2V610Z.DSNDBC.DSN8D61A.PAOLOR1.I0001.A001) -
LINEAR REUSE VOLUMES(SBOX10) RECORDS(4096 50) -
SHAREOPTIONS(3 3) ) DATA ( NAME(DB2V610Z.DSNDBD.DSN8D61A.PAOLOR1.I0001.A001) ) -
CATALOG(DS2V6)
Figure 2. User Defined Table Space: Step 1—Define the Cluster
2. The table space or index space must be defined to DB2. An example is shown
in Figure 3 on page 15. It must be noted that the high level qualifier, the
14 Storage Management with DB2 for OS/390
database name, and the table space name in Figure 2 on page 14 must match
the definitions on Figure 3 on page 15.
CREATE TABLESPACE PAOLOR1 IN DSN8D61A
Figure 3. User Defined Table Space: Step 2— Define the Table Space
BUFFERPOOL BP0
CLOSE NO
USING VCAT DB2V610Z;
3.4 DB2 System Table Spaces
DB2 uses four internally defined databases to control and manage itself and the
application data. The databases are:
• The Catalog database
• The Directory database
• The Work database
• The Default database
This section provides a general description of these databases.
Two tables, SYSIBM.SYSCOPY, belonging to the DB2 catalog, and
SYSIBM.SYSLGRNX, belonging to the DB2 directory, are directly used by DB2 to
manage backup and recovery; they are also described in this section.
3.4.1 The DB2 Catalog and Directory
The Catalog database is named DSNDB06. The Directory database is named
DSNDB01. Both databases contain DB2 system tables. DB2 system tables store
data definitions, security information, data statistics and recovery information for
the DB2 system. The DB2 system tables reside in DB2 system table spaces.
The DB2 system table spaces are allocated when a DB2 system is first created,
that is, during the installation process. DB2 provides the IDCAMS statements
required to allocate these data sets as VSAM LDSs. The size of these LDSs is
calculated from user parameters specified on DB2 installation panels. Figure 4 on
page 16 shows panel DSNTIPD with default values for sizing DB2 system table
spaces. In this figure, parameters numbered 1 to 12 are used to size DB2 catalog
and directory table spaces.
3.4.2 The Work Database
In a non-data sharing environment, the Work database is called DSNDB07. In a
data sharing environment, the name is chosen by the user. The Work database is
used by DB2 to resolve SQL queries that require temporary work space. For
example, SQL statements containing JOIN, ORDER BY, GROUP BY, may require
space in the Work database, but this depends on available storage for the DB2
internal sort and the access path chosen by the DB2 optimizer.
Multiple table spaces can be created for the Work database. These table spaces
follow the normal rules for creating a table space. At least two table spaces
should be created, one with a 4K page size, and the other one with a 32K page
size. DB2 V6 supports page sizes of 8K and 16K for table spaces, but not for the
DB2 Storage Objects 15
Work database table spaces. When required, 8K and 16K pages are placed in a
32K table space of the Work database.
Figure 4 on page 16 shows how the size and number of table spaces in the Work
database is defined. Parameters 13 through 16 on this figure show the default
number of table spaces (one for each page size), and default sizes for the 4K
table space (16 MB) and the 32K table space (4 MB).
DSNTIPD INSTALL DB2 - SIZES
===>
Check numbers and reenter to change:
1 DATABASES ===> 200 In this subsystem
2 TABLES ===> 10 Per database (average)
3 COLUMNS ===> 10 Per table (average)
4 VIEWS ===> 3 Per table (average)
5 TABLE SPACES ===> 10 Per database (average)
6 PLANS ===> 200 In this subsystem
7 PLAN STATEMENTS ===> 30 SQL statements per plan (average)
8 PACKAGES ===> 300 In this subsystem
9 PACKAGE STATEMENTS ===> 10 SQL statements per package (average)
10 PACKAGE LISTS ===> 2 Package lists per plan (average)
11 EXECUTED STMTS ===> 15 SQL statements executed (average)
12 TABLES IN STMT ===> 2 Tables per SQL statement (average)
13 TEMP 4K SPACE ===> 16 Amount of 4K-page work space (megabytes)
14 TEMP 4K DATA SETS ===> 1 Number of data sets for 4K data
15 TEMP 32K SPACE ===> 4 Amount of 32K-page work space(megabytes)
16 TEMP 32K DATA SETS ===> 1 Number of data sets for 32K data
F1=HELP F2=SPLIT F3=END F4=RETURN F5=RFIND F6=RCHANGE
F7=UP F8=DOWN F9=SWAP F10=LEFT F11=RIGHT F12=RETRIEVE
Figure 4. Installation Panel for Sizing DB2 System Objects
3.4.3 SYSIBM.SYSCOPY
This table is a DB2 Catalog table. It is referred to by its short name: SYSCOPY.
The table space in which SYSCOPY is stored is called: DSNDB06.SYSCOPY.
SYSCOPY contains recovery related information for each table space. Its main
purpose is to manage image copies, but other related recovery information is
also recorded here. For example, SYSCOPY contains information of:
• Image copies
• Quiesce points
• LOAD executions
• REORG executions
• RECOVER executions
3.4.4 SYSIBM.SYSLGRNX
This table is a DB2 Directory table. It is referred to by its short name:
SYSLGRNX. The table space in which SYSLGRNX is stored is called:
DSNDB01.SYSLGRNX.
SYSLGRNX stores records that serve to improve recovery performance by
limiting the scan of the log to changes that must be applied. The SYSLGRNX
records contain the first log RBA (or LRSN in a data sharing group) and the last
16 Storage Management with DB2 for OS/390
log RBA (or LRSN) of updates to a table space. The record is opened when a first
update is detected, and closed after an interval of read only activity. The interval
is defined with two read-only switch parameters on the DB2 installation panel
DSNTIPN.
3.5 DB2 Application Table Spaces
All application data in DB2 is organized in the objects described in 3.2, “DB2 Data
Objects” on page 11. Application table spaces and index spaces are created as
shown in 3.3, “Creating Table Spaces and Index Spaces” on page 13.
Application table spaces and index spaces are VSAM LDS data sets, with exactly
the same data attributes as DB2 system table spaces and index spaces. The
distinction between system and application data is made only because they have
different performance and availability requirements.
3.6 DB2 Recovery Data Sets
In order to ensure data integrity, DB2 uses several traditional data sets for
recovery purposes. Not all of these are always needed by DB2, but all of them
are required for contingency reasons. DB2 supports two or more copies of these
data sets to ensure a high level of data integrity.
A short description of DB2 recovery data sets is provided here. A good
description is available in "Managing the Log and the Bootstrap Data Set" in the
Administration Guide of DB2 for OS/390, SC26-8957. An attempt has been made
to avoid redundancy in these descriptions.
3.6.1 Bootstrap Data Sets
DB2 uses the bootstrap data set (BSDS) to manage recovery and other DB2
subsystemwide information. The BSDS contains information needed to restart
and to recover DB2 from any abnormal circumstance. For example, all log data
sets (active and archive) are automatically recorded within the BSDS. While DB2
is active, the BSDS is open and is updated.
Because the BSDS is critical for DB2 data integrity, DB2 always requires the
presence of two copies of the BSDS at start up time. If a copy fails while DB2 is
running, DB2 sends a warning message and continues operating with a single
BSDS. It is the responsibility of operations to monitor this circumstance and
restore the BSDS duality as soon as possible.
To recover a lost BSDS, when DB2 is executing:
1. The failing BSDS must be deleted.
2. The failing BSDS must be redefined, or alternatively, an existing spare BSDS
copy must be renamed.
3. The BSDS is rebuilt with a -RECOVER BSDS command.
If a BSDS copy fails while DB2 is starting, the startup does not complete.
To recover a lost BSDS, when DB2 is stopped:
1. The failing BSDS must be deleted.
DB2 Storage Objects 17
3.6.2 Active Logs
2. The failing BSDS must be redefined, or alternatively, an existing spare BSDS
copy must be renamed.
3. The BSDS is rebuilt from the good copy with an IDCAMS REPRO.
The active log data sets are used for data recovery and to ensure data integrity in
case of software or hardware errors. DB2 uses active log data sets to record all
updates to user and system data.
The active log data sets are open as long as DB2 is active. Active log data sets
are reused when the total active log space is used up, but only after the active log
(to be overlaid) has been copied to an archive log.
DB2 supports dual active logs. It is strongly recommended to make use of dual
active logs for all DB2 production environments.
Sizing Active Logs
The amount of space dedicated to each individual active log data set is not
critical for the DB2 administrator. Traditionally, the active logs have been sized for
practical reasons, for example, to make best use of the archive log device (tape
cartridge or disk volume).
It is the overall size of all active log data sets that is important for the DB2 DBA:
this size plays a critical role in the backup and recovery strategy.
The number of active log data sets, multiplied by the space of each active log,
defines an amount of log information most readily available: the capacity of the
active log. This capacity defines the time period that has the best recovery
performance and the highest data availability service level. The reason is that the
DB2 RECOVER utility generally performs better with an active log than with an
archive log. See 10.5.2, “Active Log Size” on page 117 for more details.
Impact of Log Size on Backup and Recovery Strategy
The relationship between the different types of log data sets is shown in Figure 5
on page 19. This figure shows a timeline that begins when a DB2 subsystem is
first started (Start Time) and proceeds until the current time (Current Time).
During this whole time, log data has been generated; this is shown by the DB2
LOG bar.
The log data sets have limited capacity and cannot cover the total time period.
The amount of DB2 log in the active log data sets (the active log capacity) is
shown as the time period from Time 2 to the Current Time. The oldest still
available archive log corresponds to Time 1. Because the whole log is not
available, recoveries are only possible throughout the period from Time 1 to
Current Time. The time period from Time 2 to Current Time corresponds to the
period with most efficient recoveries because, generally, the active log is
allocated on faster devices. The archive log usually overlaps with the active log
for a minimum of the last pair of active log data sets not yet archived up to some
time after Time 2 and before Current Time. If the data needed for RECOVER or
RESTART has been archived, but is still available on an active log data set not
yet reused, DB2 accesses the active log.
A good backup and recovery strategy considers:
18 Storage Management with DB2 for OS/390
• The amount of time to cover with all logs (Time 1 up to Current Time)
• The amount of time to cover with active logs (Time 2 up to Current Time)
3.6.3 Archive Logs
Start
Time
Time
1
Time
2
Current
Time
DB2 LOG
ACTIVE LOG
ARCHIVE + ACTIVE LOG
Figure 5. DB2 Log and Its Data Sets
Archive log data sets are DB2 managed backups of the active log data sets.
Archive log data sets are created automatically by DB2 whenever an active log is
filled. They may also be created with the -ARCHIVE command for operational
requirements. Additional circumstances may trigger the archiving process. The
DB2 for OS/390 Administration Guide, SC26-8957, describes these in detail.
DB2 supports dual archive logs and it is recommended to use dual archive log
data sets for all production environments. When dual archive log is specified,
during the archiving, the primary active log is read and two archive log data sets
are written in parallel. For better archive log availability, customers should define
both copies on different devices (or SMS classes) to physically separate the dual
data sets.
Archive log data sets are required for any recovery that spans a period of time in
excess of the time covered by the active logs. Archive log data sets are
sequential data sets that can be:
• Defined on disk or on tape
•Migrated
• Deleted with standard procedures
Archive log data sets are required for data integrity. Procedures are required to
ensure that archive log data sets are only deleted when they are not going to be
required anymore.
This book contains references related to archive log deletes, in the following
sections:
• “Deleting Image Copies and Archive Logs” on page 21.
• “Impact of Log Size on Backup and Recovery Strategy” on page 18.
DB2 Storage Objects 19
3.6.4 Image Copies
Image copies are the backup of user and system data. DB2 V6 introduces the
possibility of taking image copy for indexes. For a well-managed backup and
recovery policy, it is recommended that the amount of data in image copy data
sets should cover at least three generations of image copies in order to
guarantee recoverability. This means that a large number of image copy data sets
is required and needs to be managed in DB2 installations.
ImageCopyAvailability
Image copies ensure user and system data integrity. Their availability is critical
for DB2 system and application availability. DB2 can optionally generate up to
four image copies of a table space, index space, or data set (for a multiple data
set table space or index space). Two of these copies are intended for a disaster
recovery at a remote site. For better image copy availability, customers should
define the copies on different devices (or SMS classes) to physically separate the
data sets.
ImageCopyOptions
Image copies can be run in two important varieties, either FULL or
INCREMENTAL. Full image copies are complete backups of a table space or data
set. Incremental copies only contain the changes since the last full image copy.
Incremental and image copies can be combined (merged) to create other
incremental or full image copies.
The SHRLEVEL option is used to specify application access during the copy.
SHRLEVEL REFERENCE creates a consistent copy. During the SHRLEVEL
REFERENCE copy, only read access is allowed. SHRLEVEL CHANGE creates a
copy while the data is updated. Figure 6 on page 20 and Figure 7 on page 21
illustrate the impact these copies have on application read and write processing.
The DB2 RECOVER utility can handle the updates not reflected in a SHRLEVEL
CHANGE copy by applying the log records corresponding to those updates.
APPLICATION WRITE
Figure 6. Image Copy SHRLEVEL REFERENCE
APPLICATION READ PROCESSING
APPLICATION WRITE PROCESSING
IMAGE COPY
20 Storage Management with DB2 for OS/390
APPLICATION READ PROCESSING
APPLICATION WRITE PROCESSING
IMAGE COPY
Figure 7. Image Copy SHRLEVEL CHANGE
Another option for image copies is the use of the concurrent copy feature, with or
without SnapShot. Concurrent copy and SnapShot are described in 9.5.2,
“Concurrent Copy” on page 94. These features allow DB2 to create full image
copies with only a short time interval of data unavailability. This is illustrated in
Figure 26 on page 94. The DB2 RECOVER utility is able to handle these copies.
Table 2 on page 21 shows the different options available for an image copy with
and without the concurrent option.
Table 2. DB2 Image Copy with and without Concurrent Copy
CONCURRENT TYPE SHRLEVEL
FULL INCR REFERENCE CHANGE
YES YES NO YES YES
NO YES YES YES YES
a. Short unavailability at data set level
b. Not valid for page size larger than 4K
a,b
ImageCopyFailuresDuringRecovery
During a recovery, an image copy may fail (for example, due to an I/O error). In
this case, RECOVER attempts to use the dual image copy, assuming that such a
copy exists. If the copy does not exist or also fails, RECOVER ignores the copy if
it is an incremental image copy, and uses the log for recovery. If the failing image
copy is a full copy, RECOVER falls back to an earlier full image copy to complete
the recovery. The fallback has a performance penalty, but it helps to insure
availability.
Because the fallback insures recoverability, some installations do not generate
dual image copies. These installations prefer to run frequent incremental image
copies instead.
Deleting Image Copies and Archive Logs
Image copies are required for data integrity. The customer must have procedures
to ensure that image copies are deleted only when they are not required
anymore. Moreover, because image copies and archive logs are used together,
the deletion of these data sets has to be synchronized. For example, there no use
DB2 Storage Objects 21
for an archive log that is older than the oldest image copy unless other types of
backups, not just image copies, are also used for recovery.
Image copies and archive logs are recorded in DB2 and optionally cataloged in
an ICF Catalog. Physical deletion of the data sets removes them from the ICF
catalog. This physical deletion must be coordinated with a DB2 cleanup
procedure to remove obsolete information in SYSIBM.SYSCOPY. This cleanup is
performed with the MODIFY utility.
The deletion from the MVS catalog and the DB2 catalog of image copy data sets
must also be synchronized with the deletion of the log data sets from the MVS
catalog and from the BSDS.
3.6.5 Other Copies
DB2 table and index spaces can be copied by other utilities, not under DB2
control. This can include both IBM (DFSMSdfp, DSN1COPY) and non-IBM
products. DB2 has a limited support for these copies. The copies must be
restored outside of DB2, and the user must execute a RECOVER with option
LOGONLY to apply the changes not reflected in the external copy in order to
maintain data integrity and consistency.
3.7 Other DB2 Data Sets
Apart from table spaces and recovery data sets, DB2 requires also data sets to
store the product (libraries), to manage its execution (Clists, JCL procedures, and
work data sets). These data sets are standard MVS data sets, either partitioned
or sequential.
3.7.1 DB2 Library Data Sets
DB2 uses a set of library data sets to store distribution code, executable code,
ISPF data sets, TSO data sets, SMP/E data sets, and so on. These library data
sets are all MVS partitioned data sets (PDS). These data sets are defined during
the SMP/E installation of the DB2 product.
3.7.2 DB2 Temporary Data Sets
DB2 also uses temporary data sets. Examples are utility work and external sort
data sets. Most temporary data sets are standard sequential files. These data
sets are defined explicitly in utility JCL or are created dynamically at utility
execution time.
To allocate these data sets, DB2 has internal default attributes that can be
overridden by the user in the JCL stream.
3.8 DB2 Data Sets Naming Conventions
This section describes the naming standards used by DB2 for its data sets.
22 Storage Management with DB2 for OS/390
3.8.1 Table Space and Index Space Names
The names for DB2 table spaces and index spaces have the following structure:
Table 3. Table Space and Index Space Names
hlq.DSNDBx.dbname.spname.ynnnn.Ammm
The elements of this name are:
hlq VSAM catalog high level qualifier
DSNDB Standard part of the name
x Identifies a VSAM cluster or data component
C Cluster
D Data
dbname Database name
spname Space name. Either a table space name or an index name. Because
index names can be more than 8 characters long, DB2 sometimes
needs to generate an 8 character name. To avoid randomly generated
names, and to be able to correlate the index name to the index space,
it is recommended to limit index names to 8 characters. This is also
true for table names for implicitly defined table spaces (that is, the
creation of the table is done without having created the table space),
since DB2 will assign a unique table space name.
y Data set type:
nnnn number = 0001
A Standard character, A
mmm Used for table spaces or index spaces with multiple data sets; mmm is
3.8.2 BSDS Names
The default names for BSDSs have the following structure:
Table 4. BSDS Names
hlq VSAM catalog high level qualifier
BSDS0 Standard part of the name
n BSDS copy, 1 or 2
3.8.3 Active Log Names
The default names for active log data sets have the following structure:
Table 5. Active Log Data Set Names
I Standard data set
S Shadow data set
T Temporary data set
either 001, the data set number, or the partition number.
hlq.BSDS0n
hlq.LOGCOPYn.DSmm
hlq VSAM catalog high level qualifier
DB2 Storage Objects 23
LOGCOPY Standard part of the name
n Activelogcopy,1or2
mm Active log number, 01 to 31
3.8.4 Archive Log and BSDS Backup Names
The default names for archive log and BSDS backup data sets have the following
optional structure:
Table 6. Archive Log and BSDS Backup Names
hlq.ARCHLOGn.Dyyddd.Thhmmsst.axxxxxx
hlq VSAM catalog high level qualifier
ARCHLOG Standard part of the name
n Archive log copy, 1 or 2
Dyyddd Date, yy=year (2 or 4 digits), ddd=day of year
Thhmmsst Time, hh=hour, mm=minute, ss=seconds, t=tenths
a A=Archive log, B=BSDS backup
xxxxxx File sequence
Dyyddd and Thhmmsst are optional qualifiers defined in DSNZPARM in the
TIMESTAMP ARCHIVES option (YES or NO) of the DSNTIPH panel,
and Dyyddd can assume the format Dyyyyddd if the TIMESTAMP
ARCHIVES option is set to EXT (extended).
3.8.5 Image Copy Names
The names for image copy data sets are not defined by DB2. Each installation
needs to define a standard naming convention to make these data sets distinct
and significant. Table 7 on page 24 shows a sample naming structure for image
copies.
Table 7. Sample Image Copy Names
hlq VSAM catalog high level qualifier
w Copy type, P=Primary, S=Secondary copy
x Copy requirement, S=Standard, H=Critical
i Copy frequency, D=Daily, W=Weekly, M=Monthly
yyddd Date, yy=year, ddd=day of year
Thhmmsst Time, hh=hour, mm=minute, ss=seconds
ssssss table space or index space name
Ammm Data set identifier
hlq.wxiyyddd.Thhmmss.ssssss.Ammm
24 Storage Management with DB2 for OS/390
Chapter 4. System Managed Storage Concepts and Components
This chapter is designed to familiarize the DB2 database administrator (DBA)
with the concepts and components of system managed storage (SMS). The
following topics are discussed:
• Background
•Evolution
• DFSMS/MVS components
4.1 Background
The continued growth of data requires the need for a more effective and efficient
way of managing both data and the storage on which it resides. SMS was
introduced in 1988 both as a concept and then as a group of products of MVS
provide a solution for managing disk storage. Based upon user specifications,
SMS can determine data placement, backup, migration, performance and
expiration. The goals of SMS are:
• A reduction in the number of personnel required to manage that data, by
allowing the system to manage as much as possible
• A reduction in labor-intensive related tasks of disk management, by
centralizing control, automating tasks, and providing interactive tools
1
to
4.2 Evolution
• A reduction in the necessity for user knowledge of placement, performance,
and space management of data
Although initially a concept, with a small number of products offering limited
2
functionality, the introduction of DFSMS
has provided the functions needed for a
comprehensive storage management subsystem, which provides:
• Management of storage growth
• Improvement of storage utilization
• Centralized control of external storage
• Exploitation of the capabilities of available hardware
• Management of data availability
With each subsequent release of the product, more features have been
introduced that further exploit the concepts of SMS managed data, and this is
likely to continue; for example, advanced functions for all types of VSAM files,
which require the use of the extended addressability (EXT) attribute in the Data
Class. It is therefore important to understand that those customers who have
taken the time and effort to implement an SMS policy ultimately gain more from
DFSMS enhancements than those who have not.
The characteristics of a DB2 system allows for the management of its data by
SMS. However, there are considerations and choices that need to be made to
tailor it to suit the individual customer’s environment. These considerations are
discussed in the following sections.
1
The term MVS (OS/390) refers to the family of products which, when combined, provide a fully integrated operating system.
2
The term DFSMS refers to the family of products which, when combined, provide a system managed storage environment.
© Copyright IBM Corp. 1999 25
4.3 DFSMS/MVS Components
DFSMS/MVS provides and enhances functions formerly provided by MVS/DFP,
Data Facility Data Set Services (DFDSS), and the Data Facility Hierarchical
Storage Manager (DFHSM). The product is now easier to install and order than
the combination of the earlier offerings. This chapter describes the main
components of the DFSMS/MVS family:
•DFSMSdfp
•DFSMSdss
•DFSMShsm
•DFSMSrmm
• DFSMSopt
4.3.1 DFSMSdfp
The Data Facility Product (DFP) component provides storage, data, program,
tape and device management functions.
DFP is responsible for the creation and accessing of data sets. It provides a
variety of different access methods to organize, store and retrieve data, through
program and utility interfaces to VSAM, partitioned, sequential, and direct access
types.
DFP also provides the Interactive Storage Management Facility (ISMF) which
allows the definition and maintenance of storage management policies
interactively. It is designed to be used by both storage administrators and end
users.
4.3.1.1 ISMF for the End User
Figure 8 on page 26 shows the ISMF primary option menu displayed for an end
user. Various options allow the user to list the available SMS classes, display their
attributes, and build lists of data sets based upon a selection criteria. These lists
are built from VTOC or catalog information, and tailored using filtering, sorting,
masking criteria. This panel is selected from the ISPF/PDF primary menu
(dependent upon site customization).
ISMF PRIMARY OPTION MENU - DFSMS/MVS 1.5
Enter Selection or Command ===>
Select one of the following options and press Enter:
0 ISMF Profile - Change ISMF User Profile
1 Data Set - Perform Functions Against Data Sets
2 Volume - Perform Functions Against Volumes
3 Management Class - Specify Data Set Backup and Migration Criteria
4 Data Class - Specify Data Set Allocation Parameters
5 Storage Class - Specify Data Set Performance and Availability
9 Aggregate Group - Specify Data Set Recovery Parameters
L List - Perform Functions Against Saved ISMF Lists
R Removable Media Manager - Perform Functions Against Removable Media
X Exit - Terminate ISMF
Figure 8. ISMF Primary Option Menu for End Users
26 Storage Management with DB2 for OS/390
4.3.1.2 ISMF for the Storage Administrator
Figure 9 on page 27 shows the ISMF primary option menu displayed for a storage
administrator. Options allow lists to be built from volume selection criteria
(Storage Group), as well as the Management Class, Data Class, and Storage
Class facilities allowing the individual to define, alter, copy, and delete SMS
classes, volumes, and data sets. Again, these lists are built from VTOC or catalog
information, and tailored in the same way. This panel is selected from the
ISPF/PDF primary menu (dependent upon site customization).
ISMF PRIMARY OPTION MENU - DFSMS/MVS 1.5
Enter Selection or Command ===>
Select one of the following options and press Enter:
0 ISMF Profile - Specify ISMF User Profile
1 Data Set - Perform Functions Against Data Sets
2 Volume - Perform Functions Against Volumes
3 Management Class - Specify Data Set Backup and Migration Criteria
4 Data Class - Specify Data Set Allocation Parameters
5 Storage Class - Specify Data Set Performance and Availability
6 Storage Group - Specify Volume Names and Free Space Thresholds
7 Automatic Class Selection - Specify ACS Routines and Test Criteria
8 Control Data Set - Specify System Names and Default Criteria
9 Aggregate Group - Specify Data Set Recovery Parameters
10 Library Management - Specify Library and Drive Configurations
11 Enhanced ACS Management - Perform Enhanced Test/Configuration Management
C Data Collection - Process Data Collection Function
L List - Perform Functions Against Saved ISMF Lists
R Removable Media Manager - Perform Functions Against Removable Media
4.3.2 DFSMSdss
Figure 9. ISMF Primary Option Menu for Storage Administrators
The Data Set Services (DSS) component is a disk storage management tool. It
can be invoked using ISMF. The following sections describe DSS capabilities.
4.3.2.1 Functionality
The DSS component is able to perform a variety of space management functions.
Of these, the most common are listed below:
COMPRESS Compresses partitioned data sets.
CONVERTV Converts existing volumes to and from SMS management
without data movement.
COPY Performs data set, volume, and track movement, allowing
the movement of data from one disk volume to another,
including unlike device types.
COPYDUMP Allows the generation of 1 to 255 copies of DFSMSdss
produced dump data. The data to be copied can be tape
or disk based, and copies can be written to tape or disk
volumes.
DEFRAG Reduces or eliminates free-space fragmentation on a disk
volume.
DUMP Performs the dumping of disk data to a sequential volume
(either tape or disk). The process allows either:
System Managed Storage Concepts and Components 27
Logical processing, which is data set oriented. This
means it performs against data sets independently of the
physical device format.
Physical processing, which can perform against data
sets, volumes, and tracks, but moves data at the
track-image level.
PRINT Used to print both VSAM and non-VSAM data sets, track
ranges, or a VTOC.
RELEASE Releases allocated but unused space from all eligible
sequential, partitioned, and extended format VSAM data
sets.
RESTORE Data can be restored to disk volumes from DFSMSdss
produced dump volumes, as individual data sets, an
entire volume, or a range of tracks. Again, logical or
physical processing can be used.
4.3.2.2 Filtering
The DSS component uses a filtering process to select data sets based upon
specified criteria. These include:
• Fully or partially qualified data set name
• Last reference data
• Size of data sets
• Number of extents
• Allocation type (CYLS, TRKS, BLKS)
•SMSClass
4.3.2.3 Converting Data to SMS
Data sets can be converted by data movement using the COPY or DUMP and
RESTORE functions. However, it is possible and quite common to convert data in
place, without the need for movement, by using the CONVERTV command. This
allows:
• The preparation of a volume for conversion by preventing new data set
allocations.
• Conversion simulation, to test for any data sets that do not match the
expected criteria.
• Actual conversion of a volume to SMS management.
• Converting a volume from SMS management, for example, as part of a
Disaster Recovery scenario.
4.3.3 DFSMShsm
The Hierarchical Storage Manager (HSM)3component provides availability and
space management functions. For more information, please refer to the
DFSSMShsm Primer, SG24-5272.
HSM improves productivity by making the most efficient use of disk storage,
primarily by making better use of the primary volumes. It performs both
availability management and space management automatically, periodically, and
3
Other Vendor products exist which have similar capabilities, and can be used in place of HSM, although this may restrict full exploitation
of ISMF.
28 Storage Management with DB2 for OS/390
by issuing specific commands when manual operations are appropriate. Volumes
can be:
• Managed by SMS. In this case the Storage Group definitions controls HSM
initiated automatic functions, depending upon the appropriate Management
Class of the data set.
• Managed by HSM. These volumes are commonly known as primary or level 0.
Here each volume is defined to HSM individually by the ADDVOL parameter
and governed accordingly.
• Owned by HSM. These incorporate migration level 1 (ML1), migration level 2
(ML2), backup, dump and aggregate volumes, and are a combination of disk
and tape. Alternate tape copies can be made of ML2 and backup tapes for
off-site storage. Also, spill volumes can be generated from backups and ML2
volumes to improve tape usage efficiency.
Figure 10 shows the relationship between the main components of the HSM
environment.
DFSMShsm Environment
Level 0
Recall
ML1
Recycle
ML2
Figure 10. DFSMShsm Components
4.3.3.1 Space Management
On a daily basis, HSM performs automatic space management,
depending upon whether the volume is part of an SMS Storage Group
or managed individually by HSM. Space management consists of the
following functions:
SMS
Storage
Groups
Dump
HSM
Primary
Volumes
ABARS
Recycle
Recover
Incremental
Backup
Spill
•Migration
This is the process of moving eligible, inactive, cataloged data sets to
either ML1 or ML2 volumes, from primary volumes (Level 0). This is
System Managed Storage Concepts and Components 29
determined by either the Management Class for SMS managed data
sets, or set by the ADDVOL parameter for HSM managed. It can also be
controlled in combination with volume thresholds set by the storage
4
administrator. Data sets may be migrated to ML1 (normally disk)
,after
a period of inactivity, and then onto ML2 (tape) following a further period
of non-usage. It is feasible, and maybe more appropriate in certain
cases, to migrate directly to ML2. Additionally, there is an interval
migration process which can be used to free space on volumes during
times of high activity.
• Expiration processing
This is based upon the inactivity of data sets. For HSM managed
volumes, all data sets are treated in the same way on each volume. For
SMS managed volumes, the expiration of a data set is determined by
the Management Class attributes for that data set.
• Release of unused space
HSM can release over-allocated space of a data set for both SMS managed and
non-SMS managed data sets.
• Recall
There are two types of recall:
• Automatically retrieving a data set when a user or task attempts to access
it
• When the HRECALL command is issued
All recalls are filtered; if the data set is SMS managed, then SMS controls the
volume selection. If the data set is non-SMS, HSM directs the volume
allocation. However, it is possible for the storage administrator to control a
recall and place it on an appropriate volume or Storage Group if required.
4.3.3.2 Availability Management
The purpose of availability management is to provide backup copies of data sets
for recovery scenarios. HSM can then restore the volumes and recover the data
sets when they are needed.
• Incremental backups
This is the process of taking a copy of a data set, depending upon whether it
has changed (open for output; browse is not sufficient), since its last backup.
For SMS managed volumes, HSM performs the backup according to the
attributes of the Management Class of the individual data set. For non-SMS
managed volumes, HSM performs the backup according to the ADDVOL
definition.
• Full volume dumps
A full volume dump backs up all data sets on a given volume, by invoking
DSS. HSM Dump Classes exist which describe how often the process is
activated, for example, daily, weekly, monthly, quarterly or annually.
• Aggregate backup
ABARS is the process of backing up user defined groups of data sets that are
business critical, to enable recovery should a scenario arise.
4
Very large data sets, in excess of 64,000 tracks, cannot be migrated to disk: they must be migrated to migration level 2 tape.
30 Storage Management with DB2 for OS/390
4.3.4 DFSMSrmm
• Recovery
Recovery can be either at the individual data set level or to physically restore
a full volume. This is applicable for both SMS and non-SMS managed data
sets.
Note that full exploitation of this component requires the use of the DSS and
Optimizer components of DFSMS.
The Removable Media Manager (RMM)5component provides facilities for tape
and cartridge formats, including library, shelf, volume and data set level
management.
Tapes are an effective media for storing many types of data, especially backup
and archive copies of disk data sets. However, tapes must be mounted to be
used, and the capacity of tapes is often not fully used. DFSMS/MVS can be used
to assist in more effective use of tape resources.
With SMS, a group of disks can be defined to act as a buffer for tape drives, and
allow HSM to manage writing the tape volumes and data sets on those volumes.
DFSMS/MVS permits the use of system managed tape volumes, and RMM can
be used to manage the inventory of system managed and non system managed
tapes.
4.3.5 DFSMSopt
For further information on this topic, see the DFSMS/MVS V1R4 DFSMSrmm
Guide and Reference, SC26-4931-05.
The Optimizer (OPT) component is one of the supporting products of
DFSMS/MVS, and is a separately orderable feature. It provides data analysis and
simulation information, which assists in improving storage usage and reducing
storage costs. It can be used to:
Monitor and tune HSM functions.
Create and maintain a historical database of system and data activity.
Perform analysis of Management Class, and Storage Class policies, including
simulation, costing analysis, and recommendations for data placement.
Identify high I/O activity data sets, and offer recommendations for data
placement.
Monitor storage hardware performance of subsystems and volumes, including I/O
rate, response time, and caching statistics.
Fine tune the SMS configuration, by presenting information to help understand
how current SMS practices and procedures are affecting the way data is
managed.
5
Other Vendor products exist which have similar capabilities, and can be used in place of RMM, although this may restrict full
exploitation of ISMF.
System Managed Storage Concepts and Components 31
• Simulate potential policy changes and understand the costs of those changes.
• Produce presentation quality charts.
For more information on the DFSMS/MVS Optimizer Feature, see the following
publications:
• DFSMS Optimizer V1R2 User's Guide and Reference, SC26-7047-04
• DFSMS Optimizer: The New HSM Monitor/Tuner, SG24-5248
4.3.6 SMF Records 42(6)
DFSMS statistics and configuration records are recorded in SMF record type 42.
The type 42, subtype 6, SMF record provides information about data set level
performance. DFSMS must be active, but the data set does not need to be SMS
managed. Two events cause this record to be generated: data set close time and
each type 30 interval record being written.
You can use DFSMSopt or any SMF specialized package to format and display
this useful record. For instance, you can start by looking at the list of the first 20
data sets in terms of activity rate at the specified interval and verify that the most
accessed DB2 data sets are performing as expected both in terms of I/O and
usage of DB2 buffer pools.
Also, accesses to critical data sets can be tracked periodically by data set name.
Their performance can be mapped against the DB2 PM accounting to determine
detailed characteristics of the I/O executed, and to verify cache utilization.
4.4 Benefits
A summary of the benefits of SMS follows:
• Simplified data allocation
SMS enables users to simplify their data allocations. Without using SMS, a
user would have to specify the unit and volume on which the system should
allocate the data set. In addition, space requirements would need to be
calculated and coded for the data set. With SMS, users can let the system
select the unit, volume and space allocation. The user therefore, does not
need to know anything about the physical characteristics of the devices in the
installation.
• Improved allocation control
Free space requirements can be set using SMS across a set of disk volumes.
Sufficient levels of free space can be guaranteed to avoid space abends. The
system automatically places data on a volume containing adequate freespace.
• Improved performance
SMS can assist in improving disk I/O performance, and at the same time
reduce the need for manual tuning by defining performance goals for each
class of data. Cache statistics, recorded in system management facilities
(SMF) in conjunction with the Optimizer feature, can be used to assist in
evaluating performance. Sequential data set performance can be improved by
using extended sequential data sets. The DFSMS environment makes the
most effective use of the caching abilities of disk technology.
32 Storage Management with DB2 for OS/390
• Automated disk space management
SMS has the facility to automatically reclaim space which is allocated to old
and unused data sets. Policies can be defined that determine how long an
unused data set are allowed to reside on level 0 volumes (active data).
Redundant or expired data can be removed by the process of migration to
other volumes (disk or tape), or the data can be deleted. Allocated but unused
space can be automatically released, which is then available for new
allocations and active data sets.
• Improved data availability management
With SMS, different backup requirements can be provided for data residing on
the same primary volume. Therefore, all data on a single volume can be
treated independently. The HSM component can be used to automatically
back up data. The ABARS facility can be used to group data sets into logical
components, so that the group is backed up at the same time, allowing for
recovery of an application.
• Simplified data movement
SMS permits the movement of data to new volumes without the necessity for
users to amend their JCL. Because users in a DFSMS environment do not
need to specify the unit and volume which contains their data, it does not
matter to them if their data resides on a specific volume or device type. This
allows the replacement of old devices with minimum intervention from the
user.
System determined block sizes can be utilized to automatically reblock
sequential and partitioned data sets that can be reblocked.
System Managed Storage Concepts and Components 33
34 Storage Management with DB2 for OS/390
Chapter 5. Storage Management with DFSMS
This chapter is designed to familiarize the DB2 administrator with the functionality
of SMS. This chapter covers the following topics:
• The SMS base configuration
• The automatic class selection routine
• The SMS constructs
• Objectives of using SMS with a DB2 system
• How SMS can handle DB2 special data
Further information can be found in the following publications:
• DFSMS/MVS V1R4 Implementing System-Managed Storage, SC26-3123
• MVS/ESA SML: Managing Data, SC26-3124
• MVS/ESA SML: Managing Storage Groups, SC26-3125
5.1 Introduction
SMS manages an installation’s data and storage requirements according to the
storage management policy in use. Using ISMF, the storage administrator defines
an installation’s storage management policy in an SMS configuration, which
consists of:
• The base configuration
• Class and Storage Group definitions
5.1.1 Base Configuration
The base configuration contains defaults and identifies the systems which are
SMS managed. The information is stored in SMS control data sets, which are
VSAM linear data sets. These consist of:
• Source control data set (SCDS)
• Active control data set (ACDS)
• Communications data set (COMMDS)
Source Control Data Set
The source control data set (SCDS) contains the information that defines a single
storage management policy, called an SMS configuration. More than one SCDS
can be defined, but only one can be used to activate a configuration at any given
time.
Active Control Data Set
The active control data set (ACDS) contains the SCDS that has been activated to
control the storage management policy for the installation. When a configuration
is activated, SMS copies the existing configuration from the specified SCDS into
the ACDS. While SMS uses the ACDS, the storage administrator can continue to
create copies of the ACDS, modify, and define a new SCDS if desired.
© Copyright IBM Corp. 1999 35
Communications Data Set
The communications data set (COMMDS) holds the name of the ACDS and
provides communication between SMS systems in a multisystem environment.
The COMMDS also contains statistics on the SMS, and MVS status for each SMS
volume, including space.
5.1.2 Class and Storage Group Definitions
The storage management policies are defined to the system by use of classes.
Data sets have classes assigned to them. These are Data Class, Storage Class,
and Management Class, and they determine the volume allocation which forms
the Storage Group. The classes manage the data sets, and the Storage Groups
manage the volumes on which the data sets reside.
Figure 11 on page 36 shows the steps taken by an installation to implement an
active SMS configuration.
ALLOCATE CONTROL DATASETS
MODIFY AND CREATE SYS1.PARMLIB MEMBERS
ESTABLISH ACCESS TO STORAGE ADMIN ISMF OPTIONS
DEFINE BASE CONFIGURATION
DEFINE CLASSES AND STORAGE GROUPS
DEFINE AND TEST ACS ROUTINES
VALIDATE ACS ROUTINES AND SMS CONFIGURATION
ACTIVATE SMS CONFIGURATION
Figure 11. Implementing an SMS Configuration
5.2 Automatic Class Selection Routines
Automatic Class Selection (ACS) routines are the mechanism for assigning SMS
classes and Storage Groups. They determine the placement of all new data set
allocations, plus allocations involving the copying, moving, recalling, recovering,
and converting of data sets. ACS routines are written in a high level REXX style
programming language. If SMS is activated, all new data set allocations are
subject to automatic class selection.
There are four ACS routines. Aggregate groups also exist, but for the purposes of
this book are only mentioned where relevant. The ACS routines are executed in
the following order:
36 Storage Management with DB2 for OS/390
1. Data Class—data definition parameters.
2. Storage Class—performance and accessibility requirements.
3. Management Class—migration, backup and retention attributes.
4. Storage Group—candidate allocation volumes.
Because data set allocations, whether dynamic or through JCL, are processed
through ACS routines, installation standards can be enforced on those
allocations on both SMS and non-SMS managed volumes. ACS routines permit
user defined specifications for Data, Storage, and Management Classes, and
requests for specific volumes, to be overridden, thereby offering more control of
where data sets are positioned within the system.
For a data set to qualify for SMS management, it must satisfy the Storage Class
component. If a valid Storage class is assigned, then the data set is managed by
SMS, and proceeds via the Management Class and Storage Group routines
before being allocated on a SMS volume. If a null Storage class is assigned, the
data set exits from the process, is not managed by SMS, and is allocated on a
non-SMS volume.
Figure 12 on page 37 shows the execution process for defining data sets in an
MVS system (with SMS active).
Conversion
Procedure
(DFSMSdss/hsm)
ACS Routine Process
New Allocation
Data Class
Storage Class
SC=&STORCLAS
Management
Class
Storage
Group
SC=NULL
Non-SMS
Managed
SMS
Managed
Figure 12. ACS Routine Execution Process
Storage Management with DFSMS 37
5.3 SMS Classes
The storage administrator uses ISMF to create an ACS routine for each of the
three types of classes and one to assign the Storage Groups. These routines,
used together with the Data Class, Storage Class, Management Class, Storage
Group definitions, and the base configuration, define an installation’s SMS
configuration.
Figure 13 on page 38 shows the relationship of each of the four constructs which
make up the SMS ACS routine environment. The following sections describe
each of the classes in more detail.
SMS Construct Relationship
5.3.1 Data Class
Organization
Data
Class
Dataset
Management
Class
Availability
Figure 13. SMS Construct Relationship
Performance
Storage
Class
Storage
Group
Location
5.3.1.1 Description
Formerly, when allocating new data sets, users were required to specify a full set
of attributes. Even for multiple allocations, repetitive coding was required. With
the introduction of SMS, this process is now simplified, and also helps to enforce
standards by use of the Data Class.
A Data Class is a named list of data set allocation and space attributes that SMS
assigns to a data set when it is created. It contains associated default values set
by the storage administrator. Data Classes can be assigned implicitly through the
ACS routines or explicitly using the following:
• JCL statement. The user only need specify the relevant Data Class keyword
such as DATACLAS=DCLIB
• TSO/E ALLOCATE command DATACLAS(DCLIB)
• IDCAMS ALLOCATE and DEFINE commands
• ISPF/PDF Data set allocation panel
When specified, the Data Class allocates a data set in a single operation. Any
disk data set can be allocated with a Data Class whether managed by SMS or
not. Tape data sets cannot be allocated with Data Classes.
38 Storage Management with DB2 for OS/390
User defined allocations take precedence over default Data Classes. For
example, if a Data Class specifies an LRECL of 80 bytes, and the JCL allocation
specifies an LRECL of 100 bytes, then 100 bytes are allocated. If the Data Class
is altered by the storage administrator, attributes previously allocated by the
Class remains unchanged. Alterations are only be honored for new allocations.
5.3.1.2 Planning for Implementation
To identify and reference a particular Data Class, a unique one to eight character
name is used, for example, DCDBKSDS.
For each group of data sets that have similar attributes, a Data Class can exist,
but is not mandatory. An example where it could be used is with DB2
tablespaces, as they have identical allocation characteristics.
Prior to the definition of Data Classes, an analysis of common data types needs
to be undertaken. This should include deciding whether to use ACS routines only
for their allocation, or allow users (in this case, the DBA) to assign them as well.
There may be a requirement to standardize naming conventions, and agree upon
default space allocations.
Attributes include many of the data set characteristics specified on JCL
statements, and IDCAMS DEFINE commands. Only those applicable to a
particular data set type should be coded, all others should be left blank. Table 8
on page 39 shows a list of attributes for consideration.
Table 8. Data Class Attributes
ATTRIBUTE COMMENT
5.3.2 Storage Class
Data set
Organization
Space requirements - Average record length value
VSAM, data and volume
specifics
- VSAM type (KSDS, ESDS, RRDS or LINR)
- Non VSAM type (Sequential, partitioned)
- Record format (RECFM)
- Logical record length (LRECL)
- Key Length (VSAM)
- Size of primary allocation
- Size of secondary allocation
- Number of directory blocks, if a library
- Size of Control Interval and Control Area
- Percentage freespace
- Replicate
- Imbed
- Share options—volume count
- Backup while open
- Extended addressability
- Reuse
- Space constraint relief
- Spanned/non spanned
- Initial load (speed and recovery)
5.3.2.1 Description
Prior to SMS, critical and important data sets that required improved performance
or availability were allocated to specific volumes manually. Data sets that
required low response times were placed on low activity volumes, where caching
Storage Management with DFSMS 39
was available. SMS allows the separation of performance and service level of
data sets by use of the Storage Class.
A Storage Class construct details the intended performance characteristics
required for a data set assigned to a given class. The response times set for each
Storage Class are target response times for the disk controller to achieve when
processing an I/O request. It decides if the volume should be chosen by the user
or by SMS. Also, it determines whether SMS, when allocating space on the first
volume of a multi-volume data set, should allocate space on the remaining
volumes as well. The assignment of a Storage Class does not guarantee its
performance objective, but SMS selects a volume that offers performance as
close as possible. Only SMS managed data sets use Storage Classes. Changes
in a Storage Class applies to the data sets that are already using that class.
Storage Classes can be assigned implicitly through the ACS routines, or explicitly
by using the following:
• JCL statement. The user only needs to specify the relevant Data Class
keyword, such as STORCLAS=SCDBGS.
• DSS COPY and RESTORE commands.
• TSO/E ALLOCATE command such as STORCLAS(SCDBGS).
• IDCAMS ALLOCATE and DEFINE commands.
• ISPF/PDF data set allocation panel.
Unlike the Data Class, users cannot override individual attribute values when
allocating data sets.
5.3.2.2 Planning for Implementation
For each group of data sets that have similar performance objectives, a Storage
Class can exist. To identify and reference a particular Storage Class, a unique
one to eight character name is used, for example, SCDBFAST.
Consideration needs to be given as to whether a user is authorized to select a
specific volume within a Storage Group, which is governed by the Guaranteed
Space parameter. This is an arrangement which needs to be agreed upon
between the storage administrator and the DBA.
An example of the use of this parameter is in the allocation of the Active logs and
BSDS, where these data sets have critical performance and availability
requirements. The DBA should be allowed to allocate them on specific volumes,
which is especially important for dual logging capability, to ensure that the logs
are allocated on separate volumes. After being defined, these data sets are rarely
redefined.
Table 9 on page 40 provides a list of attributes for consideration.
Table 9. Storage Class Attributes
ATTRIBUTE COMMENT
Performance objectives - Direct bias
40 Storage Management with DB2 for OS/390
- Direct millisecond response
- Initial access response
- Sequential millisecond response
- Sustained data rate
ATTRIBUTE COMMENT
Availability objectives - Accessibility
Caching - Weighting
5.3.3 Management Class
5.3.3.1 Description
Prior to SMS, DFHSM managed the data sets at volume level, applying a
standard management criteria for all data sets on a given volume. Although this is
still applicable for non-SMS managed data sets, with the introduction of SMS, the
control is carried out at data set level by use of the Management Class.
The Management Class is only assigned if the Storage Class construct selects a
valid Storage Class, as can be seen in Figure 12 on page 37. For each data set, it
consists of attributes that determine the necessary control of:
• Retention
• Backup
•Migration
• Expiration
- Availability
- Guaranteed space
- Guaranteed synchronous write
• Management of generation data set groups (GDGs) and their data sets
(GDSs)
• Space release
When assigned to a data set, the Management Class expands on attributes
previously specified by JCL, IDCAMS DEFINE and DFHSM commands.
If an attribute is altered on a particular Management Class, the change is applied
to previously created data sets which have the same attribute, when the next
management cycle commences. A default Management Class can be specified to
cater to those groups of data sets that do not belong to a Management Class,
thereby ensuring that all SMS managed data sets have a set level of availability.
5.3.3.2 Planning for Implementation
A Management Class should be generated for each group of data sets that have
similar availability requirements. To identify and reference a particular
Management Class, a unique one to eight character name should be used, for
example, MCDB21.
Before defining Management Classes, a number criteria should be established by
the storage administrator. Based upon this information, the storage administrator
defines Management Classes that provide a centralized storage environment.
This includes the decision on whether to allow users the ability to assign
Management Classes explicitly by using JCL, as well as implicitly by the ACS
routines.
Because most production database data has specialized backup and recovery
requirements, it is recommended that standard DB2 system utilities be used to
perform backup and recovery. However, consider using DFSMSdss or
Storage Management with DFSMS 41
DFSMShsm's automatic backup services, supported by concurrent copy, to help
with point of consistency backups.
It is not advisable to use HSM to manage most production databases. Therefore,
use a NOMIGRATE Management Class for this type of data. This prevents HSM
space and availability management from operating. Specifically, AUTO BACKUP
is set to NO so that HSM does not back up the data set, ADMIN OR USER
COMMAND BACKUP is set to NONE to prevent manual backup, and expiration
attributes are set to NOLIMIT to prevent data set deletion.
Although production database data does receive automatic backup service,
DFSMSdss can be set to run concurrent copy for production databases.
ACCESSIBILITYmay be set to CONTINUOUS for Storage Classes assigned to
production databases to ensure that the data set is allocated behind a storage
control with concurrent copy support.
Testing or end user databases that have less critical availability requirements can
benefit from system management using HSM. Additionally, selected data types
for production systems could also be effectively managed using HSM.
For DB2 systems, it is possible to manage archive logs and image copies with
HSM. These data sets can be retained on primary devices for a short period of
time, and then migrated directly to tape (ML2).
HSM uses the same ML2 tape until it is full. Therefore, unless another
mechanism is used, to avoid placing consecutive archive logs on the same ML2
tape, ensure that the storage administrator defines the HSM parameter
SETSYS(PARTIALTAPE(MARKFULL), so it uses a new ML2 tape each time
space management is executed.
Requirements should be agreed upon by the storage administrator and the DBA.
Table 10 on page 42 displays a list of attributes for consideration.
Table 10. Management Class Attributes
ATTRIBUTE COMMENT
Space management - Release unused space in the data set (applies to
non-VSAM only).
Expiration - Delete data set after a number of days or a date.
- Delete after a number of days of non usage.
- Use of Retention or Expiration periods.
Migration - What method a data set can migrate (Command
or automatically, or both).
- Number of days non-usage on level 0 volumes
before migration commences.
- Number of days non-usage on level 1 volumes
before migration commences.
42 Storage Management with DB2 for OS/390
5.3.4 Storage Group
5.3.4.1 Description
Prior to SMS, disk storage was maintained as individual volumes, requiring
manual intervention to prevent volumes from filling up, and to prevent I/O
bottlenecks. SMS significantly improves the management of disk by building on
DFHSM capabilities to pool volumes together in Storage Groups.
A Storage Group is a pool of disk volumes upon which SMS managed data sets
are placed. These groups are normally transparent to users. A data set is placed
on an appropriate volume within a Storage Group depending upon the Storage
Class, volume, Storage Group status, and available free space. New data set
allocations can be directed to as many as 15 Storage Groups, although only one
Storage Group is finally selected.
ATTRIBUTE COMMENT
Backup -Who can back up the data (the storage administrator
or the user, or both).
- If automatic backup should be taken for a data set.
- Backup frequency (number of days between
backups).
- Number of backup versions (data set exists).
- Number of backup versions (data set deleted).
- Retention of backups once a data set has been
deleted.
- Backup copy type (incremental, full volume dump).
Each Storage Group has attributes which determine a range of characteristics for
the volumes in that group. This includes backup, migration, and space
thresholds.
A volume can belong to one of the following main Storage Group types; POOL,
DUMMY or VIO. Three other types also exist; OBJECT, OBJECT BACKUP and
TAPE, although these are not as commonly used.
Storage Groups:
• Cannot share a volume.
• Cannot share data sets.
• Must contain whole volumes.
• Must contain volumes of the same device geometry.
• Can contain multi-volume data sets.
• Must contain a VTOC and a VVDS.
SMS selects the volumes used for data set allocation by building a list of all
volumes from the Storage Groups assigned by the ACS routine. Volumes are
then either removed from further consideration or flagged as primary, secondary,
or tertiary volumes.
Primary volumes meet the following criteria:
• SMS Storage Group and volume status of ENABLED
• MVS volume status of ONLINE
• Requested initial access response time (IART)
Storage Management with DFSMS 43
• The number of volumes in the Storage Group satisfies the volume count
• Accessibility requested
• Availability (dual copy or RAMAC) requested
• The volume was explicitly requested and guaranteed space is YES
• Sufficient free space to perform the allocation without exceeding the high
threshold
• Volumes fall within a pre-determined range of millisecond response times
based on the request
• The volume supports extended format if EXT=PREFERRED or REQUIRED is
requested in the data class
Candidates for secondary volumes are primary volumes that, in addition:
• Are at or above high threshold, or exceed high threshold following the
allocation.
• Are quiesced, or the Storage Group to which the volume belongs is quiesced.
• Did not meet the requested millisecond response time.
• Did not meet the accessibility request of standard or preferred.
• Did not meet the IART of greater than zero.
• Did not meet the availability request of standard or preferred.
When a Storage Group does not contain enough volumes to satisfy the volume
count, all volumes in the Storage Group are flagged tertiary. Tertiary volumes are
only selected when there are no primary or secondary volumes and the request is
for a non-VSAM non-GUARANTEED SPACE request.
After the system selects the primary allocation volume, that volume's associated
Storage Group is used to select any remaining volumes requested.
5.3.4.2 Planning for Implementation
It is important that unique Storage Groups are used for production databases and
recovery data sets, because of their critical status. Appropriate groups should be
defined by the storage administrator to prevent automatic migration (AUTO
MIGRATE), and automatic backup (AUTO BACKUP). However non-production
databases should be considered for placement on standard primary volumes
(possibility shared with other data types), as their availability is normally not as
critical.
DB2 allows the DBA to define a collection of volumes that DB2 uses to find space
for new data set allocation, known as STOGROUPs. When converting DB2
databases to SMS, and DB2 STOGROUPs are used to manage DB2 database
data, one way is to design the SMS Storage Groups so they are compatible with
existing STOGROUP definitions.
Once the conversion is complete, it is recommended that SMS be used, rather
than DB2 to allocate databases. To allow SMS control over volume selection,
define DB2 STOGROUPs with VOLUMES(*).
44 Storage Management with DB2 for OS/390
Electing DB2 to select the volume requires assigning a Storage Class with
guaranteed space. However, guaranteed space reduces the benefits of SMS
allocation, so this approach is not recommended.
If you do choose to use specific volume assignments, additional manual space
management must be performed . Unlike non-SMS, SMS does not retry to skip a
volume that cannot satisfy the requested space. Free space must be managed for
each individual volume to prevent failures during the initial allocation and
extension. This will generally require more time for space management, and will
result in more space shortages. Guaranteed space should only be used where
the space needs are relatively small and do not change.
To identify and reference a particular Storage Group, a unique one to eight
character name is used, for example, SGDBFAST.
Table 11 provides a list of attributes for consideration.
Table 11. Storage Group Attributes
ATTRIBUTE COMMENT
Auto Migrate Specifies whether migration should be permitted on
this Storage Group.
Auto Backup Specifies whether backup should be performed on
this Storage Group.
Auto Dump Specifies whether full volume dumping should be
performed on this Storage Group.
Migration Threshold
(High and low)
Dump Classes Specifies the frequency of auto dumping, if required.
Guaranteed Backup Frequency Specifies the maximum number of days that can
A percentage figure which when exceeded forces
migration to occur. Likewise, a percentage figure, at
which migration stops.
elapse between backups. NOLIMIT indicates data
sets in the Storage Group are backed up according
to their Management Class.
For further information on all SMS Class attributes and definitions, see
DFSMS/MVS DFSMSdfp Storage Administration Reference, SC26-4920.
5.3.4.3 Mapping Devices to Storage Groups for Performance
From the performance point of view, migrating to SMS offers the opportunity to
automatically set DB2 allocations to predefined disk areas. Each storage server
offers a predetermined level of parallel access. For example, the RVA Turbo
allows eight concurrent data transfers to and from the host. DB2 administrators
and storage administrators can distribute the Storage Groups to maximize the
use of parallel capability offered by each storage server type. For example, with
RVA servers, a Storage Group should have a multiple of eight volumes per RVA
and be spread over several RVAs. A performance oriented small Storage Group
could have just eight volumes defined per RVA (in groups of two by LCU, and by
RVA) and spread over the number of RVAs required for best parallel access.
SMS offers a performance oriented automated allocation mechanism provided
that a defined Storage Group logical topology matches the current installed
Storage Management with DFSMS 45
hardware capabilities. For a few specific and exceptional cases, the storage class
GUARANTEED SPACE option can be used. As the Storage Group definition
exists only in SMS tables, its logical mapping onto volumes can be redistributed
when a hardware change occurs, without any DB2 application outage, provided
that DB2 and storage administrators act in concert (in particular for allocating
new DB2 objects). Notice that redefining a Storage Group does not require
application outage.
5.4 Naming Standards
To assist in the successful implementation of SMS, a vital requirement is that of
generating and adhering to a constructive and meaningful naming standard
policy. The more formal the policy, the easier it is to maintain the ACS routines.
This can be of particular use in the formation of policies for Data and
Management Classes.
These policies can:
• Simplify service-level assignments to data.
• Facilitate writing and maintaining ACS routines
• Allow data to be mixed in a system-managed environment while retaining
separate management criteria
5.5 Examples
• Provide a filtering technique useful with many storage management products
• Simplify the data definition step of aggregate backup and recovery support
Most naming conventions are based on the high level qualifier (HLQ) and low
level qualifier (LLQ) of the data set name. Additional levels of qualifiers can be
used to identify generation data sets and databases. They can also be used to
help users to identify their own data. It must be stressed that each installation has
different naming conventions, and therefore requires careful planning.
DB2 systems generate their own data set names, so it is necessary to ensure that
the storage administrator understands the implications, and is able to define a
policy and build the ACS routines so they incorporate this feature.
Examples of SMS constructs for DB2 data sets are described in this book:
• Chapter 6, “Managing DB2 Databases with SMS” on page 47.
• Chapter 7, “Managing DB2 Recovery Data Sets with SMS” on page 63.
A test implementation of these examples is shown in:
• Appendix A, “Test Cases for DB2 Table Space Data Sets” on page 161.
• Appendix B, “Test Cases for DB2 Recovery Data Sets” on page 185.
46 Storage Management with DB2 for OS/390
Chapter 6. Managing DB2 Databases with SMS
This chapter describes DB2 databases from the point of view of their attributes
for SMS management, and provides examples for these databases. Due to their
stricter availability requirements, the DB2 system databases are analyzed
separately.
This chapter includes examples of SMS Data, Storage, and Management Classes
for DB2 table spaces. These examples are applied to DB2 system tablespaces
and to DB2 application table spaces grouping them in four different user
environments.
6.1 SMS Examples for DB2 Databases
The following examples are provided to show how SMS can be used to manage
DB2 table spaces. These examples do not show all possibilities SMS offers to an
installation. Each installation can review these examples and create those
classes that best suit its environment. The examples shown here are extracted
and adapted from DFSMS/MVS Implementing System-Managed Storage,
SC26-3123.
Naming Convention:
The following naming structure is used for the example SMS constructs. Each
name has a two-character SMS construct identifier, two characters ’DB’ to identify
them as SMS constructs used for DB2, followed by a variable length (aaaa) text.
This naming convention is:
DCDBaaaa SMS Data Classes for DB2
SCDBaaaa SMS Storage Classes for DB2
MCDBaaaa SMS Management Classes for DB2
SGDBaaaa SMS Storage Groups for DB2
6.1.1 Using ISMF to Display SMS Constructs
A DB2 administrator can use ISMF to access and examine the different SMS
constructs in the installation. A storage administrator uses ISMF to create and to
manage the SMS constructs. Figure 14 on page 48 shows how to display the
active Data Class DCDB2.
The options available on the DATA CLASS APPLICATION SELECTION panel are
dependent on the authorization of the user. Only a user authorized to manage
SMS constructs is allowed to define or alter them. Other users may only have
options 1 (List) and 2 (Display) available.
6.1.2 SMS Data Class
All DB2 table spaces, either for system or for user data, have exactly the same
attributes. One Data Class can be defined for all these data sets. The Data Class
allows an override of space parameters (primary and secondary allocation
quantity) because those will be different for each table space. Figure 15 on page
48 shows some information from the Data Class DCDB2, a Data Class example
for DB2 table spaces and index spaces.
© Copyright IBM Corp. 1999 47
DATA CLASS APPLICATION SELECTION
Command ===>
To perform Data Class Operations, Specify:
CDS Name . . . . . . 'ACTIVE'
(1 to 44 character data set name or 'Active' )
Data Class Name . . DCDB2 (For Data Class List, fully or partially
Select one of the following options :
2 1. List - Generate a list of Data Classes
2. Display - Display a Data Class
3. Define - Define a Data Class
4. Alter - Alter a Data Class
If List Option is chosen,
Enter "/" to select option Respecify View Criteria
Figure 14. Display a Data Class
Data Class Name : DCDB2
Description : DATA CLASS FOR DB2 TABLESPACES
Recorg . . . . . . . . . : LS
Recfm . . . . . . . . . :
Lrecl . . . . . . . . . :
Keylen . . . . . . . . . :
Keyoff . . . . . . . . . :
Space Avgrec . . . . . . : M
Avg Value . . . . : 1
Primary .....:1
Secondary . . . . : 1
Directory . . . . :
Retpd Or Expdt . . . . . :
Volume Count . . . . . . : 1
Add'l Volume Amount . :
Imbed . . . . . . . . . :
Replicate . . . . . . . :
CIsize Data . . . . . . : 4096
% Freespace CI . . . . . :
CA.....:
Shareoptions Xregion . . : 3
Xsystem . . : 3
Compaction . . . . . . . :
specified or * for all)
Respecify Sort Criteria
Figure 15. Data Class DCDB2
6.1.3 SMS Storage Class
Some DB2 installations may use only one Storage Class for DB2, but in others,
the DB2 administrators may require several Storage Classes for DB2 table
spaces. Table 12 on page 49 shows four examples. These are:
SCDBMED This Storage Class is intended for the majority of table spaces. It
48 Storage Management with DB2 for OS/390
provides good performance and good availability.
SCDBFAST This Storage Class is intended for table spaces belonging to
applications requiring performance. It provides high performance
and good availability.
SCDBCRIT This Storage Class is intended for table spaces belonging to
critical applications. It provides high performance and continuous
availability. SMS attempts to place these table spaces on disks
with dual copy or on RAID.
SCDBTEST This Storage Class is intended for environments with lower
requirements. Examples are test systems, development systems,
and data warehouse environments. These table spaces will have
average performance and average availability.
Table 12. SMS Storage Classes for DB2 Databases
SCDBMED SCDBFAST SCDBCRIT SCDBTEST
DIRECT RESPONSE (MSEC) 10 5 5 20
DIRECT BIAS Yes
SEQUENTIAL RESPONSE (MSEC) 10 5 5 20
SEQUENTIAL BIAS
SUSTAINEDDATARATE(MB/sec)10202010
AVAILABILITY
ACCESSIBILITY
a
b
Preferred Preferred Continuous Standard
Standard Standard Standard Standard
GUARANTEED SPACE No No No No
GUARANTEED SYNCHRONOUS WRITE No No No No
CACHE SET NAME
CF DIRECT WEIGHT
CF SEQUENTIAL WEIGHT
a. Continuous=Duplexed or RAID Disk, Preferred=Array Disk, Standard=Array or Simplex Disk
b. If a device with Concurrent Copy capability is desired, specify Continuous or Continuous Preferred
6.1.4 SMS Management Class
Table 13 on page 50 shows three examples of Management Classes for DB2
table spaces. The purpose of these three Management Classes is to allow
different DFSMShsm specifications for DB2 table spaces and index spaces.
These Management Classes are:
MCDB20 This Management Class is intended for production table spaces
and table spaces that require average or higher availability. This
Management Class inhibits DFSMShsm migration of table
spaces.
MCDB21 This Management Class is intended for table spaces that are
allowed to migrate. This Management Class causes migration
after one week of inactivity; and after two weeks in level 1, the
table space will migrate to level 2. For example, this Management
Class can be used for Data Warehouse table spaces.
Managing DB2 Databases with SMS 49
MCDB22 This Management Class is intended for table spaces that are
Table 13. SMS Management Classes for DB2 Databases
Expire after Days Non-usage NOLIMIT NOLIMIT NOLIMIT
Expire after Date/Days NOLIMIT NOLIMIT NOLIMIT
Retention Limit NOLIMIT NOLIMIT NOLIMIT
Primary Days Non-usage 77
Level 1 Days Date/Days 14 0
Command or Auto Migrate None Both Both
Backup Options Not Applicable Not Applicable Not Applicable
6.1.5 SMS Storage Groups
SMS Storage Classes and Management Classes are combined to generate
Storage Groups. This function is performed by the ACS routines. Table 14 on
page 51 shows the relationship between SMS Storage Classes and the SMS
Management Classes with the SMS Storage Groups. Only those Storage Groups
required to satisfy DB2 database requirements need to be defined.
allowed to migrate and require less availability than that defined
in the MCDB2M1 Management Class. This Management Class
causes migration after one week of inactivity and the table space
will migrate directly to level 2. For example, this Management
Class can be used for Test or Development table spaces.
MCDB20 MCDB21 MCDB22
SMS Storage Groups should be created based on available disk types and data
set requirements as defined in Storage Classes and Management Classes. Only
exceptionally, for large (partitioned) table spaces and for critical table spaces,
may strict data set placement be an issue. Only in these cases may special SMS
Storage Groups be defined.
Table 15 on page 51 shows the attributes of the example SMS Storage Groups for
DB2 table and index spaces. These are:
SGDB20 Standard Storage Group intended to satisfy most of the DB2 table
spaces and index spaces. No DFSMShsm migration nor DFSMS
backup is required.
SGDB21 Storage Group for DB2 table spaces and index spaces that may
migrate; for example, data warehouse table and index spaces.
SGDB22 Storage Group for DB2 table spaces and index spaces that may
migrate to level 2. For example, development system table and
index spaces.
SGDBFAST Storage Group for DB2 table spaces and index spaces requiring
performance. No DFSMShsm migration nor DFSMS backup.
SGDBCRIT Storage Group for DB2 table spaces and index spaces requiring
performance and availability. No DFSMShsm migration nor
DFSMS backup.
50 Storage Management with DB2 for OS/390
SGDBTEST Storage Group for DB2 table spaces and index spaces with low
performance and availability requirements. This Storage Group
allows migration.
SGDBXXXX Other Storage Groups intended for specific partitioned DB2 table
spaces and index spaces, or for other critical table spaces, where
strict placement is considered essential. XXXX is any four
characters.
The attributes of these Storage Groups are similar to one of the other Storage
Groups. These Storage Groups are intended to give DB2 administrators the
possibility of placing individual partitions on specific volumes.
Table 14. Relating SMS Storage and Management Classes to Storage Groups
Management Classes
Storage Classes
MCDB20 MCDB21 MCDB22
SCDBMED SGDB20
SGDBXXXX
SCDBFAST SGDBFAST
SGDBXXXX
SCDBCRIT SGDBCRIT
SGDBXXXX
SCDBTEST SGDBTEST SGDBTEST SGDBTEST
SGDB21 SGDB22
The Storage Groups are defined with specific attributes. Table 15 on page 51
shows attributes for the example Storage Groups.
Table 15. SMS Storage Groups for DB2 Databases
Storage Group Auto-Migrate Auto-Backup Auto-Dump High-Low Thr
SGDB20 No No No 70-70
SGDB21YesNoNo70-50
SGDB22YesNoNo60-25
SGDBFAST No No No 70-70
SGDBCRIT No No No 60-60
SGDBTEST Yes No No 60-25
SGDBXXXX No No No 99-00
Figure 16 on page 52 is an ISMF display of the Storage Group SGDB20. A
Storage Group requires volumes for data set allocation. Figure 17 on page 53
shows the volumes in Storage Group SGDB20. Twelve volumes are assiged to
SGDB20. The names of these volumes range from VOL001 to VOL012.
Managing DB2 Databases with SMS 51
Panel Utilities Help
------------------------------------------------------------------------------
Command ===>
SCDS Name . . . . . : SMS.SCDS1.SCDS
Storage Group Name : SCDB20
To ALTER Storage Group, Specify:
Description ==> STANDARD STORAGE GROUP FOR DB2 TABLE AND INDEX SPACES
==>
Auto Migrate . . N (Y, N, I or P) Migrate Sys/Sys Group Name . .
Auto Backup . . N (Y or N) Backup Sys/Sys Group Name . .
Auto Dump . . . N (Y or N) Dump Sys/Sys Group Name . . .
Dump Class . . . (1 to 8 characters)
Dump Class . . . Dump Class . . .
Dump Class . . . Dump Class . . .
Allocation/migration Threshold: High . . 70 (1-99) Low . . 70 (0-99)
Guaranteed Backup Frequency . . . . . . NOLIMIT (1 to 9999 or NOLIMIT)
ALTER SMS Storage Group Status . . ..... N (Y or N)
F1=Help F2=Split F3=End F4=Return F7=Up F8=Down F9=Swap
F10=Left F11=Right F12=Cursor
Figure 16. Display of Storage Group SGDB20
POOL STORAGE GROUP ALTER
6.1.6 DB2 STOGROUPs and SMS Storage Groups
The concepts of DB2 STOGROUP and SMS Storage Group are different, but very
similar. While a Storage Group refers to a set of volumes in an installation, the
STOGROUP refers to a set of volumes containing a set of data. Different
STOGROUPs can share the same disk volume or volumes.
DB2 administrators normally define many STOGROUPs for their applications.
Sometimes they have STOGROUPs for each individual volume and use it to
direct the table spaces to that specific volume. Other installations have
STOGROUPs at database or application level.
To make the best use of DFSMS, DB2 administrators should define their
STOGROUPs as before, but using a generic volume reference (VOLUMES ’*’ ).
See the example in Figure 100 on page 172. The generic volume reference
allows DFSMS to choose a volume based on the SMS classes assigned to a table
or index space.
Sometimes these generic volume references cannot be used for DB2
STOGROUPs. This can happen, for example, during the conversion process from
non-SMS to SMS management. If generic volume references cannot be used,
SMS Storage Groups can be made to match DB2 STOGROUPs. One important
restriction may have to be resolved; this is:
One disk volume can only belong to one SMS Storage Group.
52 Storage Management with DB2 for OS/390
Panel Utilities Help
-------------------------------------------------------------------------STORAGE GROUP VOLUME SELECTION
Command ===>
CDS Name . . . . . : SMS.SCDS1.SCDS
Storage Group Name : SCDB20
Storage Group Type : POOL
Select One of the following Options:
1 1. Display - Display SMS Volume Statuses (Pool only)
2. Define - Add Volumes to Volume Serial Number List
3. Alter - Alter Volume Statuses (Pool only)
4. Delete - Delete Volumes from Volume Serial Number List
Specify a Single Volume (in Prefix), or Range of Volumes:
Prefix From To Suffix Hex
______ ______ ______ _____ _
===> VOL 001 012 ('X' in HEX field allows
===> FROM - TO range to include
===> hex values A through F.)
===>
F1=Help F2=Split F3=End F4=Return F7=Up F8=Down F9=Swap
F10=Left F11=Right F12=Cursor
Figure 17. Volumes in Storage Group SGDB20
6.1.7 Assigning SMS Classes to DB2 Table Spaces and Index Spaces
SMS classes and Storage Groups are assigned to DB2 table spaces and index
spaces through ACS routines. Normally, ACS routines have only the data set
name available for their decision making process. Many methods can be devised
with specific naming standards to assign SMS classes based on the names of the
DB2 data sets. Two types of methods are described, the filter method and the
code method.
The filter method must be used when the names are established and cannot be
changed. This is the case when an existing DB2 system converts to SMS
management. The filter method uses lists of names inside the ACS routine to
determine SMS classes.
The code method requires naming conventions for DB2 objects that must be
strictly enforced. SMS related codes are inserted into the DB2 object names.
These codes are used to determine SMS classes. At least two codes are
required, one to define the Storage Class, and one to define the Management
Class.
The DB2 data set names have a specific structure, shown in Table 3 on page 23.
These names have only three components that are dependent on the user and
can contain meaningful information for the ACS routine to use. These are:
• High level qualifier
• Database name
• Table space name
The ACS routines can use the filter method, the code method, or a combination of
the filter and code methods, and apply these to the three types of names, or to
Managing DB2 Databases with SMS 53
combinations of these names. This provides the installation with great flexibility in
implementation alternatives, such as:
High Level Qualifier Filter
The ACS routines contain a list of high level qualifiers. These qualifiers are used
to assign the specific SMS classes. The high level qualifiers can provide a
meaningful distinction between data of different DB2 subsystems. This method is
recommended as a starting point, because of its simplicity. Some installations
may have multiple, complex requirements and may prefer to use another method.
A variant of this method is used in the example shown in Appendix A, section A.4,
“DB2 Table Spaces Using SMS, Existing Names” on page 165. In this appendix,
Figure 92 on page 168 shows an ACS routine that assigns Management Classes
based on a high level qualifier (which is also the DB2 subsystem name). The
variant introduced is that certain databases (name starting with B) in the DB2D
susbsystem are assigned a separate Management Class.
Database Name Filter
The ACS routines contain a list of DB2 databases. The database name is used to
assign the specific SMS classes. All table spaces and index spaces within a
database would have the same SMS classes. When a new database is created,
the ACS routine has to be modified.
Table Space Name Filter
The ACS routines contain a list of DB2 databases and table and index spaces.
These names are used to assign the specific SMS classes. Each table space and
each index space can have distinct SMS classes. When a new table or index
space is created, the ACS routine has to be modified. This technique is only
manageable in static installations. A simple example of an ACS routine using this
method is shown in Figure 18 on page 55.
High Level Qualifier Codes
The high level qualifiers contain a Storage Class code and a Management Class
code. These codes are used to assign the specific SMS classes. Multiple high
level qualifiers are required to obtain a meaningful distinction between data with
different requirements.
Database Name Codes
The DB2 database names contain a Storage Class code and a Management
Class code. These codes are used to assign the specific SMS classes. All table
spaces and index spaces within a database would have the same SMS classes.
The ACS routine does not need maintenance for new databases. This method
provides a resolution at database or application level.
54 Storage Management with DB2 for OS/390
/*********************************************************************/
/* PARTITION FILTER
/*********************************************************************/
FILTLIST &PTSP INCLUDE ('LINEITEM','ORDER','PART','PARTSUPP',
'SUPPLIER','NATION','REGION')
/* Supply a list of the partitioned tablespaces
*/
FILTLIST &PNDX INCLUDE ('PXL@OK','PXO@OK','PXP@PK','PXPS@SK',
'PXS@SK','PXN@NK','PXR@RK')
*/
WHEN ( (&DSN(4) = &PTSP OR &DSN(4) = &PNDX)
AND (&LLQ EQ 'A001' OR &LLQ EQ 'A002') )
SET &STOGROUP EQ 'SGDB2GRA'
WHEN ( (&DSN(4) = &PTSP OR &DSN(4) = &PNDX)
AND (&LLQ EQ 'A003' OR &LLQ EQ 'A004') )
SET &STOGROUP EQ 'SGDB2GRB'
WHEN ( (&DSN(4) = &PTSP OR &DSN(4) = &PNDX)
AND (&LLQ EQ 'A005' OR &LLQ EQ 'A006') )
SET &STOGROUP EQ 'SGDB2GRC'
/* Repeat the previous WHEN statement for as many STOGROUPs as reqd
Figure 18. ACS Routine Extract Using Table and Index Name Filter List
/* Supply a list of the partitioned indexes
Table Space Name Codes
The DB2 table space and index space names contain a Storage Class code and
a Management Class code. These codes are used to assign the specific SMS
classes. Each table space and each index space can have distinct SMS classes.
The ACS routines do not need maintenance for new table spaces and index
spaces. This method is recommended when multiple requirements have to be
satisfied. This method provides the most detailed granularity for SMS
management and has limited maintenance concerns.
The names of DB2 indexes, including the SMS codes, must not exceed 8
characters. DB2 may change the index space name for indexes having names in
excess of 8 characters. The changed names may invalidate this method.
An example of how to structure DB2 data set names to use this method is shown
in 6.1.8, “Table Space and Index Space Names for SMS” on page 56.
An implementation example of this method is shown in Appendix A, section A.5,
“DB2 Table Spaces Using SMS, Coded Names” on page 174. In this appendix,
Figure 105 on page 176 and Figure 106 on page 176 show ACS routines that
assign Storage Classes and Management Classes based on codes within the
table space name.
Managing DB2 Databases with SMS 55
6.1.8 Table Space and Index Space Names for SMS
The recommendation in this book for finely tuned SMS installations is to imbed
SMS codes into the names of DB2 table and index spaces. This is shown in Table
16 on page 56. The data set names have the structure shown in Table 3 on page
23, with a change in the space name itself. As explained in 6.1.7, “Assigning SMS
Classes to DB2 Table Spaces and Index Spaces” on page 53, this name contains
codes for the ACS routines. The ACS routines use these codes to establish
Storage Classes, Management Classes and Storage Groups.
Table 16. Table Space and Index Space Names with SMS Codes
hlq.DSNDBx.dbname.uvssssss.ynnnn.Ammm
The elements of the space name are:
uvssssss Space name:
u Storage Class code
v Management Class code
ssssss User assigned name
6.1.9 Managing Partitioned Table Spaces with SMS
With DB2, the user has choices on how to allocate and distribute the individual
data sets of a partitioned table space. Two examples are shown in:
• Appendix A, Section A.2, “Partitioned Table Space, DB2 Defined, Without
SMS” on page 162
• Appendix A, Section A.3, “Partitioned Table Space, User Defined, Without
SMS” on page 164
SMS can also be used to distribute the individual partitions. Several different
methods are possible; for example:
• Let SMS manage everything.
• Use one SMS Storage Group for each partition.
• Use one SMS Storage Group for one partitioned table space.
Let SMS Manage Everything
For many partitioned table spaces and index spaces, SMS can handle the
partition distribution. If the number of volumes in the Storage Group is much
larger than the number of partitions, then SMS will most likely place each partition
on a separate volume.
Storage group SGDB20 is an example of this case. Table spaces and index
spaces are allocated by SMS on these volumes, trying to balance the I/O activity
on the volumes. This method should be adequate for many installations.This
method is the preferred technique for storage administrators, because it has the
advantage of simplicity.
This method can be used for table spaces and partitions, where each data set is
a large fraction of a volume. Because a volume can only handle one partition, the
separation is automatic. On the other hand, space fragmentation on the volumes
56 Storage Management with DB2 for OS/390
may not leave enough volumes with adequate free space; this could cause a
REORG to fail due to lack of space. The following methods address this issue.
Use One SMS Storage Group for Each Partition
A one-volume SMS Storage Group can be defined for each partition. The ACS
routine assigns to each partition its corresponding Storage Group. This method is
similar to creating a DB2 defined partitioned table space, using one STOGROUP
for each partition. One SMS Storage Group is defined for each DB2 STOGROUP.
The advantage of this method is strict data set placement. The DB2 administrator
will have the same disk distribution as he has without SMS. The disadvantage of
this method is that many SMS Storage Groups are required, and the ACS
routines become more complex and dependent on DB2 table space names. For
an example, see Appendix A, section A.7, “Partitioned Table Spaces Using SMS,
User Distribution” on page 181.
Use One SMS Storage Group for One Partitioned Table Space
Another alternative is to have one specific SMS Storage Group for each
partitioned table space. Enough volumes are assigned to the Storage Group for
all the partitions. SMS distributes the partitions on those volumes. Because this
Storage Group is dedicated to the table space, no other data sets are ever
allocated on these volumes, practically reserving the space for this table space.
If specific volumes of the SMS Storage Group are desired, guaranteed space
must be used to assign the partitions to the specific volumes.
For this situation, we do not recommend guaranteed space unless the space
requirements are relatively small and static.
To use guaranteed space with DB2 defined data sets, multiple DB2 STOGROUPs
are required. Each of these STOGROUP must refer to a volume of the SMS
Storage Group. To avoid possible allocation or extension failures, if guaranteed
space storage class is used, the storage administrator should run the
DFSMShsm space management function more frequently on the set of volumes
assigned to the DB2 STOGROUPs.
If SMS manages the allocation, or if user defined tablespaces are used, only one
DB2 STOGROUP is required, defined with (VOLUMES "*"). The example in
Figure 100 on page 172 shows a definition of such a STOGROUP. The example
described in Appendix A, section A.6, “Partitioned Table Space Using SMS
Distribution” on page 178 shows how to allocate a partitioned table space using
this method.
6.2 User Databases
This section shows how to assign SMS classes to different types of data. For the
purpose of these examples, the data has been divided into the following
environments:
• Online Production Databases
• Batch Production Databases
• Data Warehouse Databases
• Development and Test Databases
Managing DB2 Databases with SMS 57
6.2.1 Online Production Databases
The databases used in production normally contain important data and have
special availability and security requirements. Performance may become a critical
issue, if the databases are used in an online environment.
Because online production databases contain important data, the DB2 Database
Administrators typically monitor them very frequently. These databases are
sometimes placed on specific disks to manage the data individually. These
databases should not be mixed on a disk with other high activity databases or
data sets.
6.2.1.1 Storage Classes
The following example Storage Classes can be used for online production table
spaces:
• SCDBMED
• SCDBFAST
• SCDBCRIT
6.2.1.2 Management Classes
The following example Management Class can be used for online production
table spaces:
• MCDB20
6.2.2 Batch Production Databases
Most production databases are accessed both in batch and online. In this case,
the more restrictive requirement for online databases should be applied to the
batch environment. This description applies only to databases exploited in a
batch environment.
6.2.2.1 Storage Classes
The following example Storage Classes can be used for batch production table
spaces:
• SCDBMED
• SCDBFAST
6.2.2.2 Management Classes
The following example Management Classes can be used for batch production
table spaces:
• MCDB20
• MCDB21
• MCDB22
6.2.3 Data Warehouse Databases
Data Warehouse databases contain a special type of production data. Their
requirement is normally more oriented to usability and end user access. The end
users expects performance to be reasonable (and this is a subjective matter),
and the same applies to availability. Some customers run applications in their
Data Warehouse environment, and their requirements could become similar to
batch or even online production.
58 Storage Management with DB2 for OS/390
6.2.3.1 Storage Classes
The following example Storage Classes can be used for Data Warehouse table
spaces:
• SCDBMED
• SCDBTEST
• SCDBFAST
6.2.3.2 Management Classes
The following example Management Classes can be used for Data Warehouse
table spaces:
• MCDB20
• MCDB21
• MCDB22
6.2.4 Development and Test Databases
Development and test databases are not essential for immediate business needs.
Their performance and availability requirements should not have priority over
production databases. Some customers with permanent development and test
database environments may have stricter requirements than those shown here.
Test environments used for performance and capacity testing may also have
stricter requirements.
6.2.5 Summary
6.2.4.1 Storage Classes
The following example Storage Classes can be used for development and test
table spaces:
• SCDBTEST
6.2.4.2 Management Classes
The following example Management Classes can be used for development and
test table spaces:
• MCDB21
• MCDB22
Table 17 on page 60 shows some examples of how the SMS Storage Classes and
Management Classes can be combined to provide for different database
requirements. In this table, the concepts of low, average, good, and high,
represent service levels agreed upon between the storage administrator and the
DB2 administrator. These examples are not meant to be exhaustive, but are
intended to provide an idea on how the SMS classes can be used to manage
table spaces in DB2 user databases.
Managing DB2 Databases with SMS 59
Table 17. Examples of SMS Class Usage for DB2 User Databases
Databases Performance Availability Migration Storage
Online Production Avg Avg NO SGDB20
Online Production High Avg NO SGDBFAST
Online Production High High NO SGDBCRIT
Batch Production Low Low YES SGDB21
Batch Production Good Avg NO SGDB20
Batch Production High High NO SGDBCRIT
Data Warehouse Low Avg YES SGDB21
Data Warehouse High Good NO SGDBFAST
Development Low Low YES SGDB22
Test Low Low YES SGDBTEST
6.3 DB2 System Databases
A DB2 subsystem stores data about itself within a set of tables stored in table
spaces in system databases. The system databases are:
Group
• Catalog database (DSNDB06)
• Directory database (DSNDB01)
• Work database (user defined name or DSNDB07)
DB2 supports a Default database (DSNDB04), which is used when the database
is omitted in a table space or index space creation. The Default database can be
considered a user database and may be handled in the same way as other user
databases. It is not considered in this section.
The system databases have the same data organization, data type and naming
convention as user databases. The system databases have stricter availability
requirements. The examples of SMS classes in Chapter 6.1, “SMS Examples for
DB2 Databases” on page 47 are applicable to DB2 system databases.
6.3.1 Catalog and Directory Databases
The DB2 Catalog and Directory databases contain data definitions, recovery
information, security information for the data managed by DB2. If these
databases become unavailable, business data is also unavailable. Recovering
these table spaces is a lengthy and complex process.
To ensure that the availability requirement of the production databases is met,
even in case of an outage of a DB2 system database, the DB2 Catalog and
Directory databases must have an availability requirement at least as stringent as
those of the production database with the highest availability requirement.
Corollary: continuous availability of the DB2 Catalog and Directory is required in
order to have continuous availability for a DB2 application.
60 Storage Management with DB2 for OS/390
6.3.1.1 Storage Classes
The following example Storage Classes can be used for online production table
spaces:
6.3.1.2 Management Classes
The following example Management Class can be used for online production
table spaces:
6.3.2 Work Database
All DB2 subsystems use table spaces in a Work database. For example, the Work
database stores an intermediate result of a query, or is the workarea for an
internal sort of a result table. To avoid contention with DB2 environments
requiring high performance, the table spaces in the Work database should not go
to the Storage Group where the high performance table spaces are placed
(SGFAST and SGCRIT).
The Work database only stores temporary data. If the Work database is lost, DB2
rebuilds its contents automatically on a restart, or manually with a START
DATABASE command. This should be adequate for most production
environments, no special availability requirements are necessary.
• SCDBCRIT
• MCDB20
6.3.3 Summary
6.3.2.1 Storage Classes
The following example Storage Classes can be used for development and test
table spaces:
• SCDBMED
6.3.2.2 Management Classes
The following example Management Class can be used for development and test
table spaces:
• MCDB20
Table 18. DB2 System Database Requirements
Databases Performance Availability Migration Storage
Group
Catalog Good Very High NO SGDBCRIT
Directory Good Very High NO SGDBCRIT
Work Good Low NO SGDB20
Managing DB2 Databases with SMS 61
62 Storage Management with DB2 for OS/390
Chapter 7. Managing DB2 Recovery Data Sets with SMS
Some DB2 data sets are standard sequential files or partitioned data sets. Many
installations already manage these data sets with SMS and have already SMS
classes defined for these data sets. Therefore, this chapter only analyzes DB2
recovery related data sets.
This chapter describes attributes for SMS management of the DB2 recovery data
sets and provides example SMS constructs for these data sets. DB2 recovery
data sets are described in 3.6, “DB2 Recovery Data Sets” on page 17. This
chapter includes examples of SMS Data, Storage and Management Classes for
the following data sets:
• Bootstrap data sets (BSDS)
• Active log data sets
• Archive log data sets
• Image copy data sets
7.1 SMS Examples for DB2 Recovery Data Sets
The examples shown in this section do not demonstrate all the possibilities that
SMS offers; neither can they consider all the different requirements specific to
each DB2 installation. Each installation is advised to review these examples and
create those classes that best suit its requirements. The examples shown here
are extracted and adapted from DFSMS/MVS Implementing System-Managed
Storage, SC26-3123.
7.1.1 SMS Data Class
DB2 recovery data sets have different attributes. Data Classes can optionally be
defined for these data sets.
7.1.2 SMS Storage Class
DB2 administrators may require several Storage Classes for DB2 recovery data
sets. These Storage Classes have high availability requirements. Performance
requirements may be less severe, with the exception of the active log data sets
which have very high performance requirements. Table 19 on page 64 shows four
examples of Storage Classes for the DB2 recovery data sets. These are:
SCDBIC This Storage Class is intended for image copy data sets. It
SCDBICH This Storage Class is intended for image copy data sets with
SCDBARCH This Storage Class is intended for archive log data sets. It
SCDBACTL This Storage Class is intended for the BSDS and active log
provides good performance and good availability.
a high availability and high performance requirement.
provides good performance and high availability.
data sets. These data sets are allocated once and rarely
redefined. Strict placement is important in order to obtain high
availability and high performance. SCDBACTL uses
guaranteed space to allocate the data sets on specific
volumes within the assigned Storage Group.
© Copyright IBM Corp. 1999 63
Table 19. SMS Storage Classes for Recovery Data Sets
Attribute SCDBIC SCDBICH SCDBARCH SCDBACTL
Direct response (MSEC) 10 5 10 5
Direct bias
Sequential response (MSEC) 10 5 10 1
Sequential bias
Sustained data rate (MB/sec) 10 20 20 40
Availability
Accessibility
Guaranteed space No No No Yes
Guaranteed synchronous write No No No No
Cache set name
CF direct weight
CF sequential weight
a. Continuous=Duplexed or RAID Disk, Preferred=Array Disk, Standard=Array or Simplex Disk
b. If a device with Concurrent Copy capability is desired, specify Continuous or Continuous Preferred
a
b
Standard Continuous Continuous Continuous
Standard Standard Standard Standard
7.1.3 SMS Management Class
DB2 administrators may require several Management Classes for DB2 recovery
data sets. These Management Classes have different expiration and backup
requirements. Table 20 on page 65 shows five examples of Management Classes
for the DB2 recovery data sets. These are:
MCDBICD This Management Class is intended for image copy data sets
MCDBICW This Management Class is intended for image copy data sets
MCDBICM This Management Class is intended for image copy data sets
MCDBLV2 This Management Class is intended for secondary archive logs
MCDBACTL This Management Class is intended for active logs and BSDS
created daily. These data sets will expire after four days.
created weekly. These data sets will expire after 25 days.
created monthly and primary copies of the archive logs. These
data sets will expire after 365 days.
and secondary image copy data sets. Using this Management
Class, these data sets will be migrated directly to level two.
data sets. These data sets do not require SMS management.
64 Storage Management with DB2 for OS/390
Table 20. Management Classes for Recovery Data Sets
Attribute MCDBICD MCDBICW MCDBICM MCDBLV2 MCDBACTL
Expire after days non-usage
Expire after date/days
Retention Limit
Primary days non-usage
Level 1 days date/days
Command or auto migrate
# GDG elements on primary
Rolled-off GDS action
Backup frequency
Number of backup versions
(data set exists)
Number of backup versions
(data set deleted)
Retain days only backup
version (data set deleted)
Retain days extra backup
versions
NOLIMIT NOLIMIT NOLIMIT NOLIMIT NOLIMIT
425365365NOLIMIT
NOLIMIT NOLIMIT NOLIMIT NOLIMIT NOLIMIT
770
770
Both Both Both Both None
17901
1121
2221
28 28 370 1
28 28 370
Admin or user command
backup
Auto backup
7.1.4 SMS Storage Groups
SMS Storage Classes and Management Classes are combined to generate
Storage Groups. This function is performed by the ACS routines. Table 21 on
page 66 shows the relationship between SMS Storage Classes and the SMS
Management Classes with the SMS Storage Groups for DB2 recovery data sets.
Only those Storage Groups needed to satisfy DB2 recovery data set
requirements are defined.
Table 22 on page 66 shows the attributes of the example Storage Groups for DB2
table and index spaces. The five example SMS Storage Groups are:
SGDBIC Storage Group intended for standard image copies.
SGDBICH Storage Group intended for high availability image copies.
SGDBARCH Storage Group intended for primary and secondary archive logs
Both Both Both Both
Ye s Ye s Ye s N o N o
and for secondary image copies. These data sets will be migrated
by DFSMShsm.
Managing DB2 Recovery Data Sets with SMS 65
SGDBACTL Storage Group intended for BSDSs and active logs for all
non-production DB2 subsystems. Because the corresponding
Storage Class has guaranteed space defined as yes,theDB2
administrator can direct the allocation of the data sets on volumes
which are dedicated to a specific DB2 subsystem.
SGDB2PLG Storage Group intended for BSDSs and active logs for the
production DB2P subsystem. The Storage Class contains the
volumes for the DB2P subsystem. The DB2 administrator can
direct the allocation of the data sets on specific volumes of this
Storage Group. Because guaranteed space is used for the
SGDBACTL and SGDB2PLG Storage Groups, it is not strictly
necessary to create a separate SMS Storage Group for each DB2
subsystem, it simply is one of the many choices available to the
DB2 administrator.
Table 21. Relating SMS Storage and Management Classes to Storage Groups
Management Classes
Storage Classes
SCDBIC SGDBIC SGDBIC SGDBIC SGDBARCH
SCDBICH SGDBICH SGDBICH SGDBICH SGDBARCH
MCDBICD MCDBICW MCDBICM MCDBLV2 MCDBACTL
SCDBARCH SGDBARCH SGDBARCH
SCDBACTL SGDBACTL
SGDB2PLG
Table 22. SMS Storage Groups for DB2 Recovery Data Sets
Storage Group Auto-Migrate Auto-Backup Auto-Dump High-Low Thr
SGDBIC Ye s N o N o 7 0-5 0
SGDBICH Ye s N o N o 7 0-5 0
SGDBARCH Ye s N o N o 6 0-4 0
SGDBACTL No No No 99-0
SGDB2PLG No No No 99-0
7.1.5 Assigning SMS Classes to DB2 Recovery Data Sets
SMS classes and Storage Groups are assigned through ACS routines. The
naming standard from 3.8, “DB2 Data Sets Naming Conventions” on page 22 is
used for these examples. This naming standard provides ACS routines with the
necessary information for deciding the SMS classes.
66 Storage Management with DB2 for OS/390
7.2 BSDS
The bootstrap data set (BSDS) contains the information required by DB2 to start
the subsystem in normal circumstances. It also handles the restart and recovery
in any abnormal circumstance. For example, all log data sets (active and archive)
are automatically registered within the BSDS.
Data Organization
The BSDS is a VSAM KSDS. The data control interval is 4 KB; the index control
interval is 1 KB. Figure 19 on page 67 shows an example VSAM definition of a
BSDS.
Performance
While DB2 is executing, the BSDS is updated periodically. The frequency of these
updates is not high, but is dependent on general DB2 subsystem activity. For
example, the BSDS is updated at every DB2 checkpoint and at every archive
process.
Availability
The BSDS is a critical resource for DB2. Because of this, DB2 has implemented
dual copies for the BSDS. DB2 requires the presence of two copies of the BSDS
during restart, to ensure high availability. While DB2 is running, a BSDS may fail
and DB2 continues operating with one BSDS. The second BSDS should be
restored as soon as possible, to avoid DB2 shutdown, which would occur if the
last available BSDS also fails.
DEFINE CLUSTER -
DATA -
INDEX -
Figure 19. Example VSAM Definition of one BSDS
7.2.1 Storage Class
BSDSs use a Storage Class with guaranteed space. This allows the DB2
administrator to decide the location of each BSDS.
• SCDBACTL
7.2.2 Management Class
No SMS management is required for the BSDS data sets. The following
Management Class has been defined for this purpose.
( NAME(DB2V610Z.BSDS01) -
VOLUMES(SBOX10) REUSE SHAREOPTIONS(2 3) ) -
( NAME(DB2V610Z.BSDS01.DATA) -
RECORDS(180 20) RECORDSIZE(4089 4089) CONTROLINTERVALSIZE(4096) FREESPACE(0 20) KEYS(4 0) ) -
( NAME(DB2V610Z.BSDS01.INDEX) -
RECORDS(5 5) CONTROLINTERVALSIZE(1024) )
• MCDBACTL
Managing DB2 Recovery Data Sets with SMS 67
7.2.3 Storage Group
Because the Storage Class has guaranteed space, the BSDS data sets are
allocated on the disk volumes requested by the DB2 administrator. The volumes
must belong to the assigned Storage Group (such as: SGDBACTL), and the disk
volume must be eligible for SMS. For example, this can be done with the
DFSMSdss CONVERT command.
7.2.4 ACS Example
An example of ACS routines to allocate these SMS classes and Storage Groups
for BSDSs is shown in Appendix B, section B.1, “BSDS and Active Logs” on page
185.
7.3 Active Logs
The active log data sets are used for data recovery and ensure data integrity in
case of software or hardware errors. Active log data sets record all updates to
user and system data. If the active log is not available, DB2 cannot guarantee
data integrity.
The active log data sets are open as long as DB2 is active. Active log data sets
are reused when the total active log space is used up, but only after the active log
to be reused has been copied to an archive log.
• SGDBACTL for several DB2 susbsystems
• SGDB2PLG for the DB2P subsystem
Data Organization
The active log data sets are VSAM LDSs. Figure 20 on page 69 shows an
example definition of an active log data set.
Performance
For DB2 subsystems with high update transaction rates, the active logs have a
very high I/O activity (mainly write I/O). The performance of the active logs has an
important impact on the overall DB2 subsystem performance. See 10.4.5,
“Improving Log Write Performance” on page 114 and 10.5.1, “Improving Log
Read Performance” on page 116 for more information.
Availability
The active log data sets have a very high availability requirement for DB2 data
integrity. To ensure this, DB2 optionally supports two copies for each active log
data set (dual active logs). Dual active logs are highly recommended for DB2
production environments.
To improve active log availability, RAID disks or disks with dual copy can be
considered for the active logs.
Migration
Active log data sets should never be migrated by DFSMShsm.
Backup
Every time an active log data sets is filled, DB2 attempts to create an automatic
backup. The backup copies of the active log data sets are the archive log data
sets.
68 Storage Management with DB2 for OS/390
Figure 20. Example VSAM Definition of One Active Log
7.3.1 Storage Class
A Storage Class with guaranteed space set to yes, enables the DB2 administrator
to decide the location of the active logs.
• SCDBACTL
7.3.2 Management Class
The following Management Class has been defined for active logs, no SMS
management is required.
• MCDBACTL
7.3.3 Storage Group
The same Storage Groups used for the BSDSs with guaranteed space set to yes,
are also used for the active logs.
DEFINE CLUSTER -
( NAME (DB2V610Z.LOGCOPY1.DS01) -
VOLUMES(SBOX09) REUSE RECORDS(8640) LINEAR ) -
DATA -
( NAME (DB2V610Z.LOGCOPY1.DS01.DATA) -
)
7.3.4 ACS Example
7.4 Archive Logs
• SGDBACTL for several DB2 subsystems
• SGDB2PLG for the DB2P susbsystem
An example of ACS routines to allocate these SMS classes and Storage Groups
for active logs is shown in Appendix B, section B.1, “BSDS and Active Logs” on
page 185.
Archive log data sets are DB2 managed backups of the active log data sets.
Archive log data sets are required for any recovery that spans a period of time in
excess of the time covered by the active logs. This is illustrated in Figure 5 on
page 19. Archive log data sets are created automatically by DB2 when an active
log fills up, but they may also be created with the -ARCHIVE command.
Data Organization
Archive Log data sets are physical sequential data sets. Record size is 4096 and
the block size is typically 28672 bytes. The allocation of archive logs is done
dynamically by DB2. The DB2 system administrator can influence this process,
specifying options in the DB2 parameter module (default name = DSNZPARM).
Those parameters are defined on installation panel DSNTIPA. An example
definition is shown in Figure 21 on page 70. On this panel, the DB2 administrator
Managing DB2 Recovery Data Sets with SMS 69
can define two separate device types for the primary and secondary archive log.
This can be seen on line 5 and 6 of Figure 21.
DSNTIPA INSTALL DB2 - ARCHIVE LOG DATA SET PARAMETERS
===>
Enter data below:
1 ALLOCATION UNITS ===> CYL Blk, Trk, or Cyl
2 PRIMARY QUANTITY ===> 3320 Primary space allocation
3 SECONDARY QTY. ===> 0 Secondary space allocation
4 CATALOG DATA ===> YES YES or NO to catalog archive data sets
5 DEVICE TYPE 1 ===> DASD Unit name for COPY1 archive logs
6 DEVICE TYPE 2 ===> DASD Unit name for COPY2 archive logs
7 BLOCK SIZE ===> 28672 Rounded up to 4096 multiple
8 READ TAPE UNITS ===> 2 Number of allocated read tape units
9 DEALLOC PERIOD ===> 0 Time interval to deallocate tape units
10 RECORDING MAX ===> 1000 Number of data sets recorded in BSDS
11 WRITE TO OPER ===> YES Issue WTOR before mount for archive
12 WTOR ROUTE CODE ===> 1,3,4
13 RETENTION PERIOD ===> 365 Days to retain archive log data sets
14 QUIESCE PERIOD ===> 5 Maximum quiesce interval (1-999)
15 COMPACT DATA ===> NO YES or NO for data compaction
F1=HELP F2=SPLIT F3=END F4=RETURN F5=RFIND F6=RCHANGE
F7=UP F8=DOWN F9=SWAP F10=LEFT F11=RIGHT F12=RETRIEVE
Routing codes for archive WTORs
Figure 21. Archive Log Installation Panel DSNTIPA
Performance
The archive log performance requirement is dependent on recovery performance,
service level, and available active log. Performance requirements for archive logs
are normally not very high.
Availability
In general, archive log availability is important to ensure data and system
availability. Archive log availability is a function of the amount of available active
log. Some installations have enough active log to cover most of their recovery
needs. If this is the case, archive log availabilty becomes less critical.
To enhance availability, DB2 supports software duplication of archive log data
sets.
Migration
Archive logs can be created directly to tape, but may also reside on disk. Disk
archive logs are eligible to be migrated by DFSMShsm. The residence time on
disk should ensure that the likelihood of a recall is in agreement with recovery
service levels. When dual archive logs are defined, DFSMShsm should migrate
them to different tape volumes or devices to ensure availability. One way of
achieving this, would be to have the secondary copy to migrate directly to level 2,
while the primary copy remains a certain time on level 1. The examples in this
chapter show how this can be achieved.
Recovery from disk archive logs is faster than recovery from archive logs on tape.
Recovery from active logs is slightly more efficient than recovery from archive
logs. Because of these two reasons, generally the disk space dedicated to
archive logs may be better utilized for active logs and sending the archive logs
70 Storage Management with DB2 for OS/390
directly to tape.
Backup
The archive logs are a backup of the active logs. DB2 can create dual archive
logs. There is no need for an additional backup of the archive logs.
7.4.1 Storage Class
Storage Class SCDBARCH is an example of a Storage Class for archive logs.
This Storage Class has high availability and good performance.
• SCDBARCH
7.4.2 Management Class
Two different Management Classes are used for the archive logs. One is used for
the primary copy and the other for the secondary copy. Both allow migration of
the data sets. The reason for defining two separate Management Classes is to
enable a physical separation of the two copies.
The Management Class MCDBICM is used for the image copies retained longest
and for the archive logs. This ensures equivalent expiration dates for image
copies and archive logs.
The Management Class MCDBLV2 is used for the secondary archives. This will
directly migrate the secondary copy to level 2 of DFSMShsm and so ensure a
physical separation of the two archive copies.
7.4.3 Storage Group
Primary and secondary archive logs are allocated on volumes of the SGDBARCH
Storage Group. These data sets are migrated independently on different dates.
This is determined by their Management Class.
An alternative to the above Storage Group could be a TMM Storage Group, but
only for the secondary copy of the archive logs. A TMM Storage Group simulates
a tape device on disk. Multiple data sets are placed together on the same tape.
This could have a performance impact if this archive log is required for a recovery
or a restart.
7.4.4 ACS Example
An example of ACS routines to allocate these SMS classes and Storage Group
for archive logs is shown in Appendix B, section B.2, “Archive Logs” on page 191.
• MCDBICM, used for primary archive log data sets
• MCDBLV2, used for secondary archive log data sets
• SGDBARCH
7.5 Image Copies
Image copies are the backup of user and system data in a DB2 subsystem. For a
well managed backup and recovery policy, the amount of data in image copy data
sets exceeds the amount of production data by at least a factor of three. This
Managing DB2 Recovery Data Sets with SMS 71
means that a large number of image copy data sets are required and need to be
managed.
Data Organization
Image Copy data sets are physical sequential data sets. Record size is 4096 (for
any size of page) and the block size is typically 28672 bytes. Sample statements
to execute an image copy are shown in Figure 137 on page 198 in Appendix B,
section B.3, “Image Copies” on page 194.
Performance
Most image copies have no special performance requirements, but there are
cases when the time to take an image copy becomes critical.
Availability
Image copies ensure user and system data integrity. Their availability is critical
for DB2 system and application availability. DB2 can optionally generate up to
four image copies of a table space or of a data set (for a multiple data set table
space). Two of these copies are intended for a disaster recovery at a remote site.
Migration
Image copies can be created on tape, or on disk. Image copies are eligible for
migration. Some installations create image copies on a pool of disks and migrate
asynchronously later in order to avoid delays due to contention for tape units. If
multiple image copies are created, then a technique such as that described for
archive logs may be used to ensure device separation for the different copies.
Backup
Image copies are backups of system and user data. Multiple copies can be
generated. A previous image copy can act as backup for the most recent one, but
then more log needs to be applied during the recovery process. Additional
backups improve image copy availability and more frequent image copies reduce
recovery time.
7.5.1 Storage Class
This example assumes different availability and performance requirements for
image copies. Because of this, two Storage Classes have been defined for image
copies.
• SCDBIC
• SCDBICH
7.5.2 Management Class
This examples assumes different retention cycles for image copies. This is
reflected in four Management Classes:
• MCDBICD - Daily image copies
• MCDBICW - Weekly image copies
• MCDBICM - Monthly image copies
• MCDBLV2 - Secondary image copies
72 Storage Management with DB2 for OS/390
7.5.3 Storage Group
For this example, three Storage Groups are defined. These provide different
levels of performance and availability. SGDBARCH serves to separate secondary
copies from the primary copies.
7.6 Summary
Table 23. Storage Groups for DB2 Recovery Data Sets
•SGDBIC
•SGDBICH
• SGDBARCH
Data Set Performance Availability Migration St Groups
BSDS Standard High NO SGDBACTL
SGDB2PLG
Active Log Very High High NO SGDBACTL
SGDB2PLG
Primary
Archive Log
Secondary Archive Log Low Standard YES SGDBARCH
Primary Image Copy Medium High YES SGDBIC
Secondary Image Copy Standard High YES SGDBARCH
Standard High YES SGDBARCH
High High YES SGDBICH
Managing DB2 Recovery Data Sets with SMS 73
74 Storage Management with DB2 for OS/390
Chapter 8. Converting DB2 to Systems Managed Storage
This chapter describes the techniques for converting DB2 data to SMS. However,
each customer has unique data sets and facilities to support their online
environment. These differences have an impact on recommended storage
management procedures. Database data has different space, performance, and
availability requirements; therefore, dividing database data into categories will
help identify the required SMS services and implement a staged conversion to
SMS.
8.1 Overview
In order for the DB2/SMS relationship to be successful, the data base
administrator (DBA) must clearly specify the characteristics and requirements of
the DB2 data sets. The storage administrator must also ensure they are satisfied
in the physical implementation.
All types of DB2 data are important for successful operation of a DB2
environment. Great care must be taken in preparing DB2 for its conversion to
SMS management.
Under most circumstances, an installation will have already implemented SMS to
some degree prior to considering the management of DB2; likely candidates are
batch and TSO data sets. Therefore, it is assumed that sufficient skills exist
within the storage administrator’s area to provide the levels of support needed.
If possible, it is recommended to first convert a DB2 test system to DFSMS, in
order to gain experience with the various aspects of the DB2/SMS relationship.
The DB2 administrator and storage administrator should work closely together to
test the environment. Once satisfied with this scenario, a migration plan should
be developed to convert DB2 data.
The technique and implementation sequence for converting a DB2 system to
SMS varies according to each installation. However, the following topics provide
a guideline:
• Advantages of SMS managing DB2 data
• SMS management goals
• Positioning for implementation
• Conversion processes
• DFSMS FIT
• NaviQuest
8.2 Advantages of SMS Managing DB2 Data
ACS routines can be designed so that SMS restricts the allocation of data sets in
DB2 Storage Groups to production databases and selected system data sets.
Only authorized users, such as the DB2 administrator or storage administrator
can allocate data in these Storage Groups. They also will have the authority to
allocate data sets with critical performance and availability requirements to
specific volumes. Dual copy provides high availability for selected data sets that
© Copyright IBM Corp. 1999 75
are not duplexed by the database management system. The use of fast write and
cache facilities will provide increased performance for databases and recovery
data sets.
DFSMS/MVS enhances the backup and recovery utilities provided by the DB2
system as follows:
• DFSMSdss uses concurrent copy capability to create point-of-consistency
backups.
• DFSMShsm backs up system data sets and end-user database data that is
less critical than production database data.
• DFSMShsm carries out direct migration to migration level 2 for archived
recovery data sets on disk storage.
• Testing/end user databases can be migrated by DFSMShsm through the
storage hierarchy, based on database usage.
8.3 SMS Management Goals
The aims and goals for managing SMS will differ for each installation, although
there are areas where working practices will have a common ground. These
areas can be categorized as follows:
• Positioning for future enhancements to both DFSMS/MVS and DB2.
• Improving the storage management of data:
• Use of SMS to simplify JCL allocation.
• Maintain support for disk and data storage growth without increasing
staff levels.
• Use of SMS to simplify data movement.
• Improve disk storage efficiency by increasing space utilization through
better use of allocation control.
• Bring private disk volumes under centralized control.
• Segregate production from other data.
• Reduce disk storage requirements by migration of inactive data.
• Improving the DB2 aspects of data management:
• Spread partitions for a given table/PI.
• Spread partitions of tables and indexes likely to be joined.
• Spread pieces of NPIs.
• Spread DB2 work files, and temporary data sets likely to be accessed in
parallel.
• Exploitation of hardware such as RVA.
• Physical striping of data.
• Avoiding UCB contention.
• Use only what disk space is actually needed.
76 Storage Management with DB2 for OS/390
8.4 Positioning for Implementation
For the DBA, there are a number of items to be considered as prerequisites for
the process.
8.4.1 Prerequisite Planning
Categorize each data type into separate groups
The usage characteristics and service requirements will have to be considered
for each data type, and will include:
• Response time performance
• Accessibility and availability operations
• Initial sizing of data sets and future growth
• Difference between production and user/testing data sets
DB2 STOGROUPs Mapping to SMS Storage Groups
To ensure consistency, it is recommended that DB2 STOGROUPs are converted
to equivalent SMS Storage Groups.
Identify DB2 Data Sets Eligible for HSM Management
Decide for which groups of DB2 data DFSMShsm should have the authority to
migrate or backup. For example, production databases, Active logs, System
libraries, and BSDS are candidates for NO MIGRATION due to their critical
status.
Set DSNZPARM to have DFSMShsm automatically recall DB2 data sets during
DB2 access. Set RECALL to Y. Set RECALLD, the maximum wait for DFSMShsm
to complete recreation of data sets on the primary disk, based on testing with
typical end user databases.
Use of Guaranteed Space
As part of the initial phase,the GUARANTEED SPACE option can be used to
position data, particularly production tablespaces, and active logs. Once satisfied
with the allocation of the data sets, it is recommended that this option be
removed, so future allocations can be under the sole control of SMS.
Guaranteed space is recommended for use only during the migration period (from
DB2 managed to SMS managed) which should be kept short to prevent failures
on initial allocation and data set extension. Unlike non-SMS, SMS does not retry
allocation on another volume if the requested space cannot be satisfied on the
specified candidate volume.
Guaranteed space is not useful unless the space requirements are relatively
small and static.
Ensure That All Data Sets Are Cataloged
SMS requires that all data sets are cataloged in ICF catalogs, enabling the use of
standard catalog search routines (VSAM and CVOL catalogs are no longer
supported after 1999). For further information see, DFSMS/MVS Managing
Catalogs, SC26-4914.
Converting DB2 to Systems Managed Storage 77
DB2 Naming Conventions
Certain parts of tablespace names are generated by DB2. This does not leave the
DBA with much scope for a flexible naming convention. For further information on
this subject see 6.1.7, “Assigning SMS Classes to DB2 Table Spaces and Index
Spaces” on page 53 and 6.1.8, “Table Space and Index Space Names for SMS”
on page 56. Ensure that the storage administrator is fully aware of any
restrictions so ACS routines can be coded accordingly.
DB2 Recovery Requirements
For purposes of DB2 recovery, the degree of integrity required for active logs,
imagecopies and archive logs must be decided upon.
Expiration of Data Sets
Management Class expiration attributes should be synchronized with DB2's
expiration information:
• Expiration of archive logs must be consistent with the value of ARCRETN. The
BSDS should be updated with the DB2 change log inventory utility to remove
deleted archive logs.
• Expiration of archive logs must also be consistent with the expiration of image
copies. This is described under “Deleting Image Copies and Archive Logs” on
page 21.
• Expiration of any DB2 image copies requires running the MODIFY utility to
update SYSCOPY.
8.4.2 Service Level Agreement
The service level agreement has to be drawn up between the DBA and the
storage administrator, and will include items mentioned in the previous section:
• The levels of service required by different data types.
• Performance, accessibility, and availability characteristics.
• The use of dedicated volumes.
• The use of the GUARANTEED SPACE parameter.
• The use of HSM management (automatic migration, recall, backup, space
release, and data set expiration).
• Data set naming conventions.
8.5 Conversion Process
This topic covers those aspects of planning and converting DB2 data.
8.5.1 Sequence
To ensure minimum disruption to services, the following sequence is suggested
for implementation:
• Libraries and other DB2 system data sets.
• Archive logs and imagecopies.
• User and testing tablespaces.
• Production tablespaces.
78 Storage Management with DB2 for OS/390
Loading...