Data Protection For Snapshot Devices For MySAPInstallation and User's Guide For DB2

Tivoli Storage Manager
for Advanced Copy Services

Data Protection for Snapshot Devices for mySAPInstallation and Users Guide
for DB2 UDB
Version 5.4
SC33-8208-01

for Advanced Copy Services
Data Protection for Snapshot Devices for mySAPInstallation and Users Guide
for DB2 UDB
Version 5.4
SC33-8208-01
Second Edition (January 2007)

This edition is an update of Tivoli Storage Manager for Hardware: Data Protection for FlashCopy Devices for mySAP
Installation and Users Guide for DB2 UDB Version 5.3, SC33-8208-00. It applies to the following components:
v Data Protection for FlashCopy Devices for mySAP
v Data Protection for N Series Snapshot for mySAP
offered by Tivoli Storage Manager for Advanced Copy Services, Program Number 5608-ACS, which is available as a
licensed program product, and to all subsequent releases and modifications until otherwise indicated in new
editions. The term Data Protection for Snapshot Devices is an umbrella term intended to cover both of these
components.
Order publications through your IBM representative or the IBM branch office serving your area. Publications are
not stocked at the addresses given below.
Address comments on this publication to:
IBM Deutschland Entwicklung GmbH
Enterprise Solution Development
Dept. 3848, Bldg. 71032-15
Schnaicher Str. 220
71032 Bblingen
lGermany

FAX (Germany): 07031 16 3619
FAX (other countries): (+49) 7031 16 3619

Web pages:
Product information:
http://www.ibm.com/software/tivoli/products/storage-mgr-advanced-copy-services/
Support:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManagerforAdvancedCopyServices.html
Make sure to include the following in your comment or note:
v Title and order number of this document
v Page number or topic related to your comment
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 2001, 2007. All rights reserved.
US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.

Note!
Before using this information and the product it supports, be sure to read the general information under
Notices on page 343.

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Contents
Figures . . . . . . . . . . . . . . vii
Tables . . . . . . . . . . . . . . . ix
Summary of Changes . . . . . . . . xi
Preface . . . . . . . . . . . . . . xiii
Who Should Read This Document . . . . . . xiii
Where to Find More Information . . . . . . . xiv
Contents of the DP for Snapshot Devices Packages xv
Supported Platforms . . . . . . . . . . . xv
Naming Conventions . . . . . . . . . . . xv
Support . . . . . . . . . . . . . . . xv
Chapter 1. Introduction . . . . . . . . 1
Understanding DP for Snapshot Devices . . . . . 1
Storage System Environment . . . . . . . . 1
Operating Environment . . . . . . . . . . 6
Functions of DP for Snapshot Devices
(tdphdwdb2/splitint) . . . . . . . . . . 11
Support for Environments Set Up with Enhanced
Concurrent Capable Volume Group(s) . . . . 21
Understanding the SAP DB2 Administration Tools 21
Understanding Data Protection for mySAP . . . . 22
The DP for mySAP Profile . . . . . . . . 24
The DP for mySAP Configuration File . . . . 24
Understanding the Administration Assistant for DP
for mySAP . . . . . . . . . . . . . . 24
Understanding DP for mySAP and the TSM Server 25
Understanding the Hardware Interface and
Common Information Model (CIM) . . . . . . 26
Understanding the CIM Agent . . . . . . . 30
CIM Agents Used by DP for Snapshot Devices . 31
Chapter 2. General Preparations for
Installing DP for Snapshot Devices . . 33
Overview . . . . . . . . . . . . . . . 33
Overall Disk Layout Considerations . . . . . . 34
Specific Customization Requirements . . . . . . 36
DP for Snapshot Devices Functions for AIX JFS2 File
Systems . . . . . . . . . . . . . . . 40
Use of Unique Logical Volume Names . . . . . 40
Use of JFS2 Concurrent I/O (CIO) . . . . . . . 40
DP for Snapshot Devices Setup Requirement for
Using CIO . . . . . . . . . . . . . . . 40
Chapter 3. Installing and Customizing
DP for Snapshot Devices . . . . . . . 43
Installation Requirements . . . . . . . . . . 44
Hardware Requirements . . . . . . . . . 44
Software Requirements . . . . . . . . . 45
Environment Requirements . . . . . . . . 48
Volume Group Requirements . . . . . . . 49
LVM Mirroring Requirements . . . . . . . 49
General Installation Approach for the Required
Products . . . . . . . . . . . . . . . 49
CIM Components and Related Software . . . . . 51
Open SSL . . . . . . . . . . . . . . 52
CIM Server Package (Pegasus) . . . . . . . 53
DS Open API CIM Agent . . . . . . . . . 54
CIM Agent for SVC . . . . . . . . . . . 55
Other Steps Prior to Installing DP for Snapshot
Devices . . . . . . . . . . . . . . . . 55
Setting Up the NFS File System . . . . . . . 55
Setting Up the Remote Shell (RSH) . . . . . 56
Installing and Using the IBM Multipath
Subsystem Device Driver (SDD) . . . . . . 56
Setting Up Source and Target Volumes . . . . 57
Installing DP for Snapshot Devices . . . . . . 58
Customizing and Initializing DP for Snapshot
Devices . . . . . . . . . . . . . . . . 61
Customizing the DP for Snapshot Devices Profile 61
Checking Environment Variables . . . . . . 63
Initializing DP for Snapshot Devices . . . . . 64
Configuring DP for Snapshot Devices on the Backup
System (setupDB2BS) . . . . . . . . . . . 65
Prerequisites . . . . . . . . . . . . . 65
Syntax . . . . . . . . . . . . . . . 66
Description . . . . . . . . . . . . . 66
Uninstalling DP for Snapshot Devices . . . . . 71
Chapter 4. Backup Methods. . . . . . 73
Database Backups With FlashCopy Backup Disks . . 73
Target Set State . . . . . . . . . . . . . 74
Intended and Effective FLASHCOPY_TYPE . . . 75
FlashCopy Backup in a SAN Volume Controller
Environment . . . . . . . . . . . . . . 75
Database Backups Without FlashCopy Backup Disks 76
Backups of the Offline Log Files . . . . . . . 76
How to Start the Backups . . . . . . . . . 77
Automated Backup Start via Schedules . . . . 77
Tivoli Storage Manager Schedules . . . . . . 77
UNIX crontab . . . . . . . . . . . . 78
Backup Strategy and Automation . . . . . . . 78
Chapter 5. Restore Methods . . . . . 81
Using tdphdwdb2 for Restore and Recovery of DB2
Databases . . . . . . . . . . . . . . . 82
Important Information for Profiles . . . . . . . 83
Important Information about the Backup History
File . . . . . . . . . . . . . . . . . 84
FlashBack Restore Considerations . . . . . . . 84
What is FlashBack Restore? . . . . . . . . 84
Why Use FlashBack Restore? . . . . . . . 85
When Not to Use FlashBack Restore . . . . . 86
FlashBack Restore Limitations . . . . . . . . 87
Understanding the Limitations . . . . . . . 87
Description of FlashBack Restore Limitations . . 89
FlashBack Restore Rerun Capabilities . . . . . . 93

Copyright IBM Corp. 2001, 2007 iii
||
||
||
||
||
||
||
||
|
||
||
What is a FlashBack Restore Rerun? . . . . . 94
Conditions for a FlashBack Restore Rerun . . . 94
Reasons for a FlashBack Restore Rerun . . . . 94
FlashBack Restore Rerun Limitations . . . . . 95
Sample FlashBack Restore Scenarios . . . . . . 95
Scenario Descriptions . . . . . . . . . . 96
Chapter 6. Description and Usage of
the DP for Snapshot Devices
Commands . . . . . . . . . . . . 105
Functions of the DP for Snapshot Devices
Command splitint . . . . . . . . . . . 105
Syntax of the DP for Snapshot Devices Command
tdphdwdb2 . . . . . . . . . . . . . 106
Backup Function . . . . . . . . . . . . 107
Description . . . . . . . . . . . . . 107
Usage . . . . . . . . . . . . . . . 109
Syntax . . . . . . . . . . . . . . . 109
Restore Function . . . . . . . . . . . . 110
Description . . . . . . . . . . . . . 110
Usage . . . . . . . . . . . . . . . 116
Syntax . . . . . . . . . . . . . . . 117
FlashCopy Function . . . . . . . . . . . 117
Description . . . . . . . . . . . . . 117
Usage . . . . . . . . . . . . . . . 118
Syntax . . . . . . . . . . . . . . . 119
Query Function . . . . . . . . . . . . . 119
Description . . . . . . . . . . . . . 119
Usage . . . . . . . . . . . . . . . 120
Syntax . . . . . . . . . . . . . . . 120
Withdraw Function . . . . . . . . . . . 121
Description . . . . . . . . . . . . . 121
Usage . . . . . . . . . . . . . . . 121
Syntax . . . . . . . . . . . . . . . 123
Withdraw_Force Function . . . . . . . . . 123
Description . . . . . . . . . . . . . 123
Usage . . . . . . . . . . . . . . . 123
Syntax . . . . . . . . . . . . . . . 124
Unmount Function . . . . . . . . . . . 124
Description . . . . . . . . . . . . . 124
Usage . . . . . . . . . . . . . . . 125
Syntax . . . . . . . . . . . . . . . 125
Inquire Function . . . . . . . . . . . . 126
Description . . . . . . . . . . . . . 126
Usage . . . . . . . . . . . . . . . 126
Syntax . . . . . . . . . . . . . . . 126
TS_Inquire Function . . . . . . . . . . . 126
Description . . . . . . . . . . . . . 126
Usage . . . . . . . . . . . . . . . 127
Syntax . . . . . . . . . . . . . . . 127
Configure Function . . . . . . . . . . . 127
Description . . . . . . . . . . . . . 127
Usage . . . . . . . . . . . . . . . 128
Syntax . . . . . . . . . . . . . . . 128
Password Function . . . . . . . . . . . 129
Description . . . . . . . . . . . . . 129
Usage . . . . . . . . . . . . . . . 129
Syntax . . . . . . . . . . . . . . . 129
Modify_Copyrate Function . . . . . . . . . 130
Description . . . . . . . . . . . . . 130
Usage . . . . . . . . . . . . . . . 130
Syntax . . . . . . . . . . . . . . . 130
DBResume Function . . . . . . . . . . . 130
Description . . . . . . . . . . . . . 130
Usage . . . . . . . . . . . . . . . 130
Syntax . . . . . . . . . . . . . . . 131
Restart_Backup Function . . . . . . . . . 131
Description . . . . . . . . . . . . . 131
Usage . . . . . . . . . . . . . . . 131
Syntax . . . . . . . . . . . . . . . 132
Summary of tdphdwdb2 Functions . . . . . . 133
Backup and Restore Cycles . . . . . . . . . 134
Backup Cycle . . . . . . . . . . . . 134
Restore Cycle . . . . . . . . . . . . 135
Common Information for the Backup and
Restore Cycles . . . . . . . . . . . . 136
FlashCopy Agent . . . . . . . . . . . 136
PSI (Progress Status Indicator) . . . . . . . 137
BSI (Backup Status Indicator) . . . . . . . 139
RSI (Restore Status Indicator) . . . . . . . 141
Chapter 7. The DP for Snapshot
Devices Profile (.fcs) and Target
Volumes File. . . . . . . . . . . . 143
Location and Naming Conventions . . . . . . 143
Structure of the DP for Snapshot Devices Profile 143
Parameters of the DP for Snapshot Devices Profile 144
DP for Snapshot Devices Target Volumes File . . . 155
Parameters for an ESS or DS Configuration . . 156
Parameters for an SVC Configuration . . . . 158
Chapter 8. DP for Snapshot Devices
Functionality for AIX LVM Mirrored
Environments . . . . . . . . . . . 161
Overview . . . . . . . . . . . . . . . 161
Advantages of the Special Handling of AIX LVM
Mirrored Environments . . . . . . . . . . 162
Functional Overview . . . . . . . . . . . 163
FlashCopy Backup Process . . . . . . . . 163
FlashBack Restore Process . . . . . . . . 165
DP for Snapshot Devices and Copy Sets in an AIX
LVM Mirror Environment . . . . . . . . . 165
Supported AIX LVM Mirrored Environments and
DP for Snapshot Devices . . . . . . . . . 168
Symmetrical Environment . . . . . . . . 168
Asymmetrical Environment . . . . . . . . 169
Requirements for Proper Setup and Customization
with AIX LVM Mirrors . . . . . . . . . . 170
Target Set Parameter . . . . . . . . . . . 174
DP for Snapshot Devices Parameters Needed for a
Later FlashBack Restore . . . . . . . . . . 175
DP for Snapshot Devices Target Volumes File in a
Mirrored Environment . . . . . . . . . . 175
Parameters for ESS or DS . . . . . . . . 176
Parameters for SVC . . . . . . . . . . 178
Samples Using the DP for Snapshot Devices
Functionality for AIX LVM Mirrored Environments . 179
Using the DP for Snapshot Devices Commands
for Backups (Sample) . . . . . . . . . . 180

iv Data Protection for Snapshot Devices for mySAP Installation and Users Guide for DB2 UDB
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
||
Running the FlashBack Restore/Recovery
(Sample) . . . . . . . . . . . . . . 181
DP for Snapshot Devices Files Used for the
Preceding Backup and Restore/Recovery
Commands (Sample) . . . . . . . . . . 181
AIX LVM Mirror/Copy Examples . . . . . . 183
Example 1: Ideal Configuration, Symmetrical
Setup . . . . . . . . . . . . . . . 184
Example 2: Symmetrical Configuration with
Stale Physical Partitions in One ESS Unit . . . 184
Example 3: Symmetrical Configuration with
Stale Physical Partitions in Both ESS Units . . 185
Example 4: Asymmetrical Configuration with
Insufficient Target Volumes . . . . . . . . 186
Sufficient Target Volumes . . . . . . . . 187
Sufficient Target Volumes But Stale Physical
Partitions . . . . . . . . . . . . . . 188
Example 7: Symmetrical Configuration with LVs
(Different Mirror Numbers) in the Same ESS . . 189
Chapter 9. Considerations for DB2
UDB ESE with DPF . . . . . . . . . 191
EEE: Naming Conventions and DB2 UDB Instance
Setup . . . . . . . . . . . . . . . . 191
EEE: Customizing and Initializing DP for Snapshot
Devices . . . . . . . . . . . . . . . 193
EEE: Description and Usage of the DP for Snapshot
Devices Commands . . . . . . . . . . . 195
EEE: Parallel Backup/Restore of DB2 UDB EEE
and ESE Databases with Multiple EEE Partitions 195
EEE: Configure Function . . . . . . . . 201
EEE: Backup Function . . . . . . . . . 201
EEE: FlashCopy Function . . . . . . . . 204
EEE: Restore Function . . . . . . . . . 205
EEE: Other Functions . . . . . . . . . . 214
EEE: Modifying the DB2 UDB EEE Instance . . 214
Chapter 10. Multiple Backup
Generations (Target Sets) on Disk . . 219
General Overview . . . . . . . . . . . . 219
Selection Algorithms Available . . . . . . . 221
Intended FLASHCOPY_TYPE . . . . . . . . 221
Setup for Multiple Target Sets in the DP for
Snapshot Devices Target Volumes File . . . . . 221
Target Set States . . . . . . . . . . . . 222
Logical FlashCopy Group . . . . . . . . 223
Functions and Commands Providing Target Set
Status and Usage Information . . . . . . . . 223
Parameters Affecting the Use of Multiple Target
Sets . . . . . . . . . . . . . . . . 224
General Prevention of Simultaneous FlashCopy
Backups . . . . . . . . . . . . . . . 224
Algorithm Used for Automated Target Set Selection
Using the Intended FlashCopy Type. . . . . . 225
Algorithm Used for Specific Target Set Selection 226
Requirements for Using Multiple Target Sets . . . 228
Multiple Target Sets and Implications for a
FlashBack Restore . . . . . . . . . . . . 228
Required Checks Prior to FlashBack Restore . . 228
Checking the Source and Target Relationships
Using tdphdwdb2 . . . . . . . . . . . 230
Running the FlashBack Restore . . . . . . 233
Performing a FlashBack Restore Rerun with a
Different Target Set . . . . . . . . . . 233
Appendix A. Samples . . . . . . . . 235
Sample of an Overall Disk Layout . . . . . . 235
Sample NFS Server Setup on the Production
System . . . . . . . . . . . . . . . 237
Sample NFS Client Setup on the Backup System 238
Sample .rhosts for Remote Shell Connection Setup
on the Production System . . . . . . . . . 238
Sample TSM Client Options Files . . . . . . . 239
Sample Client User Options File (dsm.opt) . . 239
Sample Client System Options File (dsm.sys) 239
Sample DP for mySAP DB2 Vendor INI File . . . 239
Sample DP for mySAP Profile . . . . . . . . 239
Sample DP for Snapshot Devices Profile . . . . 241
Sample DP for FlashCopy Target Volumes File (ESS
or DS Configuration) . . . . . . . . . . . 251
Sample DP for FlashCopy Target Volumes File
(SVC Configuration) . . . . . . . . . . . 253
Sample for Defining a DP for FlashCopy Target
Volumes File (Mirror Setup, ESS or DS
Configuration) . . . . . . . . . . . . . 254
Sample DP for mySAP Installation and
Customization . . . . . . . . . . . . . 256
Sample DP for Snapshot Devices Installation and
Customization . . . . . . . . . . . . . 258
Sample tdphdwdb2 Usage . . . . . . . . . 259
Case 1: Backup with Target Withdrawal in
tdphdwdb2 Run . . . . . . . . . . . . 259
Case 2: Backup Without Subsequent Unmount
or Withdraw . . . . . . . . . . . . 260
Case 3: Backup with Delayed Withdrawal
Outside tdphdwdb2 Run . . . . . . . . . 260
Case 4: Backup with Unmounting of File
Systems in tdphdwdb2 Run . . . . . . . . 261
Case 5: FlashCopy with Delayed Withdrawal
Outside tdphdwdb2 Run . . . . . . . . 262
Case 6: Setup Test with the Query Function . . 263
Case 7: INCR/COPY Backup Run . . . . . 263
Case 8: INCR/COPY Disk-Only Backup Run 264
Case 9: Backup with Multiple Target Sets
(Without AIX Mirrors) . . . . . . . . . 265
Case 10: Backup with Multiple Target Sets (With
AIX Mirrors) . . . . . . . . . . . . 267
Sample tdphdwdb2 FlashCopy Shell Script . . . . 271
Sample tdphdwdb2 EEE FlashCopy Script . . . . 272
Sample tdphdwdb2 EEE Online/Offline Backup
Script . . . . . . . . . . . . . . . . 273
Sample DP for Snapshot Devices Scripts for
HACMP Environments . . . . . . . . . . 273
Appendix B. Data Protection for
Snapshot Devices for mySAP (DB2)
Messages . . . . . . . . . . . . . 275
Messages from splitint . . . . . . . . . . 275

Contents v
||
Messages from tdphdwdb2 . . . . . . . . 311
CIM Error Codes . . . . . . . . . . . . 321
CIM Agent Return Codes (ESS and DS) . . . 321
CIM Agent Return Codes (SVC) . . . . . . 323
Appendix C. Summary of Log and
Trace Files . . . . . . . . . . . . 329
DP for Snapshot Devices Logs and Traces . . . . 329
Storage System Logs and Traces . . . . . . . 329
CIM Logs and Traces . . . . . . . . . . . 329
DP for mySAP . . . . . . . . . . . . . 330
AIX Operating System . . . . . . . . . . 330
Appendix D. Support Information . . . 331
Using IBM Support Assistant . . . . . . . . 331
Obtaining Fixes . . . . . . . . . . . . . 331
Receiving Weekly Support Updates . . . . . . 332
Contacting IBM Software Support . . . . . . 333
Determining the Business Impact . . . . . . 334
Describing Problems and Gathering Information 334
Submitting Problems . . . . . . . . . . 334
Glossary . . . . . . . . . . . . . 337
Notices . . . . . . . . . . . . . . 343
Trademarks and Service Marks . . . . . . . 345
Accessibility . . . . . . . . . . . . . . 346
Navigating the Interface Using the Keyboard 346
Magnifying What is Displayed on the Screen 346
Index . . . . . . . . . . . . . . . 347

vi Data Protection for Snapshot Devices for mySAP Installation and Users Guide for DB2 UDB
||
||
||
||
||
||
||
||
||
Figures
1. Overall DP for Snapshot Devices Environment 7
2. Flow of FlashCopy/Backup/Withdraw
Operations . . . . . . . . . . . . . 14
3. Production System Interactions in the DP for
Snapshot Devices Environment: . . . . . . 18
4. Overview of DP for mySAP for DB2 UDB 23
5. DP for Snapshot Devices Hardware Interface
for ESS and DS Configurations . . . . . . 27
6. DP for Snapshot Devices Hardware Interface
for SVC and N Series Configurations . . . . 28
7. Overview of the Backup Scenario (Single
Target Set) . . . . . . . . . . . . . 35
8. Overview of the Backup Scenario (Multiple
Target Sets) . . . . . . . . . . . . 35
9. Control File/Profile Relationships Without DP
for Snapshot Devices . . . . . . . . . 38
10. Control File/Profile Relationships With DP for
Snapshot Devices . . . . . . . . . . 39
11. FlashBack Restore Process . . . . . . . . 85
12. Syntax of the DP for Snapshot Devices
Command tdphdwdb2 . . . . . . . . 106
13. DP for Snapshot Devices and Copy Sets in an
AIX LVM Mirror Environment for DB2 . . . 166
14. Ideal Configuration, Symmetrical Setup 184
15. Symmetrical Configuration with Stale
Physical Partitions in One ESS Unit . . . . 184
16. Symmetrical Configuration with Stale
Physical Partitions in Both ESS Units . . . . 185
17. Asymmetrical Configuration with Insufficient
Target Volumes . . . . . . . . . . . 186
18. Asymmetrical Configuration with Sufficient
Target Volumes . . . . . . . . . . . 187
19. Asymmetrical Configuration with Sufficient
Target Volumes But Stale PP(s) . . . . . . 188
20. Symmetrical Configuration with LVs
(Different Mirror Numbers) in the Same ESS . 189
21. Typical EEE Setup . . . . . . . . . . 202
22. Disk Layout Used in Sample Installation 236
23. smitty Panel for Exporting Directories 237
24. smitty Panel For Mounting NFS Files 238

Copyright IBM Corp. 2001, 2007 vii
viii Data Protection for Snapshot Devices for mySAP Installation and Users Guide for DB2 UDB
Tables
1. Related Publications . . . . . . . . . xiii
2. Hardware Requirements . . . . . . . . 44
3. Software Requirements . . . . . . . . . 45
4. Summary of Function Usage for DP for
Snapshot Devices Command tdphdwdb2 . . 133
5. DP for Snapshot Devices Actions Required to
Reset the Backup Cycle . . . . . . . . 138
6. Possible Progress Status Indicator (PSI) Values 138
7. Possible Backup Status Indicator (BSI) Values 139
8. Possible Restore Status Indicator (RSI) Values 141
9. Parameter Name Changes as of V5.3.1 144
10. DP for Snapshot Devices Profile Parameters
(global Topic) . . . . . . . . . . . 144
(DB2 Topic) . . . . . . . . . . . . 148
(copyservices_data Topic) . . . . . . . 153
13. Target Volumes File Parameter Changes as of
V5.3.1 . . . . . . . . . . . . . . 156
14. Parameters of the volumes_set_x Topic (ESS
or DS) . . . . . . . . . . . . . . 157
15. Parameters of the volumes_set_x Topic
(SVC) . . . . . . . . . . . . . . 158
16. Parameters of the DP for Snapshot Devices
Target Volumes File for AIX LVM Mirrored
Environments Using an ESS or DS . . . . 177
17. Parameters of the DP for Snapshot Devices
Target Volumes File for AIX LVM Mirrored
Environments Using an SVC . . . . . . 178
18. Sample Backup Schedule Employing Multiple
Target Sets . . . . . . . . . . . . 219
19. Automated Target Set Selection . . . . . 225
20. Effective FLASHCOPY_TYPE Value
Determination . . . . . . . . . . . 227
21. Codes Returned by the DS Open API CIM
Agent . . . . . . . . . . . . . . 321
22. Codes Returned by CIM Agent for SVC 323
23. CIM Return Codes and Corresponding SAN
Volume Controller CLI Error Codes . . . . 324

Copyright IBM Corp. 2001, 2007 ix
||
||
||
x Data Protection for Snapshot Devices for mySAP Installation and Users Guide for DB2 UDB
Summary of Changes

Note
Please consult the README information and Release Notes (see Where to
Find More Information on page xiv) for the current status of support for
specific hardware and the availability of specific new functionality described
in this publication.
The previous edition of this manual was entitled Tivoli

Storage Manager for
Hardware: Data Protection for FlashCopy Devices Installation and Users Guide for DB2
UDB Version 5.3, SC33-8208-00.
With version 5.4.0, the title has been changed to employ Data Protection for Snapshot
Devices (abbreviated as DP for Snapshot Devices) as a generic term that covers the
following components offered for V5.4:
One of these components will be installed depending on the storage system in use
for the database files.
Information applying to a specific storage system type is indicated as applicable.
Additional changes to this manual include:
v Support for SAN-based IBM System Storage N series devices providing Network
Appliance (NetApp) technology. These devices have an inherent snapshot
capability that includes allocating the target disks. There is no requirement to
predefine and allocate these volumes as is the case for FlashCopy devices.
v Communication between the Common Information Model (CIM) Client and the
CIM Agent can now employ the Secure Sockets Layer (SSL) and HTTPS
protocol.
v The installation path has been changed to:
/usr/tivoli/tsm/acssap/db2/
v The interface via rexec between the production and backup systems has been
replaced by communications via TCP/IP. There is no longer a requirement to
run rexecd on the production system.
v Functions have been added to tdphdwdb2 to allow resuming a DB2 database at
the partition level and to restart a failed TSM backup on the backup system
without restarting a complete snapshot-type backup run. In the latter case, the
new profile parameter DB2_RESTART_TSM_BACKUP can be set to permit the
use of this function (the default setting is to prevent its use).
v An option has been added to the tdphdwdb2 'configure' function to use a
password input file, bypassing the password prompts.
v The 'password' function has been added to tdphdwdb2 to modify the password
for the DB2 or Copy Services user ID. This function also makes use of an
optional password input file.
v The PROLE_SERVICE_NAME parameter is now optional.

Copyright IBM Corp. 2001, 2007 xi
v The release notes previously provided as a file with each component are now
available in the Tivoli Information Center (see Where to Find More
Information on page xiv).
v AIX native multipathing I/O (MPIO) and SDDPCM are now supported.for the
SAN Volume Controller.
v This manual has been relocated from the product CDs to the new Quick Start
CD for Tivoli Storage Manager for Advanced Copy Services. It is also available
in the Tivoli Information Center in PDF and XHTML formats (see Where to
Find More Information on page xiv).
This revision also includes maintenance and editorial changes. Technical changes
or additions to the text and illustrations are indicated by a vertical bar to the left of
the change.
Summary of Changes

xii Data Protection for Snapshot Devices for mySAP Installation and Users Guide for DB2 UDB
Preface
Who Should Read This Document
This document is intended for system programmers and administrators who are
responsible for implementing a backup solution in a mySAP e-business solution
environment using DP for Snapshot Devices. It provides information to install,
configure, and administer DP for Snapshot Devices with DB2 Universal Database
(DB2

UDB).
In this publication, it is assumed that you have an understanding of the following:
v UNIX
operating system
v The IBM storage system used for your database:
TotalStorage
Enterprise Storage Server

(ESS) Model 800
TotalStorage Disk Storage Models DS6000 and DS8000
TotalStorage SAN Volume Controller (SVC)
IBM System Storage N series
v AIX operating system and its Logical Volume Manager (LVM)
v SAP database administration tools for DB2 UDB
v DB2 database administration
v Tivoli Storage Manager for Enterprise Resource Planning: Data Protection for
mySAP (DB2)
v Tivoli Storage Manager Backup-Archive Client
v Tivoli Storage Manager Application Program Interface (API)
v Common Information Model (CIM)
The following publications provide additional information:
Table 1. Related Publications
Title Order Number
Tivoli Storage Manager for AIX Administrators Guide V5.3 GC32-0768
Tivoli Storage Manager for AIX Administrators Reference V5.3 GC32-0769
Tivoli Storage Manager Messages V5.3 GC32-0767
Tivoli Storage Manager Using the Application Program Interface
V5.3
GC32-0793
Tivoli Storage Manager for UNIX and Linux Backup-Archive
Clients Installation and Users Guide V5.3
GC32-0789
Tivoli Storage Manager for Enterprise Resource Planning: Data
Protection for mySAP Installation and Users Guide for DB2
UDB
SC33-6341
BC SAP Database Administration: DB2 Available from SAP AG
Split Mirror Backup Procedure Available from SAP AG
R/3 Installation on UNIX DB2 Database Available from SAP AG
51013686
BC R/3 Database Guide: DB2 Universal Database for UNIX &
Windows
Available from SAP AG
mySAP.com Fundamentals of Database Layout (8/2000) Available from SAP AG

Copyright IBM Corp. 2001, 2007 xiii
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
||
||
||
||
|
|
|
|
|
|
|
|
|
|
||
||
||
|
|
|
|
||
Table 1. Related Publications (continued)
Title Order Number
Command Reference
IBM DB2 Universal Database V8.1 See npte below.
SC094828
Data Recovery and High Availability Guide and Reference
IBM DB2 Universal Database V8.1. See note beloe.
SC09-4831
IBM ESS and IBM DB2 UDB Working Together IBM Redbook
SG24-6262
R/3 Data Management Techniques Using TSM IBM Redbook
SG24-5743
IBM Total Storage Enterprise Storage Server: Implementing
CopyServices in an Open Environment
SG24-5757
IBM TotalStorage Enterprise Storage Server Command-Line
Interface Users Guide
SG26-7494
AIX 5L
5.3 Common Information Model Guide SC23-4942

The IBM TotalStorage DS6000 Series: Concepts and
Architecture, IBM Redbook
SG24-6471
The IBM TotalStorage DS8000 Series: Concepts and
Architecture, IBM Redbook
SG24-6452
IBM TotalStorage SAN Volume Controller: CIM Agent
Developers Reference
SC26-7545
IBM TotalStorage DS Open Application Programming Interface
Reference
GC35-0493
IBM TotalStorage SAN Volume Controller and SAN Integration
Server, IBM Redbook
SG24-6423
IBM TotalStorage SAN Volume Controller Planning Guide GA22-1052
IBM TotalStorage SAN Volume Controller Configuration Guide SC26-7543
IBM TotalStorage Multipath Subsystem Device Driver Users
Guide
SC30-4096
IBM TotalStorage DS6000 Introduction and Planning Guide GC26-7679
IBM TotalStorage DS6000 Messages Reference GC26-7682
IBM TotalStorage DS8000 Introduction and Planning Guide GC35-0495
IBM TotalStorage DS8000 Messages Reference GC26-7659
IBM System Storage N Series, IBM Redbook SG24-7129
IBM Tivoli Storage Manager for Advanced Copy Services, IBM
Redbook
SG24-7474

Note: Refer to the DB2 Web page for DB2 V9 documentation.
Where to Find More Information
For more information about DP for Snapshot Devices and the latest fixes, please
refer to the Web pages

Product
information:
http://www.ibm.com/software/tivoli/products/storage-mgr-advanced-copy-services/
Support: http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManagerforAdvancedCopyServices.html

xiv Data Protection for Snapshot Devices for mySAP Installation and Users Guide for DB2 UDB
|
||
|
|
|
|
|
|
||
|
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
||
|
|
|
||
||
||
||
||
|
|
|
|
|
Release Notes DP for FlashCopy Devices:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.itsmreadme.doc/relnote_acfmd540.html
DP for N Series Snapshot Devices:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.itsmreadme.doc/relnote_acnmd540.html
Each release note contains links to separate pages for various topics. In particular, the
Hardware/Software Requirements page has an attachment (Preinstallation Checklist in Microsoft
Word format) that lists the current hardware and software prerequisites.

Contents of the DP for Snapshot Devices Packages
The DP for Snapshot Devices installation packages are provided on a CD-ROM or
in a CD image downloadable via Passport Advantage. See the README
information on the CD and in the individual packages for the current software
status.
Supported Platforms
The following platforms are supported:
AIX 5.2 32/64 bit
AIX 5.3 32/64 bit
Naming Conventions
DP for Snapshot Devices is used in this document to refer to the TSM for ACS
component that supports the storage system on which the DB2 database is
installed.
Tivoli Storage Manager for Enterprise Resource Planning Data Protection for mySAP is
abbreviated in this document as DP for mySAP.
The following files are often referred to simply by their extensions:
v DP for Snapshot Devices profile (.fcs)
v DP for Snapshot Devices target volumes file (.fct)
v DP for Snapshot Devices configuration file (.fcp)
v DP for mySAP profile (.utl)
v DP for mySAP configuration file (.bki)
By convention, modified versions of these files to serve specific purposes are
distinguished by a suffix to the extension, such as .fcsc, and not to the base name.
The term hardware unit in this manual generally applies to an ESS or DS
configuration, but it should be understood to mean SVC cluster in the case of an
SVC and filer in the case of an N series device.
Support
See Appendix D, Support Information, on page 331 for general information
concerning provision of support by IBM.

Preface xv
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
xvi Data Protection for Snapshot Devices for mySAP Installation and Users Guide for DB2 UDB
Chapter 1. Introduction
DP for Snapshot Devices minimizes the impact on mySAP DB2 UDB database
servers while allowing automated database backups to the Tivoli Storage Manager
(TSM) Server. DP for Snapshot Devices off-loads the transfer of backup data from
the database server. The DB2 UDB database must reside on one of the supported
storage subsystems (seeStorage System Environment). DP for Snapshot Devices
provides options to implement high-efficiency backup and recovery of
business-critical databases while virtually eliminating backup-related downtime or
user disruption on the production host.
The FlashCopy
Restore (FlashBack Restore) functionality of DP for Snapshot

Devices provides a fully automated tool for a fast restore of business-critical
databases. DP for Snapshot Devices exploits the Copy Services functionality (as
implemented for the storage system) for both FlashCopy Backup and FlashCopy
Restore.
The additional capability for FlashCopy Cloning of mySAP databases is provided
by a complementary Service Offering entitled FlashCopy Cloning. FlashCopy
Cloning is based on DP for Snapshot Devices. It produces a clone of the source
(production) DB on a clone target system by processing a FlashCopy disk backup
to become a separate DB instance. In addition, FlashCopy Cloning provides a
collection of sample scripts for basic postprocessing functions for further
automating at least a portion of the cloning process. For more information on
FlashCopy Cloning, see
http://www.ibm.com/de/entwicklung/esd
Understanding DP for Snapshot Devices
This section describes the operating environment and functions of DP for Snapshot
Devices.
Storage System Environment
DP for Snapshot Devices supports the following IBM systems:
v Enterprise Storage Server (ESS) Model 800
v Disk Storage DS6000 series subsystem
v Disk Storage DS8000 series subsystem
v SAN Volume Controller (SAN VC, or simply SVC)
v System Storage N series
One (and only one) of these systems must be configured for DP for Snapshot
Devices, and the database must reside fully on this system. However, the use of an
SVC allows it to manage one or more ESS or DS systems (as well as non-IBM
storage hardware) within the framework of the SVC configuration.
In the light of the similar point-in-time copy functionality (FlashCopy or NetApp
snapshot) provided by these storage-system options, this manual provides common
documentation for the following software components offered for V5.4:

Copyright IBM Corp. 2001, 2007 1
|
|
|
|
|
|
|
|
|
|
While only one of these packages will be installed, depending on the actual storage
environment for the database, they share major portions of code and have similar
user interfaces. For this reason, the former generic software designation (Data
Protection for FlashCopy Devices for mySAP, abbreviated as DP for FC) has, for the
purposes of this document, now been replaced by the generic term Data Protection
for Snapshot Devices, abbreviated as DP for Snapshot Devices. This new designation
applies to both of the above packages.
Note: Any occurrence of the terms FlashCopy or FlashBack Restore in the sections of
this book applying to N series devices should be interpreted as meaning the
snapshot creation or restore function of these devices. Also, multiple target
sets in an N series context are referred to as frequent snapshots.
Enterprise Storage Server (ESS)
The IBM TotalStorage Enterprise Storage Server (ESS) architecture provides
unmatchable functions for all the IBM family of e-business servers, and also for the
non-IBM (that is, Intel
-based and UNIX-based) families of servers. Across all of

these environments, the ESS features unique capabilities that allow it to meet the
most demanding requirements of performance, capacity, and data availability that
the computing business may require. The move to on demand business presents
companies with both extraordinary opportunities and significant challenges.
Consequently, companies also face an increase in critical requirements for more
information that is universally available online, around the clock, every day of the
year.
To meet the requirements of on demand business, where massive swings in the
demands placed on your systems are common, and continuous operation is
imperative, you need very high-performance and intelligent storage technologies
and systems, which can support any server application in your business, today and
into the future. The IBM TotalStorage Enterprise Storage Server has set new
standards in function, performance, and scalability in these most challenging
environments.
Prior versions of DP for Snapshot Devices (known as Data Protection for IBM ESS
for mySAP, or DP for ESS) supported only the ESS.
Disk Storage Subsystem (DS)
The IBM TotalStorage Disk Storage (DS) family is a new Enterprise Storage Server
generation with a new architecture and enhanced performance and features. The
most recent members of the DS family, the DS6000 and DS8000, give customers the
freedom to choose the right combination of solutions for their current needs and
the flexibility to help their infrastructure evolve as their needs change. The
TotalStorage DS family is designed to offer high availability, multiplatform support
and simplified management tools, all to help the customers to cost effectively
adjust to an on demand world.
The IBM TotalStorage DS Family, and the DS6000 and DS8000 series as members of
this family, supports enterprise-class data backup and disaster recovery
capabilities. As part of the IBM TotalStorage Resiliency Family of software, IBM
TotalStorage FlashCopy point-in-time copy capabilities back up data in the
background, while allowing users nearly instant access to information on both the
source and target volumes.
Note: The DS4000 is not supported.
Introduction

2 Data Protection for Snapshot Devices for mySAP Installation and Users Guide for DB2 UDB
|
|
|
|
|
|
|
|
|
|
|
|
DS6000: The DS6000 series offers an entirely new era in price, performance and
scalability. Now for the first time customers have the option for a midrange priced
storage subsystem with all the features and functions of an enterprise storage
subsystem. Some customers do not like to put large capacities of storage behind
one storage controller. In particular, the controller part of a high end storage
system makes it expensive. Now you have the option of choice, you can build very
cost efficient storage systems by adding expansion enclosures to the DS6800
controller, but since the DS6800 controller is not really expensive, you can also
grow horizontally by adding other DS6800 controllers. You have the option to
easily grow into the DS8000 series by adding DS8000 systems to your environment
or by replacing DS6000 systems.
DS8000: The IBM TotalStorage DS8000 is a new high-performance, high-capacity
series of disk storage systems. It offers balanced performance, which is up to 6
times higher than the ESS Model 800. The capacity scales linearly from 1.1 TB up
to 192 TB. With the implementation of the POWER5
Server Technology in the

DS8000, it is possible to create storage system logical partitions (LPARs) that can be
used for completely separate production, test, or other unique storage
environments.
The DS8000 series is designed for 24x7 environments in terms of availability, and it
still provides the industry leading advanced copy services to ensure business
continuity.
Note: FlashCopy backups taken from an ESS configuration cannot be restored
directly to a DS environment. Restore from a TSM backup, or an
intermediate migration from ESS to DS, is required.
SAN Volume Controller (SVC)
The SVC is a virtualization layer that allows addressing a heterogeneous
configuration of IBM and non-IBM open-system storage devices through one
interface to an open-systems host.
In a conventional SAN, the logical unit numbers (LUNs) that are defined within
the storage subsystem are directly presented to the host or hosts. Symmetrical
virtualization, also known as block aggregation or in-band virtualization,
essentially means having an appliance in the data path that can take physical
storage from one or more storage subsystems and offer it to hosts in the form of a
virtual disk.
The SAN Volume Controller provides symmetric virtualization by creating a pool
of managed disks from the attached storage subsystems, which are then mapped to
a set of virtual disks for use by attached host computer systems. System
administrators can view and access a common pool of storage on the SAN, which
enables them to use storage resources more efficiently and provides a common
base for advanced functions.
With SAN Volume Controller support, TSM for ACS offers three major customer
benefits:
v price/performance optimization of storage used for FlashCopy solutions
v removal of restrictions caused by database layout or subsystem capacity
limitations
v accommodation of non-IBM storage subsystems into a homogeneous FlashCopy
operation.
Introduction
Chapter 1. Introduction 3
Limitations:
v The SVC does not support incremental FlashCopy. Specification of INCR in the
FLASHCOPY_TYPE parameter or the -C option of the user interface will result
in an error message.
v While the SVC does not directly support multiple target sets, DP for Snapshot
Devices provides this support within the limitations of the SVC. The FlashCopy
agent that monitors the background copy processes will withdraw the
FlashCopy relationships when the processes complete.
v A maximum of 512 virtual disks per host per SVC cluster are supported.
v If the configuration includes both SVC vdisks and native ESS LUNs, SDD limits
the number of vpaths: on AIX 5.2, SDD allows a maximum of 1200 ESS vpaths
and 512 SVC vpaths to be configured.
v Concurrent I/O and download of DS4000 (FAStT) drive and ESM (EXP
100/500/700) microcode is not supported.
v The DS4000 (FAStT) capability of dynamically expanding controller LUNs is not
supported by the SVC.
v When using any supported back end storage for the SVC in single port attach
mode, the following limitations apply:
This type of storage must not be used for quorum disks.
This type of storage must not be used as a PPRC target and should not be
used for active production data.
The recommended use for this type of storage is as a Flash Copy target and
for non-mission critical data.
For restrictions related to non-IBM hardware, see the link below.
Aside from these exceptions, the full FlashCopy functionality (FlashCopy backup
and FlashBack restore) provided for the ESS and DS subsystems is also available
with an SVC configuration. With the SVC, a FlashCopy can be performed from one
storage subsystem to another and permits moving the production database from
hardware provided by one vendor to hardware provided by another vendor. In
addition, multiple target sets are also supported for an SVC configuration.
Back-end storage:
The SVC allows a great deal of flexibility in creating virtual disks and mapping
these to the back end storage. It is important that sufficient back end storage be
configured to support the anticipated load. The list of the SVC supported storage
and associated firmware levels is very large and detailed. Detailed information can
be found in the Web under:
http://www-1.ibm.com/servers/storage/support/software/sanvc/
IBM System Storage N Series
The IBM System Storage N series implements a Network Appliance (NetApp)
storage system. Currently, the models N3700, N5000, and N7000 are available. For
details, refer to IBM Redbook IBM System Storage N Series (see Table 1 on page xiii).
A Network Appliance storage system, also called a filer, offers database
administrators many advantages in terms of backup and recovery. NetApp
snapshot technology, combined with the capabilities of TSM for Advanced Copy
Services (TSM for ACS) for integration and management of point-in-time
techniques, can dramatically optimize the application server backup/recovery
activities. Handling multiple on-line NetApp snapshot images allows the system
administrator to restore file systems without the necessity of restoring from tape in
Introduction

|
|
|
|
|
|
|
|
|
|
|
many circumstances. Backup and recovery performance is dramatically improved
over that of conventional local disk, improving mean time to recovery (MTTR)
intervals.
A NetApp snapshot is a frozen, read-only copy of a volume that provides easy
access to old versions of files, directory hierarchies, and/or LUNs (logical unit
numbers). A snapshot is retained locally. A volume represents an entire file system.
The filer uses a copy-on-write technique to create snapshots very quickly without
consuming any disk space. Only as blocks in the active file system are modified
and written to new locations on disk does the snapshot begin to consume extra
space.
NetApp snapshot technology is a feature of the WAFL (Write Anywhere File
Layout) storage virtualization technology that is part of Data ONTAP, the
microkernel that is delivered with each NetApp storage system. A NetApp
snapshot takes only a few seconds to createtypically less than one second,
regardless of the size of the volume or the level of activity on the NetApp storage
system. After a snapshot copy has been created, changes to data objects are
reflected in updates to the current version of the objects, as if snapshot copies did
not exist. Meanwhile, the snapshot version of the data remains completely stable.
Since a iNetApp snapshotncurs no performance overhead; users can comfortably
store up to 255 snapshot copies per WAFL volume, all of which are accessible as
read-only and online versions of the data.
Unlike the FlashCopy devices, which require the target disks to be predefined, the
N series creates the target disks for a copy operation on request. N series volumes
are conventionally referred to as flexible volumes, and the target volumes are clones
of the source, or parent, volumes. A clone is a flexible volume that is a writable
snapshot of another volume. Initially, the clone and its parent share the same
storage. Only as one volume or the other changes is more storage space consumed.
The request to create clones is performed by the Hardware Common Interface
(HCI) for N series.
By coupling Data Protection for Snapshot Devices and NetApp snapshot, the
customer will benefit by:
v the ability to create frequent snapshot backups of the volumes constituting the
SAP database
v the ability to have as many snapshots as NetApp can support (up to 256 per
NetApp volume)
v the ability to utilize the NetApp function of reverting to a particular snapshot.
Restrictions:: The following restrictions apply to use of N series devices in this
release of Data Protection for Snapshot Devices:
v The N series hardware must reside in a SAN environment, in which the filer
exports data as blocks (LUNs) via FCP or iSCSI. The LUNs can then be used by
the AIX LVM.
v LVM mirroring is not supported by DP for Snapshot Devices on N series
hardware.
v The database must reside within one filer (single cluster).
v A snaprestore license is required to perform a snapshot restore via DP for
Snapshot Devices.
v The minimum DATA ONTAP version is 7g.
Introduction
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v NetApp allows storage overallocation, such that the creation of a snapshot can
potentially disrupt production operations in case of out-of-space conditions.
v When restoring a snapshot, all snapshots taken subsequent to the one restored
are lost
v The restore will fail if there is a clone associated with a newer snapshot that
prevents this snapshot from being destroyed.
v Incremental backup is not supported.
v The capability for multiple target sets is referred to in the context of frequent
snapshots.
v The JFS2 file system is required for N series devices. Only this file system
supports the use of the freeze and thaw functions required for the snapshot
process.
Operating Environment
The operating environment consists of the DB2 RDBMS executing on an AIX server
attached to one of the supported storage systems. This AIX server is the production
system. Another AIX server, the backup system, is also attached to the same storage
system to back up FlashCopy or snapshot hcopies of the production system to the
TSM server. This is done by the concerted action of the two DP for Snapshot
Devices components (tdphdwdb2/splitint) and Data Protection for mySAP (shared
vendor library and prole).
DP for Snapshot Devices requires DP for mySAP to perform the actual backup or
restore to or from the TSM server.
The following figure depicts the hardware and software environment in which DP
for Snapshot Devices operates.

Introduction

|
|
|
|
|
|
|
|
|
|
|
|
The products and hardware elements shown in Figure 1 have to be available on the
production and backup systems.
Prior to any involvement of DP for Snapshot Devices, the production system will
have access to the DB2 database running the mySAP application transactions. The
backup system at this time will have the software products installed but no access
to any DB2 database files.
DB2 Backup Options with Copy Services

Figure 1. Overall DP for Snapshot Devices Environment
Introduction
When you create a FlashCopy (locally or remotely), the storage system creates a
logical copy of a logical disk (or set of disks) over a window of time without
freezing or inhibiting application changes to those disks, and therefore requires
proper synchronization with the database system. DB2 provides capabilities to
ensure this synchronization.
Two commands are available that can be used to facilitate hot backups of DB2.
When the following command is issued, database writes are prevented, but the
database remains online and available for reads:
db2 set write suspend for database
In an SAP mySAP e-business solution, the hourglass might be displayed for
SAPGUI users while the database is in write-suspend mode. Once the source
database has been placed in a write-suspended state, a FlashCopy backup can be
started. The source database can then be fully enabled again by issuing the
command:
db2 set write resume for database
Any changes directed toward the data during the write suspend are then applied
and all transactions from SAPGUI users will continue.
In theory, this gives you several permutations to choose from when implementing
a backup strategy:
v Hot or cold (online or offline) backups of DB2
v Full (background) or nocopy versions of a local FlashCopy
v Use of PPRC with or without a remote FlashCopy
v Full, incremental, or nocopy versions of a remote FlashCopy
Note: DP for Snapshot Devices supports only the last strategy of full, incremental,
or nocopy versions of a remote FlashCopy.
The capability is provided to back up a database from a FlashCopy. This makes it
possible to offload DB2 backups from the production system to the backup system,
thus not impacting the production system at all except for the amount of time
required to split a copy of the database.
It is possible to rename a FlashCopy of a database to a different database name
with different mount points for the containers. The intent of this feature is to
permit users to mount a FlashCopy version of the database on the same host as the
original database, thus eliminating the need for a second host computer. This
feature is not implemented in DP for Snapshot Devices, however.
DB2 Backups
Using any of the strategies mentioned in the previous section, a DB2 backup can
be taken of the version of the database resulting from the FlashCopy.
There is a limitation that all tablespaces (including temporary tablespaces) must
use DMS containers only.
Outlined below are the steps required for creating a backup from a FlashCopy
backup of a database:
1. Attach the database that was the object of the FlashCopy to another host.
2. Catalog the database.
Introduction

3. Issue the following commands:
db2start
db2inidb database_name AS STANDBY
This initializes the database and puts the copy of the database in a rollforward
pending mode, creating a hot standby database.

4. db2 backup db <SID> ...
Immediately following the db2inidb call, a full DB2 database backup can be taken.
Currently, only full database backups are supported. Since DB2 is unable to
determine whether there was any activity on the original database at the time of
the split, this backup will essentially be equivalent to a DB2 online backup
although the online keyword is not used. This backup can later be used to
restore the production database in case of a failure.
This database subjected to a FlashCopy will remain in rollforward pending mode
and can sequentially apply the logs which were taken from the primary database
after the FlashCopy was created, leaving it in hot standby mode. There are
several methods available to get copies of the log files to the backup system,
including:
v Use PPRC to mirror the log files
v Use the user exit on the backup system to retrieve log files from the production
systems archive directory
v Use the user exit to send a copy of the log files to the backup system
This feature of a hot standby database is not implemented in DP for Snapshot
Devices.
Role of tdphdwdb2
tdphdwdb2 can be called to
v perform a backup of a FlashCopy to TSM
v perform a restore from TSM of a previous FlashCopy Backup and perform a
rollforward recovery
v perform a FlashCopy without a backup
v perform a FlashCopy Restore (FlashBack Restore) of a previous FlashCopy
Backup and perform a rollforward recovery
v perform an online or offline backup to TSM on the production system without
FlashCopy
v perform a restore from TSM and perform a rollforward recovery
Once tdphdwdb2 (on the backup system) has been started with the parameters to
perform a backup of a FlashCopy, it will first interact with the DB2 database on
the production system via DB2 remote connect to get the DB2 database
information. Then it calls splitint, which, with its components (CORE, HCI, and
LVM), will ensure that tdphdwdb2 will get all the volumes (target volumes) with the
files tdphdwdb2 needs to run a full DB2 database backup.
When performing the backup, tdphdwdb2 will call the db2 backup command,
which calls the vendor library DP for mySAP to perform the actual backup.
tdphdwdb2 can be executed on the command line but normally runs in a batch job.
Role of splitint
Introduction
splitint can be called for FlashCopy operations by tdphdwdb2; splitint is
structured into 3 component layers: CORE, LVM, and HCI.
The CORE component has the following tasks:
v acts as a direct interface to tdphdwdb2
v reads/checks the DP for Snapshot Devices profile
v performs environment checks
v performs housekeeping functions for
handling temporary and permanent files containing information for the other
components used in the various stages in one functional run or in subsequent
functional runs (these files will reside in an NFS directory)
creating/deleting log and trace files (these files will reside in an NFS
directory)
v controls the proper sequence of functions (flashcopy, unmount, and withdraw);
for details, see Backup and Restore Cycles on page 134
v when called with the unmount and/or withdraw function, gathers
information such as backup ID that a previous run of DP for mySAP has
produced
v interacts with the LVM and HCI components to exchange information
v runs and controls a splitint instance on the production system whenever a
FlashCopy is required.
The HCI (Hardware Common Interface) component has the following tasks:
v interacts with the primary Copy Services server or SVC master console via a
TCP connection, using the Common Information Model (CIM) interface, to
gather information about source and target volumes
issue the FlashCopy and withdraw requests to the primary Copy Services
server or SVC master console
HCI uses the client component of the Pegasus CIM Server package
1
(referred to
in the DP for Snapshot Devices environment as the CIM Client) to contact the
CIM Object Manager (CIMOM) on the ESS or DS CopyServices server or the
SVC master console. For more information, see Understanding the Hardware
Interface and Common Information Model (CIM) on page 26.
v returns the status of its performed tasks to CORE for controlling and reporting
purposes.
The LVM component performs the following tasks
v interacts with the operating system to gather information about the volumes and
file systems of the DB2 database files planned for use in a later step by
tdphdwdb2 for which backup is requested
v provides/removes system resources (like volume groups and file systems) on the
backup system
after a FlashCopy has been performed on the production system
prior to the withdraw of volumes
v provides/removes system resources (like volume groups and file systems) on the
production system in case of a FlashCopy Restore
Use of TCP/IP
1. Provided by the OpenPegasus project. Must be installed by the user.
Introduction

|
|
TCP/IP will be used by
v splitint when
it is running a request from the backup system on the production system to
perform the actual FlashCopy
creating/reading/writing its log, trace, and temporary files in an NFS
directory
starting or monitoring the FlashCopy
v tdphdwdb2 when
creating/writing its run log files (normally in the /db2/<SID>/dbs/logtraces
directory)
reading its profile (normally located in the /db2/<SID>/dbs directory)
getting information about tablespace containers of the DB2 database on the
production system
communication via the TCP/IP socket layer between the backup and
production systems is used (to suspend/resume the production database or in
case of EEE to synchronize all EEE partitions)
v DP for mySAP when reading/updating its profile (.utl) and configuration files
(.bki).
At product installation time, all of these files must reside in NFS directories so that
DP for mySAP and DP for Snapshot Devices can access the files depending on the
function they must perform at the time:
v tdphdwdb2 when restoring/recovering the database files from the TSM server to
the production system; in the interest of a fast restore, high-speed connections
are required
v brarchive when backing up/restoring the log files between the production
system and TSM server.
See Software Requirements on page 45 for a detailed list of applications required
by DP for Snapshot Devices.
Functions of DP for Snapshot Devices (tdphdwdb2/splitint)
This section provides an overview of the functions of the DP for Snapshot Devices
components (tdphdwdb2/splitint). DP for Snapshot Devices provides certain
inherent functions, referred to as active functions. As an agent operating in
conjunction with DB2 and DP for mySAP, it also provides additional, passive
functions:
v Active functions
High-availability DB2 database backup using FlashCopy
High-availability DB2 database restore using FlashCopy
Integration with DB2 functions to support running Copy Services functions
(FlashCopy, withdraw, etc.)
Keep the progress of the DP for Snapshot Devices functions in a
housekeeping file to monitor the proper sequential usage of the functions
Send information to the DP for mySAP Administration Assistant while DP for
Snapshot Devices is running
v Passive functions
Monitor a running FlashCopy process (FlashCopy with COPY or INCR
option)
Seamless augmentation of the functions of DP for mySAP.
Introduction
|
|
Centrally administered and scheduled backup operations
Integration with Tivoli Storage Manager Media Management functions
High-Availability DB2 Database Backup Using FlashCopy
DP for Snapshot Devices accomplishes high-availability backups of a DB2 database
implemented on FlashCopy devices.
DP for Snapshot Devices, a co-product of DP for mySAP, integrates with the
FlashCopy volumes to allow the high-performance, database-aware FlashCopy
backups of DB2 databases on a backup system machine while the production
application remains online and fully available to users. Only when performing the
FlashCopy of all volumes involved, DB2 suspends all write activity on the
production database. Reading from the database is still possible.
While DP for Snapshot Devices initiates the FlashCopy operation, creating target
volumes from the source volumes of the production database and making target
volumes and file systems available on the backup system machine, DP for mySAP
can back up the FlashCopy volumes there. Because the backup operation is
conducted from the disk copy (target volumes) produced by FlashCopy
2
, most
processing occurs on the backup system. As a result, the inaccessibility of the
production database is minimized and the production host continues to dedicate
processor time to the production database. This greatly reduces any performance
impact on the production database server.
Several disk copy backup sets (one set per backup run) can be created and kept for
restore purposes (for details, see Chapter 10, Multiple Backup Generations (Target
Sets) on Disk, on page 219).
The DP for Snapshot Devices program splitint works on requests
(flashcopy/withdraw) from tdphdwdb2. The actual backup is done by DB2 via DP
for mySAP, again on the request (db2 backup) of tdphdwdb2.
In the mySAP documentation, the term split-mirror backup is used to request an
image disk copy within a storage subsystem, which can later be used for the back
up as described above.
Should a restore/recovery be required, this must be done on the production
system with the DP for Snapshot Devices program tdphdwdb2. In case of restore
from TSM, tdphdwdb2 will call DP for mySAP to restore the database. After
finishing the restore, it will start the rollforward recovery. In case of FlashCopy
Restore, tdphdwdb2 will call splitint to initiate the FlashCopy and will then start
the rollforward recovery.
High-Availability DB2 Database Restore Using FlashCopy
DP for Snapshot Devices accomplishes high-availability restores of a DB2 database
implemented on FlashCopy devices. The program uses the volumes of a previous
FlashCopy Backup to allow the high-performance, database-aware FlashCopy
Restore of DB2 databases on the production system in case of production system
failure.
While DP for Snapshot Devices initiates the FlashCopy Restore operation, the
production system will be cleaned up (all DB file systems will be unmounted, all
DB volume groups will be exported). After the cleanup, splitint will initiate the
2. In the SAP documentation, this copy is referred to as a split-mirror copy.
Introduction

FlashCopy from the target volumes (from a previously taken FlashCopy Backup) to
the production system source volumes. Then all DB volume groups will be
imported and all DB file systems will be mounted again. This greatly reduces the
downtime of the production database server.
Depending on the storage system (and possibly the microcode level), a FlashCopy
of type COPY or INCR (incremental) will be used for the restore (see Installation
Requirements on page 44 for details).
Incremental FlashCopy Backup and Restore
DP for Snapshot Devices allows the point-in-time copy of a DB2 database
implemented on directly attached ESS or DS systems using the Incremental
FlashCopy feature. This feature makes it possible to perform a background copy
between the source and target volumes without having to copy all the tracks in the
process. This results in improved performance for the DB2 Servers that are
configured to the storage system. Incremental FlashCopy applies only to the
storage hardware level copy (the FlashCopy made between the source and target
volumes). It does not apply to the application level copy (the backup copy of the
database to the Tivoli Storage Manager Server). An incremental FlashCopy cannot
be performed when the entire database is backed up to the Tivoli Storage Manager
Server.
An incremental FlashCopy backup is invoked with the value INCR for the
FLASHCOPY_TYPE in either the DP for Snapshot Devices profile (.fcs) or with the
copy parameter -C in the tdphdwdb2 command line.
Note: Incremental FlashCopy is not available with the SAN Volume Controller,
even if the actual hardware in the SVC configuration (an ESS, for example)
would support this function if connected directly. The FLASHCOPY_TYPE
parameter in the DP for Snapshot Devices profile (.fcs) or the -C option of
the user interface cannot have the value INCR. The same is true for N series
devices (only COPY is supported).
Integration with DB2 Functions
The major functionality of DP for Snapshot Devices is to enhance the database
backup and restore processes by embedding the FlashCopy capabilities into those
processes. In order to utilize those capabilities DP for Snapshot Devices needs a
sequence of tasks to put in place which are described next.
FlashCopy Backup: DP for Snapshot Devices provides a set of necessary
functions to prepare the environment on the backup host for a backup of the
database of the production system. Such a backup must be started on the backup
system by using tdphdwdb2.
DP for Snapshot Devices uses the following features for supporting backups from
image disk copies:
db2 write suspend / db2 write resume
and
db2inidb as standby
The following figure depicts the production/backup system interactions in the DP
for Snapshot Devices environment:

Introduction
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 2. Flow of FlashCopy/Backup/Withdraw Operations
Introduction

A complete cycle of the tdphdwdb2 backup request, customized to run FlashCopy
backups, comprises the following steps:
1. Using a DB2 client for a DB2 remote connection, determine all container files
that make up the DB2 database on the production system, put the names into a
file list and add the local database directory to this file list.
2. Get volume and file system information from the list created in step 1 of the
DP for Snapshot Devices program splitint. In order to do this, the work items
listed below will be done:
a. The following steps are performed by splitint on the backup system:
v read the DP for Snapshot Devices profile
v check whether the latest backup cycle has reached a state which allows a
new backup cycle to be started; at least an unmount state is required. If
not, force termination of tdphdwdb2 (RC > 0).
v check the RSI (Restore Status Indicator); if the value is
RSI_START, then terminate (a FlashCopy of a previous FlashBack
Restore has not yet completed)
RSI_INVALID, then issue a warning, reset the RSI and continue
anything else, continue
v create a new backup cycle
v start a splitint on the production system with the list received from
tdphdwdb2 and wait until splitint has finished on the production system.
b. The following steps are now performed by splitint on the production
system:
v for each file in the file list, determine its corresponding disks (source
volumes), via DP for Snapshot Devices LVM routines.
v look for a suitable target volume (specified in the DP for Snapshot
Devices target volumes file). If the size of the source volume does not
match its counterpart target volume, the FlashCopy request to the
primary Copy Services server located within a cluster will not be
initiated.
v if more than one set of target volumes has been specified, select one
which is eligible, depending on the parameters specified with the backup
request (for details on the use of multiple target sets, see Chapter 10,
Multiple Backup Generations (Target Sets) on Disk, on page 219).
v for each source volume, look for a suitable target volume (specified in the
DP for Snapshot Devices profile). If the size of the source volume does
not match a counterpart target volume, the FlashCopy request to the
primary Copy Services server located within a cluster will not be
initiated.
v create an exchange file (with volume/mountpoint information), which is
used later on the backup system
v terminate execution on the production system.
3. Set the DB2 database on the production system in the write suspend mode.
4. Request the FlashCopy of the database volumes (source/target) by calling the
DP for Snapshot Devices program splitint.
a. The following steps are performed by splitint on the production system:
v reset the BSI (Backup Status Indicator) to BSI_START
v prior to the FlashCopy, flush buffered data
3. The SAP documentation refers to this using the generalized term split-mirror.
Introduction
|
|
v set the current backup cycle to the FlashCopy state
v generate, from the database volumes of the production system, an image
copy
3
from the source to the target volumes
v terminate execution on the production system
b. Only if FLASHCOPY_TYPE is set to INCR or COPY within the DP for
Snapshot Devices profile, initiate the FlashCopy agent on the backup system
to monitor the FlashCopy progress periodically in the storage system and
record the result in the FlashCopy agent log file. More information about
the FlashCopy agent and the BSI can be found in Backup and Restore
Cycles on page 134.
5. Set the DB2 database on the production system in the write resume mode. The
production system is now operational. Check the RC for 0 and terminate
otherwise.
6. Mount the disks (target volumes) on the backup system after an image copy
(FlashCopy) is available with the following actions:
v check whether the actions on the production system were successful. If not,
force termination of tdphdwdb2 (RC > 0)
v evaluate the exchange file and, based on the information found therein,
import volume groups, run fsck, and mount file systems
v set the current backup cycle entry to the mount state (PSI_MOUNT_DONE).
v return control to tdphdwdb2 with RC 0 if the FlashCopy/mount was
successful
7. Perform the backup of the DB2 database to the TSM Server with the db2
backup command via DP for mySAP on the backup system.
8. Request splitint to withdraw all FlashCopy source/target relationships.
Note: This step will be done if the backup function of the DP for Snapshot
Devices program tdphdwdb2 is used, which will usually be the case. The
step is useful to
v first unmount all file systems and export volume groups
v run a withdraw request to the primary Copy Services server located
within a cluster to withdraw the source/target volume relationships.
In order to keep the target volumes
4
available as a disk backup as long
as possible (FLASHCOPY_TYPE is INCR or COPY), the withdrawal part
of this step (releasing resources) must be skipped by using the unmount
and nowithdraw parameters of tdphdwdb2 (with the backup function). If
the step is omitted entirely, tdphdwdb2 must be called with the unmount
function prior to the next tdphdwdb2 FlashCopy Backup run, in the case
of a FLASHCOPY_TYPE of INCR or COPY, or with the withdraw
function in the case of NOCOPY.
The status of the current backup cycle will be set to PSI_UNMOUNT_DONE or
PSI_WITHDRAW_DONE.
FlashBack Restore: DP for Snapshot Devices provides the capability to restore
target volumes, created in the FlashCopy Backup, to the original source volumes.
This is referred to as FlashBack Restore.
In contrast to the FlashCopy Backup, all database restore activities with DP for
Snapshot Devices need to be started on the production system.
4. This requires the FlashCopy request to have been performed with the INCR or COPY option (see the DP for Snapshot Devices
profile).
Introduction

When DP for Snapshot Devices is called for a restore, its two components
tdphdwdb2 and splitint interactively work together in order to
v provide information as to which backup levels are available for a restore
v prompt the administrator to determine
which backup level and which type (TSM or FlashCopy) - if available - to
select for a restore
how far to recover the database
v restore and recover, based upon the values the administrator entered when
prompted.
A backup level will only be shown by DP for Snapshot Devices as an available
FlashCopy type if all of the following conditions exist:
v the backup was done via DP for Snapshot Devices using FlashCopy Backup
v the FlashCopy Backup was done with the DP for Snapshot Devices profile
parameter:
FLASHCOPY_TYPE COPY or INCR
v the BSI (backup status indicator) shows a value BSI_DISKONLY or
BSI_DISKANDTAPE, which will be set in the FlashCopy agent initiated as described
in step 4b on page 16. More information about the BSI and the FlashCopy agent
can be found in Backup and Restore Cycles on page 134.
Note: Even if the DP for Snapshot Devices backup run has already completed
successfully after being started with either
tdphdwdb2 -f backup -t nowithdraw flashcopy or
tdphdwdb2 -f flashcopy
a FlashBack Restore might not yet be possible. This is because the
background copy process initiated for all volumes is still running and
thus the FlashCopy agent (see 4b on page 16) could not set the BSI to one
of the two required values.
Only FlashCopy backups of a database are used in a FlashBack Restore.
The following figure depicts the production system interactions in the DP for
Snapshot Devices environment:

Introduction
Once a FlashCopy type backup of the database has been selected on the
production system by the administrator for a restore, tdphdwdb2 performs the
following tasks as they are depicted in Figure 3.
1. Stop the database
2. Call splitint with its flashback function; splitint will
a. perform some checks against the production system environment, display
information about the file systems involved and issue the break message
IDS1084I to allow either
v stopping before applying any changes to the production system or
v continuing to run with no other intervention possibility up to step 3c
splitint will check:
v the RSI (Restore Status Indicator) for valid values. The administrator will
be informed with message IDS1089I in case a previous FlashBack Restore
left the system in a state where the administrator needs to decide to
continue or to stop the newly started FlashBack Restore, depending on
the state.
Note: For details, see When Not to Use FlashBack Restore on page 86
and FlashBack Restore Limitations on page 87.

Figure 3. Production System Interactions in the DP for Snapshot Devices Environment:
Introduction

v whether all source volumes used in the FlashCopy Backup are still
assigned to the production system. Although it is unlikely that they were
unassigned and given to another system, splitint will check and
terminate if the administrator cleaned up the production system at the
AIX disk storage management level (AIX device and vpath removed). If
he failed to do the cleanup, splitint cannot detect this unlikely change
and will fail in step 2c, leaving the production system in a damaged state
that cannot be fixed by splitint as long the relevant source volume is not
reassigned to the production system and can be used there.
Note: For details, see When Not to Use FlashBack Restore on page 86
and FlashBack Restore Limitations on page 87.
Next, splitint issues the break message IDS1084I. This allows the
administrator to enter
v cont to continue with step 2b up to step 3c (next break message)
v stop to terminate the FlashBack Restore
The decision should be based on the information displayed up to this point
(or written to the restore log).
Prior to this break message splitint displays
v the currently visible file systems on the volume groups which were
backed up, via message EEP0293I
v the file systems which will be restored, via message EEP0294I; these are
the file systems it had backed up with the FlashCopy function and that
will be made available again when running step 2c) and 2d) of the
FlashCopy Restore (see below)
If changes to the storage structure of the DB volume groups have been
applied since the FlashCopy Backup, the administrator might be required to
redo those changes as discussed below. Possible storage structure changes
are
v adding/removing a volume to/from a VG (including unassigning the
volume)
v creating/removing file systems (to add/drop tablespaces)
v extending file systems (e.g. to add new tablespaces)
The administrator must make his decision (for a cont or stop reply) based
on the requirement that
v all source /target volumes used in the FlashCopy Backup still be
available and not in use elsewhere (see When Not to Use FlashBack
Restore on page 86 and FlashBack Restore Limitations on page 87).
v resources (file systems and the underlying LVs/VGs/volumes) be
available for the DB at a later point in time (step 3d) during the
rollforward recovery; this recovery will be done as specified within the
menu when the FlashBack Restore was started ; in step 3c, a breakpoint
message (IDS2522I) will allow the administrator to manually perform
reasonable AIX disk storage management activities after step 2d has been
executed.
The cont reply can be given:
v if no changes to the file systems were done and the file systems and sizes
listed under EEP0293I and EEP0294I are therefore the same (the normal
restore situation)
v if tablespaces in new or extended file systems were created; before the
next break message (see step 3c) has been answered to continue, in order
Introduction
to start with the rollforward recovery, all AIX definitions must be
manually redone as they were after the FlashCopy Backup
v if system resources (file systems and the underlying LVs/volume(s) have
been removed, but the volume(s) they resided on are still assigned to the
production system and can still be used there; after the FlashBack
Restore, the system resources will appear as they were at FlashCopy
Backup time.
The stop reply must given if the source volumes on which a previously
available file system (listed under EEP0294) was allocated
v are already in use in another VG (which was not a VG of the DB backup)
or
v have been assigned to and are being used in another system.
The only way to use the FlashBack Restore is to make all the original source
volumes available to the production system again. Make sure that once they
are assigned back to the production system they are not used in another VG
when running the FlashBack Restore; the FlashCopy in step 2c would fail,
leaving behind an unusable AIX disk storage management environment.
b. disable production system resources
v unmount the file systems making up the database
v vary off the VGs of the database
v export the VGs of the database
Note: Only those VGs that made up the database at FlashCopy Backup
time will be involved.
c. perform FlashBack
v start the FlashCopy using the source volumes of the FlashCopy Backup as
the target volumes and the target volumes of this run as the source
volumes
Note: Within the storage system, a background copy will be started for
all source/target volume pairs.
v if this FlashCopy starts and then fails
the RSI will be set to RSI_INVALID and
the FlashBack Restore will terminate with error message EEP0302E
v if the FlashCopy is started successfully, the FlashCopy agent on the
production system will be started with RSI value RSI_START
Note: Once the background copy running in the storage system has
completed, the FlashCopy agent will set the RSI to RSI_DISKONLY.
d. enable production resources used by the database
v importvg (varyonvg) the VGs
v mount the file systems
v give control back to the calling tdphdwdb2 component
3. Start the rollforward recovery (only if the option rollforward is selected):
a. start the database manager
b. initialize the database with db2inidb as mirror only in the case that a
FlashCopy without backup to TSM was done at backup time
c. display the breakpoint message IDS2522I and continue when the ENTER
key has been pressed.
Introduction

Notes:
1) This breakpoint will allow the administrator to provide the AIX changes
(such as add volumes, ..., file systems) as was done after the FlashCopy
Backup, for the objects now subject to the restore.
2) Volumes and LVs of the production system which were not in the VGs
of the database at FlashCopy Backup time need special administrator
attention (see When Not to Use FlashBack Restore on page 86,
FlashBack Restore Limitations on page 87, and Sample FlashBack
Restore Scenarios on page 95).
d. start the rollforward recovery with db2 rollforward db
Seamless Augmentation of the Functions of DP for mySAP
On the production system, DP for mySAP can work via a LAN in conjunction with
the SAP database administration tools brarchive/brrestore to back up/restore the
log files or tdphdwdb2 to restore and recover the database.
On request of tdphdwdb2, DP for mySAP running on another system (backup
system) can perform the backup of the database from the FlashCopy target
volumes, which are images of the source volumes on the production system.
Centrally Administered and Scheduled Backup Operations
Unattended DB2 backups can be scheduled via crontab or from the TSM server.
You can select when the backups occur without waiting for off-peak hours or
maintenance downtime.
Type of Backup
DP for Snapshot Devices has been designed to support DB2 in running full online
FlashCopy Backups. Such a backup will essentially be equivalent to a DB2 online
backup, even though the online keyword is not used (see DB2 Backups on page
8).
Integration with TSM Media Management Functions
Working together with DP for mySAP, all TSM storage devices and media
management capabilities can be utilized. You can share the devices used for other
backups or give DB2 exclusive use of certain devices and media. Life cycle
management of the media and generation of tape copies for off-site vaulting are
supported.
Support for Environments Set Up with Enhanced Concurrent
Capable Volume Group(s)
When performing a FlashBack Restore on a production system that runs HACMP
together with enhanced concurrent capable volume groups, DP for Snapshot

Devices has been changed so that all LVM changes are properly propagated to the
takeover system. For this purpose, DP for Snapshot Devices delivers and uses the
script reImportVG.sh.

Understanding the SAP DB2 Administration Tools
mySAP provides a set of DB2 database administration tools (for example,
brarchive), also referred to as the Admin Tools, which are intended to facilitate the
database administrators work. For a database backup/restore, DB2 has its own
implementation of the commands db2 backup, db2 restore, and db2 rollforward,
Introduction
and therefore no need for similar functions offered by mySAP such as brrestore,
brrecover, and brbackup. The architecture of DB2 allows
v the integration of external data protection products (like DP for mySAP) to
perform highly sophisticated backup and restore of DB2 data to and from a data
protection server (such as the Tivoli Storage Manager).
v the involvement of an external program (such as DP for Snapshot Devices) or
scripts to
create, by means of a FlashCopy of the source volumes, an image copy on the
target volumes (in mySAP terms, to split the disk mirrors) and
free up, by means of a hardware-level withdraw, the relationship of
source/target volume pairs (in mySAP terms, to resynchronize the disks for a
new split).
tdphdwdb2 interfaces with DB2 to
get information about the database structure
set the DB2 database in write suspend mode or reset the database to write
resume mode
Once the FlashCopy is done (requested by tdphdwdb2), tdphdwdb2 will involve
DB2, which uses an external vendor library such as DP for mySAP to perform a
backup. While Figure 2 on page 14 illustrates how tdphdwdb2 calls splitint and
DP for mySAP, Figure 4 on page 23 shows the general flow of how DB2 works
together with DP for mySAP.
The interfaces to the data protection products DP for mySAP and DP for Snapshot
Devices are established by customizing the profiles.
Understanding Data Protection for mySAP
Data Protection for mySAP (DP for mySAP) is an intelligent client/server program
to manage backing up and restoring mySAP DB2 databases using the Tivoli
Storage Manager (see Understanding DP for mySAP and the TSM Server on
page 25).
DP for mySAP lets you manage backup storage and processing independently of
normal mySAP operations. DP for mySAP and Tivoli Storage Manager provide
reliable, high performance, repeatable backup and restore processes that let system
administrators manage large volumes of data more efficiently.
DP for mySAP allows system administrators to follow procedures for backup and
restore. Other SAP files, for example executables, are backed up using Tivoli
Storage Manager standard techniques for file backup and restore such as
incremental backup, file filtering, and point-in-time recovery.
DP for mySAP for DB2 UDB backs up and restores data blocks using the DB2
Vendor API as seen in the following figure:

Introduction

DP for mySAP consists of two components:
v Prole
permanently running background process
controls backup/restore operations
reads and interprets parameters that are specified in the profile
reads/writes internal parameters (e.g., Tivoli Storage Manager password)
from/to the configuration file
sends backup/restore performance data to the Administration Assistant
server.
v Shared vendor library
shared library
reads/transfers data blocks from/to the DB2 Vendor API
reads/transfers data from/to the Tivoli Storage Manager API client
DP for mySAP for DB2 UDB supports the backup of data blocks.
In the case of a backup (e.g., full backup, incremental backup) DB2 starts a DB2
agent process. This process reads the data (data blocks) to be backed up from the
DB2 database and transfers it to the shared vendor library using the DB2 Vendor
API. The backup client reads the data blocks and sends them to one or more DP
for mySAP servers using the DP for mySAP API client.
DP for mySAP optimizes the data throughput for backup and restore in several
ways to minimize downtime and the impact on normal system operation:

Figure 4. Overview of DP for mySAP for DB2 UDB
Introduction
v It is able to handle multiple backup/restore sessions. Each session reads data
from and writes data to storage devices in parallel with (and independently of)
each other.
One session can be established per backup storage device.
v It utilizes multiple communication paths to Tivoli Storage Manager servers to
eliminate network-induced bottlenecks.

Note
When DP for mySAP is called to perform a backup or restore, it always uses
the Tivoli Storage Manager API archive and retrieve functions. DP for mySAP
does not use the Tivoli Storage Manager API backup and restore functions.
For more information on and for installing DP for mySAP, see Data Protection for
mySAP Installation and Users Guide for DB2 UDB and the Web page
http://www.ibm.com/software/tivoli/products/storage-mgr-erp/ .
The DP for mySAP Profile
You can customize the way DP for mySAP operates with keywords and
parameters in a profile that is analyzed by DP for mySAP Prole before any Tivoli
Storage Manager subcommands are processed. By customizing this profile, you can
adapt DP for mySAP to your environments specific needs.
You must modify the profile, since DP for mySAP reads only this file.
The DP for mySAP Configuration File
Parameters that DP for mySAP modifies are stored in a separate binary
configuration file for use in later sessions. In addition to other information, this file
contains the Tivoli Storage Manager password in an encrypted form. Be aware that
DP for mySAP might not be able to run if you change this file manually.
Understanding the Administration Assistant for DP for mySAP
The Administration Assistant for DP for mySAP consists of a Web-browser-based
graphical interface to support and assist the customizing of DP for mySAP and the
analyzing of mySAP database backup and restore operations.
The objective of the Administration Assistant is to assist in configuration,
monitoring, and administration of DP for mySAP from local or remote
workstations. It gives mySAP administrators the possibility of centralizing the
database backup/restore administrative work, especially the monitoring of DP for
mySAP and mySAP database backup/restore actions from all mySAP database
servers within the system landscape.
DP for Snapshot Devices can, on request, send all of its runtime information for a
FlashCopy backup to the Administration Assistant. To request this information be
sent, you need to customize the parameters SUPPORT_ADMIN_ASSISTANT and
optionally PROLE_SERVICE_NAME in the DP for Snapshot Devices profile (see
Chapter 7, The DP for Snapshot Devices Profile (.fcs) and Target Volumes File, on
page 143).
More information about the Administration Assistant can be found in Data
Protection for mySAP Installation and Users Guide for DB2 UDB.
Introduction

Understanding DP for mySAP and the TSM Server
TSM is a client/server program that provides storage management services in a
multivendor, multiplatform computer environment.
DP for mySAP is a so-called API client specifically developed to work in
conjunction with DB2 UDB on the one hand and the TSM server on the other. This
allows many of the overall TSM functions to be utilized:
Reduces Network Complexity
TSM reduces network complexity with interfaces and functions that span
network environments. This provides consistency across different operating
systems and hardware.
Increases Administrator Productivity
TSM can reduce the cost of network administration by allowing administrators
to:
Automate repetitive processes
Schedule unmanned processes
Administer TSM from anywhere in the network
Reduces the Risk of Data Loss
Many users do not back up their data. Other users apply stand-alone backup
techniques with diskettes and tapes as the only protection for business data.
These backup systems often produce disappointing results during recovery
operations. TSM schedules routine backups that enable users to recover from
accidental data deletion without administrator involvement.
The TSM Server provides the following services:
Backup and Restore Services
Backup and restore services allow backup-archive clients to generate backup
copies of data at specified intervals and restore the data from these copies when
required. These services protect against workstation or file server media failure,
accidental file deletion, data corruption, data vandalism, or site-wide disasters.
Archive and Retrieval Services
Archive and retrieval services provide backup-archive clients with image copies
of data for long-term storage. DP for mySAP uses these services to generate
backup copies of data at specific intervals and restore the data from these
copies when required. These services protect against workstation or file server
media failure, accidental file deletion, data corruption, data vandalism, or
site-wide disasters.
Automation Services
TSM administrators can increase productivity by automating common storage
administration tasks.
Administration Services
TSM administration services provide support for routine monitoring,
administration, and accounting. Administrators can manage the server from
another system or the same system. The TSM utilities allow the administrator
to perform these functions:
Define devices
Label tape volumes
Add clients
Format storage volumes
Set client and server options
Introduction
TSM monitors scheduled operations and maintains status information in the
database. An administrator can export data to removable media. This data can
be imported by another server, making the export and import features a
convenient utility for moving server data. The administrator can specify the
accounting option generated at the end of each client session.
Security Services
Security services control user access to TSM data, storage, policy definitions,
and administrative commands.
Disaster Recovery Services
Disaster recovery services help the administrator implement a comprehensive
backup and recovery procedure for important business applications, data, and
records.
Understanding the Hardware Interface and Common Information Model
(CIM)
Prior to V5.3.1, DP for Snapshot Devices supported only the ESS and employed the
ESS Copy Services Command Line Interface (CLI) to communicate with this
storage system.
Starting with V5.3.1, storage-system support was retained for the ESS Model 800
and extended to the ESS successors DS6000 and DS8000 as well as to the SAN
Volume Controller (SVC). A common, modular mechanism called the Hardware
Common Interface (HCI) was implemented to provide the link between DP for
Snapshot Devices (then known as DP for FlashCopy Devices) and these hardware
options for the purpose of managing disk volumes and controlling FlashCopy
operations. Support for the ESS 800 is provided via the HCI.
Note: For an ESS Model 800 configuration, installation of the ESS CLI interface
software continues to be required in conjunction with the DS Open API CIM
Agent (see DS Open API CIM Agent on page 54).
As of release V5.4.0, the Data Protection for N Series Snapshot for mySAP component
support IBM System Storage N series devices defined in a storage area network
(SAN). This interface does not involve CIM. The Data Protection for FlashCopy
Devices for mySAP component provides the support for ESS, DS, and SVC devices
via CIM.
The following figure depicts the hardware interfaces for the ESS or DS.

Introduction

|
|
|
|
|
The following figure shows the hardware interfaces for the SVC andr N Series
configurations.

Figure 5. DP for Snapshot Devices Hardware Interface for ESS and DS Configurations
Introduction
The key user-visible component of the hardware interface is the implementation of
the Common Information Model (CIM). The CIM is a conceptual information
framework for describing management properties (in this case, for managing disk
storage). It is not bound to a particular implementation. The CIM design allows for
the interchange of management information between management systems and
applications through the Common Information Model Object Manager (CIMOM),
which is an object management engine that exists between the managed system
and the management application.
The CIM implementation employed by DP for Snapshot Devices focuses on storage
systems and is compliant with the Storage Management Initiative Specification
(SMI-S) defined by the Storage Networking Industry Association (SNIA). SMI-S is
based on a number of existing technologies or industry standards that include the
following:
Common Information Model (CIM)
An object model for data storage and management developed by the

Figure 6. DP for Snapshot Devices Hardware Interface for SVC and N Series Configurations
Introduction

Distributed Management Task Force (DMTF). CIM makes it possible to
organize devices and components of devices in an object-oriented pattern.
Web-Based Enterprise Management (WBEM)
A tiered enterprise management architecture also developed by the DMTF.
This architecture provides the management design framework that consists
of devices, device providers, the object manager, and the messaging
protocol for the communication between client applications and the object
manager. In the case of the CIM, the object manager is the CIMOM and the
messaging protocol is CIM-over-HTTP. The CIM-over-HTTP approach
specifies that the CIM data is encoded in XML and sent in specific
messages between the client applications and the CIMOM over the IP
network in a SAN.
Service Location Protocol (SLP)
A directory service that the client application calls to locate the CIMOM.
There is a tailored CIM interface, referred to as the CIM Agent, for the selected
storage system. The CIM Agent resides on the storage-system host and comprises
the following major components:
v CIM object manager (CIMOM)
v Service Location Protocol (SLP)
v Provider for the specific storage system
The immediate CIM interface for DP for Snapshot Devices is OpenPegasus
5
, which
is an open-source implementation of the Distributed Management Task Force
(DMTF) CIM and Web-based Enterprise Management (WBEM) standards. The
Pegasus CIM Server is installed on the DP for Snapshot Devices AIX hosts to
interface with DP for Snapshot Devices and the CIM Agent. However, only the
client libraries of the CIM Server package are used by DP for Snapshot Devices,
and these libraries are referred to in this environment as the CIM Client.
Pegasus is designed to be inherently portable and builds and runs on the AIX,
Linux
, and Windows

operating systems. The CIM Standard Schema provides the
actual model descriptions. The CIM schema supplies a set of classes with
properties and associations that provide a conceptual framework within which it is
possible to organize the available information about the managed environment.
Platform-specific objects, such as AIX, that must be managed are defined as
extensions to this standard CIM model. Providers collect the management data
from the underlying platform resources and populate the CIM objects described in
the conceptual CIM model. These objects are then ready to be served by the
CIMOM to the client management applications for managing the resources of the
underlying platform. This mechanism provides an open-standard way for a
management application to manage the resources of the underlying platform.
The Pegasus software is provided with AIX 5.2 maintenance level 5 (or higher) as
part of the AIX Expansion Pack and must be installed separately.
Pegasus requires the OpenSSL package, even if the CIM Client will be configured
to run in non-SSL mode.
5. Hereafter referred to simply as Pegasus.
Introduction
|
|
For more information, see the following:
v The OpenPegasus Web site at http://www.openpegasus.org/
v The DMTF Web sites at http://www.dmtf.org/standards/cim and
http://www.dmtf.org/standards/wbem
v The WBEM Web site at http://www.wbemsolutions.com/tutorials/CIM/cim.html
v The OpenSSL Web site at http://www.openssl.org
Understanding the CIM Agent
A CIM Agent allows the use of common building blocks, rather than proprietary
software or device-specific programming interfaces, to manage CIM-compliant
devices. A CIM Agent typically involves the following components:
CIM object manager (CIMOM) client application device The storage server that
processes and hosts the client application requests. device provider A
device-specific handler that serves as a plug-in for the CIM. That is, the CIMOM
uses the handler to interface with the device. Service Location Protocol (SLP) A
directory service that the client application calls to locate the CIMOM.
Agent code
An open-systems standard that interprets CIM requests and responses as
they transfer between the client application and the device.
CIM object manager (CIMOM)
The common conceptual framework for data management that receives,
validates, and authenticates the CIM requests from the client application. It
then directs the requests to the appropriate component or device provider.
Client application
A storage management program (such as DP for Snapshot Devices) that
initiates CIM requests to the CIM agent for the device.
Device
The storage server that processes and hosts the client application requests.
In the DP for Snapshot Devices framework, a device can be an ESS 800,
DS6000, DS8000, or a SAN Volume Controller.
Device provider
A device-specific handler that serves as a plug-in for the CIM. That is, the
CIMOM uses the handler to interface with the device.
Service Location Protocol (SLP)
A directory service that the client application calls to locate the CIMOM.
The interactions involving the CIM Agent are as follows:
1. The client application (in this case, DP for Snapshot Devices) locates the
CIMOM by calling an SLP directory service. When the CIMOM is first invoked,
it registers itself to the SLP Service Agent and supplies its location, IP address,
port number, and the type of service it provides, thus enabling discovery by the
client application.
2. With this information, the client application starts to communicate directly with
the CIMOM by sending it CIM requests.
3. As requests arrive, the CIMOM validates and authenticates each request. It then
directs the requests to the appropriate functional component of the CIMOM or
to a device provider. A device can be a storage server such as the DS8000.
4. The provider makes calls to a device-unique programming interface on behalf
of the CIMOM to satisfy client application requests.
Introduction

CIM Agents Used by DP for Snapshot Devices
Separate CIM Agents are employed by DP for Snapshot Devices, one for ESS and
DS configurations and one for the SVC. While these versions implement Copy
Services in an SMI-S compliant manner, they have different:
v parameters and specification modes in certain software components
v properties for monitoring background copy processes
v procedures for querying information from the storage system
v approaches to the point-in-time copy process
These differences are sufficiently complex to justify separate HCI interfaces.
DS Open API CIM Agent
The ESS 800, DS6000, and DS8000 are supported by a CIM Agent that employs the
DS Open API (see Figure 5 on page 27). The DS Open API is an industry standard
API that is SMI-S- and CIM-compliant. The ESS Network Interface (NI) Client (to
support Copy Services) and the LIC (microcode with FlashCopy feature) for the
ESS or DS are required. The CIM Agent product includes the CIMOM, device
provider, SLP, and ESS NI client. The ESS NI server is preinstalled with the Storage
Hardware Management Console (HMC) shipped with the DS8000 and the Storage
Management Console (SMC) of the DS6000. The interface to the ESS 800 is
provided by the ESS Copy Services Command Line Interface (CLI), which was
used by DP for ESS through V5.3.0 and has now been relocated to the machine
hosting the DS Open API CIM Agent.
Note: With an ESS Model 800 configuration only, the ESS CLI must be installed
prior to the DS Open API CIM Agent.
For more information on this agent (including installation and configuration), see
IBM TotalStorage DS Open Application Programming Interface Reference, GC35-0493.
CIM Agent for SVC
The CIM Agent for a SAN Volume Controller (SVC) is provided as part of the
software shipped with the SVCs Master Console (see Figure 6 on page 28). For
more information see IBM TotalStorage SAN Volume Controller CIM Agent Developers
Reference, SC26-7545, and IBM TotalStorage SAN Volume Controller Configuration
Guide, SC26-7543.
Introduction
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Chapter 2. General Preparations for Installing DP for
Snapshot Devices
In general, it is very helpful prior to the installation of an operating system and
various products within a computer environment to have done a careful layout of
the disk configuration you are using.
It is therefore all the more imperative that you have done such planning in
advance if you are considering using application-driven, sophisticated image
backup/restore processes (such as a FlashCopy in a two-system environment) to
avoid
v unnecessary re-installation work
v unplanned behavior of FlashCopy backups
v conflicting situations when performing a restore of FlashCopy disks
Note: See the Preinstallation Checklist file on the installation CD or at the support
Web site for a summary of the prerequisites for installing DP for Snapshot
Devices.
Overview
The two-system environment consists of a production system (which contains the
database server) and a backup system.
The production system will have a disk setup for the mySAP database such that
the database files will be allocated on so-called source volumes; the backup system
will only see the database disks (target volumes) after a FlashCopy has been done
on the production system.
Multiple sets of target volumes can be used, in order to have different generations
of disk copy backups.
Understanding the behavior of the program tdphdwdb2 allows you to set up the
disk environment properly. When DP for Snapshot Devices performs a FlashCopy
Backup,
v all the tablespace container files and
v all files in the local database directory
must be transferred via FlashCopy to the backup system.
Because the totality of all these database files will be involved in the FlashCopy
disk process, some rules must be followed:
v The above files (or the underlying physical volumes) must be on so-called
source volumes, which will be copied to target volumes as a result of a
FlashCopy request.
v No other files from other applications should be allocated on the set of the
above physical volumes, to avoid complications with these files in the case of a
FlashCopy Restore (FlashBack Restore).

Combined with other requirements such as database performance, the planning of
the overall disk environment could now be undertaken as discussed in the next
section.
Overall Disk Layout Considerations
For planning purposes, it is advisable to subdivide the disk environment (spread
over the 2 systems) into the following categories (see Figure 7 on page 35).
1. Local disks on the production system (p_disk category)
Besides the OS disks, you will also have here the disks where DB2 and mySAP
executables will be placed during DB2/mySAP installation.
2. Source volumes (disks) on the production system (db_disk category)
These will contain all files such as tablespace containers and the local database
directory. All the disks that make up the volume groups in which those files
reside must be logical volumes in the respective storage system, which become
the source volumes in the FlashCopy operation.
At least the same number of target volumes (constituting one target set) must
be planned and made available for the planned subsequent FlashCopy
operations. Those volumes will become available, with the image copies, on the
backup system after the FlashCopy has been initiated by tdphdwdb2.
3. Shared disks on the production system (NFS_disk category)
Via NFS mount, the backup system must have access to a directory of the
production system:
/db2/<SID>/dbs
This directory, part of the local disk setup of the production system, will be
exported on the production system such that it can be NFS-mounted on the
backup system. This directory is used by DP for mySAP and DP for Snapshot
Devices.
4. Supplementary local disks on the production system (p_db_disk category)
These will contain the log, log archive, and retrieve directories.
5. Local disks on the backup system (b_disk category)
In addition to the operating system disks, you will also have here the disks on
which DB2 executables will be placed during the installation.
6. Disks for the TSM server (optional, TSM_disk category)
If the TSM server is planned to run on the backup host, you will plan for an
additional disk category (TSM_disk category) for the TSM DB/log/storage
disks.

General Preparations for Installing DP for Snapshot Devices

Compared to Figure 7, Figure 8 depicts an environment with multiple target sets, in
which the FlashCopy backup can be done to different target sets, thus allowing
different disk-copy backup levels (see Chapter 10, Multiple Backup Generations
(Target Sets) on Disk, on page 219).

The above layout does not prevent you from using disks of categories 1, 3, 4, 5,
and 6 in the database storage system too. It is just meant to visualize the various
categories you will have to deal with and to highlight the role of FlashCopy
source/target volume pairs, which will be the ones for the FlashCopy/withdraw
6
process.
6. The R/3, or mySAP, documentation refers to this using the generalized terms split-mirror and resynchronize.

Figure 7. Overview of the Backup Scenario (Single Target Set)

Figure 8. Overview of the Backup Scenario (Multiple Target Sets)
Chapter 2. General Preparations for Installation 35
By following the above approach, you ensure that DP for Snapshot Devices and
DP for mySAP on the backup system will find all files which must be backed up to
TSM.
Sample of an Overall Disk Layout on page 235 demonstrates in detail how the
disks could be set up.

Disclaimer
Later releases/versions of the SAP software or DB2 might have new or
renamed file systems. The user must adapt the provisions of this document to
such changes.
More detailed setup requirements concerning supported environments or specific
configurations are discussed in the following sections:
v DP for Snapshot Devices Functions for AIX JFS2 File Systems on page 40
v Use of Unique Logical Volume Names on page 40
v Use of JFS2 Concurrent I/O (CIO) on page 40
v DP for Snapshot Devices Setup Requirement for Using CIO on page 40
v Environment Requirements on page 48
v Installing and Using the IBM Multipath Subsystem Device Driver (SDD) on
page 56
v DP for Snapshot Devices and Copy Sets in an AIX LVM Mirror Environment
on page 165
Specific Customization Requirements
With respect to running
v brarchive on the production system
v tdphdwdb2 when requesting
a FlashCopy backup on the backup system
an offline/online backup on the production system via the LAN or SAN
it is strongly recommended, on both production and backup systems, to use
v a common profile directory, via NFS mount (/db2/<SID>/dbs)
v only one common TSM Client node name
v a common backup directory (/db2/<SID>/dbs) as an NFS repository, to
facilitate backup/restore for tdphdwdb2 and avoid restore/recovery problems.
In planning to utilize the DP for mySAP backup version control function, you must
set up the environment so that
v tdphdwdb2 (calling DP for mySAP on the backup system) and
v tdphdwdb2 and brarchive (calling DP for mySAP on the production system)
will use the same file (init<SID>.bki) specified in the CONFIG_FILE parameter in
the DP for mySAP profile (normally init<SID>.utl).
Further customization requirements to plan for are:
v The DB2 RDBMS software must also be installed on the backup server (same
version and FixPak level as on the production system).
v The DB2 home directory structure must correspond to that of the SAP standard
installation required by tdphdwdb2.

Default directories used by tdphdwdb2 will be
/db2/<SID>/dbs
/db2/<SID>/db2<sid>
$INSTHOME/sqllib
where $INSTHOME is normally
/db2/<SID>
The directory structure of DB2 UDB Enterprise Edition (EE) is different from that
of DB2 UDB Enterprise-Extended Edition (EEE). In EEE environments the
$INSTHOME variable is normally set to
/db2/db2<sid>
v The directory /db2/<SID>/dbs of the production system must be mounted on the
backup system as NFS whenever tdphdwdb2 or splitint runs are planned on the
backup system.
v Ensure that within the db_disk category each jfslog LV with all its LPs is
allocated non-striped on one OS disk (AIX physical volume) only.
v No other files or file systems from applications other than the mySAP
application should be allocated on the disks of the db_disk category. Such an
invalid allocation can create problems during the FlashCopy backup and within
restore runs if planned for a disk-to-disk restore/recovery.
v Ensure that the DB2 local database directory resides on the db_disk category
disk volumes.
v Ensure that the DB2 log directory resides on the p_db_disk category disk
volumes.

Important Note
Running tdphdwdb2 on the backup and production systems requires that
user (db2<sid>) and user ID number
group (db<sid>adm) and group ID number
match on both systems. You will also need the group (dba) with the same
group ID number on all your SAP systems and on the backup system.
Today, without utilizing the FlashCopy/withdraw functions of the storage system,
you can run the traditional backups with the db2 backup command using DP for
mySAP in the so-called one-system environment. Figure 9 on page 38 illustrates the
various profiles and control files needed for such backups and also restores. While
all, with the exception of init<SID>.bki, are customized at setup time (see Data
Protection for mySAP Installation and Users Guide for DB2 UDB), it is the
init<SID>.bki control file in which DP for mySAP keeps control information about
versions (if MAXVERSION is nonzero) and password (if PASSWORDREQUIRED is
set to YES).

Figure 9. Control File/Profile Relationships Without DP for Snapshot Devices

The following figure shows the relationships of the profiles of DP for Snapshot
Devices, DP for mySAP, and the TSM API with DP for Snapshot Devices for a
two-system environment:

Utilizing the storage system capabilities, such as FlashCopy and withdraw, for disk
copy backups, with succeeding backups to external media (using TSM and DP for
mySAP), you involve a two-system environment (see Figure 10), in which the
various control files and profiles contain information needed by both systems. The
ideal setup is to have the DP for mySAP and DP for Snapshot Devices profiles and
control files set up on NFS disks, so that all DP tools (tdphdwdb2, splitint, prole,
shared vendor library) use the same profiles and control files, regardless of the
system the tool
7
has been started on.
In addition, DP for mySAP and DP for Snapshot Devices use the same profiles,
regardless of whether they were started on the production or backup system.
7. Keep in mind that the FlashCopy Backup can be started only on the backup system and the FlashBack Restore only on the
production system.

Figure 10. Control File/Profile Relationships With DP for Snapshot Devices
Such a setup will allow the FlashCopy function of the storage system to be
integrated transparently into DP for Snapshot Devices and DP for mySAP in such
a way that the DB administrator can perform all the mySAP DBA tasks he is
accustomed to doing, such as:
v administering a DB2 database on the production system
v initiating backups with Copy Services capabilities on the backup system using
DP for Snapshot Devices and DP for mySAP, or backups without Copy Services
capabilities on the production system with DP for Snapshot Devices and with
DP for mySAP.
v running and controlling backups/archiving of the log files on the production
system
v restoring/recovering the database on the production system with Copy Services
capabilities using DP for Snapshot Devices FlashBack Restore, or
restoring/recovering the database on the production system on the basis of the
objects that were backed up to TSM
DP for Snapshot Devices Functions for AIX JFS2 File Systems
DP for Snapshot Devices can be run on AIX JFS2 file systems. AIX 5L provides this
new type of file system. The basic support requires the following:
v At least one JFS2log logical volume must exist in each VG that is set up with
JFS2 file systems that are in turn involved in a FlashCopy backup.
v JFS2 inline logs must not be used for the file system setup.
The JFS2 file system is required for N series devices.
Use of Unique Logical Volume Names
It is strongly recommended to use unique logical volumes names (including the
ones for the jfslog logical volumes) residing on the source/target volumes of a
FlashCopy Backup (or FlashBack Restore) within the scope of the involved
production system(s) and the backup system. This is to avoid
v having AIX rename the original logical volume name when using
non-concurrent volume groups
v AIX failure on encountering the duplicate logical volume name when using
enhanced concurrent capable volume groups
Use of JFS2 Concurrent I/O (CIO)
AIX 5L v5.2 ML01 introduced the CIO feature in the Enhanced Journaling File
System (JFS2), which allows the inode lock serialization on a file level. Database
applications that implement their own data serialization mechanisms, usually at a
finer level of granularity than the file, can now achieve performance throughput
comparable to that obtained by using raw logical volumes. When properly set up,
DP for Snapshot Devices propagates the CIO of the Enhanced Journaling File
System (see the following section).
DP for Snapshot Devices Setup Requirement for Using CIO
In order to have your DB2 data files work properly with DP for Snapshot Devices,
the following are required:
v AIX 5L v5.2 ML01 (or higher) and JFS2 file systems for the DB2 database

|
v the JFS2 file systems need the CIO option to be established at the file system /
logical volume level; this can be done with
mkfs -o cio <fs name>
Make sure that the option cio is defined in /etc/filesystems (check with
command lsfs). Also check the LVCB (logical volume control block) of the file
system using the command getlvcb:
x1::root:/#getlvcb -AT fslv01
AIX LVCB
intrapolicy = m
copies = 1
interpolicy = m
lvid = 0059d79a00004c00000000fb53c1c4d1.9
lvname = fslv01
label = /db2/C01/sapdata7
machine id = 9D7AA4C00
number lps = 13
relocatable = y
strict = y
stripe width = 0
stripe size in exponent = 0
type = jfs2
upperbound = 32
fs = vfs=jfs2:log=/dev/loglv10:mount=true:options=cio,rw:account=false
time created = Wed Mar 10 13:50:33 2004
time modified = Tue Aug 16 17:11:15 2005
v use of the default value (4K) for the alignment and length restriction parameter
(agblksize) of the database file systems.

Caution:
A CIO setup is not supported by DP for Snapshot Devices in its FlashCopy
Backup/FlashBack Restore functions if the CIO option is specified using the
mount command
v on a file system level or
v on subdirectories of a file system
If you do so, you will lose the CIO option should a FlashBack Restore become
necessary; in this case, after a FlashBack Restore, you need to perform an
unmount yourself and rerun the mount (with the CIO).

Chapter 3. Installing and Customizing DP for Snapshot
Devices

Note
For current information concerning installation of DP for Snapshot Devices,
refer to the README information shipped with the product installation
media or files.
This chapter provides the information needed to plan and perform the installation
and customization of DP for Snapshot Devices.
For the purposes of planning such an installation,
v Installation requirements
Hardware
Software
Environment
Volume group setup
LVM mirroring setup
are shown first. Prior to installation and customization of DP for Snapshot Devices,
other product installation and activities should be done and are discussed in the
sections
v General installation approach for the required products
v Other steps prior to installing DP for Snapshot Devices
Setting up the NFS file systems
Defining source and target volumes
The actual installation and customization of DP for Snapshot Devices is discussed
in
v Installing DP for Snapshot Devices
v Customizing DP for Snapshot Devices
Customizing the DP for Snapshot Devices profile
Initializing DP for Snapshot Devices
Information on how to use DP for Snapshot Devices in conjunction with DP for
mySAP for FlashCopy Backups and FlashCopy Restores is provided in
v Customizing the DB2 and DP for Snapshot Devices environments
Preparing for DB2 remote connect usage
Customizing the DP for Snapshot Devices profile
If you have completed the activities required in the above line items, you can start
to run FlashCopy Backups on the backup system as shown in Chapter 4, Backup
Methods, on page 73 and FlashCopy Restores on the production system as shown
in Chapter 5, Restore Methods, on page 81. Samples of FlashCopy Backups and
FlashCopy Restores are shown in Sample tdphdwdb2 Usage on page 259.

Installation Requirements
The following requirements must be met for DP for Snapshot Devices to install
successfully. Also, check the README files and release notes (see Where to Find
More Information on page xiv) for the latest information on hardware and
software requirements. A Word document entitled Preinstallation Checklist is
attached to the Hardware/Software Requirements page linked to from the release
notes (see Where to Find More Information on page xiv).
Hardware Requirements
Note: The numbers in parentheses refer to the notes following the table.
Table 2. Hardware Requirements
Component
Database Storage System
Production
System (PS)
Backup
System (BS)
Takeover
System
(HACMP) ESS 800
DS6000/
DS8000 SVC N Series (9)
Processor IBM System p x x x
Storage
system
options
FC 1830-1835
(7)
2244-PTC (7) x x x
Storage
system
microcode
and LIC
(8) (8) (8)
Data ONTAP
7g or higher
(10)
x x x
Connection
of processor
to storage
system
SCSI or Fibre Channel adapters (1) Fibre
Channel
x x x,
Disk space 100 MB (3) x x x
Memory 256 MB (4) x x x
LAN
connection
to:
DS Open API CIM Agent SVC master
console
N series filer x x x
NFS (PS to BS) x x x
LAN or SAN
connection
to:
TSM Server x (2) x (2) x
LVM mirrors
(6)
Two mirror sets (if used) x x x
HACMP (5) x x x x x

Notes:
1. Source volumes accessible to PS, target volumes accessible to BS. Sources and
targets must not be accessible to both systems simultaneously. Source and
target volume pairs must have the same size and reside in the same hardware
unit.
2. On the PS, to the TSM Server for restore and backup/restore of log files
(brarchive/brrestore). On the BS, to TSM Server for backup, if not installed on
BS.
3. Applies to each DP for Snapshot Devices version level installed. In order to
avoid an uncontrolled termination of DP for Snapshot Devices (or the called
system commands) due to lack of space, DP for Snapshot Devices issues a
Installing and Customizing DP for Snapshot Devices

|
|
||
|
|
|
|
|
|
|
|
||
|
|||
|||||
|
|
|
|
|
||||||
|
|
|
|
|||
|
|
|
|||
|
|
|
|
||
|
|||
|||||
|||||
|
|
|
||
|
||||
||||
|
|
|
||||
|
|
|||||
||||||
|
|
|
|
|
|
|
|
|
|
|
|
warning message (IDS1310W) if an essential file system has less than 50 MB
free space. If the available space is less than 5 MB, DP for Snapshot Devices
terminates with an error message (IDS1311E); in this case, the affected file
system first needs to be increased prior to rerunning DP for Snapshot Devices.
4. However, check the mySAP DB server memory requirements, which normally
are in the range 1-2 GB, depending on workload objectives.
5. Three IBM System p systems are required when planning for a high
availability environment where a primary and takeover system with HACMP
will become established with HACMP. Each needs to play the role of the
production system depending on which is currently the active system. The
takeover system for the production server cannot be the backup system. If the
HACMP software is installed on the production machine and the volume
groups to be involved in the snapshot process are concurrent capable or
enhanced-capable, the HACMP file sets
cluster.es.clvm.rte
bos.clvm.enh
are also required on the backup machine.
6. For details, see Chapter 8, DP for Snapshot Devices Functionality for AIX
LVM Mirrored Environments, on page 161.
7. The FlashCopy LIC or the equivalent point-in-time copy (PTC) function is
required. For the ESS, at least microcode V2 is required.
8. See the Preinstallation Checklist file attached to the Hardware/Software
Requirements page (see Where to Find More Information on page xiv).
9. The N series models currently available are the N3700, N5000, and N7000
series (see the IBM Redbook IBM System Storage N Series in Table 1 on page
xiii).
10. Operating system required on the N series filer. FCP, Flexible Volume Clone,
Snap Restore features activated.
Software Requirements
Notes:
1. The levels shown specify the minimum required. For the latest supported
levels, check the README information or refer to the Hardware/Software
Requirements page linked from the release note (see Where to Find More
Information on page xiv).
2. Unless otherwise stated, software required on both the production and backup
systems must be installed and configured identically on each system.
3. The numbers in parentheses refer to the notes following the table.
Table 3. Software Requirements
Component
Production
System
Backup
System ESS 800
DS6000/
DS8000 SVC N Series
Operating System
AIX (32- or
64-bit)
5.2. ML05, 5.3 ML01 (2) x x
Multipath
Subsystem
Device Driver
(SDD) (13)
1.6.1.2 or 1.6.2.0 x x
Chapter 3. Installing DP for Snapshot Devices 45
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
||
|
|||
|
|
|
|||
|
|
|
|
|||
Table 3. Software Requirements (continued)
Component
Production
System
Backup
System ESS 800
DS6000/
DS8000 SVC N Series
Multipath
Subsystem
Device Driver
Path Control
Module
(SDDPCM)
(13)
2.1.1.1 or 2.1.2.0 x x
MPIO AIX
native driver
x x x
Locale en_US.ISO8859-1 (3) x x
JFS/JFS2 x (14) JFS2 x x
NFS x x x
Tivoli Storage Manager (TSM)
TSM Server 5.3 x (optional, see
2 on page 44)
TSM
Backup/
Archive Client
5.3 x x
TSM API 5.3.0 (5) x x
Data
Protection for
mySAP (DB2)
5.3.1 (8) x x
Data
Protection for
FlashCopy
Devices for
mySAP
5.4.0 x x
Data
Protection for
N Series
Snapshot for
mySAP

5.4.0 x x
Database Software
SAP R/3 or
mySAP (6)
R/3: 4.6B to 4.6D or
mySAP e-business solution (such as BW)
x
SAP Admin
Tools
6.20 Patch 15 or higher (15) x (6)
DB2 UDB
Enterprise
Server Edition
(ESE) 32- or
64-bit (14)
8.1 (FixPak 3), 8.2, or 9.1 x x
Storage System Interface

|
|
|
|
|
|
||
|
|||
|
|
|
|
|
|
|
|||
|
|
|||
||||
|||||
||||
|
|
||||
|
|
|
|
|||
||||
|
|
|
|||
|
|
|
|
|
||||
|
|
|
|
|
|
|||
|
|
|
|
|
|
||
|
|
|||
|
|
|
|
|
|||
|
|
Table 3. Software Requirements (continued)
Component
Production
System
Backup
System ESS 800
DS6000/
DS8000 SVC N Series
ESS Copy
Services
Command-
Line Interface
(CLI) (7)
2.4.1.50

DS Open API
CIM Agent
(11)
5.1.0.50
(10) (10)
CIM Agent for
SVC (12)

x

CIM Server
Runtime
Environment
(Pegasus) (1)
2.5.1.0 x x
CIM Server
Base Providers
for AIX
(Pegasus)
2.5.1.0 x x
OpenSSL (4) x x x
ESS NI Server (9)

Notes:
1. FC 0949 (AIX 5.2), FC 0968 (AIX 5.3). From the AIX Expansion Pack CD (not
part of the DP for Snapshot Devices package). Consisting of:
v sysmgt.pegasus.cimserver.rte
v sysmgt.pegasus.osbaseproviders
Only the client libraries are used in a DP for Snapshot Devices environment.
Therefore, the term CIM Client is used instead of CIM Server to refer to the
software following installation.
2. See the README information and/or the Preinstallation Checklist for current
maintenance level and PTF information. Virtual I/O not supported.
3. Check with
locale a
4. Available on the AIX Toolbox for Linux Applications for POWER
Systems
CD. Installation is required by Pegasus, even if non-SSL mode is to be
configured. Installation required for N Series but not exploited in this release.
5. As required by version of DP for mySAP installed (including 32- or 64-bit
configuration). Included in Backup-Archive Client and Server package.
6. SAP on production system (with SAP-approved DB2 version). The SAP
Admin Tools are automatically installed in this process. They are not required
if DB2 V8.2 log file management used (see the DP for mySAP documentation
for more information).
7. For ESS 800 only: IBM 2105 ESS Storage Management CLI and Copy Services
CLI for AIX. The code level must correspond to that of the microcode installed
in the ESS clusters. See Hardware Requirements on page 44. Installation
required only on the machine hosting the DS Open API CIM Agent. Must be
installed prior to installing the CIM Agent.
|
|
|
|
|
|
||
|
|||
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
||||
||||
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
8. Corresponding to OS level and DB2 level (32- or 64-bit).
9. Included with microcode and installed in HMC (DS8000) or SMC (DS6000).
Not required for ESS 800.
10. Installable on any supported host accessible to both systems
8
. Installation on
the PS is not recommended, due to the load imposed by Java
on the CIMOM
component. User ID required for DP for Snapshot Devices access.
11. Includes DS Open API, ESS NI Client, CIMOM, SLP. User ID required for DP
for Snapshot Devices access. Installable on any host accessible to PS or BS.
Installation on the PS is not recommended due to the loading imposed by Java
on the CIMOM.
12. Installed as part of SVC. User ID required to allow access by DP for Snapshot
Devices.
13. See Support Matrix for the Subsystem Device Driver, Subsystem Device Driver Path
Control Module, and Subsystem Device Driver Device Specific Module at
http://www-1.ibm.com/support/docview.wss?rs=540&uid=ssg1S7001350
14. The database must reside on a Journaled File System (JFS or JFS2)
9
. The DB2
database must not be installed
v on raw devices
v in mirrored AIX LVM environments other than that described in Chapter 8,
DP for Snapshot Devices Functionality for AIX LVM Mirrored
Environments, on page 161)
v using the JFS2 file system inline logs
15. Check by entering db2uext2 -V. Corresponding patch level for other kernel
releases.
Environment Requirements
DP for Snapshot Devices requires that certain conditions concerning the overall
system environment be satisfied before DP for Snapshot Devices can be installed:
v Certain directories on the production side must be made available via NFS to
the backup side (see Setting Up the NFS File System on page 55).
v The DB2 database files needed for backup reside completely on the storage
subsystem and are visible to the production machine.
v All DB2 tablespaces must be database-managed tablespaces (DMS). All
user/system temporary tablespaces such as PSAPTEMP can be system- managed
tablespaces.
v A remote shell connection (rsh) for user db2<sid> must be established between
the backup and production systems while installing and configuring DP for
Snapshot Devices on the backup system (see Setting Up the Remote Shell
(RSH) on page 56).
v DP for Snapshot Devices uses rsh and su commands while running several
setup scripts. The output of these commands will be traced from the scripts. If
the /etc/profile or other profiles called during the login process (done by rsh
or su) will produce output to standard output (such as an echo command in
the /etc/profile), the setup script will probably fail. For proper installation and
customization of DP for Snapshot Devices, comment out all commands that
produce output on standard output (e.g. echo commands). This should be done
for user db2<sid> only. After successfully running all setup scripts, these
commands can be included again.
8. Tested on AIX only.
9. See details of supported AIX/LVM environments in the current README or get this information using the Internet channels.

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v The DB2 database must be in log-retain mode.
v The ulimits of the db2<sid> user and root on the production and backup
systems should be at least the following (check with ulimit a):
data seg size (kbytes) unlimited
max memory size (kbytes) 131000
stack size (kbytes) 131000
Depending on the users shell and OS level, the output of ulimit a can vary.
Release 5.3.1 requires more memory than previous releases.
Volume Group Requirements
See the Preinstallation Checklist file (Where to Find More Information on page xiv)
for current information.
LVM Mirroring Requirements
See Chapter 8, DP for Snapshot Devices Functionality for AIX LVM Mirrored
Environments, on page 161 and the Preinstallation Checklist file (Where to Find
More Information on page xiv) for current information.
General Installation Approach for the Required Products
It is recommended that the prerequisite products be installed and customized in
the following sequence:
v DB2 UDB on the production and backup servers
v SAP R/3 or another mySAP e-business solution on the production system
10
v Tivoli Storage Manager products
TSM Server on your backup system (might not apply if already available or
on a different host)
TSM Backup-Archive clients and the TSM API on the production and backup
systems.
For information regarding installation procedures for these software
applications, see Tivoli Storage Manager for UNIX and Linux Backup-Archive
Clients Installation and Users Guide V5.3 (or its predecessor TSM for UNIX
Using the Backup-Archive Clients) and TSM Using the Application Program
Interface. Samples for the customized TSM Client option files can be found in
Sample TSM Client Options Files on page 239.
v DP for mySAP on the production and backup systems
For information regarding installation, see Tivoli Storage Manager for Enterprise
Resource Planning: Data Protection for mySAP Installation and Users Guide for DB2
UDB. You can find a sample of the profile and DB2 Vendor INI file as used in
our test setup in Sample DP for mySAP Profile on page 239 and Sample DP
for mySAP DB2 Vendor INI File on page 239, respectively.
When installing DP for mySAP, you must provide the correct path to the DP for
mySAP profile /db2/<SID>/dbs, which will be NFS-mounted on the backup
system. Make sure that the specified path has been created on the production
system before starting the installation. Otherwise, you will have to customize
two different DP for mySAP profiles on the production and backup systems.
Correct sequence for the installation of DP for mySAP and DP for Snapshot
Devices products:
10. Ensure that you have identified the source volumes to be used for the DB2 database on the production system and the target
volumes to be used later after a FlashCopy on the backup system.
1. Create the directory /db2/<SID>/dbs on the production system and
NFS-export this directory for the backup system (see Setting Up the NFS
File System on page 55).
2. Prepare remote shell connectivity on the production system (see Setting Up
the Remote Shell (RSH) on page 56).
3. Install and customize DP for mySAP on the production system.
At this point a db2 backup using DP for mySAP should work on the
production system.
4. Install DP for Snapshot Devices on the production system (see Installing
DP for Snapshot Devices on page 58).
5. Run the setup.sh script for post-installation of DP for Snapshot Devices on
the production system.
6. Customize DP for Snapshot Devices on the production system (see
Customizing and Initializing DP for Snapshot Devices on page 61).
At this point a db2 backup using DP for Snapshot Devices
tdphdwdb2 f backup t online/offline
should work on the production system without FlashCopy.
7. Install DP for Snapshot Devices on the backup system.
8. Run the configuration script setupDB2BS on the backup system (see
Configuring DP for Snapshot Devices on the Backup System
(setupDB2BS) on page 65).
9. Run the setup.sh script for post-installation of DP for Snapshot Devices on
the backup system.
10. Install DP for mySAP on the backup system.
At this point a db2 backup using DP for Snapshot Devices
tdphdwdb2 f backup
should work on the backup system.
DP for mySAP downward compatibility:
In order to allow the restore of data on the production system that was backed
up on a different system (in the case of DP for Snapshot Devices, on the backup
system), the downward compatibility of DP for mySAP must be strictly
observed. In general, DP for mySAP has downward restore compatibility unless
otherwise stated in the product.
If possible, keep the DP for mySAP levels the same on both systems. Never have
the backup system running a higher level than on the production system.
If multiple DP for mySAP levels are required on the backup system:
When dealing with several production systems (each one being by itself a
dedicated SAP DB server), you might need to run different DP for mySAP levels
on the common backup system for the various production systems. In this case
you have to do some steps manually for the relevant <SID> (on production and
backup systems) after running the DP for mySAP setup script (and prior to
installing a new DP for mySAP level):
Create a maintenance level directory under the directory
/usr/tivoli/tsm/tdp_r3/db2 or /usr/tivoli/tsm/tdp_r3/db264, such as
/usr/tivoli/tsm/tdp_r3/db2/3.2.0.12 (e.g. for version 3.2.0.12 32 bit)
/usr/tivoli/tsm/tdp_r3/db264/3.2.0.12 (e.g. for version 3.2.0.12 64 bit)
Copy (with the -p option) all files from the directory
/usr/tivoli/tsm/tdp_r3/db2

or
/usr/tivoli/tsm/tdp_r3/db264
to the new maintenance level directory
For each maintenance level you have installed, you will need an entry in
/etc/inittab for starting the correct version of prole:
pd3232012:2:respawn:/usr/tivoli/tsm/tdp_r3/db2/3.2.0.12/prole
-p <prole port>
or
pd6432012:2:respawn:/usr/tivoli/tsm/tdp_r3/db264/3.2.0.12/prole
-p <prole port>
where <prole port> represents the TCP/IP port which is used by this version
of prole. For each different version you have to define a separate port
number.
For each maintenance level you have installed, you will need to set the DP
for mySAP parameter PROLE_PORT with a unique TCP/IP port in the DB2
Vendor INI file:
PROLE_PORT=<prole_port>
to the corresponding prole port you have defined in /etc/inittab. After
changing the DB2 Vendor INI file, you must restart DB2.
For each maintenance level you have installed, you must adapt the DP for
Snapshot Devices parameter DB2_TDPR3_LIB in the DP for Snapshot Devices
profile:
DB2_TDPR3_LIB /usr/tivoli/tsm/tdp_r3/db2/3.2.0.12/libtdpdb2.a
or
DB2_TDPR3_LIB /usr/tivoli/tsm/tdp_r3/db264/3.2.0.12/libtdpdb264.a
It is recommended to wait with the customization of DP for mySAP on the
backup system until you have done the NFS setup as described in the next
section.
If you followed the above sequence, you should be able now to run the db2
backup command together with DP for mySAP on the production system; you can
perform the backup/restore via the LAN to the TSM Server using the db2 backup
command.
CIM Components and Related Software
This section describes the requirements related to the CIM interfaces.
Note: The following software is not furnished with the DP for Snapshot Devices
packages. The user must obtain, install, and configure the following:
v Open SSL
v Pegasus CIM Server package
v DS Open API CIM Agent (ESS or DS configuration)
v ESS Copy Services CLI (ESS configuration)
v ESS NI Server (DS configuration)
The CIM Agent for SVC is automatically installed with and integrated into
the SVC master console.
Open SSL
In order for the CIM Client (see CIM Server Package (Pegasus) on page 53) to
run (even if DP for Snapshot Devices will run in non-SSL mode), the OpenSSL rpm
file must be installed. To determine if it has been installed on your system, run the
following commands:
rpm -q -f /opt/freeware/lib/libssl.a
rpm -qa | grep -i openssl
If both the libssl.a library and the openssl-0.9.6XXX rpm, where XXX indicates the
build level, are found, then OpenSSL is currently installed on your system.
If OpenSSL has not been installed, the rpm file can be found on the AIX Linux
ToolBox CD or downloaded from the AIX Toolbox for Linux Applications Web site
http://www.ibm.com/servers/aix/products/aixos/linux/download.html
Select AIX Toolbox Cryptographic Content under the Sorted Download heading on
the right of the page. After you have registered and accepted the license, you can
download openssl - Secure Sockets Layer and cryptography libraries and tools,
such as openssl-0.9.6k-1.aix4.3.ppc.rpm, or a later version. To install the OpenSSL
rpm file, run the following command:
rpm -ivh openssl-0.9.6XXX.rpm
where XXX indicates the build level.
Configuring the CIM Environment for SSL Communication
The CIM Agent for DS8000 (for example), which is preinstalled on the HMC,
requires communication in secure mode by default. In this case, the clients such as
DP for Snapshot Devices need to connect using HTTPS instead of HTTP. This
requires that the CIM Client (Pegasus, see CIM Server Package (Pegasus) on
page 53) first obtain the public key used for encryption from the 'truststore'
certificate in the CIM Agent and then authenticate using the user name and
password.
To enable the HTTPS protocol, profile parameter
COPYSERVICES_COMMPROTOCOL must be set to HTTPS. In this case,
parameter COPYSERVICES_CERTIFICATEFILE can define a certificate file name,
and Data Protection for Snapshot Devices exports the certificate using this file.
The CIM Agent also provides another communication mode known as null trust
provider. In this case, the CIM Agent does not verify that the certificate passed by
the client matches a known certificate. Rather, it accepts any certificate from the
client (including a null string for the filename). To enable this mode, the value of
COPYSERVICES_CERTIFICATEFILE must be set to NO_CERTIFICATE, which is
the default setting. However, it is recommended to use this mode only if the
production and backup systems, as well as the storage system, are protected by a
firewall.
Generating a New Certificate
If it is suspected that security has been or could be comprised, a new certificate
can be generated. There are two procedures depending on the version of the CIM
Agent:
v For CIM Agent Version 5.1:
1. Change to the CIM Agent installation directory (normally
/opt/IBM/cimagent)

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. Run the mkcertificate command. This command creates an X.509 certificate
and places it in a certificate store entitled 'truststore'.
v For CIM Agent Version 5.2:
1. Change to the CIM Agent installation (normally /opt/IBM/cimagent)
2. The dscimcii command is used to view and modify the configuration of the
CIM Agent.
3. The following subcommands for SSL Certificate Management are provided
by dscimcii:
lscert: List the current SSL certificate
mkcert: Create a new SSL certificate
rmcert: Remove the current SSL certificate
getcert: Obtain the current SSL certificate from the CIM Agent in ASCII
form.
CIM Server Package (Pegasus)
In addition to a server component that is installed but not used by DP for
FlashCopy, the Pegasus CIM Server package includes the client libraries that DP
for Snapshot Devices needs to interface to the CIM agent for the respective storage
system. The client libraries are referred to in the DP for Snapshot Devices
environment as the CIM Client. The Pegasus package must be installed on each
AIX server on which DP for Snapshot Devices is installed.
The CIM Client requires the libssl.a library component of Open SSL (see Open
SSL on page 52).
For more information, see AIX 5L Version 5.3, Common Information Model Guide,
SC23-4942.
Installing the CIM Client
Note: Consult the README file for the latest information concerning the Pegasus
CIM Server.
The AIX Expansion Packs of AIX 5.2 and 5.3
11
provide the following packages for
Pegasus:
sysmgt.pegasus.cimserver.rte (Pegasus CIM Server Runtime)
Installs the Pegasus CIM Server filesets in the /opt/freeware/cimom/
pegasus directory
sysmgt.pegasus.osbaseproviders (Base Providers for AIX OS)
Installs the base providers for AIX filesets in the /usr/pegasus/provider
directory
You can install the above packages using either the System Management Interface
Tool (SMIT) or the installp command. For more information about using the
installp command, see the installp command in AIX 5L Version 5.3 Commands
Reference, Volume 3.
Note: Before continuing with the installation, review the license information.
To install the packages using SMIT, perform the following:
11. To obtain the AIX Expansion Pack, place an order on the 5692-A5L SPO in the configurator for feature 0968 (AIX 5.3 Expansion
Pack) or 0949 (AIX 5.2 Expansion Pack). A valid AIX software maintenance agreement (SWMA) is required.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. At the command line, type smitty.
2. Select Software Installation and Maintenance Install and Update Software
Install Software.
3. At the Input Device/directory for software field, press the F4 key to view a list
of options.
4. Select the option that reflects the location or medium that contains the CIM
packages.
5. At the Software to Install field, press the F4 key to view a list of package
options.
6. Select the sysmgt.pegasus.cimserver and sysmgt.pegasus.osbaseproviders
packages by pressing the F7 key.
To verify that the CIM client filesets were installed correctly, use the lslpp
command as follows:
lslpp -al sysmgt.pegasus.cimserver.rte
If the installation completed successfully, a message similar to the following is
returned:
lslpp -l sysmgt.pegasus.cimserver.rte
Fileset Level State Description
----------------------------------------------------------------------------
Path: /usr/lib/objrepos sysmgt.pegasus.cimserver.rte 2.3.1.0 COMMITTED \ Pegasus CIM Server Runtime Environment

If the installation was not successful, a message similar to the following is
returned:
lslpp: Fileset sysmgt.pegasus.cimserver.rte not installed.
To verify that the base providers for AIX filesets were installed correctly, use the
lslpp command as follows:
lslpp -al sysmgt.pegasus.osbaseproviders
If the installation completed successfully, a message similar to the following is
returned:
lslpp -l sysmgt.pegasus.osbaseproviders
Fileset Level State Description
----------------------------------------------------------------------------
Path: /usr/lib/objrepos sysmgt.pegasus.osbaseproviders 1.2.3.0 COMMITTED \ Base Providers for AIX OS

If the installation did not complete successfully, a message similar to the following
is returned:
lslpp: Fileset sysmgt.pegasus.osbaseproviders not installed.

Configuring the CIM Client
The only configuration options concern tracing and logging. See the Pegasus
documentation (Table 1 on page xiii) for more information.
If the storage system supported is an ESS or DS, install the DS Open API CIM
Agent on a system with access to both the production and backup systems via
HTTP. For the installation procedure, refer to the IBM TotalStorage DS Open
Application Programming Interface Reference, GC35-0493. This manual also contains

the procedure for configuring the agent to run in non-SSL mode, if this has not
already been done. In addition, refer to the appropriate CIM Agent and DP for
Snapshot Devices README files for any additional information.
The DS Open API CIM Agent can be co-located with the CIM Client. In this case,
installation on the backup system is preferred, because installing it on the
production system can be detrimental due to the system loading imposed by Java
on the CIMOM.
The CD image for the DS Open API CIM Agent, as well as updates and other
information, can be obtained at the following URL:
http://www.ibm.com/servers/storage/support/software/cimdsoapi/installing.html
Note: The DS Open API CIM Agent requires the prior installation of the ESS Copy
Services Command Line Interface (CLI) if an ESS 800 storage system is
configured. The functions of this package for a DS storage system are
performed by the ESS Network Interface (NI).
CIM Agent for SVC
The CIM Agent for SVC is installed as part of the SVC master console
environment.
Configuring the CIM Agent for SVC
By default, the CIM Agent for SVC runs in secure mode using the HTTPS protocol
(see Open SSL on page 52).. If desired, for DP for Snapshot Devices, non-SSL
mode can be established as follows:
1. Stop the CIMOM by entering the stopcimom command in the installation
directory of the SVC master console.
2. Ensure that the cimom.properties file in this directory has the following
settings:
Port=5988
// Port=5989
// 5988 for HTTP, 5989 for HTTPS

ServerCommunication=HTTP
//ServerCommunication=HTTPS

DigestAuthentication=false
//DigestAuthentication=true
3. Restart the CIMOM by entering startcimom. The CIMOM will now accept
requests using HTTP and basic authentication.
Other Steps Prior to Installing DP for Snapshot Devices
Before installing DP for Snapshot Devices, ensure that the following requirements
have been met.
Setting Up the NFS File System
It is recommended to do this step prior to installation and customization of DP for
Snapshot Devices in order to facilitate the overall installation/customization
process.
To simplify the implementation and to facilitate later operations control, the
following directory of the production system should be mounted on the backup
system:
|
|
|
/db2/<SID>/dbs
If additional directories (such as the one you will specify in the DP for Snapshot
Devices profile) will be shared, you have to mount them as well. However, if you
choose a similar directory structure as shown in Sample DP for Snapshot Devices
Profile on page 241, no additional directories other than the one mentioned above
are necessary.
Details on how to set up the above directories for NFS use are shown in:
v Sample NFS Server Setup on the Production System on page 237 and
v Sample NFS Client Setup on the Backup System on page 238
Setting Up the Remote Shell (RSH)
It is recommended to do this step prior to installation and customization of DP for
Snapshot Devices on the backup system in order to facilitate the overall
installation/customization process.
To allow a remote shell connection from the backup system to the production
system, a configuration file must be set up in the users $HOME directory on the
production system.
You need to set up the file .rhosts for db2<sid> in the directory /db2/<SID> and
allow users root and db2<sid> access to the production system (see Sample
.rhosts for Remote Shell Connection Setup on the Production System on page
238).
Installing and Using the IBM Multipath Subsystem Device
Driver (SDD)
Note: If multipathing is implemented, SDD (or SDDPCM) is required for an SVC
configuration and optional for other configurations.
DP for Snapshot Devices provides basic support for the IBM Subsystem Device
Driver (SDD), also referred to as multipathing. SDD resides on the host server(s)
(production and backup systems) with the native device driver for the respective
storage system. SDD uses redundant connections between the host server and a
disk storage subsystem to provide enhanced performance and data availability. By
installing and configuring SDD, the user can have several hdisk devices defined to
a single SDD device (vpath device). Each vpath device represents a unique
physical device (LUN) on the same storage subsystem. There can be up to 32
different paths to the same physical device when using DP for Snapshot Devices.
The alternative driver module SDDPCM is also supported for SVC, ESS, and DS
configurations. SDDPCM is a loadable path control module for disk storage system
devices to supply path management functions and error recovery algorithms.
When the disk storage system devices are configured as multipath I/O (MPIO)
devices, SDDPCM becomes part of the AIX MPIO FCP (Fibre Channel Protocol)
device driver during the configuration. The AIX MPIO-capable device driver with
the disk storage system SDDPCM module enhances data availability and I/O load
balancing.
The following SDD configurations have been tested and are supported:
v SDD is not installed on the production system, and the volume group containing
the DB2 database has AIX hdisk devices.

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v SDD is installed on the production system, and the volume group containing the
DB2 database has vpath devices.

Note
If SDD is installed and multiple paths to the volumes are used, all volume
groups that have physical volumes within a hardware unit must be set up
with SDD vpaths to avoid serious problems at FlashBack Restore time.
Termination will be forced at backup time if this requirement is not met.
v If SDD is installed on the backup system, the hdisk device volume group is
converted to a SDD vpath volume group by DP for Snapshot Devices.
v If SDD is not installed on the backup system, the hdisk device volume group is
kept unchanged.
A configuration in which SDD is installed on the production system and the
volume group containing the DB2 database has a mixture of hdisk and vpath
devices is not supported. This environment is not recommended when using SDD.
A volume group with mixed devices needs to be fixed using dpovgfix.
For more information on SDD and SDDPCM, search for these terms at
http://www.ibm.com/support/
Setting Up Source and Target Volumes
Note: Explicit definition of target volumes is required only for FlashCopy devices.
Snapshot devices such as N series allocate target volumes automatically on
request.
Setting up volumes for later FlashCopy operations requires that the volumes that
will become source and target be in the same hardware unit or SVC cluster and
that the size of a source volume match the size of the planned target volume.
If you plan to use multiple target sets, the target-volume requirements apply for all
target volumes in each set.
Attach the source volumes to one system (production system) and the target
volumes to the other system (backup system). When the FlashCopy takes place,
your copy will always appear on the server that is the backup system.
Note: Do not attach the source and target volumes to both systems.
Source and Target Volumes in an ESS or DS Configuration
To make volumes accessible in AIX, the ESS Specialist or DS Storage Manager
interface must be used by the storage system administrator.
In customization, the target volumes you plan to use must be set up in the file
identifying the target volumes by serial number (see Table 14 on page 157).
Generally, you should spread the volumes of one storage system server across as
many LSS as possible.
To check the volumes you have received, you can issue:
lsdev -Cc disk
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
and look for volumes of the storage system by the applicable device type.
Source and Target Volumes in an SVC Configuration
To make volumes accessible in AIX, use the Web interface provided by the SVC
master console.
In customization, the target volumes you plan to use must be set up in the file
identifying the target volumes by virtual disk name (see Table 15 on page 158).
To check the volumes you have received, you can issue:
lsvpcfg
The number shown is the UID as seen by clicking on a virtual disk in the SVC
master console.
Shared Usage of Target Volumes
DP for Snapshot Devices was designed such that at least one dedicated set of
target volumes must be provided for each database instance (identified by an
SID).
If an installation plans to use one common set of target volumes for multiple
databases, the following rules (in addition to the previously mentioned LSS and
size requirements) must be followed:
v The tdphdwdb2 executions for the various databases (SIDs) must run in sequence
and always show a successful completed backup cycle for one database (e.g.,
SID=TST) before running tdphdwdb2 for a different database (e.g., SID=PRD).
v The tdphdwdb2 run must utilize the
DP for Snapshot Devices flashcopy function and the
DP for Snapshot Devices withdraw function.
v A control mechanism
12
must be in place to ensure that succeeding tdphdwdb2
runs will be started only if the preceding tdphdwdb2 terminated successfully.
Important: If the customer fails to exercise stringent control over the sequence of
tspessdb2 runs for the different database instances when using shared
target volumes, this can have a decidedly negative impact on all
tdphdwdb2 runs involved. Of course, sharing target set volumes in
conjunction with disk copy backups (FLASHCOPY_TYPE COPY or
INCR) is counterproductive. DP for Snapshot Devices cannot detect
such improper use and would assume that the target set can be used
for a FlashBack Restore if the set was not withdrawn with the DP for
Snapshot Devices withdraw function. If a FlashBack Restore is
attempted using the disk copy backup from another database,
corruption of your database is a certainty.
Installing DP for Snapshot Devices
The following steps guide you through the DP for Snapshot Devices installation.
To install and customize DP for Snapshot Devices, you must log in as user ID root.
12. There are various possibilities for a customer to establish such a mechanism, such as the use of job scheduling products,
controlled lock files, etc.

|
|
|
Installation Notes
v Refer to the Preinstallation Checklist file on the installation CD or at the
support Web site to verify that all installation prerequisites have been
satisfied.
v Installation of DP for Snapshot Devices must be done at least twice, once
on the production database server machine, referred to as the production
system, and once on the backup system on which tdphdwdb2 will run
FlashCopy disk backups.
v Using multiple databases requires installing DP for Snapshot Devices on
each production system and once on the common backup system.
v Each production system running DP for Snapshot Devices to a common
backup system must use a different DB2 SID.
v The version/maintenance level of DP for Snapshot Devices
(tdphdwdb2/splitint) used for the FlashCopy of one database (SID) must
be the same on the production and backup systems.
v After the installation of DP for Snapshot Devices, you must run setup.sh
for each specific database (SID) on the production system, as well as on the
backup system.
The above approach permits the production and backup systems to have
different version/maintenance levels.
DP for Snapshot Devices is installed by means of InstallShield.
Uninstalling: It is recommended that you uninstall an earlier version package of
DP for Snapshot Devices to remove the old files (see Uninstalling DP for Snapshot
Devices on page 71). To uninstall from a version earlier than 1.2, do the following:
1. Log in as user ID root on the production (or backup) system.
2. Invoke the AIX system management interface tool: smitty.
3. Choose the menu Software Installation and Maintenance.
4. Choose the menu Software Maintenance and Utilities.
5. Choose the menu Remove Installed Software.
6. Press F4 to choose from a list of packages.
7. Choose the package to be uninstalled:
tivoli.tsm.tdpessr3.db2.aix43.32bit
8. You will be asked to remove the directories named as the earlier version
installed. If you want only to install the new package but keep parts of your
database instances working with the earlier version, you have to reply no
here.
The following steps guide you through the DP for Snapshot Devices installation:
1. Log in as user ID root on the production (or backup) system
2. The DP for Snapshot Devices install packages are delivered as individual
executable files with the name format
<version>-TIV-TSMACSSAPDDB2-AIX (Data Protection for FlashCopy Devices for mySAP)
<version>-TIV-TSMACSSAPNDB2-AIX (Data Protection for N Series Snapshot for mySAP)
on the CD-ROM or a CD image downloaded from Passport Advantage. The
package files have the appropriate extension and are executable. Refer to the
README.1ST file on the CD for information on the directory structure. You can
also download an install package for upgrading via
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManagerforAdvancedCopyServices.html
Web-based install packages reside on the IBM public FTP server, and the
packages contain "FTP" prior to the platform designation.
3. To install from the CD-ROM, ensure that it is inserted in the proper CD-ROM
drive.
4. Ensure that the environment variable DISPLAY is set to host:display, where
host identifies the host name of the X Server to contact and display is the
display number.
5. Invoke the executable file and follow the instructions of InstallShield.
6. Check the summary at the last InstallShield dialog panel for successful
installation. If an error occurs during the installation process, check for the
error message in the output panel carefully and correct the problems. After
correcting the error(s) repeat the installation procedure beginning at step 4.
7. The DP for Snapshot Devices software will be installed in the directory
Check the README information for a brief description of all installed files. The
above directory contains the DP for Snapshot Devices executables, which are
accessed by the setup.sh script described in the following.
For DP for Snapshot Devices to work properly, a post-installation procedure must be
started. During this procedure, a shell script setup.sh will be processed and the
following tasks performed:
v Rename the DP for Snapshot Devices profile (init<SID>.fcs) and copy it to the
/db2/<SID>/dbs directory or to the/db2/<SID>/dbs/<HostName> directory (in case
of EEE, see Chapter 9, Considerations for DB2 UDB ESE with DPF, on page
191). This applies only to new installations; otherwise this step is omitted.
v Copy the tdphdwdb2 and splitint executables to a version/maintenance level
directory.
v Create two softlinks for the DP for Snapshot Devices executables tdphdwdb2 and
splitint in the directory /db2/<SID>/dbs.
The following steps describe the post-installation procedure:
1. Using user ID root, invoke the post-installation shell script
/usr/tivoli/tsm/acssap/db2/setup.sh
2. Enter the system ID (SID) for the mySAP system to be backed up.
3. Enter the path for the DP for Snapshot Devices profile (init<SID>.fcs). If
appropriate, you can use the suggested default (/db2/<SID>/dbs) by pressing
Enter. In the case of EEE, use also the path /db2/<SID>/dbs without the
<HostName> subdirectory. The setup script will handle EE and EEE
installations. As already discussed, this directory must be an NFS directory. See
also Overall Disk Layout Considerations on page 34.
Note: setup.sh ensures that several levels of DP for Snapshot Devices
(tdphdwdb2/splitint) can be used simultaneously on the backup and
various production systems.
At this point, the DP for Snapshot Devices installation procedure is finished when
you have run the installation first on the production system and then on the
backup system (without running setup.sh: see Configuring DP for Snapshot
Devices on the Backup System (setupDB2BS) on page 65).

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To prepare DP for Snapshot Devices for use, perform the customization and
initialization steps described in the next section.
Customizing and Initializing DP for Snapshot Devices
In order to use DP for Snapshot Devices, it is necessary to
v customize the DP for Snapshot Devices profile
v check environment variables
v initialize DP for Snapshot Devices
These topics are discussed in this section.
Customizing the DP for Snapshot Devices Profile
This section discusses customizing the DP for Snapshot Devices profile (generally
init<SID>.fcs), which will be used when performing certain DP for Snapshot
Devices functions (backup, flashcopy, restore, inquire, unmount, withdraw, or
configure).
A minimum set of DP for Snapshot Devices profile entries must be defined. These
are:
global topic:
LOGON_HOST_PROD
Specifies the TCP name of the production system and db2<sid> user ID
with which the FlashCopy request will be performed.
LOGON_HOST_BACK
Specifies the hostname of the backup system on which tdphdwdb2 will be
started and will call the splitint program of DP for Snapshot Devices to
take care of activating the functions (such as FlashCopy) on the storage
system.
IDS_CONTROL_FILE
Specifies the file that will contain the status and summary information for
the various backup cycles. The file must be accessible via NFS from the
WORK_DIR
Specifies the directory where the temporary files of a backup cycle are
kept. The file must be accessible via NFS from the production and backup
systems.
CONFIG_FILE
Specifies the file to receive the encrypted information created when you
run the configure function of tdphdwdb2. The file must be accessible via
NFS from the production and backup systems.
TDPR3_CONFIG_FILE
Specifies the name of the DP for mySAP for DB2 UDB configuration file.
COPYSERVICES_HARDWARE_TYPE
Specifies the type of hardware subsystem. Possible values are:
ESS800 | SVC | DS6000 | DS8000 | SAN_NSERIES.
Note: These values are mutually exclusive: only one of the options is
supported. However, a combination of ESS and DS devices is
possible in an SVC framework. This allows FlashCopy operations
|
|
|
|
|
|
|
|
from ESS to DS and vice versa. The value SAN_NSERIES requires
the installation package for Data Protection for N Series Snapshot for
mySAP.
db2 topic:
DB2_REMOTE_ALIAS
Specifies the database alias on which the remote database is cataloged on
the backup system.
DB2_RECOVERY_LOG
Specifies the name of the DP for mySAP for DB2 UDB recovery log file. DP
for mySAP writes all information on backups to this file.
DB2_TDPR3_LIB
Specifies the name of the DP for mySAP for DB2 UDB vendor library that
is called by the db2 backup and db2 restore commands.
DB2_NUM_SESSIONS
The number of TSM sessions to be used for the db2 backup and db2
restore commands. When creating a backup to multiple locations, a higher
number of sessions may be used to improve performance.
DB2_PARALLELISM
Determines the number of tablespaces which can be read in parallel by the
DB2 backup utility. If the parameter is not specified, tdphdwdb2 uses the
default value, which is 1.
DB2_NUM_BUFFERS
The number of buffers to be used for the db2 backup and db2 restore
commands. The default is 2. However, when creating a backup to multiple
locations, a larger number of buffers may be used to improve performance.
DB2_BUFFER_SIZE
The size, in 4 KB pages, of the buffer used when building the db2 backup
image and restoring a backup image.
copyservices_data topic:
PRIMARY_COPYSERVICES_SERVERNAME
Defines the TCP/IP address of the host running the DS Open API CIM
Agent (or the SVC master console), or of the NetApp filer.
COPYSERVICES_USERNAME
Defines the username which was set up by the DS Open API CIM Agent
(or the SVC master console), or the one set up to use the NetApp API. The
username must have been defined by the storage device administrator.
VOLUMES_FILE
Specifies the name of the file containing, at a minimum, a list of all target
volumes planned for use. The file must be accessible via NFS from the
Note: This file is not required for N Series devices, because the target
volumes are allocated automatically by the device when a snapshot
is requested.
Other parameters and details are described in Chapter 7, The DP for Snapshot
Devices Profile (.fcs) and Target Volumes File, on page 143.

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The setup.sh shell script (see Installing DP for Snapshot Devices on page 58)
provided you, in the directory you specified, a DP for Snapshot Devices profile,
which you should adapt with the values you need. It is similar to the sample
shown in Sample DP for Snapshot Devices Profile on page 241.
Checking Environment Variables
This section describes the requirements related to environment variables.
For Production and Backup Systems
The following changes are required for the production and backup systems. See
Configuring DP for Snapshot Devices on the Backup System (setupDB2BS) on
page 65.
tdphdwdb2 requires that the PATH environment variable include the /usr/sbin
directory. If this directory is not in the chain of PATH directories, it must be added
as follows:
v If the Korn shell is used, the statements
PATH=${PATH}:/usr/sbin
export PATH
have to be added to $HOME/.profile.
v If the C shell is used, the statement
setenv PATH ${PATH}:/usr/sbin
must be added to $HOME/.cshrc
The variable $HOME normally points to the home directory of user ID db2<sid>. In
addition, the variables DB2INSTANCE and DB2DBDFT must be set to the SAP
DB2 instance name (db2<sid>) and database name; this is normally done by the
mySAP installation.
Another environment variable must be set correctly for using DP for Snapshot
Devices with DP for mySAP. It only applies to DP for mySAP releases up to 3.2.0.9.
This is done by DP for mySAP setup.sh on the production system:
DB2_DIAGPATH=/db2/<SID>/dbs
The name of the variable DB2_DIAGPATH in the DP for Snapshot Devices setup
may be confusing. This variable comes with DP for mySAP and normally points to
/db2/<SID>/db2dump, which corresponds to the DB2 database manager variable
DIAGPATH. DP for mySAP uses this variable DB2_DIAGPATH for writing log and
trace files (e.g., the DP for mySAP recovery log file).
For the DP for Snapshot Devices setup we need the DP for mySAP recovery log
file in the NFS mount /db2/<SID>/dbs because then the information on backups
from the production and backup systems is stored in the same file. The name of
this variable is TDP_DIR, and an additional variable, TDP_RLF (Recovery Log
File), has been introduced. If neither TDP_DIR nor TDP_RLF is specified, DP for
mySAP writes log/trace files and the recovery log file to the /tmp directory. If
only TDP_DIR is specified, DP for mySAP writes these files to the directory
specified by TDP_DIR. If TDP_RLF is also specified, the recovery logfile is written
to that directory. For information on how to set the variables DB2_DIAGPATH,
TDP_RLF, and TDP_DIR or about the naming conventions for the DP for mySAP
recovery log file see the Data Protection for mySAP Installation and Users Guide for
DB2 UDB.
The name of the DP for mySAP recovery log file has changed as of fix level 3.2.12.
When you upgrade, make sure that you adapt the DP for Snapshot Devices profile
parameter DB2_RECOVERY_LOG accordingly. If you want to restore backups
taken with an older version of DP for mySAP after this upgrade, you have to
merge the DP for mySAP recovery log files before starting DP for Snapshot
Devices program tdphdwdb2, or you have to restore manually by using the db2
restore command.
For Production Systems
Setting the ENV environment variable for the Korn shell:
For the remote exec call of splitint on AIX, the ENV environment variable must
be set only on the production system. The following entry must be inserted into
the /etc/environment file:
ENV=$HOME/.profile
This will ensure that the database-specific variable setting in .profile will take
effect for the tdphdwdb2/splitint run. Make sure that the environment settings are
correct for both the C and Korn shells. That means you have to adapt all login
scripts (.profile, .login, .cshrc) and SAP and DB2 profiles
(.dbenv_<hostname>.csh, .dbenv_<hostname>.sh, .sapenv_<hostname>.csh,
.sapenv_<hostname>.sh) for the user db2<sid>.
Initializing DP for Snapshot Devices
TCP/IP client/server socket communication is implemented between the backup
and production systems. In the case of a production database running on DB2
UDB EE, the socket server running on the production system is used to open a
connection to the production database and to suspend/resume the production
database write activity on request of the socket client (on the backup system). In
the case of DB2 UDB EEE, for each EEE partition in the production database, one
dedicated socket server is running on the corresponding production server. In
addition, one socket server is also used to synchronize all EEE partitions while
doing backups and restores with DP for Snapshot Devices. This TCP/IP
client/server socket communication implementation avoids production database
hang situations in case of network problems because the connection to the
production database is held locally on the production server. DP for Snapshot
Devices has additionally implemented a function dbresume, which can be used
locally on the production system to resume database write activities, in case of
network problems while performing a FlashCopy Backup. In order to permit the
splitint program of DP for Snapshot Devices to run the FlashCopy
13
function on
the production system, you have to provide the password once for the db2<sid>
user ID so that DP for Snapshot Devices can use this password to run the
FlashCopy function on the other system.
In addition, you need to prepare for using the storage system password for the
user with which you will run Copy Services within splitint. You will get this
password from your storage-system administrator. See also
COPYSERVICES_USERNAME.
To do all of the configuration previously described, you should run the following
command on the production system under the user ID db2<sid>:
/db2/<SID>/dbs/tdphdwdb2 -f configure
-p /db2/<SID>/dbs/init<SID>.fcs
13. In the SAP documentation, this copy is referred to as a split-mirror copy.

You will be asked for the TCP/IP port on which the socket server will listen. After
entering a correct TCP/IP port, you will be asked for the password for the user
IDs you have specified in the
v LOGON_HOST_PROD and
v COPYSERVICES_USERNAME
statements in the DP for Snapshot Devices profile. The replies will be encrypted
and stored in the file specified in the CONFIG_FILE parameter of the DP for
Snapshot Devices profile, and the entries in the files /etc/services and /etc/inittab
will be created. In case of DB2 UDB EEE, the configure function must be started on
the coordinating production server (partition 0), and it will automatically create all
entries in the above mentioned files on all production servers (if the production
EEE database is spread over multiple servers).
Whenever the password of the db2 <sid> user ID or the user name used on the
storage system is changed, it is necessary to rerun the configure function.
Whenever the EEE configuration has changed (e.g. after adding an EEE partition to
the DB2 instance or moving an EEE logical partition from one production server to
a new one; see Chapter 9, Considerations for DB2 UDB ESE with DPF, on page
191 for details), it is necessary to rerun the configure function.
Configuring DP for Snapshot Devices on the Backup System
(setupDB2BS)
Certain steps must be performed on the backup system to configure DB2 UDB and
DP for Snapshot Devices. To facilitate setting up the backup environment, the
sample script setupDB2BS can be executed. It is part of the DP for Snapshot
Devices package and is located in
Be careful when running the script, and check the prerequisites below before
starting.
Prerequisites
Before running setupDB2BS, check the following prerequisites:
v A supported DB2 UDB release and maintenance level are installed on the
production and the backup systems.
v setupDB2BS must be run as user root on the backup system.
v You will need a temporary remote shell connection to the production system for
user db2<sid> (.rhosts). After successfully running the script, this rsh
connection setup for user db2<sid> can be removed.
v You will need a standard SAP/DB2 UDB V8.x or V9 ESE installation on the
production system.
v The NFS export of directory /db2/<SID>/dbs must be configured on the
production system; access with user ID root from the backup system must be
allowed. Make sure that the NFS file system /db2/<SID>/dbs is not mounted on
the backup system while running the script. The script will create this
NFS-mount and mount this file system on the backup system.
v A file system /db2/<SID> must be created on the backup system. DB2 will create
the DB2 instance db2<sid> in the file system. Provide at least as much space
for this file system as on the production system. In the case of EEE, the file
system /db2/db2<sid> must also be created on the backup system.
|
|
v DB2 on the production system must have a correct setup of DP for mySAP and
TSM (DSM-variables)
v Make sure that the environment for user db2<sid> on the production system is
set up properly for both the C and Korn shells.
v DP for Snapshot Devices uses rsh and su commands while running several
setup scripts. The output of these commands will be traced from the scripts. If
the /etc/profile or other profiles called during the login process (done by rsh
or su) will produce output to standard output (such as an echo command in
the /etc/profile), the setup script will probably fail. For proper installation and
customization of DP for Snapshot Devices, comment out all commands which
produce output on standard output (e.g. echo commands). This should be done
for user db2<sid> only. After successfully running all setup scripts, these
commands can be included again.
Syntax
The script setupDB2BS is started with the command
cd /usr/tivoli/tsm/acssap/db2/
./setupDB2BS <SID> <production system hostname>
Note: In an HACMP (High-Availability Cluster Multiprocessing) environment, the
hostname command called on the production system can return a different
name than the <production system hostname> that you must provide when
executing the script. The script setupDB2BS can handle this HACMP
environment properly. You do not need to make any adjustments in your
HACMP setup.
Description
The sample script setupDB2BS performs the following steps:
1. Check rsh connection to production server (PS).
The script tries to ping the production server and connect as user root (via
rsh). User root on the backup server must be able to connect to the production
server as user db2<sid>. This means, on the production server you must
create an entry in db2<sid>s $HOME/.rhosts file for user root on the backup
server host (see Setting Up the Remote Shell (RSH) on page 56).
2. Check the TCP/IP service ports for DB2 on the production server.
For a DB2 connection to a remote database, you need to know the TCP/IP
port on which the remote database on the production server listens. This
TCP/IP port is defined in /etc/services and in a DB2 database manager
(DBM) parameter. The entry in /etc/services looks like
sapdb2<SID> 5912/tcp
or in case of EEE or ESE
DB2_db2<sid> 50000/tcp
DB2_db2<sid>_END 50005/tcp
For this port, you will need the DBM parameter SVCENAME set to
SVCENAME = sapdb2<SID>
or in case of EEE or ESE
SVCENAME = DB2_db2<sid>
3. Set TCP/IP service ports for DB2 in /etc/services on the backup server
After checking the port on the production system, the script will create the
same entry in /etc/services on the backup server. If you want to use the
backup server for more than one production server, you must not use
duplicate TCP/IP ports.

|
|
4. Check the DP for mySAP (prole) entry in /etc/inittab on the production
server
For DP for mySAP to work properly, an entry in /etc/inittab must be
created. This will be done by the script setup.sh during the installation and
configuration of DP for mySAP. The script setupDB2BS checks if the entry
exists.
5. Check the DP for Snapshot Devices (idscntl<SID>) entry in /etc/services on
the production server
TCP/IP client/server socket communication is implemented in the product.
This socket communication requires an entry in /etc/services. The entry in
/etc/services looks like
idscntl<SID> 57330/tcp
In case of EEE, additional entries will be created for each EEE logical partition
on each production server. These entries will look like:
idscntl<SID>_0 57340/tcp
6. Set TCP/IP service ports for DP for Snapshot Devices in /etc/services on the
backup server. After checking the port on the production system, the script
will create the same entry in /etc/services on the backup server. If you want
to use the backup server for more than one production system, you must not
use duplicate TCP/IP ports.
7. Check the DP for Snapshot Devices (sock<SID>) entry in /etc/inittab on the
production server
TCP/IP client/server socket communication is implemented in the product.
This socket communication requires an entry in /etc/inittab that will start a
DP for Snapshot Devices socket server on the previously defined TCP/IP port
at system boot time or in case of manually stopping the socket server. The
entry in /etc/inittab looks like:
sock<SID>:2:respawn:su - db2<sid> -c cd /db2/<SID>/dbs/ ; /db2/<SID>
/dbs/tdphdwdb2 -f initsocket -p init<SID>.fcs>/dev/null 2>&1
In the case of EEE, additional entries will be created for each EEE logical
partition on each production server. These entries will look like:
sock<SID>_0:2:respawn:su - db2<sid> -c cd /db2/<SID>/dbs/ ; /db2/<SID>
/dbs/tdphdwdb2 -f initsocket -p init<SID>.fcs -s 0 >/dev/null 2>&1
sock<SID>_1:2:respawn:su - db2<sid> -c cd /db2/<SID>/dbs/ ; /db2/<SID>
/dbs/tdphdwdb2 -f initsocket -p init<SID>.fcs -s 1 >/dev/null 2>&1
These entries will only be checked on the production system. They will not be
created on the backup system.
8. Check NFS export on production server
DP for Snapshot Devices requires an NFS connection between the production
and backup systems. Before running the script setupDB2BS , this NFS export
must be created (see Setting Up the NFS File System on page 55).
9. Check for the existence of the file system /db2/<SID> on the backup system
The script checks if the file system /db2/<SID> exists on the backup system.
This file system is needed to separate all <SID> instances that will be backed
up on the backup system.
10. In the case of EEE or ESE, check for the existence of the file
system /db2/db2<sid> on the backup system.
11. Create DB2 directories on the backup server.
The script creates all directories on the backup system:
|
|
|
|
|
|
|
|
|
|
|
/db2
/db2/db2<sid> (only in the case of EEE or ESE)
/db2/<SID>
/db2/<SID>/db2<sid>
/db2/<SID>/sapdata1..n
/db2/<SID>/sapdatat
/db2/<SID>/log_dir
/db2/<SID>/log_archive
/db2/<SID>/log_retrieve
/db2/<SID>/db2dump
/db2/<SID>/errors
/db2/<SID>/dbs
12. Check and create the db<sid>adm group (same GID as on production server)
The script checks for group db<sid>adm on the production system and
creates the same group with the same group ID on the backup system. Make
sure that no duplicate group IDs exist in your overall SAP environment.
Otherwise you will run into problems when setting up the backup system.
13. Check and create the db2<sid> user (same UID as on production server)
The script checks for user db2<sid> on the production system and creates the
same user with the same user ID on the backup system. Make sure that no
duplicate user IDs exist in your whole SAP environment. Otherwise you will
run into problems when setting up the backup system.
14. Set password for db2<sid>
The script asks for the new password for user db2<sid>
15. Check and create the dba group (same GID as on all production servers)
The script checks for group dba on the production system and creates the
same group with the same group ID on the backup system. This group is not
created in a standard SAP/DB2 environment. DP for Snapshot Devices needs
a group to which all DB2 admin users belong, because of file access
permissions. Make sure the group ID of dba is the same on all production
systems and on the backup system.
16. Change the user rights for all files in the directory /db2/<SID> on the backup
system to user db2<sid> and group db<sid>adm.
The script is executed by the user root. After creating all of the directories, all
files in the directory /db2/<SID> are owned by root. In this step of the script,
the user rights of all these files will be changed to user db2<sid> and group
db<sid>adm.
17. Create NFS mount /db2/<SID>/dbs on the backup system
The NFS mount /db2/<SID>/dbs will be created and mounted on the backup
system.
18. Mount the NFS file system /db2/<SID>/dbs on the backup system
The script now mounts the NFS file system /db2/<SID>/dbs on the backup
system.
19. Check for the existence of DP for Snapshot Devices programs in the directory
/db2/<SID>/dbs (NFS file system)
The script checks if the DP for Snapshot Devices programs tdphdwdb2 and
splitint exist in the NFS-mounted file system /db2/<SID>/dbs. If they do not,
an error in the DP for Snapshot Devices installation process on the production
system is indicated.
20. Check for the existence of DP for Snapshot Devices and DP for mySAP license
files in the directory /db2/<SID>/dbs (NFS file system).
The script checks if the DP for Snapshot Devices and DP for mySAP license
files agentess.lic/agent.lic exist in the NFS-mounted file system

/db2/<SID>/dbs. If not, an error in the DP for Snapshot Devices installation
process on the production system is indicated.
21. Copy the DB2 environment from the production server to the backup server
(.dbenv_<hostname>.<sh>, .profile, .cshrc, .login)
To set up the SAP/DB2 environment for user db2<sid> on the backup system,
the script copies all needed environment files from the production to the
backup system:
.dbenv_<hostname>.sh
.dbenv_<hostname>.csh
.profile
.cshrc
.login
All files are located in the $HOME directory of user db2<sid> (in EE normally
/db2/<SID> and in EEE normally /db2/db2<sid>).
22. Create DB2 instance db2<sid> on the backup system
The DB2 instance db2<sid> will be created on the backup system.
The command for creating the DB2 instance db2<sid> with TCP/IP port 5912
for user db2<sid> is:
<DB2DIR>/instance/db2icrt -a SERVER -p sapdb2<SID>
-s ese -w 64 -u db2<sid> db2<sid>

where <DB2DIR> is the DB2 installation directory
23. Check the TSM settings on the production server, copy dsm.opt from the
production to the backup system
The TSM configuration on the production system will be checked and the
configuration file dsm.opt will be copied from the production to the backup
system.
24. Set DB2 registry and database manager parameters on the backup system
The DB2 registry variable will be set on the backup system:
db2set DB2COMM=TCPIP
The database manager parameter is set with the command:
db2 update dbm cfg using SVCENAME sapdb2<SID>
or in the case of EEE or ESE:
db2 update dbm cfg using SVCENAME DB2_db2<sid>
In the same way, the other database manager parameters will be set:
SYSADM_GROUP = db<sid>adm
DFTDBPATH = /db2/<SID>
DIAGPATH = /db2/<SID>/db2dump
25. Catalog TCP/IP node REM<SID> on the backup system
A remote TCP/IP node REM<SID> will be cataloged on the backup system
with the following command:
db2 catalog tcpip node REM<SID> remote <production system host>
server sapdb2<SID> remote_instance db2<sid>
or in case of EEE or ESE:
db2 catalog tcpip node REM<SID> remote <production system host>
server DB2_db2<sid> remote_instance db2<sid>
26. Catalog database <SID> as R_<SID> at node REM<SID> on the backup
system
|
|
|
|
|
|
|
|
The production DB2 database will be cataloged as a remote DB on the backup
system with the following command:
db2 catalog db <SID> as R_<SID> at node REM<SID>
27. Start DB2
The database manager on the backup system will be started with the
command:
db2start
28. Create all EEE partitions on all backup servers
At this point, the DB2 administrator has to manually add as many EEE
partitions to the backup system as exist on the production system. If multiple
backup servers are used, make sure that all backup servers are configured
correctly for DB2 UDB EEE before adding new EEE partitions. If the
production system consists of only one EEE partition, then no action is
required.
If the script fails at any point in the execution, you must resolve the error and
rerun the script.
After successful execution of setupDB2BS, you must run the DP for mySAP and
DP for Snapshot Devices setup scripts. Since both now run on the NFS-mounted
directory /db2/<SID>/dbs, they will find the already customized profiles from the
production system and will not change them. After both setup scripts have
finished, DP for Snapshot Devices for DB2 UDB has been configured on the
production and backup systems, and you can perform backups via FlashCopy.

Uninstalling DP for Snapshot Devices
To uninstall DP for Snapshot Devices, do the following:
1. Log in as root user
2. The uninstall procedure requires a graphical X-Window. Ensure that the
environment variable DISPLAY is set to host:display, where host identifies the
host name of the X Server to be contacted and display is the display number.
3. Invoke the executable <installation path>/_uninst/uninstaller.bin
where:<installation path> is the installation path:
and follow the instructions of the uninstall dialog.

Chapter 4. Backup Methods
Note: The term FlashCopy in this chapter should be interpreted as meaning the
snapshot function if N series devices are configured.
DB2 files for large databases can be spread over many physical volumes in a large
number of ways. Together with the complexity of how files can be spread over
physical volumes and in the context of using Logical Volume Managers, online and
offline backup and restore/recovery procedures can become highly sophisticated
when using diskcopy-supported backup techniques
14
. To avoid any unforeseen
situations, the disk environment should have been planned and set up similarly as
discussed in Overall Disk Layout Considerations on page 34.
In order to provide a safe and simple strategy for image disk backups, DP for
Snapshot Devices allows only full database backups.
It is also possible to back up tablespaces or offline log files without involving
image disk backup techniques, as explained under Database Backups Without
FlashCopy Backup Disks on page 76.
The image disk backups are the result of the FlashCopy function of Copy Services.
Note: For restore/recovery purposes, the FlashCopy disk backups can be used
only with the techniques described in Chapter 5, Restore Methods, on
page 81.
Database Backups With FlashCopy Backup Disks
DB2 in conjunction with DP for Snapshot Devices supports full database disk
backups via the FlashCopy function
14
.
Note: It is required to have all disks (source/target volumes) on which the
database files reside (see tdphdwdb2 run log, part 1) set up in such a way
that for all source/target volumes
v a source and its equivalent target volume are in the same LSS (this
restriction does not apply if FlashCopy V2 is installed).
v a source and its equivalent target volume have the same size
v source volumes contain only files that are part of the backup (DP for
Snapshot Devices / DP for mySAP) that follows the FlashCopy disk
backup operation.
The backups must be started on the backup system. tdphdwdb2 uses splitint to
initiate a FlashCopy disk backup of the SAP DB2 database on the production
system and to make the file systems on the FlashCopy disk backup (target
volumes) available on the backup system; tdphdwdb2 then uses the DP for mySAP
product for the actual backup. After the backup of the database files, tdphdwdb2
will again call splitint to free up the target volumes so they can be reused in a
new backup cycle.
14. In SAP documentation, normally referred to as split-mirror disk backup.

|
|
tdphdwdb2 uses the DP for Snapshot Devices profile, which was set up at
customization time for FlashCopy
14
backups, and tdphdwdb2 performs all the steps
required for this backup cycle.
tdphdwdb2 must be started as user db2<sid> as follows:
cd /db2/<SID>/dbs
./tdphdwdb2 -f backup -p /db2/<SID>/dbs/init<SID>.fcs
to start a full database backup (having invoked the FlashCopy function). See
Syntax of the DP for Snapshot Devices Command tdphdwdb2 on page 106.
DP for Snapshot Devices and DP for mySAP will use their own profiles (see the
relationships of these profiles in Figure 10 on page 39).
The actual backup will be done by DB2 via DP for mySAP.
A FlashCopy backup request can create 2 sets of backup objects with different
backup types; each one can be used for a restore. The 2 backup possible backup
types are:
v a Tivoli Storage Manager (TSM) backup. The backup resides on the Tivoli
Storage Manager server media (usually tapes).
v a FlashCopy backup. The backup resides as an image on disks (target volumes
created with the FlashCopy request). The disks can be used for quick restores
such as the FlashBack Restore; not every disk copy can be used for a quick
disk restore.
Both backup types can coexist or be created independently. Whether both or only
one are created during a FlashCopy backup depends on the intended
FLASHCOPY_TYPE (see Intended and Effective FLASHCOPY_TYPE on page
75). You can use tdphdwdb2 (see Syntax of the DP for Snapshot Devices
Command tdphdwdb2 on page 106) to check which backup copy type is
available and the status of backup copy type.
Notes:
1. In the unlikely case of an unexpected event on the backup system, such as a
system crash or outage at the moment when DP for Snapshot Devices
(-f flashcopy/backup) performs the system management function
importvg/recreatevg on behalf of the DP for Snapshot Devices flashcopy
function, the system is left in a state in which another -f flashcopy will fail at
the point where it is affected by the previous outage or system crash. However,
importvg will at this time repair the ODM environment such that a subsequent
-f flashcopy request will not encounter problems.
2. The DP for Snapshot Devices multiple target support can allow the start of a
new FlashCopy backup if the FlashCopy type of a still-running background
copy is different (see Chapter 10, Multiple Backup Generations (Target Sets) on
Disk, on page 219).
Target Set State
A target set can have one of the following states:
AVAILABLE
The initial state of the target set after you have set up the target set in the
storage system and the DP for Snapshot Devices target volumes file (.fct).
A target set will also be assigned this state when it has been freed using
the DP for Snapshot Devices withdraw function.
Backup Methods

IN_USE
The state once DP for Snapshot Devices has used it within a FlashCopy
Backup and has not done a DP for Snapshot Devices withdraw.
To get information about the target set state, use the DP for Snapshot Devices
ts_inquire function. When working with multiple target sets, see Chapter 10,
Multiple Backup Generations (Target Sets) on Disk, on page 219 for additional
information.
Intended and Effective FLASHCOPY_TYPE
The intended FLASHCOPY_TYPE is the value specified by the DBA in a profile or
on the command line. DP for Snapshot Devices determines the intended
FLASHCOPY_TYPE by checking, in a FlashCopy backup, for the
FLASHCOPY_TYPE value in the mySAP and DP for Snapshot Devices profiles as
follows:
1. The FLASHCOPY_TYPE parameter value in the DP for Snapshot Devices
profile (.fcs) is examined first; if this parameter is not specified, the default
value COPY will be used.
2. The FLASHCOPY_TYPE value of the copy type parameter (-C
<flashcopy_type>), if specified in the tdphdwdb2 command line, will override
the value found in 1.
3. Use of the -f flashcopy function of tdphdwdb2 will reset the
FLASHCOPY_TYPE parameter value to COPY if the intended
FLASHCOPY_TYPE from 1. and 2. is NOCOPY.
Besides the intended FLASHCOPY_TYPE, an effective FLASHCOPY_TYPE will be
used when running the FlashCopy backups with the target set parameter (-n) in
an environment where multiple target sets are configured for the backups (see
Chapter 8, DP for Snapshot Devices Functionality for AIX LVM Mirrored
Environments, on page 161 and Chapter 10, Multiple Backup Generations (Target
Sets) on Disk, on page 219). The effective FLASHCOPY_TYPE takes the conditions
applying to multiple target sets into consideration and can therefore differ from the
intended FLASHCOPY_TYPE.
FlashCopy Backup in a SAN Volume Controller Environment
A FlashCopy with an SVC has the following characteristics, requirements, and
restrictions:
v Volumes in the SVC are referred to as virtual disks (vDisks) and are addressed by
a logical unit number (LUN). The user can define the virtual disks in the Web
GUI of the SVC master console.
v In the SVC, FlashCopy occurs between a source virtual disk and a target virtual
disk.
v The virtual disks must have the same size.
v A virtual disk is designated by a name, which must be unique.
v The minimum granularity that SVC supports for FlashCopy is an entire virtual
disk. The FlashCopy of part of a virtual disk is not supported.
v The source and target virtual disks must both be managed by the same SVC
cluster, but they may be in different I/O groups within that cluster.
v The source and target virtual disks are available (almost) immediately after the
FlashCopy is initiated.
Backup Methods
Chapter 4. Backup Methods 75
v After the start of the FlashCopy, the target and source may be updated
independently
v SVC FlashCopy associates a source virtual disk and a target virtual disk together
in a FlashCopy mapping.
v Each virtual disk may be a member of only one FlashCopy mapping, and a
FlashCopy mapping always has exactly one source and one target virtual disk.
Therefore, it is not possible for a virtual disk to simultaneously be the source for
one FlashCopy mapping and the target for another.
v The sizes of vDisks that are members of a FlashCopy mapping cannot be
changed while the mapping is in effect.
v An SVC supports the creation of enough FlashCopy mappings to allow each
virtual disk to be a member of a FlashCopy mapping.
v Incremental FlashCopy is not supported by the SVC
v The use of multiple target volumes associated with the same source volume is
not supported.
v The SVC requires that the SDD be installed on all attached hosts.
Consistency groups: A FlashCopy Backup from an SVC employs consistency groups.
Consistency groups address the issue that the using application may have related
data which spans multiple virtual disks. In the past, TSM for ACS ensured the
consistency of data by either setting the database in backup mode and applying
the database logs after a restore or suspending the database during the short
period of time required to create the point-in-time FlashCopy The time to initialize
a point-in-time FlashCopy took from 1 to 5 minutes, depending on the number of
disks. The consistency group feature can be expected to reduce that time to less than
one minute. In order to create a consistent image of the customer data it is
necessary to perform a Flash Copy operation on multiple virtual disks as an
atomic operation. A FlashCopy mapping is built between a source and target
virtual disk. A FlashCopy mapping must be a member of a consistency group. A
consistency group can contain an arbitrary number of Flash Copy mappings, up to
the maximum number supported by an SVC cluster. The SVC Start command
causes the point-in-time copy to be directed to a consistency group. In this case, all
of the mappings in the consistency group are started at the same time, resulting in
a point-in-time copy that is consistent across all mappings in the group.
Database Backups Without FlashCopy Backup Disks
Partial backups of a database (such as tablespace backups) can be performed, but
on the production system only. The DB2 backup command will work together with
DP for mySAP, but will not be utilized for DP for Snapshot Devices (splitint).
Also, running a full online/offline backup without interfering with DP for
Snapshot Devicess FlashCopy (splitint) on the production system is possible.
Backups of the Offline Log Files
There are a number of backup methods available with the Admin Tools to back up
the DB2 offline log files. The DBA tool that initiates and controls the backup of
these files is brarchive.
The backups must be started on the production system. brarchive uses the DP for
mySAP product for the actual backup. For example, backing up the offline log files
and automatically deleting the files after they are backed up could be started as
user db2<sid> as follows:
Backup Methods

brarchive -sd
In this sample, the default DBA setup from R/3 post-installation (sddb6ins) has
been used. For details on the brarchive command, see the SAP manual BC R/3
Database Guide: DB2 Universal Database for UNIX & Windows or run brarchive -help.
Note: Ensure that, after any online or FlashCopy backup has been completed, a
brarchive run is scheduled to back up the offline log files. In the case of a
restore of such online backups, only the existence of such log files allows a
successful database recovery.
In future releases of DP for Snapshot Devices, backup of offline log files will be
implemented.
How to Start the Backups
The above backups can be started either
v manually by entering the commands as shown above, or
v automatically using schedulers as described below
Automated Backup Start via Schedules
The following two types of schedules
15
can be used to run the FlashCopy disk
backups on the backup system automatically:
v Tivoli Storage Manager schedules
v UNIX crontab
The scope of control of the Tivoli Storage Manager is at an enterprise level. The
UNIX crontab can only be used to set up schedules on systems on which the
backups will be later performed.
Tivoli Storage Manager Schedules
The Tivoli Storage Manager also provides functions for automating client
operations by defining a new schedule or updating an existing schedule.
Schedule definition work can be done quickly using the GUI-based Tivoli Storage
Manager Web administrative client.
When a schedule is defined, it will be assigned to a specific policy domain (more
than one schedule for each policy domain can be defined). For this purpose, the
database client requires a schedule that provides for the execution of command
files. The command files (for example, shell scripts on UNIX) contain sequences of
commands that are run at a scheduled start date and time.
Information on how to define Tivoli Storage Manager schedules can be found in
the Tivoli Storage Manager Administrators Reference manual.
This method could be used to set up the schedules (for the backup of log files, for
example) on the production system.
15. The SAP Computing Center Management System (CCMS) scheduler cannot be used to schedule the backups on the backup
system; CCMS can only be used for backup work which will be done on the production system.
Backup Methods
Note: For schedules, it is recommended to utilize the UNIX crontab method due to
the difficulties
16
which might occur in a backup strategy using TSM
schedules with one TSM node name in a 2-system environment.
UNIX crontab
Another possibility for backup automation is offered by the cron jobs for UNIX
systems.
UNIX cron jobs can be scheduled with the so-called crontab command, which
invokes an editing session that allows you to create a crontab file. The cron jobs
and the appropriate times are defined within the crontab. The crontab can be
customized with the command:
crontab -e
For example, you want a cron job to start a shell script backup_flashcopy.ksh (the
contents of backup_flashcopy.ksh can be found in Elements of Backup Schedules
in the Data Protection for mySAP Installation and Users Guide for DB2 UDB) from
Monday through Friday at 11:30 p.m. which will use tdphdwdb2 to save the SAP
database. In this case, the entry in the crontab to start the script will be as follows:
0 23 * * 1,2,3,4,5 /usr/bin/su - db2<sid>
-c "/db2/<SID>/sapscripts/backup_flashcopy.ksh"
backup_flashcopy.ksh is supplied with the installation and can be found after
setup in /usr/tivoli/tsm/acssap/db2/.
Backup Strategy and Automation
The products described in this manual
v DP for Snapshot Devices (tdphdwdb2)
v DP for Snapshot Devices (splitint)
v DP for mySAP
provide high-availability backups of the DB2 database objects. In planning the
backups of
v operating system, DB2 system data, and SAP system data
v offline log files
v backup protocols and profiles
you can find detailed information in Backup Strategy and Backup Automation in
the Data Protection for mySAP Installation and Users Guide for DB2 UDB.
To also cover disaster recovery failures, it is recommended after each execution of
tdphdwdb2 to run an incremental backup of the NFS directory with the TDP
Backup/Archive client command dsmc, with focus on the files/directories
specified in the various parameters in the DP for Snapshot Devices profile.
Warning: The sequence of the required system management operations issued by
the DP for Snapshot Devices functions can work properly only as long
as the status of the objects (e.g., mounted file systems, mounted volume
groups, available devices) used for a database has not been changed by
an authorized user.
16. After expiration of the password change interval, the passwords must be synchronized on both systems at the same time.
Backup Methods

|
Example:
If, after successful completion of the DP for Snapshot Devices unmount
or withdraw function, an authorized user should have a need to again
import volume groups and/or mount file systems of a database, he
would have to take all steps necessary to restore the system
management objects to the state prior to the intervention. If this is not
done, a new tdphdwdb2 (flashcopy) for the database would, according to
the backup cycle state (PSI_UNMOUNT_DONE or
PSI_WITHDRAW_DONE) known to it, be allowed to start but would fail
(probably with fsck).
Note: If a set of target volumes is planned to be used for the FlashCopy backup of
several databases, only sequentially controlled backups (with a completed
backup cycle for each database in turn) are allowed (see also Shared Usage
of Target Volumes on page 58).
Backup Methods
Backup Methods

Chapter 5. Restore Methods
Note: In an N Series environment, the terms FlashCopy and Flashback Restore in this
chapter should be interpreted as meaning the snapshot and snapshot-restore
functions if N series devices are configured.
The range of methods to restore a mySAP
17
DB2 database includes the snapshot
features of the storage system, which is FlashCopy for Disk Storage
(DS6000/DS8000), ESS 800, and SAN Volume Controller, and NetApp snapshot for
N Series devices.

Warning
We strongly recommend that you practice the restore and recovery on a test
system as similar as possible to your production system. Repeat this test
regularly, especially after you have modified your system or your
restore/recovery concept.
Depending on the chosen backup method (see Chapter 4, Backup Methods, on
page 73), you (as a database administrator) can now, for restore/recovery
purposes, use the DP for Snapshot Devices component tdphdwdb2 to select
between
v an entire database restore from the TSM server through either the LAN or SAN
environment or
v an entire database restore employing the FlashCopy feature, hereafter referred to
as FlashBack Restore.
18
v multiple levels of disk copy backups when using multiple target sets
In general, two different types of backup objects may be available for the restore
process:
v a TSM backup type and
v a FlashCopy backup type
Depending on the chosen function of the FlashCopy Backup command, both
backup types may be eligible for one backup level for a restore. It might happen,
however, that a FlashCopy backup type is not yet eligible, although the FlashCopy
Backup on the backup system completed successfully, because the background
copy has not yet finished (for details, see Restore Function on page 110).
The first restore method uses backup objects that reside on the TSM server; these
objects will be referred to as TSM backup type objects.
The second restore method will handle backup objects residing on the so-called
target volumes created in the backup run with a FlashCopy process; these objects
will be referred to as FlashCopy backup type objects.
17. In prior releases and documentation, the term SAP R/3 is used.
18. This type of restore is often referred to in various publications as a Quick Restore or FlashCopy Restore.

|
|
|
|
|
|
|
You still have the option of using the commands db2 restore and db2 rollforward
for a restore/recovery. Using these commands, however, will not allow you to
make use of the FlashBack Restore capability. For information on using these
commands see:
v the relevant mySAP DBA documentation
v the restore/recovery information in the Data Protection for mySAP Installation and
Users Guide for DB2 UDB
v the Tivoli Redbook Using TSM to Back Up Databases
The following will describe how and under which conditions the above two DP for
Snapshot Devices restore/recovery methods can be used
Using tdphdwdb2 for Restore and Recovery of DB2 Databases
For both restore methods, tdphdwdb2 provides functions that facilitate the
restore/recovery work for the mySAP DB2 database administrator.
All DB restore/recovery work has to be done on the production system. Even
when choosing the FlashBack Restore, the production system needs connections
(network or SAN) to the TSM server for retrieving the transaction log files for
recovery purposes.
Note: At present, tdphdwdb2 can perform only a full restore/recovery of the
database.
You will have to log in as user db2<sid> on the production system and, depending
on the kind of error, run a full restore/recovery with the objects of a complete
offline/online backup and with the necessary transaction log files; tdphdwdb2 will
guide you through the restore/recovery process.
In this process, you will be
v shown the various available backup levels and their available backup types
(TSM or FlashCopy) and will then make a selection
v asked how far the recovery should proceed
Depending on the selection, the restore process is initiated by tdphdwdb2 by issuing
either
v the db2 restore command, which will call DP for mySAP to retrieve backup data
(TSM backup type) from TSM or
v splitint the other component of DP for Snapshot Devices to run the
FlashBack Restore to make the FlashCopy Backup type objects available on the
production system.
A recovery process will then be initiated by tdphdwdb2.
There are two different cases to be considered:
v recovery after the restore of a TSM backup type by DP for mySAP has
completed.
v recovery immediately after the FlashBack Restore of a FlashCopy backup type
has started the FlashCopy and remounted the relevant DB2 file systems.
Restore Methods

Prior to initiating the recovery by calling the db2 rollforward command, DP for
Snapshot Devices will tell you, via breakpoint message IDS2522I, what log files
may have to be retrieved first, specifying the first file in the series (see Restore
Function on page 110).
Note: Be aware that you have the advantage when selecting the restore of the
FlashCopy Backup type objects (requesting a FlashBack Restore) that the
recovery and the subsequent start of the database can be done even while
the background copy process initiated by the FlashBack Restore is still
running. This should allow you to get the database ready for production
much quicker than using the restore of the TSM backup type objects through
a LAN or SAN and then running database rollforward recovery.
The following shows how tdphdwdb2 can be called for a restore/recovery:
cd /db2/<SID>/dbs
./tdphdwdb2 -f restore [database] [no/rollforward] -p /db2/<SID>/dbs/init<SID>.fcs
which will allow the restore of backup objects from either the TSM server or target
volumes of a previous FlashCopy backup.
For detailed information about the DP for Snapshot Devices restore functions, see
Restore Function on page 110.
Information about the restore/recovery run can be found in the files listed in
Appendix C, Summary of Log and Trace Files, on page 329
Important Information for Profiles
There is no problem using different DP for mySAP profiles on the backup and
production systems. However, you must ensure that both profiles have the same
values for the relevant parameters for DP for mySAP, which are
v CONFIG_FILE
v BACKUPIDPREFIX
v MAXVERSION
v SERVER
v ADSMNODE
v PASSWORDREQUIRED
v BRBACKUPMGMTCLASS, and
v BRARCHIVEMGMTCLASS
Following this rule, the DP for mySAP profiles used when you work with
tdphdwdb2/db2 restore/db2 rollforward can restore all objects on the production
system regardless of whether they were backed up on the backup system in
conjunction with DP for Snapshot Devices or on the production system without DP
for Snapshot Devices. Figure 10 on page 39 shows the relationships of the various
control files and profiles.
However, whenever possible, it is recommended that you use only one profile for
each of the components DP for mySAP and DP for Snapshot Devices, in order to
keep the overall setup as simple as possible.
Restore Methods
Chapter 5. Restore Methods 83
Important Information about the Backup History File
DB2 UDB has its own history file for storing all information about backup, restore,
and changes in the database (such as adding containers to a tablespace), for
example. To list information from the backup history file, you use the command:
db2 list history backup all for <SID>
or
db2 list history rollforward all for <SID>
For more information about the db2 list history command, see IBM DB2 UDB
Command Reference.
To restore a backup that was performed on the local production system, you can
find the timestamp of the backup with the db2 list history command. If the
backup was performed with DP for Snapshot Devices on the backup system, DB2
does not know about this backup of FlashCopy on the production system. This is
due to the fact that DB2 performs the backup on the backup system and writes all
information about this backup (such as the timestamp) in the backup history file
on the backup system. After the withdrawal of the FlashCopy, this backup history
file no longer exists.
For this reason, DP for mySAP has another log file (DP for mySAP recovery log) to
collect all information about backups/restores done with DP for mySAP. This log
file is placed in the directory /db2/<SID>/dbs, which is NFS-mounted on the
backup system. This means that all backups performed by DP for mySAP on the
production or backup systems will be logged in the same DP for mySAP recovery
log file. To view the contents, you could use the command:
pg /db2/<SID>/dbs/tdprlf.<SID>.NODE0000.backup.log (release 3.2.0.11 and earlier)
pg /db2/<SID>/dbs/tdprlf.<SID>.NODE0000.log (release 3.2.0.12 and later)
or
vi /db2/<SID>/dbs/tdprlf.<SID>.NODE0000.backup.log (release 3.2.0.11 and earlier)
vi /db2/<SID>/dbs/tdprlf.<SID>.NODE0000.log (release 3.2.0.12 and later)
To simply view the DP for Snapshot Devices and DP for mySAP backup history,
you can use the command tdphdwdb2 -f restore -p <profile>. Do not select a
backup to restore but rather just x to cancel the DP for Snapshot Devices restore
process.
FlashBack Restore Considerations
This section discusses topics related to FlashBack Restore.
What is FlashBack Restore?
DP for Snapshot Devices uses the storage systems FlashCopy feature to back up a
DB2 UDB database from the production system to the Tivoli Storage Manager
Server storage. In earlier releases, the DB2 restore command was used to restore
the database back to the original source volumes on the production system via
SAN or LAN connections. The FlashBack Restore method is now provided to
restore the database. FlashBack Restore uses the FlashCopy feature to restore a
database directly from the backed up volumes (so-called target volumes) on the
storage system (instead of from the Tivoli Storage Manager Server) to the original
source volumes on the production system. The volumes then undergo a DB2
rollforward recovery to restore the database state to a particular point in time.
Restore Methods

Due to the risks involved in performing a FlashBack Restore when changes have
been made to the AIX disk storage management objects and/or database
tablespaces since the corresponding FlashCopy Backup, you are offered two
breakpoints that allow you to
1. determine, on a file system level, what differences exist in the
storage-management or database environment since the FlashCopy Backup was
performed
2. before the database is rolled forward, restore any log files needed for the
rollforward and/or reconstruct changes made after the previous backup.
These breakpoints are implemented by messages IDS1084I and IDS2522I,
respectively, and you have the opportunity in each case to perform any necessary
actions before continuing.
File system and tablespace changes made after the previous backup must be
reconstructed prior to database rollforward, because the track-oriented FlashCopy
phase of the FlashBack Restore will overwrite them.
Figure 11 depicts the FlashBack Restore process.

Why Use FlashBack Restore?
FlashBack Restore offers the following benefits:
v A quick restore of the production database in the event of a major failure.

Figure 11. FlashBack Restore Process
Restore Methods
v A restore of a database along with the storage structures of the operating system
that may have been lost after the original backup, such as the tablespaces, file
systems and volume groups.
v In earlier releases, only one disk backup version could be created and used for
restore purposes. With the capability to perform FlashCopy Backup to multiple
target sets, several disk backup levels can be created (see Chapter 10, Multiple
Backup Generations (Target Sets) on Disk, on page 219).
v When using an AIX LVM mirrored setup (see Chapter 8, DP for Snapshot
Devices Functionality for AIX LVM Mirrored Environments, on page 161 for
this special environment) it was possible even in earlier releases to run a
FlashBack Restore from one target set back to the one (source) copy set from
which it was created in a FlashCopy backup. Thus, a maximum of two target
sets, one for each copy set, could be selected for a FlashBack Restore.
DP for Snapshot Devices allows more than one target set for one (source) copy
set in the various FlashCopy backups (see Chapter 10, Multiple Backup
Generations (Target Sets) on Disk, on page 219). The DBA has the option of
selecting one of several target sets for a FlashBack Restore to a copy set.
When Not to Use FlashBack Restore
FlashBack Restore must not be used in the following situations:
1. If the source volumes on the production system specified by the
TARGET_VOLUME parameter in the DP for Snapshot Devices target volumes
file (.fct) used for the FlashBack Restore differ from the source volumes that
were specified by the TARGET_VOLUME parameter in the DP for Snapshot
Devices target volumes file, were used for the original backup, and not all are
still available. FlashBack Restore to a new location is not supported.
2. If you are unsure of what backup images you have on the target volumes that
you plan to restore using FlashBack Restore (see also the requirement for
maintaining the integrity of the target volumes as documented in FlashBack
Restore Limitations on page 87).
3. If the source volume configuration on the production system to be used in the
FlashBack Restore differs from the source volume configuration that existed
during the original backup and you want to preserve the current source
volume configuration. Some original source volumes may have been given to
another application.
Note: In such a case you might only be able to use a TSM backup for a restore,
if all necessary tablespace containers are available for restore and
recovery. See also the discussions for FlashBack Restore Scenarios 5, 6,
and 7 starting on page 101.
4. If the last backup of the database was performed using DP for Snapshot
Devices with the FLASHCOPY_TYPE parameter specified as NOCOPY.
tdphdwdb2 provides the necessary information.
5. If the FlashCopy agent process initiated by the DP for FlashCopy Backup has
not yet detected that the FlashCopy has physically completed and the process
is therefore not yet ready for a FlashBack Restore. tdphdwdb2 provides the
necessary information.
6. If, after a FlashCopy Backup was performed, a double volume assignment
condition has been created due to environment changes and, at the time of the
FlashBack Restore, the following situation exists for a physical disk (volume)
that was part of the DB FlashCopy Backup:
v The disk has been removed on the production system from a database
volume group and
Restore Methods

v its AIX device and vpath has not been removed and
v it is still assigned to the production system and
v it has been assigned to another system.
DP for Snapshot Devices cannot detect such an improperly managed
environment change. Once the first breakpoint message IDS1084I (see What is
FlashBack Restore? on page 84) has been answered with cont, DP for
Snapshot Devices will either
v run successfully if the volume is not yet being used in a new volume group
or
v terminate with message EEP0302E if the volume is already being used in a
new volume group or is accidentally being used at the same time in a
FlashCopy for another system.
Note: Be aware that the production source volumes other than the one
which is doubly assigned will now be overwritten by the FlashCopy
background copy activities.
The production system now is in an unrecoverable state, as long as the
missing source volume is not returned to the production system and is
no longer in use elsewhere. Even having the source volume back again
cannot guarantee that the FlashBack Restore rerun will be successful.
The difficulties and unforeseen complications you might run into (including a
corrupted and unrecoverable production system) should alert you not to leave
the production system environment in a situation as described above after AIX
disk storage management changes have been performed.
The consequence is that, after a source volume has been removed from the DB
volume group:
a. remove its hdisk and vpath
b. unassign it from the production system
c. remove the entry in the DP for Snapshot Devices target volumes file (fct)
d. run a new FlashCopy Backup to make a new FlashCopy type backup
available for a FlashBack Restore.
FlashBack Restore Limitations
Understanding the Limitations
An extract from a FlashBack Restore run log (see below) will make it easier to
understand the FlashBack Restore limitations, especially the discussion about the
impact of AIX disk storage management changes by the administrator within the
involved DB volume groups between the FlashCopy Backup and the FlashBack
Restore, and what action might be required before and while the tdphdwdb2
FlashBack Restore and database recovery are running.
An extract from such a run log, with the relevant parts described in this chapter,
appears as follows:
Restore Methods
EEP0293I List of the current file systems on the backed up volume groups ...
Name Nodename Mount Pt VFS Size Options Auto Accounting
/dev/lvE01data1 -- /db2/E01/sapdata1 jfs 655360 rw yes no
/dev/lvE01datat -- /db2/E01/sapdatat jfs 655360 rw yes no
/dev/lvdb2E01e01 -- /db2/E01/db2e01 jfs 655360 rw yes no
EEP0294I List of file systems which will be restored...
IDS1084I This is your last chance to stop the FlashBack Restore. Please enter cont
to continue or stop to terminate.
.....
IDS2522I Press [ENTER] when all logfiles are restored.

You will get the above information once you have completed the selection menu of
the tdphdwdb2 restore function (see Restore Function on page 110 for details).
Two file system summaries will be shown, followed by the first breakpoint
message (IDS1084I) and, when the first has been answered with cont, the second
breakpoint message (IDS2522I). By the time IDS2522I appears, DP for Snapshot
Devices has started the FlashCopy for all source/target pairs and mounted all the
file systems of the file system summary listed under message EEP0294I.
The purpose of the first breakpoint message (IDS1084I) is to allow you to
v end the FlashBack Restore (without changing anything on the production
system)
v first check the summaries to determine if you have to do any manual redo work
prior to answering the second breakpoint message.
Message EEP0293I summarizes the file systems and their sizes as they are now
encountered at FlashBack Restore time (see exception below), and message
EEP0294I does the same for the file systems and their sizes as they existed at
FlashCopy Backup time. If you have changed the AIX disk storage environment (of
the DB volume group(s) involved in the FlashCopy Backup) between the
FlashCopy Backup and FlashBack Restore, you will see that not all file systems
and/or sizes will match in the two summaries; this will therefore need your
intervention as discussed in the specific limitations that follow.
Notes:
1. File systems for tablespace containers which were created in new volume
groups are not shown in the above summaries and need to be tracked by the
administrator himself.
2. Once you rerun a FlashBack Restore (you might have already restored the file
systems of the FlashCopy Backup because the first break message was
answered with cont and the FlashBack completed successfully), it can happen
that the first file system summary (listed under EEP0293I) no longer matches
the one presented before the first FlashBack Restore run. If you still want to
check on the information of the first FlashBack Restore run, you need to look
this up in the tdphdwdb2 restore run log.
Restore Methods

The purpose of the second breakpoint message (IDS2522I) is to allow you to do
one or more of the following before allowing the DB2 rollforward recovery to start:
v check for the existence of logfiles (some might first need to be restored)
v if required, redo the changes for the new/changed file systems (needed in the
time span of the DB rollforward recovery) on the basis of the changes discussed
in conjunction with the first breakpoint message.
v drop and recreate the SAP DB2 administration database (see Restore Function
on page 110).
Description of FlashBack Restore Limitations
When planning to use the FlashBack Restore functionality of DP for Snapshot
Devices, be aware of the following limitations:
Limitation 1
Any time, following a FlashCopy Backup, that you make changes on the
production system to the AIX disk storage management objects that are used by
the DB objects, you should perform a new FlashCopy Backup of the database
(and/or to TSM Storage Manager storage) in order to avoid minor or major
conflicts in case you need to run a FlashBack Restore.
Despite the above recommendation, however, the FlashBack Restore can be used in
such a modified system environment under the following conditions:
v The FlashBack Restore can be used if you can redo the changes within the
FlashBack Restore run (at the second breakpoint message IDS2522I) and if the
changes are not covered by the reasons specified in When Not to Use FlashBack
Restore on page 86.
You might need to redo acceptable environment changes at breakpoint message
IDS2522I in cases where, for the purpose of new tablespace creation or
tablespace extension:
a new file system has been established within the DB volume groups in use
a file system has been extended within the DB volume groups in use
a new source volume has been added to the DB volume groups in use
a new volume group with file systems has been added to the existing DB
volume groups.
Note: Environment changes in the context of using a previous FlashCopy
Backup for a FlashBack Restore are not allowed whenever a source volume
has been removed from the production system and can no longer be
returned (see When Not to Use FlashBack Restore on page 86). Ignoring
this restriction and using the FlashBack Restore in an incorrect
environment might leave the production system in a corrupted state (see
points 5 and 6 below). See also the details of such an attempt under
FlashBack Restore Scenario 7: Source Volume Not Properly Removed on
page 102).
v The FlashBack Restore can be used if you are familiar with the FlashBack
Restore and have a good knowledge of AIX disk storage management and DB2
rollforward recovery such that you can, if required, manually redo the changes
(prior to the continuation at the second breakpoint message IDS2522I) to permit
a successful DB2 rollforward recovery. See the samples shown in the DP for
Snapshot Devices FlashBack Restore scenarios below.
Restore Methods
There are basically two reasons that special attention and help by an
administrator are required when a FlashBack Restore is desired but the AIX disk
storage management objects used for the DB have been changed since the
FlashCopy Backup:
The FlashCopy performed in the FlashBack Restore needs all source volumes
that were part of the FlashCopy Backup, and these objects (with the
underlying AIX disk storage management metastructure) can be restored as a
unit only.
The DB2 rollforward requires that you redo any system environment changes
such as those mentioned above at breakpoint message IDS2522I
19
, as they
were previously done between the FlashCopy Backup and the start of the
FlashBack Restore.
Validation by DP for Snapshot Devices Prior to Restore: As previously noted,
removing a source volume from a DB volume group involved within the
FlashCopy Backup and then using this backup in a FlashBack Restore can leave
your system in a corrupted state. Within its FlashBack Restore function, DP for
Snapshot Devices tries to avoid running into this type of critical situation, even if it
cannot detect all such situations. The following will describe what DP for Snapshot
Devices tries to detect and what it cannot. In order to avoid a critical situation, DP
for Snapshot Devices checks, prior to the first breakpoint message IDS1084I,
whether all required source volumes are still present in the relevant DB volume
groups:
1. If all volumes are still present, execution continues, and no further problems
are anticipated.
2. If one or more volumes have been moved on the production system to a
non-DB-relevant volume group, DP for Snapshot Devices will terminate with
error message EEP0290E without making any AIX system management changes
3. If one or more volumes have been deleted from the DB related volume groups
and are still assigned to the production system and not yet assigned to another
system, execution continues and no further problem is anticipated. At the
second breakpoint message IDS2522I, you will again see these source volumes
within the original DB relevant volume groups.
and are still assigned to the production system and in addition are assigned to
another system (double storage-system assignment) and (in contrast to 5.) are
not yet being used in a volume group on the other system, execution continues
and no further problem is anticipated. At the second breakpoint message
IDS2522I, you will see these source volumes again within the original DB
relevant volume groups. Avoid this double assignment, because it can lead to
serious problems (as shown in 5).
5. If one or more volume(s) have been deleted from the DB related volume
group(s) and are still assigned, with respect to the storage system, to the
production system and in addition are assigned to another system (double
assignment) and (in contrast to 4.) are used in a volume group on that other
system:
DP for Snapshot Devices cannot detect such an improper setup and will fail
with error message EEP0302E within the FlashCopy phase after the
continuation reply for the first breakpoint message, in the attempt to FlashCopy
the set of all original source volumes, despite the fact that the set is no longer
complete (incomplete FlashBack Restore process). The result will be a corrupted
19. This message occurs after the FlashCopy phase within the FlashBack Restore has been initiated.
Restore Methods

DB and an AIX disk storage management environment that is no longer usable.
This is because the FlashCopy, the source/target background copy running in
the storage system has been started but not for all volumes.
Note: To avoid this serious problem, always:
v be sure to make only single assignments for a volume, and
v run a new FlashCopy Backup after such environment changes (see
also When Not to Use FlashBack Restore on page 86).
and have been unassigned, with respect to the storage system, from the
production system but the hdisks/vpaths still exist on the production system:
DP for Snapshot Devices cannot detect such an improperly maintained
environment and will fail with error message EEP0302E within the FlashCopy
phase after the continuation reply for the first breakpoint message, in the
attempt to FlashCopy the set of all original source volumes, despite the fact
that the set is no longer complete (incomplete FlashBack Restore process). The
result will be a corrupted DB and an AIX disk storage management
environment that is no longer usable, because the FlashCopy, the background
copy of source/target pairs, has been started but not for all volumes.
Limitation 2
Make sure there are no logical volumes or file systems in the volume groups
associated with the database that belong to other applications. In case of a
FlashBack Restore, these file systems will not be mounted by tdphdwdb2. The
existence of such file systems in the database volume groups can even cause loss of
integrity of the FlashCopy Backup and FlashBack Restore operation for the
database. In case file systems belonging to applications other than the mySAP DB2
application were created in the volume groups that are part of the FlashCopy
Backup, they might be lost or no longer be usable by the other application once the
FlashBack Restore for the mySAP application has been done.
Limitation 3
FlashBack Restore overwrites data from all the storage-system volumes on the
production database server that contain a tablespace container for the associated
database or the local database directory. As a result, it is required that you specify
a dedicated volume group for the database log path. The mySAP DB2 database
installation/configuration process runs the DB2 update database configuration
command with the NEWLOGPATH database configuration parameter to change
the log path to a location other than the local database directory. This prevents the
log files from being overwritten during the FlashBack Restore process. Recovery of
the database to the current point in time will not be possible if log files are
overwritten during the FlashBack Restore process and an archived version of the
current database logs is not available.
Note: It is recommended that this requirement still be met after an installation of a
database with a new mySAP release. Otherwise, you must change the setup
for the database log path as just described.
Limitation 4
DP for Snapshot Devices does not offer you a FlashBack Restore for restore
selection if the backup object is not a FlashCopy backup type. A FlashCopy Backup
creates a FlashCopy backup type only if the DP for Snapshot Devices profile
parameter FLASHCOPY_TYPE is set to COPY or INCR.
Restore Methods
Limitation 5
The FlashBack Restore and recovery process is a menu driven process, which
provides information such as backup history and available backup types (TSM
and/or FlashCopy). Based on the information provided, you will select what will
be restored and how far the recovery has to be done. The DP for Snapshot Devices
restore/recovery has been designed to be a manually driven, menu-guided process
only.
Limitation 6
FlashBack Restore cannot restore a database that was backed up with a version of
DP for ESS prior to 5.3. Such a database backup can only be restored from the
Storage Manager Server using backups with backup type TSM, as long as they are
not in contradiction to the release requirements of DP for mySAP and its
capabilities.
Limitation 7
The database to be restored must not be brought online on the backup system after
it has been backed up by DP for Snapshot Devices. As a result, you must
determine how you will maintain the database copy on the target volumes after
you have run a FlashCopy backup. You can maintain the database copy as a
standby database or as a FlashBack Restore database:
Standby database
You must initialize the database using the db2inidb <dbname> as standby
command, routinely retrieve transaction logs from the production system,
and continually apply these transaction logs to the database. This
maintains the database on the backup system as a standby database. The
database must initially be backed up with the following value specified in
the Setup File:
If you perform a FlashCopy Backup with the DP for Snapshot Devices
backup function, DP for Snapshot Devices initializes the database in this
standby mode automatically.
Note: Be aware that you will not be able to perform a FlashBack Restore
with this database once you have stopped the database recovery on
the backup system by using the command
db2 rollforward db <dbname> stop
FlashBack Restore database
You must not initialize the database on the backup system. This ensures
that the database state remains at the latest backup image and is available
for a FlashBack Restore. The database must initially be backed up with the
following value specified in the DP for Snapshot Devices profile:
If you perform a FlashCopy with the flashcopy function, DP for Snapshot
Devices does not initialize the DB automatically on the backup system.
Limitation 8
You must maintain the integrity of the target volumes used in the FlashCopy
Backup. DP for Snapshot Devices cannot and does not maintain the integrity of
volumes processed by FlashCopy on the storage system. The integrity of the
volumes of a target set will definitely be lost in the following cases, for example:
Restore Methods

1. The complete/partial set of target volumes will be used for a FlashCopy of
other databases/applications.
2. You run the withdraw command for the complete/partial set of target volumes
that were used in a successfully completed FlashCopy Backup run.
3. The database copy (on the target volumes) has been brought up on the backup
system after the successfully completed FlashCopy Backup run (see the above
discussions Standby database / FlashBack Restore database)
4. One or more target volumes of a set of target volumes are no longer available
Limitation 9
The volume group containing the transaction log files must not contain any
tablespace containers or data files, and should be used exclusively for the archive
logs (see also Limitation 3 on page 91). In order to be able to roll the FlashBack
Restore database forward to the current point in time, you need to roll the
database forward using the active logs contained in this volume group in the log
directory. You are responsible for performing periodic backups and archiving these
logs, since DP for Snapshot Devices does not manage log files. The current log
directory for a database can be obtained by issuing the following command:
db2 get db config for <database name>
Look for the path to log files text in the output display. Note that FlashBack
Restore processing overwrites the log files if the log path is in the database
directory (the default location). Use the NEWLOGPATH database configuration
parameter to specify a location other than the database directory. This prevents log
files from being overwritten during FlashBack Restore processing.
Limitation 10
You must maintain the integrity of source/target volumes used in a FlashBack
Restore. DP for Snapshot Devices does not allow you to stop the background copy
process (via the withdraw function) once it is started by a FlashBack Restore. The
reason for this is that withdrawing a source/target relation before all data from the
source volumes has been copied to the target volumes will lead to an undefined
state of all file systems, LVs, and VGs included in the FlashBack Restore on the
production system. This can then be resolved only by unmounting all file systems,
exporting the VGs, recreating the VGs, recreating the LVs, and recreating all the file
systems
Important: After an incomplete FlashBack Restore process, the metastructure data
may be corrupted. Complete metastructure information, however, is
required for restoring a backup from TSM. It is therefore strongly
recommended to keep track of the metastructure data as volume
groups, logical volumes, and file systems in order to recreate the
metastructure manually, or via script, should this be required.
Limitation 11
A FlashCopy backup from ESS volumes cannot be restored directly to DS volumes.
A restore from TSM or an intermediate migration from ESS to DS is required.
Furthermore, backups of databases configured on DS6000 or DS8000 cannot be
restored to an ESS using the earlier DP for ESS versions.
FlashBack Restore Rerun Capabilities
This section describes the restart of a FlashBack Restore that did not complete
successfully.
Restore Methods
What is a FlashBack Restore Rerun?
Under certain conditions, DP for Snapshot Devices allows a Flashback Restore
rerun even if the FlashCopy running in the background has not yet finished for the
latest FlashBack Restore. DP for Snapshot Devices will first check whether a
FlashBack Restore was previously requested and allow the DBA to continue or stop
this FlashBack Restore; the reason for such a rerun can be that the forward
recovery of the previous restore/recovery proceeded too far and there is a need for
another point-in-time forward recovery, or that the FlashCopy failed.
Once you select a backup to be restored, using the restore function of tdphdwdb2,
and reply to the rollforward selection menu, the DB will be stopped, and:
v If a TSM backup type is selected, a DP for mySAP restore will be started with
no additional manual intervention possible
Note: It might happen that the background copy from the first FlashBack
Restore is still running, concurrently with the selected Tivoli Storage
Manager restore. Even this impacts the restore performance. You should
not try to stop the background copy because the results can be
unpredictable.
v If a FlashCopy backup type is again selected, the tdphdwdb2 component splitint
will be called, which in turn will start the FlashBack Restore. At this time, the
first breakpoint message IDS1084I will be displayed to allow to either stopping
or continuing. If you stop the FlashBack Restore at this breakpoint, nothing in
the AIX disk storage environment with respect to the DB has been changed. If
you allow the FlashBack Restore to continue at this breakpoint, then the AIX
disk storage environment with respect to the DB will be deleted and rebuilt as
described in detail within the functional overview of DP for Snapshot Devices
FlashBack Restore on page 16 steps 2b to 3c.
In case, for the reasons discussed below, you need to perform a FlashBack
Restore again, this will be considered a FlashBack Restore rerun.
See Performing a FlashBack Restore Rerun with a Different Target Set on page
233 for information on rerunning a FlashBack Restore from a target set other than
the one used in the initial restore.
Conditions for a FlashBack Restore Rerun
DP for Snapshot Devices allows you to restart a FlashBack Restore, provided,
however, that
v you use the same Backup ID
20
as you did for the preceding Flashback Restore
and
v no condition (see FlashBack Restore Limitations on page 87 ) has occurred in
the meantime which would prohibit such a rerun.
Rerunning such a FlashBack Restore is the only case in which DP for Snapshot
Devices automatically runs a withdraw of all background copy processes started
by the last FlashBack Restore, should this still be required.
Reasons for a FlashBack Restore Rerun
Reasons for such a FlashBack Restore rerun might be:
20. In general, only one Backup ID is available for FlashBack Restore. When running in AIX LVM mirrored environments and using
the DP for Snapshot Devices functionality for AIX LVM mirrored environments, or when multiple target sets are configured, one
of a number of target sets can be selected for a FlashBack Restore.
Restore Methods

v The FlashBack Restore runs successfully, but after restarting the mySAP
application, it is determined that the database was rolled forward too far. This
case can now be resolved quickly by restarting the FlashBack Restore with the
same Backup ID and performing a rollforward to the correct point in time.
v There was a hardware problem after the FlashBack Restore was initiated. For
example, the FlashBack Restore fails after unmounting all file systems, exporting
all VGs and while starting the FlashCopy process for all source/target volume
pairs. If the VGs consist of 10 source/target volume pairs, one reason could be
that, after establishing the FlashCopy for the first 6 pairs, the Copy Services
server returns the error message EEP0302E while establishing the FlashCopy for
volume pair 7.
Once the reason for the storage system failure is resolved, the FlashBack Restore
can be restarted using the same Backup ID.
FlashBack Restore Rerun Limitations
Under certain conditions, a rerun of a FlashBack Restore is not possible:
v The FlashBack Restore runs successfully, but after restarting the mySAP
application, it is determined that the database was rolled forward too far. If there
is now a need to use a backup with an older Backup ID
20
than the one which
was used with a FlashBack Restore (because you actually need to restore to a
point preceding the last FlashCopy Backup), you will have to restore a TSM
backup and perform a rollforward to the correct point in time.

Important Note
If the FlashCopy background copy process of the previous FlashBack
Restore has not yet completed, you must not stop this process (with the
withdraw function), in order not to violate the integrity of the volumes on
the production system (see Limitation 10 on page 93). The restore with
backup objects of the TSM backup type and a subsequent recovery will
need to run with the not-yet-completed FlashCopy background copy
process; however you might see reduced TSM restore performance,
depending on the time elapsed since the FlashBack Restore was started.
v One or more conditions under When Not to Use FlashBack Restore on page 86
are encountered at rerun time that were not true in the prior attempt.
v One or more FlashBack Restore limitations (see FlashBack Restore Limitations
on page 87) are encountered at rerun time that did not apply in the prior
attempt.
A restore with backup objects of a TSM backup type is required in this case.
Sample FlashBack Restore Scenarios
Different FlashBack Restore scenarios will be considered to illustrate the conditions
under which a FlashBack Restore can or cannot be started after a FlashCopy
Backup is done. The following conditions are assumed to be common for all
scenarios:
v The DP for Snapshot Devices profile used during the initial backup
is /db2/E01/dbs/initE01.fcs
v The path to the transaction logs for the database E01 (/db2/E01/log_dir) resides
in a volume group that is not shared with
any tablespace container
the file system of the local database directory (/db2/E01/db2e01) for E01
Restore Methods
The tablespace containers as well as the local database directory are allocated in
volume groups, which are made up of physical disks using source volumes
v The E01 database was originally backed up by logging on to the backup system
as user db2e01 and running the DP for Snapshot Devices backup/flashcopy
command:
cd /db2/E01/dbs
/tdphdwdb2 -f backup t flashcopy unmount nowithdraw -p /db2/E01/dbs/initE01.fcs
The following parameter was specified in the above DP for Snapshot Devices
profile at backup time:
v The above two DP for Snapshot Devices profile parameters cause DP for
Snapshot Devices to initiate a FlashCopy that can be used for a FlashBack
Restore. In addition, DP for Snapshot Devices will start a FlashCopy agent
process that monitors the results of the FlashCopy background copy in the
storage system. A valid FlashCopy Backup type object will only be available for
a FlashBack Restore when the background copy for all involved source/target
volumes has successfully completed.
v Enough time has expired since the FlashCopy Backup was executed, thus
allowing the background copies of all source/target pairs to complete.
v tdphdwdb2 will ask to perform a FlashBack Restore with a DB rollforward
recovery to end-of-logs.
Scenario Descriptions
The following scenarios (except FlashBack Restore Scenario 1: No Changes Made
Since Backup and FlashBack Restore Scenario 9: No Changes Made But
FlashCopy Failed on page 103) describe the situation in which changes to the
system were made after a FlashCopy Backup was done and before the FlashBack
Restore is initiated. The changes to the system are:
v a file system has been added or removed or
v a source volume has been added to or removed from one of the volume groups
after a FlashCopy Backup was run.
v a volume group along with a file system has been added.
Note: Only volumes and file systems that contain DB2 relevant objects (such as
tablespace containers) are the subject of this discussion.
FlashBack Restore Scenario 1: No Changes Made Since Backup
For Scenario 1, the following conditions are assumed.
In this so-called unchanged scenario, no new file systems or logical volumes have
been created on the source volumes the E01 database resides on since the database
was originally backed up with FlashCopy Backup.
The steps to perform a FlashBack Restore of database E01 are as follows:
1. Log on to the production system as user db2e01 and issue the following
command:
cd /db2/E01/dbs
./tdphdwdb2 -f restore -p /db2/E01/dbs/initE01.fcs
2. You can now select the latest backup from the tdphdwdb2 menu (see Restore
Function on page 110) and select a backup type:
v TSM or
v FlashCopy
Restore Methods

Select the FlashCopy backup type for a FlashBack Restore.
Note: The FlashCopy backup is marked with an X, indicating the background
copy is completed and the FlashCopy agent process detected this state.
(X) would indicate the backup type was either invalid or is not yet
complete for a restore.
The menu offers an option to recover and will ask how far to recover.
3. DP for Snapshot Devices now checks on the availability of the source volumes
and whether they are still seen by the production system. In case any of the
source volumes are no longer assigned to the production system, tdphdwdb2
will terminate with message EEP0290E.
4. Assuming all source volumes of the FlashCopy Backup run are still assigned to
the production system, the summaries of file systems (of the DB volume
groups) and their sizes will be shown with message EEP0293I as they currently
exist, followed by message EEP0294I with the file systems and their sizes as
they existed when the FlashCopy Backup was run.
Notes:
a. DB file systems created in volume groups not involved in the FlashCopy
Backup will not be shown in the EEP0293 file system summary.
b. Once you rerun a FlashBack Restore (you might have already restored the
file systems of the FlashCopy Backup because the first breakpoint message
was answered with cont), it can happen that the first file system summary
(listed under EEP0293I) is no longer the way it appeared prior to the first
FlashBack Restore run; if you still want to check on the information of the
first FlashBack Restore run, you need to look in the tdphdwdb2 restore run
log for this information.
Extract from tdphdwdb2 restore run log file:
IDS1084I This is your last chance to stop the FlashBack Restore.
Please enter cont to continue or stop to terminate.
...

The file system summaries are intended to help
v you see changes that occurred in the form of new/extended file systems
v make it easier to decide whether to continue or stop in reply to IDS1084I
v remind you that manual work has to be done in case you identify, by means
of the summary, new or changed file systems that were found at the time of
the FlashBack Restore and that you need to redo the applied AIX disk
storage management changes at the next breakpoint message IDS2522I in
step 5 on page 98.
Since no differences are evident (and this is not a FlashBack Restore rerun and
you have not established any new DB volume groups between the FlashCopy
Backup and this FlashBack Restore) a cont reply is entered.
After DP for Snapshot Devices successfully initiates the FlashCopy within the
FlashBack Restore, it will import the volume groups and mount the file systems
Restore Methods
as they were available at FlashCopy Backup time. In addition, the FlashCopy
agent will be started to monitor the progress of the background copies and,
once they are finished, set the RSI (restore status indicator) to RSI_DISKONLY.
5. After the FlashCopy agent is started, the breakpoint message IDS2522I will be
displayed. Assuming that all log files have been restored and no changes have
been identified, as is the case in this scenario, you can press [ENTER] to roll the
database, which has been in rollforward pending state, forward. For correct
handling of the SAP DB2 administration database, see Restore Function on
page 110.
6. After the recovery processing has completed successfully (even if the
FlashCopy background copy has not completed), you are now able to connect
to the database E01 and start your production again. The FlashCopy
background copy is, in all probability, still running at this point in time.
Notes:
a. As long the FlashCopy background copy (now for the FlashBack Restore)
has not yet completed, no new FlashCopy Backup with DP for Snapshot
Devices can be started.
b. If your FlashBack Restore and recovery was not successful and you receive
an error message, see Appendix B, Data Protection for Snapshot Devices
for mySAP (DB2) Messages, on page 275 for error descriptions and
assistance. You can also view the contents of the log and error log files (see
Appendix C, Summary of Log and Trace Files, on page 329).
FlashBack Restore Scenario 2: File System Added Since Backup
For Scenario 2 the following conditions are assumed:
v Since the database was originally backed up, a new file system was created on
the disk on which the database E01 resides. Two cases are possible:
Case 1: The new file system (/newFS = /db2/E01/sapdatatest2 ) was created
for a new tablespace (PSAPTST2)
Case 2: The new file system contains files that are not part of the FlashCopy
Backup request.
v In Case 1, tables were created and SQL transactions performed on the tables
within the new tablespace prior to the FlashBack Restore.
The FlashBack Restore will remove the new file system (/newFS) once you enter
the continuation reply for breakpoint message IDS1084I. Basically, we perform the
same steps (1 to 6) as in FlashBack Restore Scenario 1: No Changes Made Since
Backup on page 96. Steps 1 to 3 are handled in the same manner as in that
scenario. When running step 3, the tdphdwdb2 FlashBack Restore function issues
warning messages after noticing that the configuration has changed since the
database was originally backed up, as a result of the new file system, /newFS.
On the screen, you see the following (extracted from the tdphdwdb2 restore run
log file):
Restore Methods

/dev/lvtest2 -- /db2/E01/sapdatatest2 jfs 655360 -- no no
Name Nodename Mount Pt VFS Size Options Auto
...

At the breakpoint message IDS1084I, it is evident that redo work will be necessary
at breakpoint message IDS2522I to recreate the new file system.
The two cases considered here are:
Case 1, New File System is DB-Related: The new file system (/newFS=
/db2/E01/sapdatatest2) contains database related data such as tablespace
containers. You can now let the tdphdwdb2 FlashBack Restore continue as
discussed in FlashBack Restore Scenario 1: No Changes Made Since Backup on
page 96, step 4. However, you need to remember that, once the first breakpoint
message has been answered, at the second break point message IDS2522I (step 5 of
FlashBack Restore Scenario 1: No Changes Made Since Backup on page 96) you
need to redo the changes that are required to recreate the new file system, because
the FlashCopy that runs within the FlashBack Restore will restore only those file
systems (see summary under message EEP0294I) that existed at FlashCopy Backup
time (see FlashBack Restore Limitations on page 87). Once you have recreated
the new file system, you have to mount it and change its owner and permissions.
Then you can let tdphdwdb2 continue by just pressing the [ENTER] key to
complete step 5 and allow the DB rollforward recovery for the E01 database to
complete. During the recovery, any new tablespace containers will be automatically
allocated via the DDL within the new file system and updated properly.
Case 2, New File System is Not DB-Related: If the new file system (/newFS)
does not contain database data (see FlashBack Restore Limitations on page 87),
then you could support the FlashBack Restore and recovery process as follows:
1. Again, you would see the file system listed in the file system summary at
breakpoint message IDS1084I. If you want to preserve this file system, which
does not belong to the DB, you can first check whether you have a good
backup of this new file system (/newFS) available that could be used for a later
restore; if not, first back it up (to TSM, for example).
2. Allow DP for Snapshot Devices to continue the FlashBack Restore and recovery
to steps 4 to 6. This will delete the new file system and perform the restore and
recovery of the DB.
3. Manually recreate the new file system in a volume group that does not contain
E01 database objects, to avoid restore conflicts in the future.
4. Manually restore /newFS (from TSM, for example).
Note: Be aware that any future FlashBack Restores will again restore the
non-DB related file system if you leave it within the DB related volume
groups (see Limitation 2 on page 91).
Restore Methods
FlashBack Restore Scenario 3: File System Removed Since
Backup
For Scenario 3, the following conditions are assumed:
A DB-related file system was removed from the disks the database E01 resides on
since the database was originally backed up.
Note: The administrator removed this file system only from the VG but not from
any of the source or related target volumes.
The tablespace PSAPTST1 which was used up to and after the FlashCopy Backup
has been dropped and the file system unmounted. Should a FlashBack Restore
without a new FlashCopy Backup now be required, the same steps as in
FlashBack Restore Scenario 1: No Changes Made Since Backup on page 96 are
executed.
Steps 1 to 3 are handled in the same manner as in Scenario 1.
log file):
/dev/lvtest1 -- /db2/E01/sapdatatest1 jfs 655360 -- no no
...

At breakpoint message IDS1084I, you see that no redo work will be necessary at
breakpoint message IDS2522I. If you check what file systems are available at the
time the break message IDS2522I is displayed, you will see as a result of the
FlashBack Restore that the system /db2/E01/sapdatatest1 is again available with
a DB2 tablespace container allocated in it. After you enter the reply for the
breakpoint message IDS2522I, the tablespace will be dropped and its container
deleted (or reset to 0) during the recovery; the db2 list tablespaces command will
no longer show the tablespace PSAPTST1. Once tdphdwdb2 has completed, you
can unmount and remove the file system again (for cleanup purposes).
FlashBack Restore Scenario 4: Source Volume Added
After a FlashCopy Backup, a new source volume was added to one of the database
volume groups that had been part of a previous FlashCopy Backup.
Case 1, No File System or Tablespace Created: Neither a file system nor a
tablespace was created prior to the FlashBack Restore. You can run the FlashBack
Restore, including DB recovery, without having to redo any work at the second
breakpoint IDS2522I, because no file system mismatch exists between the two
summaries shown at the first breakpoint message IDS1084I.
Restore Methods

Case 2, File System Created: A file system was created, but no tablespace was
created before the FlashBack Restore. You can run the FlashBack Restore, including
DB recovery, without being required to redo any work at breakpoint message
IDS2522I, even if a file system mismatch exists in the two summaries, because the
tablespace has not yet been created and the file system will therefore not be used
in the DB rollforward recovery. It would, however, be advisable to create the file
system at the breakpoint IDS2522I if you are not sure whether a tablespace has
been already created, to avoid the risk of a failure in the DB recovery (see Case 3).
Case 3, File System and Tablespace Created: You created a file system and a
tablespace therein prior to the FlashBack Restore. At the breakpoint message
IDS1084I, a file system mismatch will be shown as in Case 2. In this case, you need
to perform the system changes at the time of the second breakpoint message
IDS2522I, in order to avoid DB2 recovery failure.
FlashBack Restore Scenario 5: Source Volume Removed from
Volume Group But Still Present
After a FlashCopy Backup, a source volume was removed from one of the VGs
that had been part of the previous backup. It is assumed that you restructured one
or more file systems within the related VG in such a way that one source volume
(used in the FlashCopy Backup) was freed up and removed from the VG.
You know the following:
v the volume has not yet been reused in another VG
v the volume is still assigned only to the production system (this can be verified
using the ESS STORWATCH tool)
v vpath and hdisk information is still available on the production system.
When running the FlashBack Restore, you will probably see differences in the file
system sizes when the file system information is displayed, followed immediately
by the first breakpoint message IDS1084I:
v the current file systems (identified with message EEP0293I), and
v the file systems (identified with message EEP0294I) as they were when the
FlashCopy Backup was executed
With your knowledge of
v the previous restructuring and
v a volume that is still assigned and not being used elsewhere
you could request continuation at the first breakpoint message, which will result in
a start of the FlashCopy for all source/target pairs used at FlashCopy Backup time.
The source volume that was removed from the VG will definitely be required in
the subsequent recovery (remember that the assumption was recover to
end-of-logs).
During the FlashBack Restore, no redo work is necessary.
After the FlashBack Restore has successfully completed, you can again remove the
source volume from the DB volume group; once you have done this and
performed another FlashCopy Backup, this source volume will no longer be part of
a future FlashBack Restore.
Restore Methods
FlashBack Restore Scenario 6: Source Volume Removed and
Reassigned or No Longer Present
that had been part of a previous FlashCopy Backup. The source volume is already
being used either in another volume group on the production system for another
application or is no longer assigned to the production system.
The FlashBack Restore will terminate prior to the first breakpoint message
IDS1084I with error message EEP0290E, because the source volume is required and
is already assigned to a volume group other than the volume groups used at
FlashCopy Backup time (see point 2 under Validation by DP for Snapshot Devices
Prior to Restore on page 90). The same result will be seen if the source volume is
already assigned to another system and the production system was left in a clean
state (hdisk and vpath removed as well) after the volume was unassigned from the
production system.
As long as the previously used source volumes are not available, it is impossible to
run the FlashBack Restore (see When Not to Use FlashBack Restore on page 86),
and only a TSM backup type can be used for a restore.
FlashBack Restore Scenario 7: Source Volume Not Properly
Removed
that had been part of a previous FlashCopy Backup. The source volume is still
assigned to the production system and the original vpath/hdisk is still shown to
be available in the ODM and is assigned and in use within a volume group on
another system.
Even though it is very unlikely that a source volume will be removed from a DB
volume group and, in conjunction with this removal, the system incorrectly left in
the condition described, this type of scenario is shown to alert you to the critical
situation which you will run into if you ignore the information given in
FlashBack Restore Limitations on page 87 and the reasons listed under When
Not to Use FlashBack Restore on page 86.
This kind of scenario demonstrates that you have not correctly performed all the
changes for the AIX disk storage management environment (vpath and hdisk were
not removed for the volume that is no any longer available) and a FlashBack
Restore is done despite not being allowed.
In contrast to FlashBack Restore Scenario 6: Source Volume Removed and
Reassigned or No Longer Present, the FlashBack Restore under these conditions
(hdisk/vpath in the ODM) cannot detect that the source volume is no longer
available and will display the first breakpoint message IDS1084I. Once you allow
continuation, the FlashCopy within the FlashBack Restore will fail with message
EEP0302E, leaving a corrupted DB and/or a damaged AIX disk storage
management environment.
Notes:
1. DP for Snapshot Devices assuming all original source/target pairs are
available for the FlashBack Restore has, for the reasons shown above, started
the FlashCopy for the complete original set of volumes, even though the set is
Restore Methods

not actually complete. This will cause copies to the production system to be
done for the source/target pairs except for the one that is no longer available;
the metastructure of the AIX disk storage environment, however, can only be
used if it is flashed back in the FlashBack Restore as one unit, i.e., if all
volumes in the FlashCopy backup are available at restore time. To remedy this
situation, you will have to manually rebuild the AIX disk storage environment
and run a restore with a TSM type backup.
2. If you remove a source volume from its DB volume group and the source
volume is no longer available, it is imperative to run a new FlashCopy Backup
after such a change in order to be able to run the FlashBack Restore with no
conflict.
FlashBack Restore Scenario 8: File System Size Increased
After a FlashCopy Backup, the size of an existing file system within the DB related
volume groups was extended. This kind of scenario is to be handled similarly to
the FlashBack Restore Scenario 2, where a new file system was added to the DB
related volume group.
log file) :
...

The above system summaries show that the size of file system /db2/E01/sapdata1
was increased since the FlashCopy Backup was done. The FlashCopy of the
FlashBack Restore will show a file system with a smaller size than is currently seen
for the present file system.
Therefore, once you have entered cont for the first breakpoint message (IDS1084I),
you should be prepared at the next breakpoint message (IDS2522I) to redo all the
changes that were done prior to the FlashBack Restore to increase the size of file
system /db2/E01/sapdata1, thus allowing the DB recovery following the IDS2522I
message to perform all activities for (new) containers in this extended file system.
FlashBack Restore Scenario 9: No Changes Made But FlashCopy
Failed
No AIX disk storage management changes were done on the production system
after the FlashCopy Backup, and all source/target volumes of the FlashCopy
Backup are available. However, a FlashBack Restore fails after the first breakpoint
message with IDS0302E, indicating that the request for a FlashCopy for all
source/target volumes could not be fully satisfied and one or more volumes will
not be copied. The FlashBack Restore will end up with a mix of good and bad
Restore Methods
copies on the production system. No DB related volume groups remain available
on the production system. A FlashBack Restore rerun is required.
This situation exists when a FlashBack Restore has terminated with error message
IDS0302E, but all source volumes were available prior to the first FlashBack
Restore attempt. This means there was apparently a temporary problem with the
hardware unit or with the applicable Copy Services server. Prior to the subsequent
FlashBack Restore rerun, you should first analyze and remove the cause of the
error situation (see Appendix C: Summary of Log and Trace files). After resolving
the cause of the error and starting a FlashBack Restore rerun, you will be asked
(with rerun breakpoint message IDS2098I, prior to the first breakpoint message
IDS1084I) to allow the FlashBack Restore Rerun to continue. If you select
continuation, the FlashBack Restore will first break the FlashCopy relationship for
all source/target pairs that remained from the just-terminated FlashBack Restore
run before it again displays the first breakpoint message IDS1084I. This withdraw
is required because you cannot request that a FlashCopy be done again as long as
there is still a source/target relationship established.
The FlashBack Restore run will then again provide the two breakpoint messages
you normally see. The discrepancies you have in the file system summaries at the
first breakpoint message IDS1084I are irrelevant in this case, because of the
FlashBack Restore rerun condition. This scenario (unchanged AIX disk storage
management) can then continue as described in FlashBack Restore Scenario 1: No
Changes Made Since Backup on page 96.
Restore Methods

Chapter 6. Description and Usage of the DP for Snapshot
Devices Commands
DP for Snapshot Devices is split into the two components splitint and tdphdwdb2.
While splitint represents the part controlled by the storage system, which is
database independent, tdphdwdb2 is the DB2 dependent part and the user interface.
Functions of the DP for Snapshot Devices Command splitint
DP for Snapshot Devices provides the command splitint to run functional requests
for the storage system:
v FlashCopy source volumes of a storage system containing the DB2 database
objects (such as tablespace containers) for a full backup to target volumes of a
storage system
v (FlashBack) Restore target volumes of a storage system, containing the DB2
database objects of a previously taken FlashCopy Backup, in reverse to the
source volumes of a storage system on the production system.
v Withdraw the FlashCopy source/target volume relationship after the backup has
been performed on the backup system or before starting a new FlashCopy
Backup.
v Withdraw_Force to run the unmount function and withdraw the FlashCopy
source/target volume relationship after the backup has been performed on the
backup system or before starting a new FlashCopy Backup. It differs from
withdraw in that the states of the BSI and PSI are ignored.
v Query whether the setup will allow running the FlashCopy. The query function
is planned only for setup checks and will not subsequently be used in the
normal backup procedures.
v Unmount file systems and vary off volume groups
v Inquire about the status of the backup cycles.
v (TS_)Inquire about the status of one or all target sets
v Modify the copy rate of an SVC FlashCopy process.
The storage-system-specific part of DP for Snapshot Devices and its functions have
been designed for use within tdphdwdb2. All functions are called from tdphdwdb2
and are explained in Syntax of the DP for Snapshot Devices Command
tdphdwdb2 on page 106.

Syntax of the DP for Snapshot Devices Command tdphdwdb2

DP for Snapshot Devices provides the database-specific command tdphdwdb2.
This is the coordinating part of DP for Snapshot Devices. While performing
functions like backup, flashcopy, restore, unmount, or withdraw, it calls DB2 as
well as the storage-system part of DP for Snapshot Devices (splitint).
DP for Snapshot Devices (splitint) will be involved from the time the user
db2<sid> requests a FlashCopy disk backup (using source and target volumes)
until the target volumes are withdrawn, if required, and from the time the user
requests a FlashBack Restore until the background copy process is finished.
In this document, such a period will be referred to as a backup cycle and the status
of such a backup cycle is used to control the status of the mounted file systems
which are made available on request of a FlashCopy operation.
The backup or flashcopy function of tdphdwdb2, which is always started on the
backup system, can initiate on the production system either
v a FlashCopy with the NOCOPY option (preferred for normal backups) or
v a FlashCopy with the COPY or INCR option (for backup/cloning and for
FlashBack (FlashCopy Restore))
unmount withdraw
-t flashcopy

nounmount

nowithdraw

tdphdwdb2

-f backup

-t online

-p

profile

-t offline

database

rollforward

-f restore

norollforward

-f query

-f flashcopy

-f unmount

-f withdraw

-f withdraw_force

-f inquire

,

-r

fieldno

-b

backup sequence number

-f ts_inquire

-f configure

-i

password input file

-f password

-i

password input file

-f modify_copyrate

-R

copyrate

-f dbresume

-s

DB partition number

-f restart_backup

-C

flashcopy type

-n

target set number

Figure 12. Syntax of the DP for Snapshot Devices Command tdphdwdb2
DP for Snapshot Devices Commands

|||
The restore function of tdphdwdb2, which is always started on the production
system, can initiate either
v a restore from TSM via DP for mySAP or
v a FlashBack (FlashCopy Restore)
and a subsequent rollforward of the restored database.
This chapter
v describes the details of the various functions of the DP for Snapshot Devices
command tdphdwdb2 and how the functions can be initiated
v shows the role of the DP for Snapshot Devices backup and restore cycles
For sample cases demonstrating the proper use of tdphdwdb2, see Sample
tdphdwdb2 Usage on page 259.
Backup Function
Description
The backup function is used to perform a backup of the SAP DB2 UDB database.
If no option is given, tdphdwdb2 performs a backup of FlashCopy with unmount
and/or withdrawal of the target volumes. The default cleanup work depends on
the FLASHCOPY_TYPE specified in the DP for Snapshot Devices profile. In the
case of NOCOPY, an unmount and withdrawal will be done. In the case of COPY
or INCR, only an unmount will be done.
You can specify the type option -t flashcopy and the parameter nounmount in
conjunction with nowithdraw, which prevents the unmount and withdrawal after
the backup. You can further specify the parameter unmount with the parameter
nowithdraw, which unmounts the targets after the backup but does not withdraw
them. These options are only possible when the function is initiated on the backup
system.
When performing a Backup with option FlashCopy and with FLASHCOPY_TYPE
COPY or INCR, you will get a point-in-time copy of your production database.
Make sure that the copy process in the background is finished before starting the
withdraw. You can use this point-in-time disk copy for a later FlashCopy Restore
(FlashBack Restore). See Chapter 5, Restore Methods, on page 81 and Restore
Function on page 110 for further information.
On the production system, you must use the function backup with the type
options -t online or -t offline. tdphdwdb2 will then perform a full online/offline
database backup on the production system.
Once initiated on the backup system (either without any options or with type
option -t flashcopy [no/unmount] [no/withdraw]), the backup function of
tdphdwdb2 will perform the following actions:
v use DB2 remote connection to get the filenames of the relevant database files
from the DB2 production system
v call splitint with the list of files to get the disk volumes which will be the
candidates for the subsequent FlashCopy.
check the status of the previous backup cycle to determine whether a new
backup cycle can be started. If the status of a previous backup is other than
PSI_FLASHCOPY_QUERY or PSI_UNMOUNT_DONE (in the case of a
FLASHCOPY_TYPE of COPY or INCR), or PSI_WITHDRAW_DONE (in the
Chapter 6. DP for Snapshot Devices Commands 107
case of a FLASHCOPY_TYPE of NOCOPY), splitint will terminate with RC
< 0 to indicate to tdphdwdb2 that the previous request failed or file systems
are still mounted. As a consequence, tdphdwdb2 will also fail. The user will be
asked to first use the withdraw function.
Note: In case multiple target sets are specified in the DP for Snapshot Devices
target volumes file, this check will be done for volumes of the target
set used, depending on
- whether specific or automated target selection is desired, and
- the outcome of the selection algorithm
Check the RSI (Restore Status Indicator) for a still-active background copy
initiated by a FlashBack Restore. If the value is
- RSI_START: terminate (a FlashCopy of a previous FlashBack Restore has
not yet completed)
- RSI_INVALID: issue a warning, reset the RSI, and continue
- anything else: continue
start a new backup cycle
v put the DB2 production database in write suspend mode.
v prepare the flashcopy call of splitint with the list of disk volumes that will be
the candidates for the subsequent FlashCopy. The flashcopy request is based on
information tdphdwdb2 will find in the profile it is using (NOCOPY/COPY/
INCR) See Intended and Effective FLASHCOPY_TYPE on page 75.
v on the production system, perform, based on the file list received by tdphdwdb2,
a FlashCopy for all the disk volumes (source) over which the various files are
spread
v and after calling splitint with a flashcopy request:
check the return code from splitint:
if nonzero, terminate with error messages
if 0, continue
v start the FlashCopy agent process on the backup system to observe the
FlashCopy in the storage system (only if the FlashCopy type is set to COPY or
INCR)
v put the DB2 production database in write resume mode.
v On the backup system, perform the following task to allow files (on the target
volumes) to be read:
cfgmgr -v -l fsci/scsi ...
1. Run cfgmgr to identify the new volumes
2. Import all necessary volume groups if required
3. Mount all necessary file systems
4. Set the status of the current backup cycle to PSI_MOUNT_DONE.
5. return control to tdphdwdb2 with RC=0, which can now call DP for mySAP to
back up the files
v check on the backup system for the existence of all database files on so-called
target volumes, which it had asked splitint (with option flashcopy) to create
using a FlashCopy
v call the db2 backup command, which calls DP for mySAP to back up the
database
v after DP for mySAP has finished the backup, call splitint again to unmount file
systems, export volume groups, and withdraw target volumes if not prevented
with the given options.

See Unmount Function on page 124 and Withdraw Function on page 121.
v finish the tdphdwdb2 run (remove any lock files).
During the various activities, splitint will
v provide information in its own log files (see also Appendix C, Summary of Log
and Trace Files, on page 329)
v write information to the tdphdwdb2 backup file
v on request, write traces for service if required
v update the current backup cycle, which can be viewed with the tdphdwdb2
inquire function.
For more information about the backup of a DB2 database, see DB2 Data Recovery
and High Availability Guide and Reference and DB2 Command Reference and the IBM
Redbook Working Together: IBM ESS with DB2 UDB.
Usage
The backup function was developed for the SAP database administrator to perform
a backup of a FlashCopy on the backup system. When tdphdwdb2 is started with
the backup option, the program will perform all the steps that need to be done
within the complicated process of a FlashCopy.
With the type options online/offline, the SAP database administrator can
perform backups on the production system and with the flashcopy option on the
backup system. The SAP database administrator can perform most types of backup
with a single command.
In the context of supporting multiple target sets, the following options can be used:
v the -C <flashcopy_type> option to run specific types of FlashCopy Backups
(INCR, COPY, or NOCOPY), and
v the -n x option to select a specific target set for the backup
For details, see Chapter 10, Multiple Backup Generations (Target Sets) on Disk,
on page 219
Syntax
On the backup system:
cd /db2/<SID>/dbs
./tdphdwdb2 -f backup [-t flashcopy
[no/unmount] [no/withdraw]]
On the production system:
cd /db2/<SID>/dbs
./tdphdwdb2 -f backup -t online/offline
where
/db2/<SID>/dbs/init<SID>.fcs
is the DP for Snapshot Devices profile.
If, for any reason, the use of a user-written script is planned and tdphdwdb2 is
called in that script, the developer of such a script must ensure that
v tdphdwdb2 is called in the script as shown above.
v Any output written to stdout starts with #INFO.
v The return codes of tdphdwdb2 are propagated to the script
To avoid any undefined situation, it is recommended not to use such scripts.
System to be performed on: Backup system (type flashcopy) or production system
(type online/offline)
Restore Function
Description
The restore function can be used to restore and recover the production database.
DP for Snapshot Devices supports two types of restore:
v Restore from TSM
v FlashCopy Restore (FlashBack Restore) from a previously taken FlashCopy
Backup
tdphdwdb2 guides you through the restore and recovery process with a menu
driven user interface.
The following steps will be done:
v A menu is presented from which the SAP database administrator can select the
backup to be restored.
v For a refresh of the menu press r and [ENTER]. This will check the backups in
TSM and the state of the FlashCopy Backups again.
v To display details on each backup, press d and [ENTER]. This will show the
details for each backup
BSN: backup sequence number
ESS ID: serial number (only in LVM mirrored environments)
FCType: FlashCopy type
TargetID: ID of the target set)
In the case of an EEE with more than one EEE partition, this will also show a
detailed view for all EEE partitions, containing the backup timestamp, the TSM
state, the FlashCopy state, and the first active log for each EEE partition. If you
press d and [ENTER] again, the details will disappear.
v To display older backups press o and [ENTER].

IBM Tivoli Storage Manager for Hardware
Data Protection for IBM Disk Storage and SAN VC for mySAP (R) on DB2
--------------------------------------------------------------------------------

B a c k u p H i s t o r y f o r D a t a b a s e
SystemID: G01

--------------------------------------------------------------------------------
Backup timestamp (ID) Type TSM FlashCopy RTime(min) 1st active Log
--------------------------------------------------------------------------------
[1] - 21.09.2004 17:55:23 DB online ok running 32.5 S0000010.LOG
[2] - 21.09.2004 17:12:36 DB online ok invalid S0000009.LOG
[3] - 21.09.2004 17:09:58 DB online - ok S0000004.LOG
[4] - 21.09.2004 17:06:06 DB online - invalid S0000003.LOG
[5] - 21.09.2004 16:56:41 DB offline ok invalid S0000002.LOG

[d] - show details
[r] - refresh display
[o] - choose from older backups
[#] - restore the database with line number #
[f] - show FlashCopy backups only (target set state IN_USE)
[x] - exit tdphdwdb2

Enter your selection:
The following shows the detail view:
--------------------------------------------------------------------------------
Backup timestamp(ID) Type TSM FlashCopy RTime(min) 1st active Log
BSN ESS-ID FCType TargetID
--------------------------------------------------------------------------------
00163 23376 COPY 1
[2] - 21.09.2004 17:12:36 DB online ok invalid S0000009.LOG
00162 23376 COPY 3
[3] - 21.09.2004 17:09:58 DB online - ok S0000004.LOG
00161 22031 INCR 2
[4] - 21.09.2004 17:06:06 DB online - invalid S0000003.LOG
00160 22376 NOCOPY 4
[5] - 21.09.2004 16:56:41 DB offline ok invalid S0000002.LOG

[d] - hide details
The information concerning all the backups taken with DP for Snapshot Devices
or DP for mySAP is stored in the DP for mySAP recovery log file, which
normally is located in the NFS mount /db2/<SID>/dbs. For information on the
naming conventions for the DP for mySAP recovery log file, see the Data
Protection for mySAP Installation and Users Guide for DB2 UDB. In addition, DP
for Snapshot Devices stores information about FlashCopy Backups in its local
repository. While reading the DP for mySAP recovery log file, DP for Snapshot
Devices also checks in its local repository and the results are shown. In the
example above, you can see 7 different kinds of backup.
1. The most recent backup was done as a FlashCopy Backup. This backup is
valid for a restore from TSM and is not yet valid for a FlashCopy Restore.
The FlashCopy background copy is still running, and the estimated
remaining time is 32.5 minutes. When the background copy is finished and
the display is refreshed afterwards, this backup will be shown as ok. The
display of the remaining time requires at least ESS Copy Services CLI version
2.3.
2. This backup was also done as a FlashCopy Backup. It is valid for a restore
from TSM but not for a FlashCopy Restore. There could be multiple reasons
that a FlashCopy Backup is not valid for a FlashCopy Restore:
a. the FlashCopy Backup process failed
b. the FlashCopy Backup process was successful, but a more recent
FlashCopy Backup was performed or at least started (in the above
example, this is the most probable reason)
c. the FlashCopy Backup process was successful, but it was withdrawn
3. This backup was done as a FlashCopy Backup. It is not valid for a restore
from TSM but it is valid for a FlashCopy Restore. There could be two reasons
that a backup to TSM is not valid for a restore from TSM:
a. The backup-to-TSM process failed (see DP for mySAP Installation and
Users Guide for DB2 UDB for correcting the failure)
b. The backup-to-TSM process was successful but the backup has expired in
TSM.
c. The disk-only FlashCopy was done. In the detailed view you can see that
this FlashCopy backup was done on ESS #22031. In the example, an LVM
mirrored environment is shown with multiple target sets 1-4 on two
hardware units. In such an environment, it is possible to have multiple
FlashCopy Backup versions available for a FlashCopy Restore.
4. This backup was done as a FlashCopy Backup. It is not valid for any kind of
restore
5. This backup was done as a backup to TSM only. As shown, this was done as
an offline backup. This backup is only valid for restore from TSM.
To do a backup to TSM only without a FlashCopy, DP for Snapshot Devices
must be started on the production system with options -f backup t
online|offline p <profile>. All other backups listed before were started
on the backup system.
v If a backup is selected for which both FlashBack Restore and restore from TSM
are valid options, then the following screen is presented and one of the two
options must be selected. In the example above, backup 1. was selected.
--------------------------------------------------------------------------------

[f] - FlashBack from FlashCopy run
[r] - Restore from TSM



v The next screen is presented only if a FlashBack Restore is selected. In this case,
the SAP database administrator will be asked if the log files should be saved
into a logsafe directory.

--------------------------------------------------------------------------------

R e c o v e r y o f D a t a b a s e

--------------------------------------------------------------------------------

Do you want to save all active logfiles to logsafe directory?
!! This step may take several minutes and needs double space in the Log path !!

[s] - save to logsafe directory (this may take several minutes)

[n] - do not save logfiles


This step can be omitted in the case of a FlashBack Restore because no log files
will be changed or deleted from the active log directory; for security reasons,
however, the administrator can choose to save log files.
This step is essential in the case of a restore from TSM, because the DB2 restore
will delete all log files in the active log directory after the backup is successfully
restored from TSM. For that reason, in case of a restore from TSM, DP for
Snapshot Devices will not ask for saving log files, but saves them anyway.
v In the next screen after selecting the backup to be restored and the type of
restore to be performed, tdphdwdb2 will ask for the point in time to rollforward
to. If the parameter norollforward was specified, this screen and the
rollforward of the database will be skipped.
--------------------------------------------------------------------------------

R o l l f o r w a r d D a t a b a s e

--------------------------------------------------------------------------------
Node 1st active Log DB2 Log path
--------------------------------------------------------------------------------
0000 S0000010.LOG /db2/E01/log_dir/
--------------------------------------------------------------------------------

Enter the time to rollforward to:

[timestamp] - any timestamp with format YYYY-MM-DD-HH.MM.SS between
2002-12-05-17.49.13 and
2002-12-09-15.13.22 (Caution!! Use local time)

[e] - to end of logs


You can either choose to rollforward to end-of-log or specify the point in time
to which the rollforward process should be performed. The rollforward point in
time MUST be entered in local time. DP for Snapshot Devices will convert this
time into coordinated universal time (UTC), because DB2 internally uses this
time format and needs the time given in UTC to the db2 rollforward command.
v After selecting the rollforward point in time, tdphdwdb2 will ask for
confirmation of the input:
--------------------------------------------------------------------------------

You want to FlashBack the FlashCopy run from
05.12.2002 17:48:45 (local time)
05.12.2002 16:48:45 (coordinated universal time (UTC))
You want to rollforward the database to end of logs

Is this correct [y/n] :

v After this confirmation, tdphdwdb2 will stop the database and if specified above,
save all log files that are currently located in /db2/<SID>/log_dir into the
directory /db2/<SID>/log_dir/logsafe. Make sure there is enough space in the
corresponding file system. If /db2/<SID>/log_dir/logsafe is in the same file
system as /db2/<SID>/log_dir, double the space for this file system. If not
enough space is provided, tdphdwdb2 will exit with an error message.
This step is important because the db2 restore command will delete log files
from /db2/<SID>/log_dir. To avoid this, you must save all log files and use the
option overflow log path with the db2 rollforward command. You must make
sure that no old log files are located in the logsafe directory. Under certain
circumstances they can force the rollforward command to fail. Refer to the DB2
Administration Guide for more information
v tdphdwdb2 then calls
in case of restore from TSM, the db2 restore command with all necessary
parameters, and DB2 calls DP for mySAP for the restore process
in case of FlashCopy Restore (FlashBack Restore), splitint with all necessary
parameters.
After successfully performing the restore from TSM or the FlashCopy Restore,
and if you specified the parameter rollforward (which is the default), tdphdwdb2
will ask, if all log files required for the rollforward recovery of the database were
restored from TSM. tdphdwdb2 will wait until this is confirmed by the SAP
database administrator.
--------------------------------------------------------------------------------

S t a r t i n g t h e R e c o v e r y

You have to restore all DB2 logfiles beginning with

--------------------------------------------------------------------------------
Node 1st active Log DB2 overflow Log path
--------------------------------------------------------------------------------
0000 S0000010.LOG /db2/E01/log_dir/logsafe/
--------------------------------------------------------------------------------

up to end of logs

by using brrestore or DP for mySAP (backom).

IDS2522I Press [ENTER] when all logfiles are restored...

v If the current DP for Snapshot Devices restore is a FlashBack Restore and if the
SAP DB2 userexit is configured for indirect archiving with the SAP DB2
administration database ADM<SID>, then the SAP database administrator must
perform the following steps prior to pressing [ENTER]:
make sure the latest patch level of the SAP DB2 administration tools is
installed.
log in on the production system as user db2<sid>

drop the SAP DB2 administration database ADM<SID> with the command
db2 drop db ADM<SID>
restore the latest SAR file of the ADM<SID> DB from TSM or use the SAR
file archived in the directory /tmp/adminDB_<SID>/ during the last
brarchive run. Refer to the SAP DB2 administration documentation.
The SAP DB2 administration configuration file /usr/sap/<SID>/SYS/global/
init<SID>.db6 contains a variable DB2DB6_TEMP_DIR, which points by
default to /tmp. In HACMP environments it could be necessary to change
this variable to a shared file system, for example /db2/<SID>/log_archive/.
Make sure that user <sid>adm has write permission on this directory.
switch to user root without changing the user environment using the
command
su root (without leading hyphen)
recreate the SAP DB2 administration database ADM<SID> without applying
an existing SAR file using the command
sddb6ins r
or applying an existing SAR file using the command
sddb6ins r <complete Path to SAR-file>/adminDB.<TS>.SAR
These steps are required because the SAP DB2 administration database
ADM<SID> is located in the same local database directory as the SAP DB2
database <SID> and for that reason will be flashed as well. In case of a
FlashBack, it will also be flashed back but with an outdated or invalid state.
v tdphdwdb2 then calls the db2 rollforward command. The rollforward process will
run either to the end-of-log or to the point in time you specified. While the
rollforward process is running, the user exit db2uext2 will retrieve any log file
which is not in the log directory or, in case of selection to copy log files, in the
logsafe directory (overflow log path)
if the userexit is configured for archiving with the SAP DB2 administration
database:
from the DB2 archive path or the DB2 retrieve path (specified by the
environment variables DB2DB6_ARCHIVE_PATH, DB2DB6_RETRIEVE_PATH
set in the configuration file for the SAP DB2 administration tools
init<SID>.db6). The administrator must restore all logfiles needed for the
rollforward with the brrestore command or with the DP for mySAP tool
backom prior to DP for Snapshot Devices starting the DB2 rollforward
command. For information on the brrestore command and the configuration
of the SAP DB2 administration tools, see Database Administration Guide: SAP
on IBM DB2 Universal Database for UNIX and Windows. For information about
the DP for mySAP tool backom, see the DP for mySAP Installation and Users
Guide for DB2 UDB.
if the userexit is configured for direct archiving into TSM:
directly from the TSM server. In this case, the administrator does not need to
restore any log file manually via brrestore command or with the DP for
mySAP tool backom.
v Once the rollforward recovery of the database has reached the point in time, the
following rollforward status screen is shown. In case of errors during the
rollforward recovery (such as userexit returns error code 36), the rollforward
status screen is also shown, to help the administrator decide on the next steps to
take.
Rollforward Status

Input database alias = E01
Number of nodes have returned status = 1

Node number = 0
Rollforward status = DB working
Next log file to be read = S0000011.LOG
Log files processed = S0000010.LOG - S0000011.LOG
Last committed transaction = 2002-12-09-16.08.22.000000

DB20000I The ROLLFORWARD command completed successfully.
hdwIntRC: 0

Use the command

db2 rollforward database E01 stop

to stop the rollforward recovery.

--------------------------------------------------------------------------------

Recovery of database E01 finished successfully

v Once the database is successfully rolled forward to the desired point in time, the
SAP DB2 administrator must stop the rollforward recovery by using the
command
db2 rollforward db <SID> stop
After successfully stopping the rollforward recovery as follows:
Rollforward Status

Input database alias = E01

Node number = 0
Rollforward status = not pending
Next log file to be read =
Log files processed = S0000010.LOG - S0000011.LOG
Last committed transaction = 2002-12-09-16.08.22.000000


you can start the SAP system for operational use.
For more information about the restore/recovery of a DB2 database, see DB2 Data
Recovery and High Availability Guide and Reference and DB2 Command Reference.
Usage
The restore function was developed for the SAP database administrator to perform
a restore from TSM or a FlashCopy Restore (FlashBack Restore) and a recovery of
the production system. When tdphdwdb2 is started with the restore option, the
program performs all the steps that need to be done within the restore or
FlashCopy Restore and rollforward processes.
With the norollforward and rollforward options, the SAP database administrator
can decide whether he wants tdphdwdb2 to perform the rollforward process as well
or not.

Syntax
/db2/<SID>/dbs/tdphdwdb2 -f restore [database]
[no/rollforward] -p /db2/<SID>/dbs/init<SID>.fcs
where
System to be performed on: Production system only
FlashCopy Function
Description
The flashcopy function is used to perform a disk-only FlashCopy of the SAP
system DB2 UDB database. When performing a FlashCopy of type COPY or INCR,
you will get a point-in-time copy of your production database. You can use this
point-in-time disk copy for a later FlashCopy Restore (FlashBack Restore). See
Chapter 5, Restore Methods, on page 81 and Restore Function on page 110 for
further information.
If you specify FLASHCOPY_TYPE NOCOPY, this value will be overridden by
COPY or INCR (see Intended and Effective FLASHCOPY_TYPE on page 75)
You cannot specify an option with the flashcopy function. tdphdwdb2 performs a
FlashCopy with no unmount and no withdrawal of the target volumes. This
function can only be initiated on the backup system.
Once initiated on the backup system, the flashcopy function of tdphdwdb2 will
perform the following actions:
v use DB2 remote connection to get the file names of the relevant database files
from the DB2 production system.
v call splitint with the list of files to get the disk volumes that will be the
candidates for the subsequent FlashCopy.
check the status of the previous backup cycle to determine whether a new
backup cycle can be started. If the status of a previous backup is other than
PSI_FLASHCOPY_QUERY or PSI_UNMOUNT_DONE (in the case of a
FLASHCOPY_TYPE of COPY or INCR), or PSI_WITHDRAW_DONE (in the
case of a FLASHCOPY_TYPE of NOCOPY), splitint will terminate with RC
< 0 to indicate to tdphdwdb2 that the previous request failed or file systems
are still mounted
21
. As a consequence, tdphdwdb2 will also fail. The user will
be asked to first use the withdraw function.
Note: In case multiple target sets are specified in the DP for Snapshot Devices
target volumes file, this check will be done for volumes of the target
set used, depending on
- whether specific or automated target selection is desired, and
- the outcome of the selection algorithm
Check the RSI (Restore Status Indicator) for a still-active background copy
initiated by a FlashBack Restore. If the value is
21. According to the information splitint has in the IDS control file.
- RSI_START: terminate (a FlashCopy of a previous FlashBack Restore has
not yet completed)
- RSI_INVALID: issue a warning, reset the RSI, and continue
- anything else: continue
start a new backup cycle
v put the DB2 production database in write suspend mode.
v prepare the flashcopy call of splitint with the list of disk volumes which will
be the candidates for the subsequent FlashCopy. The flashcopy request is based
on information tdphdwdb2 will find in the profile it is using (NOCOPY
/COPY/INCR). See Intended and Effective FLASHCOPY_TYPE on page 75.
v on the production system, perform, based on the file list received by tdphdwdb2,
a FlashCopy for all the disk volumes (source) over which the various files are
spread
v and after calling splitint with a flashcopy request:
check the return code from splitint
if nonzero, terminate with error messages
if 0, start the FlashCopy agent process on the backup system to observe the
FlashCopy (only if the FLASHCOPY_TYPE is set to COPY or INCR)
v put the production DB2 database in write resume mode.
v On the backup system, perform the following task to allow files (on the target
volumes) to be read:
cfgmgr -v -l fsci/scsi ...
1. Run cfgmgr to identify the new volumes
2. Import all necessary volume groups if required
3. Mount all necessary file systems
4. Set the status of the current backup cycle to PSI_MOUNT_DONE.
5. return control to tdphdwdb2 with RC 0, which can now call DP for mySAP to
back up the files
v check on the backup system for the existence of all database files on so-called
target volumes which it had asked splitint (with option flashcopy) to create
using a FlashCopy
v finish the tdphdwdb2 run (remove any lock files)
During the various activities, tdphdwdb2 will
v provide information in its own log files (see also Appendix C, Summary of Log
and Trace Files, on page 329)
v write information to the tdphdwdb2 backup file
v on request, write traces for service purposes, if required
v update the current backup cycle, which can be viewed with the tdphdwdb2
inquire function.
Usage
The flashcopy function was developed for the SAP database administrator to
perform a disk-only FlashCopy on the backup system. When tdphdwdb2 is started
with the flashcopy option, the program will perform all the steps that need to be
done within the complicated process of a FlashCopy.
This function is identical to the function backup with option -t flashcopy up to
the step in which the backup function starts the backup, unmount, and withdraw.

Use the flashcopy function to perform a disk-only FlashCopy of the production
database on the backup system. After successful termination of the FlashCopy, you
can use the point-in-time copy of the production system, for example, to create a
DB2 backup on disk or build up a snapshot or a clone of the production database
for testing, or you can use other vendor libraries to back up the copy.
You can also use the flashcopy function to create a disk backup for a later
FlashCopy Restore (FlashBack Restore) using DP for Snapshot Devices.
Note: If functions other than the backup function of tdphdwdb2 are used, the users
themselves are responsible for the backup history.
In the context of supporting multiple target sets, the following options can be used:
v the -C <flashcopy_type> option to run specific types of FlashCopy Backups
(INCR, COPY, or NOCOPY), and
v the -n x option to select a specific target set for the backup
For details, see Chapter 10, Multiple Backup Generations (Target Sets) on Disk,
on page 219
Syntax
cd /db2/<SID>/dbs
./tdphdwdb2 -f flashcopy -p /db2/<SID>/dbs/init<SID>.fcs
where
System to be performed on: Backup system only
Query Function
Description
The DP for Snapshot Devices query function performs actions similar to those of
the initial part of the flashcopy function. In summary, the query function checks:
v the status of the actual backup cycle (PSI) to determine whether a new backup
cycle can be started
v the validity of the various parameters specified in the DP for Snapshot Devices
profile as well as the existence of the DP for Snapshot Devices configuration and
.fct ( target volumes) files
v for proper setup of the passwords needed by DP for Snapshot Devices (see
Password Function on page 129)
v that the hostname of the backup system matches the one specified with the
LOGON_HOST_BACK parameter of DP for Snapshot Devices
v that the connection to the production system is functional
v that the primary or backup CopyServices server can be reached
v that the production and backup systems are running with the DP for Snapshot
Devices program (splitint) with the same service level and the owner rights of
the program file are properly set
v for the existence of the Shared Disk as specified in the Overall Disk Layout
Considerations on page 34
|
v whether the files of the DB file list reside on the hdisks/vpaths as described in
Overall Disk Layout Considerations on page 34 and determines the so-called
source volumes those files are using
v when using the HARDWARE_ID_LVM_MIRROR DP for Snapshot Devices
profile parameter in AIX LVM mirrored environments, that the special setup
requirements and customization with AIX LVM mirrors have been done (see
Chapter 8, DP for Snapshot Devices Functionality for AIX LVM Mirrored
Environments, on page 161)
v that for each source volume on the production system an appropriate target
volume can be found in the .fct file
If an error is encountered, DP for Snapshot Devices will stop immediately with
messages which allow the system administrator to react accordingly.
Due to its passive nature, when everything has been properly found, the DP for
Snapshot Devices query function stops execution with message IDS1083I. Unlike
the flashcopy function, the query function
v does not initiate an actual FlashCopy operation and therefore
v does not mount any file systems on the backup system
Use of this function does not change the status (PSI) of the current backup cycle.
Usage
The DP for Snapshot Devices query function should only run when
preparing/checking the DP for Snapshot Devices setup of the production and
backup systems. tdphdwdb2, when used with its query option:
v uses a DB2 remote connection to get the filenames of the relevant database files
from the production DB2 database
v does not put the DB2 database in write suspend mode
v prepares the query call to splitint with the list of files whose source volumes
will be the candidates in the later run with the flashcopy function
v using the just-created list of files, runs the query function of splitint, which
now performs all the checks described above.
v stops execution after receiving control back from splitint
During the various activities, tdphdwdb2 will provide information into its own log
files (see Appendix C, Summary of Log and Trace Files, on page 329).
Syntax
cd /dbs/<SID>/dbs
./tdphdwdb2 -f query -p /db2/<SID>/dbs/init<SID>.fcs
where db2/<SID>/dbs/init<SID>.fcs is the DP for Snapshot Devices profile.
Case 6: Setup Test with the Query Function on page 263 shows how the DP for
Snapshot Devices query function can be used.
System to be performed on: Backup system only.

Withdraw Function
Description
The withdraw function was basically developed to break the relationship between
source/target volumes which were established running tdphdwdb2 with FlashCopy.
It will perform the necessary operations to prepare the disk environment on the
backup system such that it can be used again for tdphdwdb2 with a new FlashCopy
request. The withdraw. function involves basically two operations:
1. unmount all the file systems which had been mounted within a FlashCopy
request (in addition to the unmount, the export of volume groups will also be
done if required). The PSI status of the current backup cycle is set to
PSI_UNMOUNT_DONE.
2. withdraw the source/target relationships between volumes if still required. The
PSI status of the current backup cycle is set to PSI_WITHDRAW_DONE.
In order to have only the first operation done, DP for Snapshot Devices also offers
an unmount function to be used to keep the target volumes; see Unmount
Function on page 124 for details and usage.
If a previous flashcopy request failed with a status other than
PSI_FLASHCOPY_QUERY or PSI_FLASHCOPY_STARTED, you should first run
the withdraw function. However, prior to this, you should check the tdphdwdb2
run log to determine why the flashcopy function failed and correct the error.
Usage
The withdraw function can be used
v on its own, when appropriate
v within a DP for Snapshot Devices run with the function backup, which in turn
can call either the DP for Snapshot Devices unmount or withdraw function
The reasons to run the withdraw function are quite different and depend on the
FLASHCOPY_TYPE value used in a FlashCopy backup and the conditions a
system environment has been left in after a previous FlashCopy backup run.
The following table describes the conditions under which the withdraw function
must be run, depending on the FLASHCOPY_TYPE value within the FlashCopy
backup run:

Value of
FLASHCOPY_TYPE
Requirement for withdraw Function
NOCOPY A withdraw is always required to terminate a backup cycle, so
that a new FlashCopy backup can be started. To achieve this,
you either
v call the DP for Snapshot Devices backup function without
any option, which will run the DP for Snapshot Devices
withdraw function, or
v run the withdraw function after the FlashCopy backup run
Value of
FLASHCOPY_TYPE
Requirement for withdraw Function
COPY To terminate a backup cycle, it is normally sufficient to run the
DP for Snapshot Devices unmount function. Running the
unmount function instead of withdraw will allow you to clean
up the system to be prepared for a new FlashCopy backup and
still keep the disk copy available for a FlashBack restore up to
the next FlashCopy backup.
A withdraw is meaningful only if there is a need for another
FlashCopy backup to be started and the background copy
initiated by the previous FlashCopy backup has not yet
completed.
INCR To terminate a backup cycle, it is normally sufficient to run the
DP for Snapshot Devices unmount function. Running the
unmount function instead of withdraw will allow you to clean
up the system to be prepared for a new FlashCopy backup and
still keep the disk copy available for a FlashBack restore up to
the next FlashCopy backup.
A withdraw is meaningful only if there is a need for another
FlashCopy backup to be started and the background copy
initiated by the previous FlashCopy backup has not yet
completed. However, assuming the background copy runs
faster than for the COPY case, the probability of needing to run
the withdraw is much lower than for COPY. In addition a
withdraw would also cause the next incremental run to start
the bit-level copy from scratch.

The withdraw will terminate a source/target relationship established by a
FlashCopy absolutely if the FLASHCOPY_TYPE is NOCOPY or for as long as the
background copy is running if the FLASHCOPY_TYPE was INCR or COPY (the
disk copy of such a backup becomes invalid).
When using the cleanup (resynchronization) request facility within the backup
function without any options, the DP for Snapshot Devices withdraw function will
be started by the DP for Snapshot Devices backup function if the
FLASHCOPY_TYPE is NOCOPY.
The rules for using the withdraw function outside the scope of the backup function
are as follows:
v If you plan to run FlashCopy backups with FLASHCOPY_TYPE NOCOPY,
ensure that you have, within and/or outside the function backup, set up the DP
for FlashCopy command with the withdraw function.
v In case of problems during a FlashCopy backup that are not dependent on the
FLASHCOPY_TYPE value (e.g., DP for Snapshot Devices terminated with a
FLASHCOPY_STARTED condition), you must, after analyzing the cause of the
failure, run the DP for Snapshot Devices withdraw function to prepare the
environment to allow a new FlashCopy backup run to be started.
More about the use of the withdraw function is contained in Sample tdphdwdb2
Usage on page 259
Note: In case the FLASHCOPY_TYPE was INCR, use of the withdraw function to
terminate the source/target relationship would reset ICR, which would
cause the next FlashCopy backup run to start the bitwise copy from scratch.

Restarting such a FlashCopy backup with a still-running background copy
(from the previous request) will cause the newly requested FlashCopy to
fail.
When the withdraw function of splitint runs by itself, and multiple target sets
(Chapter 10, Multiple Backup Generations (Target Sets) on Disk, on page 219) are
used, withdraw will perform its function
v to the selected target, if the target set parameter (-n x) was specified
v to the last terminated FlashCopy backup, if no target set parameter was
specified
Syntax
/db2/<SID>/dbs/tdphdwdb2 -f withdraw -p /db2/<SID>/dbs/init<SID>.fcs
where
The withdraw function can be used either within a script or as an explicit
command preceding a tdphdwdb2 command. Samples for both cases are shown
above in this section. See also Case 3: Backup with Delayed Withdrawal Outside
tdphdwdb2 Run on page 260.
If multiple target sets are configured (see Chapter 10, Multiple Backup
Generations (Target Sets) on Disk, on page 219), the optional target-selection
parameter -n x specifies the set with which a withdraw should be performed. x
is the ID, normally a number, specified in the target set topic in the DP for
Snapshot Devices target volumes file (.fct). If this parameter is not specified, the
target set of the last terminated FlashCopy backup is used.
Important: Do not try to use this function while a previous backup is still running
within tdphdwdb2. This can lead to abnormal termination of the
running backup, leaving the file systems and target volumes on the
backup system in a state in which manual cleanup work might be
necessary to restore the backup system to a normal operating mode.
Withdraw_Force Function
Description
The withdraw_force function performs a withdraw (see Withdraw Function on
page 121) without examining the BSI or PSI.
Usage
This function can be useful in some cases in cleaning up the target resources in the
backup machine and when the status values of the FlashCopy relationship in the
storage system and the local snapshot repository of DP for Snapshot Devices are
out of sync. It can be used when a FlashCopy backup cannot be started due to the
state of the BSI or PSI and the normal function -f withdraw is not effective.
Note: The withdraw_force function should be used with caution and only if
recommended by IBM support.
Syntax
/db2/<SID>/dbs/tdphdwdb2 -f withdraw_force -p /db2/<SID>/dbs/init<SID>.fcs
where
parameter -n x specifies the set with which a withdraw should be performed. x
Important: Unless instructed to do so by IBM Support, do not try to use this
function while a previous backup is still running. This can lead to
abnormal termination of the running backup, leaving the file systems
and target volumes on the backup system in a state in which manual
cleanup work might be necessary to restore the backup system to a
normal operating mode.
Unmount Function
Description
The unmount function of the DP for Snapshot Devices command tdphdwdb2 was
basically developed for backup/restore implementations in which the user plans a
disk-to-disk restore (FlashBack Restore).
22
Note: In order to run such a restore
1. the tdphdwdb2 request must have been done with a FlashCopy with the
COPY or INCR option, and
2. the background disk copy operation initiated thereby must have
finished.
Within a DP for Snapshot Devices Backup or FlashCopy run, tdphdwdb2
starts a background process on the backup system, which checks the
completion of the asynchronously running background copy operation.
The unmount function, called with the tdphdwdb2 command will
v on the one hand, free up the disk environment on the backup system in such a
way that
the file systems which had been mounted within a flashcopy request will be
unmounted and
any volume groups that had been imported will be exported
any AIX physical device (hdisk/vpath) that had been used will be removed
22. Using for the reverse FlashCopy the primary source volumes as target volumes and vice-versa.

v on the other hand, keep the FlashCopy target volumes (created with the COPY
or INCR option) available as long as possible for a disk-to-disk restore/recovery
process.
The backup system would be left in the backup cycle state
PSI_UNMOUNT_DONE, which is
v complete if the FLASHCOPY_TYPE value was INCR or COPY, allowing a new
FlashCopy backup to be started
v not yet complete if the FLASHCOPY_TYPE was NOCOPY, causing an attempt to
start a new FlashCopy backup to fail
Usage
The unmount function is mainly intended for use when a FlashBack Restore is
planned for a disk-to-disk restore/recovery based on the existing disk backup
level. If such procedures are not planned, it is recommended, for simplicity, to use
DP for Snapshot Devices as shown in Case 1: Backup with Target Withdrawal in
tdphdwdb2 Run on page 259. If such procedures are planned, it is recommended to
use DP for Snapshot Devices as shown in Case 4: Backup with Unmounting of
File Systems in tdphdwdb2 Run on page 261.
When the unmount function of splitint runs by itself, and multiple target sets
(Chapter 10, Multiple Backup Generations (Target Sets) on Disk, on page 219) are
used, unmount will perform its function
v to the selected target, if the target set parameter (-n x) was specified
v to the last terminated FlashCopy backup, if no target set parameter was
specified
Syntax
/db2/<SID>/dbs/tdphdwdb2 -f unmount -p /db2/<SID>/dbs/init<SID>.fcs
where
The function could also be used within a script or as an explicit command
preceding or following a tdphdwdb2 command. See Case 4: Backup with
Unmounting of File Systems in tdphdwdb2 Run on page 261.
parameter -n x specifies the set with which an unmount should be performed. x
Inquire Function
Description
The inquire function shows the results and details of all backup cycles as long as
this information is kept in the DP for Snapshot Devices control file (see
IDS_CONTROL_FILE and BACKUP_MAX parameters in the DP for Snapshot
Devices profile).
Usage
This function might be performed whenever you would like to see information
such as
v target set number
v target set state
v backup ID associated with the FlashCopy backup
v backup sequence number
v backup status
v processing status
v status of the backup cycle(s)
v time required for a FlashCopy
Syntax
/db2/<SID>/dbs/tdphdwdb2 -f inquire [
-r <field>[,<field>] / -b <backup sequence number>]
where
is the DP for Snapshot Devices profile
You can utilize optional parameters to see the
v details of a specific backup cycle
by adding the -b parameter with values such as nnnnn (nnnnn could represent the
backup sequence number of a backup cycle) or backup ID, or
v selected details of all backup cycles
by adding the -r parameter and thereby selecting the positions of the various
fields. For example
-r 1,2,3,4,21
would show all information about the backup and restore cycles (BSN, BSI, PSI,
BID, RSI)
System to be performed on: Backup and production systems
TS_Inquire Function
Description
The ts_inquire function provides information about the target set(s) defined in the
DP for Snapshot Devices target volumes file (.fct). This function was made
available with DP for Snapshot Devices 5.3 to support the multiple target set

functionality (for more information on this functionality, see Chapter 10, Multiple
Backup Generations (Target Sets) on Disk, on page 219).
Usage
The ts_inquire function can be used to
v see the state (either ALLOCATE or IN_USE) of a specific or all target sets
v get information as to whether a background copy is still running for a target set,
by checking for the value BSI_STARTED in the BSI field. In case it is completed,
BSI_DISKONLY or BSI_DISKANDTAPE will be encountered
v see other information related to a target set, such as the BSN (backup sequence
number)
v check, for example in a backup script, the target set state of a previously started
backup in order to avoid starting a new backup request if the background copy
of the previously started backup has not yet completed.
Syntax
tdphdwdb2 -p /db2/<SID>/dbs/init<SID>.fcs -f ts_inquire [n x]
where
v /db2/<SID>/dbs/init<SID>.fcs is the DP for Snapshot Devices profile
v -n allows to select a specific target set (identified by x) from a group of target
sets. x is called the target set number (or also data container ID). If n is not
specified, the state and other information are shown for all target sets specified
in the DP for Snapshot Devices target volumes file (.fct).
The RC of tdphdwdb2 -f ts_inquire (when using the parameter n x) will be 0
when the background copy has completed for the selected target set .
The RC of tdphdwdb2 -f ts_inquire (without the parameter n x) will be 0 when
there is no background copy running for one of the target sets defined in the DP
for Snapshot Devices volumes file (.fct).
System to be performed on: Backup and production systems
Configure Function
Description
TCP/IP client/server socket communication is implemented between the backup
and production systems. In the case of a production database running on DB2
UDB EE, the socket server running on the production system is used to open a
connection to the production database and to suspend/resume the production
database write activity on request of the socket client (on the backup system).
In the case of DB2 UDB EEE, for each EEE partition in the production database,
one dedicated socket server runs on the corresponding production server. In
addition, one socket server is also used to synchronize all EEE partitions while
doing backups and restores with DP for Snapshot Devices.
This TCP/IP client/server socket communication implementation avoids
production database hang situations in case of network problems because the
connection to the production database is held locally on the production server. DP
for Snapshot Devices has additionally implemented the function dbresume (see
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DBResume Function on page 130), which can be used to resume database write
activities in case of network problems while performing a FlashCopy Backup.
The configure function of DP for Snapshot Devices will create all needed entries in
the files /etc/services and /etc/inittab on the production system.
In case of DB2 UDB EEE the configure function must be started on the
coordinating production server (partition 0) and it will automatically create all
entries in the above mentioned files on all production servers (if the production
EEE database is spread over multiple servers).
In addition, the configure function will store the passwords required to run
v splitint on the production system once tdphdwdb2 with function flashcopy has
been started on the backup system
v the storage-system functions invoked within splitint
The configure function will keep the password encrypted in a file once it has been
called and the user has specified the current password for the
v db2<sid> user ID (specified in LOGON_HOST_PROD) and
v storage system user ID (specified in COPYSERVICES_USERNAME)
The file for storing the passwords must be specified in the CONFIG_FILE
parameter in the DP for Snapshot Devices profile.
Usage
This function must be performed
v during installation and customization of the DP for Snapshot Devices product
v whenever the passwords of the db2<sid> user and/or storage-system user ID
are changed
v whenever the EEE configuration has changed (e.g. after adding an EEE partition
to the DB2 instance or moving an EEE logical partition from one production
server to a new production server)
When calling this function, the user will be asked for the TCP/IP port on which
the socket server will listen. After entering a correct TCP/IP port, the user will be
prompted to enter the appropriate passwords. If the option '-i' is specified with a
password input file, the user will not be prompted and the passwords in the file
will be used.
Syntax
cd /db2/<SID>/dbs
./tdphdwdb2 -f configure [-i password_input_file]
where
db2/<SID>/dbs/init<SID>.fcs
is the DP for Snapshot Devices profile and
password_input_file>
is the full path and filename of an optional input file with the following structure:

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>>> DBUSER
PWD <DB user password>
<<< DBUSER
>>> CSUSER
PWD <User password for CIM agent or N series API>
<<< CSUSER
The passwords must be specified in plain text. They must not contain spaces or tab
characters.
System to be performed on: Production system only.
Password Function
Description
The password function will store the passwords required to run
v DB2 API calls on the production and backup systems
v the various storage system functions called within splitint
The password function will keep the encrypted passwords in a file once it has
been called and the user has specified the current password for the
v db2<sid> user ID (specified in LOGON_HOST_PROD) and
v storage-system user ID (specified in COPYSERVICES_USERNAME)
The file for storing the encrypted passwords must be specified in the
CONFIG_FILE parameter in the DP for Snapshot Devices profile.
Usage
This function must be performed whenever the passwords of the db2<sid> user
and/or storage-system user ID are changed.
During the installation and customization of DP for Snapshot Devices, the
'configure' function must be used to configure the TCP/IP socket servers and the
passwords.
When calling this function, the user will be prompted to enter the appropriate
passwords.
When specifying the option -i with a password input file, the user will not be
prompted for the passwords. Instead, the passwords in the file will be used.
Syntax
cd /db2/<SID>/dbs
./tdphdwdb2 -f password [-i password_input_file]
where
is the DP for Snapshot Devices profile and
password_input_file>
is the full path and filename of an optional input file with the following structure:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>>> DBUSER
PWD <DB user password>
<<< DBUSER
>>> CSUSER
PWD <User password for CIM agent or N series API>
<<< CSUSER
The passwords must be specified in plain text. They must not contain spaces or tab
characters.
System to be performed on: Backup or production system.
Modify_Copyrate Function
Description
The modify_copyrate function allows the copy rate of an active SVC FlashCopy
backup or restore to be modified dynamically. The initial copy rate is established
by the value of the SVC_COPY_RATE parameter in the DP for Snapshot Devices
profile.
Usage
The new copy rate is specified with the -R option. The value can range from 0
(lowest priority) to 100 (highest priority). A value of 0 effectively suspends the
copy process, which can be resumed at a later time by specifying a nonzero value.
Syntax
/db2/<SID>/dbs/tdphdwdb2 -f modify_copyrate -R <copyrate>
[-n x]
where
To set the copy rate to 50, for example:
/db2/<SID>/dbs/tdphdwdb2 -f modify_copyrate -R 50
System to be performed on: Production and backup systems
DBResume Function
Description
The 'dbresume' function is used to resume a suspended SAP DB2 UDB database. If
a snapshot-type operation fails or the tdphdwdb2 f flashcopy or f backup call
terminates and leaves the DB2 database or one or more DB2 database partitions in
a suspended state, this function will help to resume normal database operation.
Usage
The 'dbresume' function was developed for the SAP database administrator as a
last-chance remedy to resume normal operation of the DB2 database in the case of
an error in a snapshot operation that leaves the database in suspended mode. This

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
command must be called once for each DB2 database partition that is suspended.
With the option 's <DB partition>' (for example.' s 0') the administrator can
resume each database partition. A prerequisite for proper operation of this function
is that the Data Protection for Snapshot Devices socket servers have not been
stopped or killed on the production system as well, because these servers opened
the connection to the database partitions at the time they were suspended and this
is the only connection that can safely be used for the resume command. If this
connection is also lost (by a 'kill -9' command on the socket servers, for example),
the 'dbresume' function will fail.
All database partitions should be resumed in numerical order The command
db2 LIST DBPARTITIONNUMS
provides a list of the partitions by number. The '-s 0' option is required for a
non-partitioned database.
Syntax

cd /db2/<SID>/dbs
./tdphdwdb2 -f dbresume -s <DB partition number>

where
is the DP for FlashCopy profile.
System to be performed on: Production system only
Restart_Backup Function
Description
The 'restart_backup' function is used to restart a failed TSM backup on the backup
system without restarting the entire snapshot-type backup run.
Usage
In TSM for ACS releases prior to 5.4.0, a failed TSM backup after a successful
snapshot backup could not be restarted without restarting an entire snapshot
backup run. For example, if the TSM backup of partition 5 of a DB2 database with
6 partitions failed due to a TSM full condition, then all TSM backups already
performed successfully for partitions 0-4 also had to be restarted to get a complete
TSM backup of the database. With this new function, the failed TSM backup of
partition 5 can be restarted on the backup system and the successful TSM backups
of partitions 0-4 reused.
The DP for Snapshot Devices profile parameter DB2_RESTART_TSM_BACKUP has
been introduced to enable or disable the new capability. The default value is NO
(disable). If this parameter is set to YES, then a snapshot-type backup will no
longer be automatically unmounted/withdrawn if the TSM backup fails for one or
more DB2 partitions. With the filesystems left mounted on the backup system,
customers can then investigate the reason for the failed TSM backup. After
resolving the problem, the TSM backup of the failed DB2 partitions can be
restarted.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The 'restart_backup' function can be called multiple times until all TSM backups of
all DB2 partitions have completed successfully. The function first detects which
TSM backups failed and then starts the backups for these partitions only.
Syntax

cd /db2/<SID>/dbs
./tdphdwdb2 -f restart_backup -p /db2/<SID>/dbs/init<SID>.fcs

where

|
|
|
|
|
|
|
|
|
|
|
|
Summary of tdphdwdb2 Functions
The following table summarizes the tdphdwdb2 functions.
Table 4. Summary of Function Usage for DP for Snapshot Devices Command tdphdwdb2
Function of
tdphdwdb2 called
with -f
Allowed to run
on
Required
parameters
Optional parameters Status of the backup
cycle when function is
successful
backup Production and
backup systems
-p ppp -t flashcopy
[unmount/nounmount]
[withdraw/nowithdraw]
-t online
-t offline
-n x
1
-C <flashcopy_type>
PSI_MOUNT_DONE
[PSI_UNMOUNT
_DONE]
[PSI_WITHDRAW
_DONE]
restore Production system
only
-p ppp [database]
[rollforward/norollforward]
n/a
flashcopy Backup system
only
-p ppp -n x
1
-C <flashcopy_type>
PSI_MOUNT_DONE
query Backup system
only
-p ppp -n x
1
-C <flashcopy_type>
n/a
unmount Backup system
only
-p ppp -n x
1
(-C <flashcopy_type>
will be ignored if specified.)
PSI_UNMOUNT_DONE
withdraw Backup system
only
-p ppp -n x
1
PSI_WITHDRAW_DONE
withdraw_force Backup system
only
-p ppp -n x
1
PSI_WITHDRAW_DONE
inquire Production and
backup systems
-p ppp -b bbb
-r c1,c2,...
n/a
ts_inquire Production and
backup systems
-p ppp -n x
1
n/a
configure Production system
only
-p ppp -i pwd n/a
password Production or
backup system
-p ppp -i pwd n/a
modify_copyrate Production and
backup systems
-R rrr
-p ppp
-n x
1
n/a
dbresume Production system
only
-p ppp
-s <DB
partition #>
None n/a
restart_backup Backup system
only
-p ppp None BSI_TAPEONLY or
BSI_DISKANDTAPE
||
|
|||
||
|
|||
||
|
|
|
|
||
||
|
|||
|
Table 4. Summary of Function Usage for DP for Snapshot Devices Command tdphdwdb2 (continued)
Function of
tdphdwdb2 called
with -f
Allowed to run
on
Required
parameters
Optional parameters Status of the backup
cycle when function is
successful
Key:
ppp Name of the DP for Snapshot Devices profile
pwd Name of the password input file
rrr Copy rate
bbb Backup sequence number (BSN)
c1,c2,... Summary limited to columns c1,c2,...
1
x must match the target set number (data container ID) specified for the volumes_set_x topic in the DP for
Snapshot Devices target volumes file. If only one target volume set is defined, this parameter is unnecessary.

Backup and Restore Cycles
This section describes the role of a backup and a restore cycle including the control
elements such as PSI, BSI and RSI together with the FlashCopy agent.
Using DP for Snapshot Devices for backup purposes will primarily allow first to
FlashCopy source volumes to target volumes on a production system and make the
target volumes available on a backup system. There, DP for Snapshot Devices will
import volume groups and mount the file systems. After the backup has been
done, the disk environment on the backup system can be restored to its initial state
with respect to the DB2 database files, in which
v no file systems remain mounted
v no volume groups remain imported and
v no logical volumes remain available (only if the FLASHCOPY_TYPE is
NOCOPY).
DP for Snapshot Devices uses a progress status indicator (PSI) to control the status
of the involved volumes and of the AIX storage management environment left
once a DP for Snapshot Devices function completed, thus allowing the next DP for
Snapshot Devices function to be started only when the PSI has a proper value.
A special FlashCopy Restore (FlashBack Restore) is integrated in this product,
which integrates the FlashCopy target volumes (created with the COPY or INCR
option) in a disk-to-disk restore process as long as those target volumes are still in
the state
23
they were in after successful completion of the FlashCopy operation
from the respective source volumes. The background copy within the storage
system has been completed.
Backup Cycle
In order to monitor on the backup system the status of the target volumes (such as
mounted file systems) involved in a backup and to run controlled tdphdwdb2
requests, DP for Snapshot Devices will establish, for each new FlashCopy Backup
request, a new backup cycle after checking whether a preceding request has left
the disk environment of the backup system in a state that a new tdphdwdb2 can
be started and completed again. If DP for Snapshot Devices encounters a situation
where a new tdphdwdb2 will fail, it will terminate this request, asking the
database administrator first to
23. For invalid conditions, see When Not to Use FlashBack Restore on page 86 and FlashBack Restore Limitations on page 87.

||
v check the procedure setup, or
v recover from an unexpected failure within the tdphdwdb2 run (such as a power
failure) that left the disk environment in a state that must be cleaned up (see
Case 2: Backup Without Subsequent Unmount or Withdraw on page 260).
A new FlashCopy backup request, creating a new backup cycle, can be successfully
initiated only if the following two conditions are fulfilled:
1. The preceding backup cycle successfully terminated with the required DP for
Snapshot Devices function according to the FLASHCOPY_TYPE value as
follows:
v In the case of NOCOPY, the withdraw function (sets the PSI to
PSI_WITHDRAW_DONE) or
v In the case of INCR or COPY, the unmount function (sets the PSI to
PSI_UNMOUNT_DONE). In addition to the completed backup cycle, a
background copy must have completed. The BSI value is either
BSI_DISKONLY or BSI_DISKANDTAPE
2. In the case of a FlashBack Restore that started a restore cycle within the
preceding backup cycle, the restore cycle has terminated completely
(RSI_DISKONLY).
Such a restore cycle can only be seen when a backup with the
FLASHCOPY_TYPE value of INCR or COPY has been used for a restore
(FlashBack Restore).
A backup cycle is identified with a unique backup sequence number (BSN); within
a specific backup cycle. Control elements are used such as
v a PSI to record the status of the used source/volume pairs and the status of the
AIX storage management environment on the backup system
v a BSI to record the status of a backup object (FlashCopy and/or TSM type) with
respect to its usability for a future restore
v an RSI to record the usability of a restored FlashCopy type object with regard to
its progress and usability for a new FlashCopy Backup following a FlashBack
Restore.
Restore Cycle
A restore cycle will be started using the BSN of a backup cycle
v once, using the DP for Snapshot Devices restore function, a backup eligible for
FlashBack Restore is chosen by the administrator for a restore and
v when, within the further restore process flow, DP for Snapshot Devices has been
allowed to continue at breakpoint message IDS1084I.
A backup will become eligible for a FlashBack Restore only if
v it was done using the COPY or INCR option within the DP for Snapshot Devices
profile and
v the FlashCopy agent started within the backup flow has signaled that it detected
that the background copy process has been completed for all source/target pairs
(the final BSI value must be BSI_DISKANDTAPE or BSI_DISKONLY)
A FlashBack Restore can be performed only with the latest available backup cycle
and only if the following conditions exist for the last FlashCopy or FlashCopy
Backup request:
v the selected backup is eligible for a FlashBack Restore and
v the PSI has, after a successful backup request, been set to PSI_MOUNT_DONE,
PSI_UNMOUNT_DONE, or PSI_WITHDRAW_DONE
A restore cycle is considered to be completed only after the FlashCopy agent
started within the FlashBack Restore has detected that all background copies have
completed. Once the FlashCopy agent has detected the completion, it will change
the initial RSI value (RSI_START) to RSI_DISKONLY. After a successfully
terminated DP for Snapshot Devices FlashBack Restore you can restart the mySAP
database and its applications even if the restore cycle is not yet completed;
however you still have to wait for the completion of the restore cycle before the
database can again be backed up with DP for Snapshot Devices.
Common Information for the Backup and Restore Cycles
The BSN of a backup and restore cycle will be
v kept in the DP for Snapshot Devices control file (see IDS_CONTROL_FILE
parameter of the DP for Snapshot Devices profile)
v written to the DP for Snapshot Devices run logs (see Appendix C, Summary of
Log and Trace Files, on page 329)
The status of the backup and restore cycles can be checked with DP for Snapshot
Devices (see Inquire Function on page 126). The last line of the inquire function
output shows the latest and current backup and restore cycles with the backup
sequence number (BSN), backup status indicator (BSI), restore status indicator (RSI)
and progress status indicator (PSI).
The maximum number of backup cycles recorded and kept in the DP for Snapshot
Devices control file is defined with the BACKUP_MAX parameter in the DP for
Snapshot Devices profile.
Note: Do not edit/change the contents of the DP for Snapshot Devices control file;
otherwise, you might hamper or prevent the controlling functions of the DP
for Snapshot Devices product. Use the DP for Snapshot Devices inquire
function if you want to see the contents of this control file.
To better understand the role and behavior of a backup cycle and its status, see
also the following case examples under Sample tdphdwdb2 Usage on page 259:
v successful tdphdwdb2 requests (cases 1, 3, 4)
v tdphdwdb2 request that will fail due to a backup cycle in a mount done status
(case 2)
v tdphdwdb2 request that will fail due to a backup cycle being in an unmount
done state, but the FlashCopy relationship still exists (case 5).
FlashCopy Agent
Within a FlashCopy Backup (if the option COPY or INCR has been used), as well
as in a FlashBack Restore, a FlashCopy Agent will be started that will, even if the
called DP for Snapshot Devices function has already completed, periodically check
for the completion of the background copy processes; once it has detected that all
of these processes have completed for all volumes, the FlashCopy agent will
v set the BSI to BSI_DISKONLY or BSI_DISKANDTAPE (in the case of a
FlashCopy Backup)
v set the RSI to RSI_DISKONLY (in the case of a FlashBack Restore)
In this way, DP for Snapshot Devices knows when the copy process is complete.
The purpose of the FlashCopy agent is to ensure that DP for Snapshot Devices will

not initiate a FlashCopy for a set of source/target volumes as long as the
FlashCopy for the same set of source/target volumes in the other direction has not
yet completed for all volumes.
The FlashCopy agent will periodically write its results into a log and end its
processing once the copy for all source/target pairs has finished (see Appendix C,
Summary of Log and Trace Files, on page 329).
Note: Never use the volume pairs whose copy processes were manually
terminated with storage-system tools or other means for a FlashCopy or
FlashBack process, such that the normal processing is outside the control of
the FlashCopy agent. The FlashCopy Agent would not know about this
intervention and would misinterpret the information (as reflecting
completed copies which in reality they are not). This could cause serious
problems if you need the successfully completed copy. Using such
supposedly complete (but in reality incomplete) copies would on the
production system
v result in a broken database and broken AIX storage environment when
using an incomplete copy of a FlashCopy Backup within a restore. The
BSI would be set by the FlashCopy agent as BSI_DISKONLY or
BSI_DISKANDTAPE because the FlashCopy agent is not aware of the
manual intervention.
To resolve this situation, you need to manually recreate the AIX storage
environment and restore a TSM type backup.
v result in a broken DB and a broken AIX storage environment when
creating an incomplete copy of a FlashBack Restore due to the forbidden
premature manual termination of the background copy activities. The RSI
would be set by the FlashCopy agent to RSI_DISKONLY even the copy is
incomplete, because the FlashCopy agent is not aware of the manual
intervention.
To resolve this situation, you might try to perform a FlashBack Restore
rerun; in case this is not successful, you need to manually recreate the
AIX storage environment and restore a TSM type backup.
PSI (Progress Status Indicator)
The PSI is used by DP for Snapshot Devices functions to determine whether a new
tdphdwdb2 request (with the flashcopy or backup function) can be started. If the PSI
has one of the following values
v PSI_FLASHCOPY_STARTED
v PSI_FLASHCOPY_DONE
v PSI_MOUNT_STARTED
v PSI_MOUNT_DONE
v PSI_UNMOUNT_DONE
v PSI_WITHDRAW_STARTED
no new tdphdwdb2 using the FlashCopy functionality can be done. In this case, you
must run:
tdphdwdb2 -f withdraw ... or
tdphdwdb2 -f unmount ...
to put the latest backup cycle into a valid PSI state.
The DP for Snapshot Devices commands should be issued with the same
parameters (-p ... [-n x]) used in the FlashCopy backup.
Table 5. DP for Snapshot Devices Actions Required to Reset the Backup Cycle
DP for Snapshot Devices function to reset the backup
cycle to allow a new FlashCopy backup to be started with
a FLASHCOPY_TYPE value of
Existing PSI Status NOCOPY COPY or INCR
PSI_FLASHCOPY_STARTED withdraw withdraw
PSI_FLASHCOPY_DONE withdraw withdraw
PSI_MOUNT_DONE withdraw unmount
PSI_UNMOUNT_DONE withdraw n.a.
PSI_WITHDRAW_STARTED withdraw withdraw

The values the PSI can have and their meanings are shown in the following table:
Table 6. Possible Progress Status Indicator (PSI) Values
Value Meaning tdphdwdb2 Function
Allowed for Restart
Possible Cause of Failure
PSI_PREPARE_FLASHCOPY Set on the backup system
just before the flashcopy
request is issued to the
production system.
flashcopy
Restart tdphdwdb2 (with
function -f flashcopy... or
-f backup -t flashcopy)
after you have fixed the
failure cause.
v Production system not
set up properly
v Invalid
LOGON_HOST_PROD
value
PSI_FLASHCOPY_QUERY Set on the production
system when all source
and target volume queries
to the Copy Services
server have been done.
flashcopy
Restart tdphdwdb2 (with
function -f flashcopy or -f
backup -t flashcopy) after
you have fixed the failure
cause.
v Copy Services server
not available
v Incorrect volume size
v Target volume not
available
v Duplicate target
volumes found in .fct
file
PSI_FLASHCOPY_STARTED Set on the production
system just prior to the
flashcopy request to the
Copy Services server.
withdraw
Start tdphdwdb2 -f
withdraw to clean up the
backup system. Restart
tdphdwdb2 (with function -f
flashcopy or -f backup -t
flashcopy) after you have
fixed the failure cause.
v Copy Services server
not available
v Source/target
relationship already
exists
PSI_FLASHCOPY_DONE Set on the production
system when the
flashcopy request has
successfully finished.
withdraw
Start tdphdwdb2 -f
Backup system failed
while processing was
being done on production
system.

||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 6. Possible Progress Status Indicator (PSI) Values (continued)
Allowed for Restart
PSI_MOUNT_STARTED Set on the production
system when the import
volume groups, fscks,
and mounts have been
started.
withdraw or unmount
Start tdphdwdb2 -f
v fsck failure
PSI_MOUNT_DONE Set on the backup system
once all the mounts have
been done. Normal result
when using the
flashcopy function.
withdraw or unmount
Run tdphdwdb2 -f withdraw
prior to the next tdphdwdb2
-f flashcopy or tdphdwdb2
-f backup -t flashcopy
request.
Not an error condition
PSI_UNMOUNT_DONE Set on the backup system
once all the unmounts
have been done.
withdraw or new
FlashCopy backup
PSI_WITHDRAW_STARTED Set on the backup system
once tdphdwdb2 has been
started with the
withdraw function.
withdraw
Restart tdphdwdb2 -f
withdraw after you have
Copy Services server not
available
PSI_WITHDRAW_DONE Set on the backup system
after all source/target
volume relationships
have been withdrawn.
Normal result when
using the withdraw
function.
tdphdwdb2 with -f
flashcopy can be started.

BSI (Backup Status Indicator)
The BSI is used by DP for Snapshot Devices to determine whether a tdphdwdb2
request (with the flashcopy or backup function) is finished and a restore
(FlashBack Restore) can be started for this backup sequence number (BSN). The
values the BSI can have and their meanings are shown in the following table:
Table 7. Possible Backup Status Indicator (BSI) Values
Allowed for Restore
BSI_START Set on the backup system
when a flashcopy or
backup request is started.
No restore is allowed for
this BSN:
v The backup to TSM is not
yet finished (in case it
was requested)
v FlashCopy background
process not yet finished.
Table 7. Possible Backup Status Indicator (BSI) Values (continued)
Allowed for Restore
BSI_TAPEONLY Set on the backup system
when a FlashCopy
Backup to TSM has
finished successfully.
Previous BSI state:
BSI_START
Only a restore from TSM is
allowed for this BSN:
v The backup to TSM is
finished
process not yet finished
BSI_DISKONLY Set on the backup system
by the fcagent process
when it notices that the
FlashCopy background
process has finished
successfully.
Previous BSI state:
BSI_START
Only Flashback Restore is
v The backup to TSM is not
yet finished (in case it
was requested)
process is finished
BSI_DISKANDTAPE Set on the backup system
when a FlashCopy
Backup to TSM has
Previous BSI state:
BSI_DISKONLY
Set on the backup system
when it notices that the
FlashCopy background
process has finished
successfully.
Previous BSI state:
BSI_TAPEONLY
Flashback Restore and
restore from TSM are
v The backup to TSM is
finished
process is finished
BSI_INVALID Set on the backup system
by splitint when the
FlashCopy run terminates
with error.
Set on the backup system
when it notices an error.
No restore is allowed for
this BSN
v Last FlashCopy run
terminated with error
v Last FlashCopy run
was withdrawn before
the BSI was updated to
BSI_DISKONLY or
BSI_DISKANDTAPE by
the fcagent


RSI (Restore Status Indicator)
The RSI is used by DP for Snapshot Devices to determine whether a tdphdwdb2
request (with the restore function, FlashBack Restore) is finished and a new
flashcopy or backup function call with a new backup sequence number (BSN) can
be started.
The following table shows the values and the meanings of the RSI:
Table 8. Possible Restore Status Indicator (RSI) Values
Allowed for Restore
RSI_START Set on the production
system when a FlashCopy
Restore is started.
No new FlashCopy is
allowed:
v The FlashCopy
background process
initiated by the last
FlashBack Restore is not
yet finished.
RSI_DISKONLY Set on the production
system by the fcagent
process when it notices
that the FlashCopy
background process has
Previous RSI state:
RSI_START
A new FlashCopy is
allowed::
v The FlashCopy
background process
FlashBack Restore is
finished
RSI_INVALID Set on the production
system when a FlashCopy
Restore terminates with
error.
Set on the production
system by the fcagent
process when it notices
an error.
A new FlashCopy is
allowed, but a warning
message is shown:
v The FlashCopy
background process,
FlashBack Restore is not
finished.
v The administrator has to
make sure that the
production system is in a
valid state, by means of a
database restore from
TSM
Only a warning
condition:
v last FlashBack Restore
run terminated with
error.


Chapter 7. The DP for Snapshot Devices Profile (.fcs) and
Target Volumes File
This profile is defined by the user with all the information DP for Snapshot
Devices needs to successfully perform the following functions:
v run a FlashCopy from source to target volumes
v withdraw the source/target volume relation
v inquire about the status of the backup cycles
v delete an entry from the DP for Snapshot Devices control file
Like the other profiles of DP for mySAP (.utl), the DP for Snapshot Devices
profile is normally used in conjunction with only one database, i.e., for only one
SID. The profile is identified by the value of the parameter -p of the DP for
Snapshot Devices program tdphdwdb2.
Location and Naming Conventions
The profile is normally located in the /db2/<SID>/dbs directory; it should follow
the naming convention of the other profiles and, to easily distinguish it from the
others, have the character string fcs as the suffix of its name. Example:
/db2/D01/dbs/initD01.fcs
Being in an NFS directory, the profile can be accessed from the production and
backup systems.
To facilitate understanding and use of this profile, the sample used in the test and
development environments is shown in Sample DP for Snapshot Devices Profile
on page 241.
While the elements of the profile are not case sensitive, by convention topics are
shown in lowercase and parameters in uppercase.
Structure of the DP for Snapshot Devices Profile
Comments can be used at any place within the profile; they are indicated by a #
sign in the first column of a line.
Note: Tab characters are not permitted.
In order to cover future development additions, the profile has been broken up
into the following topics:
v global
v DB2
v copyservices_data
Each topic has a unique set of specific parameters. All parameters belonging to a
topic are enclosed by a topic begin statement (>>> topicname) and a topic end
statement (<<< topicname). The base structure for the topics is as follows:

# Global topic
>>> global
parameter_line 1
....
....
parameter_line n
<<< global
# DB2 topic
>>> DB2
parameter_line 1
....
....
parameter_line n
<<< DB2
# copyservices_data topic
>>> copyservices_data
parameter_line 1
....
....
parameter_line n
<<< copyservices_data

As of DP for Snapshot Devices 5.3.1, the shark_data topic has been redesignated
as the copyservices_data topic in order to provide a more generic naming for
supporting various storage systems. The following table summarizes the naming
changes:
Table 9. Parameter Name Changes as of V5.3.1
Old name (prior to 5.3.1) New name (as of 5.3.1)
shark_data copyservices_data
SHARK_SERVERNAME_PRIMARY PRIMARY_COPYSERVICES_SERVERNAME
SHARK_SERVERNAME_BACKUP BACKUP_COPYSERVICES_SERVERNAME
SHARK_USERNAME COPYSERVICES_USERNAME
SHARK_VOLUMES_FILE VOLUMES_FILE

Parameters of the DP for Snapshot Devices Profile
The following parameters are part of the global topic:
Table 10. DP for Snapshot Devices Profile Parameters (global Topic)
Parameter Name Value
LOGON_HOST_PROD tcp_name db2<sid> The values will be used when tdphdwdb2 is started on the
backup system to perform the actual FlashCopy under the
user ID db2<sid> on the production system identified by the
TCP name.
Note: The former format LOGON_HOST_PROD hostname
tcp_name db2<sid> has been reduced to
LOGON_HOST_PROD tcp_name db2<sid> to facilitate use
within high availability (HA) environments. The old format is
still supported for compatibility. However, if the hostname is
not identical to the production TCP name, it will be ignored.
Prior to level 1.1.0.3, tcp_name and hostname had to be
identical.
This parameter is required.
DP for Snapshot Devices Profile and Target Volumes File

Table 10. DP for Snapshot Devices Profile Parameters (global Topic) (continued)
LOGON_HOST_BACK hostname This statement identifies the hostname of the backup system
and allows tdphdwdb2 to call DP for Snapshot Devices with the
flashcopy function only on the backup system. Use the
format as indicated.
IDS_CONTROL_FILE complete path/filename The value of this parameter specifies the name of the file that
will contain the status and the summary information of the
various backup cycles. A new tdphdwdb2 run (with a
tdphdwdb2 flashcopy request) is considered to start a backup
cycle, which normally will end with a successful tdphdwdb2
withdraw request.
Each backup cycle will be represented by a record containing
information such as BACKUP SEQ.NUMBER, STATUS, etc.
See also the BACKUP_MAX parameter described below.
Details can be displayed via the tdphdwdb2 inquire function.
The backup sequence number of a backup cycle will also
appear in the tdphdwdb2 backup log files.
With the very first tdphdwdb2 flashcopy/backup request, the
specified directory and the file itself will be created. The
directory must be within the scope of an available NFS
directory so it can be reached from the production and backup
systems.
BACKUP_MAX nnn The decimal value of this parameter specifies how many
entries (backup cycles) will be kept in the
IDS_CONTROL_FILE. Whenever the number of backup cycle
entries reaches the BACKUP_MAX value, the oldest entry will
be deleted. However, the files (such as splitint reports, traces
etc.) for deleted entries are retained as long as they are within
3 days of the now oldest entry.
A backup cycle that refers to a target set that is in the state
IN_USE will not be deleted. These cycles can also be seen
using the tdphdwdb2 ts_inquire function.
Default value: 30
CONFIG_FILE complete path/filename The value of this parameter specifies the name of a file that
will be created and written to when the password function of
the tdphdwdb2 command is performed. The directory used
must be within the scope of an available NFS directory so that
it can be reached from the production and backup systems.
Use the character string "fcp" as a file extension to distinguish
it from the other profiles and control files (see also Figure 7 on
page 35).
The user must create the specified directory under the user ID
db2<sid>, if it does not already exist.
Chapter 7. The DP for Snapshot Devices Profile (.fcs) and Target Volumes File 145
WORK_DIR complete path The value of this parameter specifies a directory where the
temporary files of a backup cycle are kept. It is mainly used
by tdphdwdb2 to exchange temporary information between the
backup and production systems. It must be reachable via the
NFS setup.
db2<sid>, if it does not already exist.
LOG_TRACE_DIR complete path The value of this parameter specifies the directory in which all
the run logs and trace files of tdphdwdb2 will be placed. It
must be reachable via the NFS setup.
db2<sid>.
This parameter is optional. If not specified, the log and trace
files are written to the directory specified in WORK_DIR.
TRACE YES|NO This value allows specifying a trace along with the normal
report on the backup and production sides.
Default value: YES
SUPPORT_ADMIN_ASSISTANT YES|NO If the value of this parameter is set to YES, all information
that is written to the DP for Snapshot Devices log file
(tdphdwdb2_b_<date/time stamp>.log) is forwarded from the
backup system to the DP for mySAP Administration Assistant.
If the value of this parameter is set to YES, you must also set
PROLE_SERVICE_NAME parameter if a service name other
than the default was defined at installation time.
To install and use the DP for mySAP Administration Assistant,
see Data Protection for mySAP Installation and Users Guide for
DB2 UDB.
Default value: NO
PROLE_SERVICE_NAME This parameter specifies the service name with which DP for
Snapshot Devices communicates with the DP for Snapshot
Devices acsprole process to launch the DP for Snapshot
Devices splitint process on the production system and to
provide information to the Administration Assistant. The
service name is defined by DP for Snapshot Devices at
installation time in /etc/services.
Default value: tsmacsdb2

|
|
|
||
|
|
|
|
|
|
|
TDPR3_CONFIG_FILE complete path/filename The value of this parameter will specify the DP for mySAP for
DB2 UDB profile. For more information, see Data Protection for
mySAP Installation and Users Guide for DB2 UDB.
If you want to employ parallel backup/restore of EEE
databases, you can use different DP for mySAP profiles. This
requires that you specify the parameter DB2_VENDOR_ENV
in the DP for Snapshot Devices profile. To specify different DP
for mySAP profiles, you have to add the extension .## to this
parameter. For example:
/db2/G01/dbs/initG01.utl.##
This value will be replaced by DP for Snapshot Devices with
the corresponding DP for mySAP profiles for each node, for
example:
/db2/G01/dbs/initG01.utl.0
COPYSERVICES_HARDWARE_TYPE This parameter specifies the type of hardware subsystem.
Possible parameter values :
ESS800 | SVC | DS6000 | DS8000 | SAN_NSERIES
LVM_FREEZE_THAW Specifies whether a freeze will be performed prior to taking
the FlashCopy/snapshot and a thaw operation afterward.
Under AIX it only takes effect for JFS2 file systems. Possible
parameter values : YES | NO. This parameter is optional. It will
be forced to YES for N Series configurations.
Default value: NO
LVM_FREEZE_TIMEOUT (JFS2 filesystem only) This parameter specifies the maximum
amount of time (in minutes) the file system will remain frozen
if LVM_FREEZE_THAW is set to YES. This ensures that the
file systems do not remain frozen indefinitely. This parameter
is optional.
Default value: 12
SNAPSHOT_POLICY For an N series configuration, determines whether a fixed
number of snapshots will be kept (VERSIONING) or whether
the number is based on the free space provided in the
volumes (ADAPTIVE). If VERSIONING is selected, the
number of snapshots is defined by the MAX_VERSIONS
parameter.
If ADAPTIVE is specified, and a failure occurs due to lack of
space, the earliest snapshot will be deleted until sufficient
space is available. The user can thus indirectly control the
number of snapshots by the amount of space that is available
for them.
Default value: VERSIONING
||
|
|
|
||
|
|
|
|
|
||
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
MAX_VERSIONS For an N Series configuration, this parameter specifies the
maximum number of snapshot versions to be maintained
when SNAPSHOT_POLICY is set to VERSIONING. When this
limit is reached, the oldest version is deleted.
Default value: 256

The following parameters are part of the DB2 topic:
Table 11. DP for Snapshot Devices Profile Parameters (DB2 Topic)
DB2_REMOTE_ALIAS aliasname The value of this parameter specifies the database alias name
for the DB2 connection to the remote database on the
production system. The remote database aliasname will be
cataloged on the remote node REM<SID>. For more
information, see Configuring DP for Snapshot Devices on the
Backup System (setupDB2BS) on page 65.
DB2_RECOVERY_LOG complete path/filename The value of this parameter specifies the DP for mySAP for
DB2 UDB recovery log file. DP for mySAP writes all
information concerning backups to this file. For more
information, see Data Protection for mySAP Installation and
Users Guide for DB2 UDB.
DB2_TDPR3_LIB complete path/filename The value of this parameter specifies the DP for mySAP for
DB2 UDB vendor library, which is called by the db2 backup
and db2 restore commands. For more information, see Data
DB2_NUM_SESSIONS n0[:n1:n2...] The value of this parameter specifies the number of TSM
sessions to be used for the db2 backup and db2 restore
commands. When creating a backup to multiple locations, a
larger number of sessions may be used to improve
performance. For more information, see IBM DB2 Universal
Database Command Reference Version 8.
When employing multiple EEE partitions, n0 applies to
partition 0, and additional values (n1, n2, etc., separated by
colons) can be supplied to apply to partitions 1, 2, etc. If the
number of values specified is less than the number of
partitions, the values not supplied default to the value of n0.
If this parameter is not specified, the number of TSM sessions
will be determined by the parameter MAX_SESSIONS of the
DP for mySAP profile.
This parameter is required if you specified the extension .##
with the parameter TDPR3_CONFIG_FILE. Otherwise, it is
optional.

||
|
|
|
|
Table 11. DP for Snapshot Devices Profile Parameters (DB2 Topic) (continued)
DB2_PARALLELISM n0[:n1:n2...] The value of this parameter specifies the number of
tablespaces which can be read in parallel by the db2 backup
and db2 restore commands. If the parameter is not specified,
tdphdwdb2 will take the default value, which is 1. For more
information, see IBM DB2 Universal Database Command
Reference Version 8.
This parameter is optional.
DB2_NUM_BUFFERS n0[:n1:n2...] The value of this parameter specifies the number of buffers to
be used for the db2 backup and db2 restore commands. The
default is 2. However, when creating a backup to multiple
locations, a larger number of buffers may be used to improve
performance. For more information, see IBM DB2 Universal
Database Command Reference Version 8.
DB2_BUFFER_SIZE n0[:n1:n2...] The value of this parameter specifies the size, in 4 KB pages,
of the buffer used when building the db2 backup image and
restoring a backup image. The minimum value for this
parameter is 8 pages; the default value is 1024 pages. If a
buffer size of zero is specified, the value of the Database
Manager configuration parameter backbufsz will be used as the
buffer allocation size.
DB2_VENDOR_ENV complete path/filename The value of this parameter specifies the DP for mySAP
vendor environment file vendor.env. This file is created by
DP for mySAP at installation time and will be placed in the
same location as the DP for mySAP profile. It contains at least
one value XINT_PROFILE, which points to the DP for mySAP
profile, for example:
XINT_PROFILE=/db2/G01/dbs/initG01.utl
If you specify this parameter, DP for Snapshot Devices can
make use of the enhanced DP for mySAP support for DB2
UDB V8. For more information about this support see Data
If you want to utilize the parallel backup/restore of EEE
databases, you can use different DP for mySAP profiles. To
specify different DP for mySAP profiles, you have to add the
extension .## to this parameter. For example:
/db2/G01/dbs/vendor.env.##
This value will be replaced by DP for Snapshot Devices with
the corresponding DP for mySAP profiles for each node, for
example:
/db2/G01/dbs/vendor.env.0
Each of the vendor.env files has an entry XINT_PROFILE,
which must point to the DP for mySAP profile, for example:
u XINT_PROFILE=/db2/G01/dbs/initG01.utl.0
XINT_PROFILE=/db2/G01/dbs/initG01.utl.1
XINT_PROFILE=/db2/G01/dbs/initG01.utl.2
DB2_EEE_PARALLEL_BACKUP YES/NO If the value of this parameter is specified with YES, the
functionality for parallel backup/restore of EEE databases will
be used for DB2 backups of EEE databases.
This parameter requires that you specify the parameter
DB2_VENDOR_ENV in the DP for Snapshot Devices profile.
The default value is NO.
DB2_EEE_PARALLEL_RESTORE YES/NO If the value of this parameter is YES, the functionality for
parallel backup/restore of EEE databases will be used for DB2
restores of EEE databases.
This parameter requires that you specify the parameter
DB2_VENDOR_ENV in the DP for Snapshot Devices profile.
The default value is NO.

DB2_EEE_SYNCTIMEOUT nnnnn DB2 UDB EEE (with more than one production database
server) only.
The value of this parameter specifies the time in seconds that
DP for Snapshot Devices waits for synchronization of all DP
for Snapshot Devices processes running for multiple
production EEE database servers. Make sure that the specified
value is large enough. For example, if you plan to do backups
to TSM, you must set this value at least as large as the backup
time to TSM. If your EEE database partition has 200GB of data
and you back up to 4 tapes in parallel (each tape with
50GB/h), then this backup will take about 1 hour (3600
seconds). You should then set DB2_EEE_SYNCTIMEOUT at
least to 4000 seconds. If this value is too small, then the
synchronization of all DP for Snapshot Devices processes will
fail and the backup of the database will fail as well. If you
have only one production database server, then this value is
not needed.
Default value: 3600
DB2_AUTHENTICATION SERVER/
SERVER_ENCRYPT/CLIENT
Authentication methods for the DB2 database server
Access to a DB2 instance or DB2 database first requires that
the user be authenticated. The authentication type for each
instance determines how and where a user will be verified.
The authentication type is stored in the database manager
configuration file at the server.
The following authentication types are provided:
SERVER
Specifies that authentication occurs on the server
using local operating system security. This is the
default security mechanism.
SERVER_ENCRYPT
Specifies that the server accepts encrypted SERVER
authentication schemes.
CLIENT
CLIENT Specifies that authentication occurs on the
database partition where the application is invoked
using operating system security.
.If you change the DB2_AUTHENTICATION method, you
must uncatalog the DB2 aliases (R_<SID>, R_<SID>_<NN>)
on the backup system. On the next FlashCopy or snapshot
run, all DB2 aliases will be re-cataloged with the new
DB2_AUTHENTICATION method.
Default value: SERVER
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DB2_RESTART_TSM_BACKUP YES/NO This parameter must be specified to enable the function
'restart_backup'. If this parameter is set to YES, then a
FlashCopy Backup (with function f backup) will no longer be
automatically unmounted/withdrawn, if the TSM backup fails
for one (or more) DB2 partitions. With the filesystems left
mounted on the backup system, customers can then
investigate the reason for the failed TSM backup. When the
problem has been resolved, the TSM backup of the failed DB2
partitions can be restarted.
Default value: NO


||
|
|
|
|
|
|
|
|
|
|
The following parameters are part of the copyservices_data topic.
Table 12. DP for Snapshot Devices Profile Parameters (copyservices_data Topic)
COPYSERVICES_USERNAME Defines the username that was set up by the CIM Agent (or
SVC master console) or the NetApp username defined to use
the API.
PRIMARY_COPYSERVICES_SERVERNAME Defines the TCP/IP address of the host running the DS Open
API CIM Agent (which can manage the the primary and
secondary Copy Services servers of the ESS or DS cluster), or
the SVC master console, or of the filer for N Series (Net App).
COPYSERVICES_SERVERPORT Defines the port number of the CIMOM in the DS Open API
CIM Agent (or the SVC master console).
Note: Do not specify 5989, which is the default port for secure
mode.
Default value: 5988
COPYSERVICES_TIMEOUT Defines the maximum amount of time (in minutes) the CIM
Client will wait for the response to a call issued to the
CIMOM (CIM Agent) If the CIM Client does not receive a
response within this time, DP for Snapshot Devices will issue
a timeout error message.
Default value: 12
COPYSERVICES_COMMPROTOCOL Defines the protocol to be used for communication between
Data Protection for Snapshot Devices and the CIM Agent.
Possible parameter values are : HTTP | HTTPS
Default value: HTTP
COPYSERVICES_CERTIFICATEFILE If COPYSERVICES_COMMPROTOCOL is set to HTTPS, defines
the fully qualified certificate file name or NO_CERTIFICATE to
select null trust provider mode. Use of NO_CERTIFICATE is
recommended only when both the production and backup
systems, as well as the storage system, are protected by a
firewall.
Default value: NO_CERTIFICATE
BACKUP_COPYSERVICES_SERVERNAME
(currently not implemented)
Defines the TCP/IP address of a second host running the DS
Open API CIM Agent (or the SVC master console). If the
backup is also not accessible, DP for Snapshot Devices will
terminate with an error message.
||
|
|
|
||
|
|
|
|
||
|
|
|
|
|
|
||
|
|
|
|
||
|
|
|
|
|
|
|
Table 12. DP for Snapshot Devices Profile Parameters (copyservices_data Topic) (continued)
FLASHCOPY_TYPE COPY|NOCOPY|INCR This value specifies whether the storage subsystem performs a
bitwise copy of data from one logical volume to another.
A NOCOPY value directs the storage system to not
immediately perform a bitwise copy of the data from one
volume to another. However, it directs the system to perform
a bitwise copy of a track if data is modified after the
FlashCopy request. This value is recommended under the
following conditions:
v A complete copy of the source volumes on which the
database files reside to the target volumes is not desired.
v Backup time constraints are a concern
A successful backup of the database to the Tivoli Storage
Manager server is obtained even if the parameter is set to
NOCOPY. The Tivoli Storage Manager server will contain a
valid database backup. However, the target volumes cannot be
used for a FlashBack Restore.
A COPY value directs the storage system to perform a bitwise
copy of the data from one physical volume to another. This
value is recommended under the following conditions:
v You intend to perform a Quick Restore of the backed-up
database
v A copy of the database data on the target volume is desired.
An INCR value directs the storage system to perform a
bitwise cop,y of only the tracks modified on the source
volume since the previous FlashCopy to the target volume.
This value is recommended under the following conditions:
v You intend to perform a FlashBack Restore of the backed-up
database.
v You intend to schedule more frequent backups for your
database.
v A copy of the database data on the target volume(s) is
desired.
Note: INCR is not valid for an SVC configuration. Only
COPY is supported for an N series configuration
COPY or INCR is recommended if quick disk-only backups
are planned.
A COPY or INCR value is required if the customer plans to
run a disk restore such as a FlashBack Restore.
INCR is recommended if Tivoli Storage Manager backups are
desired from disk copies, which are created with less burden
on the storage system than for the COPY option.
This parameter value is overridden with the value of the -C
parameter if it is specified in the command line at backup
time.
For SVC only: If FLASHCOPY_TYPE is specified as NOCOPY,
SVC_COPY_RATE is forced to 0. Conversely, if
SVC_COPY_RATE is specified as 0, FLASHCOPY_TYPE is
forced to NOCOPY.
This is an optional parameter. Default value: COPY

|
|
Table 12. DP for Snapshot Devices Profile Parameters (copyservices_data Topic) (continued)
VOLUMES_FILE This value specifies the fully qualified file name (the DP for
Snapshot Devices target volumes file) containing the serial
numbers of all target volumes planned for use. The specified
file must be reachable via the NFS setup. Use the character
string fct as file extension to distinguish it from the other
profiles and control files (see also Figure 7 on page 35).
Note: This parameter is required for FlashCopy devices only.
N series devices define the target volumes automatically when
a snapshot is requested.
CLEAR_TARGET_PVID YES|NO (obsolete) Defines whether the withdraw function of DP for Snapshot
Devices should clear the physical volume identifiers (PVID) of
the target volumes that were created during the flashcopy
function of DP for Snapshot Devices.
If the FLASHCOPY_TYPE is set to INCR or COPY, the value
of this parameter will be forced to NO.
This parameter has been removed. If it is specified, it will be
ignored.
This is an optional parameter. Default value: None
SVC_COPY_RATE (SVC only) The copy rate specifies the priority that the SVC
will give to the FlashCopy background process for the current
backup or restore. A value of 100 is the highest but has the
greatest impact on the responsiveness of the storage system. A
value of 0 means no that there is no background copy process
and forces FLASHCOPY_TYPE to NOCOPY.
This parameter is optional. If it is not specified, 100 is
assumed if FLASHCOPY_TYPE is COPY (or not specified)
and 0 if FLASHCOPY_TYPE is NOCOPY.

Note: The copy rate for an active FlashCopy operation can be
changed dynamically by using the tdphdwdb2 -f
modify_copyrate function.

DP for Snapshot Devices Target Volumes File
Note: This file pertains only to FlashCopy configurations. The N series subsystem
defines the target files internally as part of the snapshot process.
The DP for Snapshot Devices target volumes file, which is referenced by the DP for
Snapshot Devices profile (.fcs) when running a FlashCopy backup, is the file in
which the customer needs to specify the target volumes he plans to use in such a
backup.
Within one FlashCopy backup, a set of target volumes (a target set) will be needed
for a FlashCopy operation with a set of source volumes making up the database
(see Overall Disk Layout Considerations on page 34). More than one target set
can be defined for use in different FlashCopy backups (see Chapter 10, Multiple
Backup Generations (Target Sets) on Disk, on page 219); in the past a maximum
of two targets sets were possible when running the DP for FlashCopy functionality
for AIX LVM mirrored environments (see Chapter 8, DP for Snapshot Devices
Functionality for AIX LVM Mirrored Environments, on page 161).
||
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The volumes in each target set used in one backup need to be specified in a similar
way in a separate target set topic. A target set topic is delimited by a topic begin
string (>>>) and a topic end string (<<<), each followed by the target set topic
name. The target set topic names start with the prefix volumes_set_ and are
appended with a target set number x (also referenced in some documentation as a
data container ID) to differentiate the various target set topics, where it is
recommended to use one- or two-digit values.
In each topic, use one TARGET_VOLUME parameter for each target volume to be
used in this target set; for details, see Table 14 on page 157. A target set topic
appears as follows:
>>>volumes_set_1
TARGET_VOLUME ...
.
.
.
TARGET_VOLUME ...
<<<volumes_set_1

If you plan to use a second target set (multiple target sets), you just add the next
target set topic in the file:
>>>volumes_set_2
TARGET_VOLUME ...
.
.
,
TARGET_VOLUME ...
<<<volumes_set_2

For information on defining multiple target sets, see Chapter 10, Multiple Backup
Generations (Target Sets) on Disk, on page 219.
Comments can be used only before the first target set topic; they are indicated by
the # character in the first column of a line. Tab characters are not permitted.
As of DP for Snapshot Devices 5.3.1, the shark_volumes_set topic has been
redesignated as volumes_set in order to provide a more generic naming for
supporting various storage systems. The following table summarizes the naming
changes:
Table 13. Target Volumes File Parameter Changes as of V5.3.1
Old name (prior to 5.3.1) New name (as of 5.3.1)
shark_volumes_set_x volumes_set_x
SHARK_TARGET_VOLUME TARGET_VOLUME
SHARK_ID_LVM_MIRROR (see Chapter 8,
DP for Snapshot Devices Functionality for
AIX LVM Mirrored Environments, on page
161)
HARDWARE_ID_LVM_MIRROR

Parameters for an ESS or DS Configuration
Each target volume planned for use must be specified by its serial number as
shown in Table 14 on page 157. When DP for Snapshot Devices is executing its
split function, it will, for each source volume which was identified as a candidate
for a FlashCopy, look for either

v a source/target volume correlation, or
v a target-volume-only specification
Table 14. Parameters of the volumes_set_x Topic (ESS or DS)
TARGET_VOLUME
<target volume serial number>
<source volume serial number>
<source volume size>
This parameter specifies the serial number of at least the target volume
of one volume pair involved in the FlashCopy. Each target volume
planned for use for a FlashCopy operation must be specified by its
serial number in the volumes_set_1 topic. The source volume serial
number and size are optional. If they are given, they must correctly
reflect the current storage-system configuration and have the following
format:
TARGET_VOLUME 401FCA90 40EFCA90 Size=2.0_GB
If they are omitted, dashes must be entered in both fields as
placeholders, as shown in the following example:
TARGET_VOLUME 401FCA909 - -
The dashes will be replaced by splitint with the information obtained
from the storage system configuration. When splitint has found all the
source volumes that make up the backup request of brbackup, splitint
tries to find an appropriate target volume specified in the
volumes_set_1 topic. Note the target volume requirements for a
FlashCopy:
v Tthe size must be the same as that of the source volume
v The source volumes can be in different hardware units.
v The target volume in each case must be in the same hardware unit as
the respective source volume.
Note: Do not change the order of the parameters (target volume serial
number, source volume serial number, size of source volume).

For the functions of the DP for Snapshot Devices program splitint, its parameters
and how it should be used, see Chapter 6, Description and Usage of the DP for
Snapshot Devices Commands, on page 105.
Samples of the different setup possibilities for the volumes_set_1 topic are shown
in Sample DP for FlashCopy Target Volumes File (ESS or DS Configuration) on
page 251.
Note: Although you can specify all three fields within the TARGET_VOLUME
parameter, it is recommended to specify only the first field (target volume
serial number) and a dash (-) for the other two fields. Once a FlashCopy
has been done, DP for Snapshot Devices will replace the two dashes with
the actual values (source volume serial number, source volume size), and
these values will continue to be used in future runs. If the storage-system
configuration is subsequently altered, the source volume serial numbers and
sizes should be reset to dashes to allow the new values to be determined.
Any comments placed within or between the target set topics will be overwritten
when DP for Snapshot Devices rewrites the target set topic(s).
In case you plan to remove a target set volume, you must first run a DP for
Snapshot Devices tdphdwdb2 -f withdraw to ensure that, based on the usage of
this target set:
v any existing source/target relationships (such as INCR or NOCOPY) are
withdrawn, the FlashCopy backup is no longer valid, and no potential problems
remain for succeeding FlashBack Restores.
v any mounted file systems using this target volume on the backup system will be
released (unmount fs, ..., exportvg)
Parameters for an SVC Configuration
Each target volume planned for use must be specified by its virtual disk name as
shown in Table 15. When DP for Snapshot Devices is executing its split function, it
will, for each source volume which was identified as a candidate for a FlashCopy,
look for either
Table 15. Parameters of the volumes_set_x Topic (SVC)
TARGET_VOLUME
<target volume virtual disk name>
<source volume virtual disk name>
This parameter specifies the virtual disk name of at least the target disk
of one pair of virtual disks involved in the FlashCopy. Each target
planned for use for a FlashCopy operation must be specified by its
name (also known as the caption) in the volumes_set_1 topic. The source
name and size are optional. If they are given, they must correctly reflect
the current storage-system configuration and have the following format:
TARGET_VOLUME svdftgt4 svdfsrc4 Size=2.0_GB
If they are omitted, dashes must be entered in both fields as
placeholders, as shown in the following example:
TARGET_VOLUME svdftgt4 - -
The dashes will be replaced by splitint with the information obtained
from the storage system configuration. When splitint has found all the
source volumes that make up the backup request of brbackup, splitint
tries to find an appropriate target volume specified in the
volumes_set_1 topic. Note the target volume requirements for a
FlashCopy:
v the size must be the same as that of the source volume
v the source and target volumes must be in the same SVC cluster.
Note: Do not change the order of the parameters (target volume name,
source volume name, size of source volume).

For the functions of the DP for Snapshot Devices program splitint, its parameters
and how it should be used, see Chapter 6, Description and Usage of the DP for
Snapshot Devices Commands, on page 105.
Samples of the different setup possibilities for the volumes_set_1 topic are shown
in Sample DP for FlashCopy Target Volumes File (SVC Configuration) on page
253.
name) and a dash (-) for the other two fields. Once a FlashCopy has been
done, DP for Snapshot Devices will replace the two dashes with the actual
values (source volume name, source volume size), and these values will
continue to be used in future runs. If the storage-system configuration is

subsequently altered, the source volume names and sizes should be reset to
dashes to allow the new values to be determined.
Any comments placed within or between the target set topics will be overwritten
when DP for Snapshot Devices rewrites the target set topic(s).
In case you plan to remove a target set volume, you must first run a DP for
Snapshot Devices splitint -f withdraw to ensure that, based on the usage of this
target set:
v any existing source/target relationships (such as NOCOPY) are withdrawn, the
FlashCopy backup is no longer valid, and no potential problems remain for
succeeding FlashBack Restores.
v any mounted file systems using this target volume on the backup system will be
released (unmount fs, ..., exportvg)

Chapter 8. DP for Snapshot Devices Functionality for AIX LVM
Mirrored Environments

Notes
Data Protection for Snapshot Devices currently does not support AIX LVM
mirroring within an N series configuration.
The use of LVM mirroring in an SVC configuration requires that the mirror
sets be in different SVC clusters. Please refer to the README information for
the current status of the support for this requirement.
Overview
In order to shorten the backup window needed for online/offline backups of a
large mySAP database, customers can employ the hardware copy function of a
storage system running under control of DP for Snapshot Devices and DP for
mySAP (a process hereafter referred to in this chapter as FlashCopy backup).
Database environments set up with mirrored logical volumes using the AIX Logical
Volume Manager (LVM) that are physically separated in different hardware units
(or SVC clusters
24
) have a high availability in a production environment, where
even a total loss of half of the mirrors will not cause an outage of the production
system. However, in earlier releases, the physical volumes (source volumes) of all
AIX LVM mirrors
25
made up the source for the FlashCopy backup process of the
database and required the same number of physical volumes (target volumes) for
the FlashCopy (in Figure 13 on page 166, for example, both copy sets A and B, or a
total of 12 source volumes, thus requiring 12 target volumes).
The software now offers a FlashCopy backup solution that is much more cost
effective. If the logical volume (LV) mirrors (for each LV a maximum of 3) are
properly distributed over various source volumes in separate hardware units, the
number of target volumes needed does not exceed the number of source volumes
required to keep a complete set of a single mirror of all involved LVs. In the
preceding example, only 6 source volumes (and 6 target volumes) are needed.
Note: DP for Snapshot Devices support of the LVM mirroring functionality
restricts the number of hardware units to be used. The database (one AIX
LVM mirror thereof) and its target volumes needed for a FlashCopy backup
must fit into one hardware unit. For an SVC configuration, each SVC cluster
is considered to be a hardware unit.
Assuming, in an AIX LVM environment, that the database is set up such that each
logical volume (LV) runs with 2 AIX LVM mirrors and the mirrors have been
properly distributed over 2 hardware units, only half of the previously required
target volumes are needed any longer; only 1 of the 2 units is then involved within
the FlashCopy backup process. By using the parameter
24. In an SVC environment, the term hardware unit should be understood to mean SVC cluster.
25. The terms mirror and copy are used interchangeably in this chapter.

|
|
|
|
|
HARDWARE_ID_LVM_MIRROR, the DP for Snapshot Devices functionality can be
activated if the AIX LVM mirrors have been properly set up.
Note: In the following, the term hardware unit should be understood to mean SVC
cluster if an SVC is configured.
The DP for Snapshot Devices functionality for AIX LVM mirrored environments is
restricted to the support of 2-mirror AIX LVM environments.
The overall benefits of DP for Snapshot Devices support for LVM mirroring are
noted in Advantages of the Special Handling of AIX LVM Mirrored
Environments.
The software provides a Flashback Restore functionality which allows those
FlashCopy backup objects (residing on target volumes) to be used for a restore
process; this will significantly lower the outage time needed for a restore/recovery
compared to a LAN/SAN-based restore process using Tivoli Storage Manager
backup objects.
This chapter focuses on the basic requirements for running the pre-5.3 FlashCopy
functionality for AIX LVM mirrored environments, with which a FlashCopy
backup can be performed from one (source) copy set to one target set. From the
viewpoint of a database backup, the option has been available up to now to save
the database, consisting of 2 (source) copy sets, to 2 different target sets. From the
viewpoint of a FlashCopy, however, this was in each case a FlashCopy of one
source set to one target set (1:1 relation). As such, it could have been considered as
a specific type of multiple target set support.
The software now offers support for multiple target sets for each copy set in each
of the 2 hardware units; this is a 1:n relation between copy sets and target sets. For
details, see Chapter 10, Multiple Backup Generations (Target Sets) on Disk, on
page 219.
Advantages of the Special Handling of AIX LVM Mirrored Environments
The LVM mirroring functionality offers the following advantages:
v Only one of the 2 AIX LVM LV mirrors becomes the subject of a triggered
FlashCopy process, which
saves the number of needed target volumes
shortens the FlashCopy process
avoids unnecessary performance degradation within the storage system
avoids AIX LVM conflicts when at least one stale physical partition is
produced within one or more AIX LVs on the backup system.
v Late failures within the FlashCopy operation due to unsuitable setups can be
avoided; by checking the proper disk setup and customization, DP for Snapshot
Devices terminates in case of unsuitable conditions and therefore avoids
unnecessary cleanup activities on the backup system.
v All AIX LVM mirrors on the production system therefore stay synchronized
during the FlashCopy backup process. The FlashCopy backup process at no time
compromises the high availability purpose the AIX mirrors were set up for. It is
not necessary to resynchronize the LVs after the FlashCopy backup request.
v Online or offline FlashCopy backups can be taken in the same manner as before;
there is no change in the backup/restore procedures as outlined in the
applicable chapters.
AIX LVM Mirrored Environments

v DP for Snapshot Devices provides information about asymmetrical AIX LVM
mirror setups when encountered, which can not only prevent the FlashCopy
backup from running in unfavorable situations but can also reveal a general
deficiency of the high availability setup as well.
v The software allows one copy set to be used in a FlashCopy backup to more
than one target set in one hardware unit (see Chapter 10, Multiple Backup
Generations (Target Sets) on Disk, on page 219), thus increasing the earlier
maximum number of disk backup levels from 2 to n
26
.
v DP for Snapshot Devices needs only one of the 2 copy sets for a Flashback
Restore, thereby
offering the possibility that n FlashCopy backup versions can be eligible for
a Flashback Restore
enabling much faster return to production mode after an outage (everything
for the synchronization of the VG will be prepared in advance; however the
synchronization can be initiated by the DBA at a more suitable time later).
Functional Overview
The targeted environment is an AIX LVM mirroring setup within which DP for
Snapshot Devices now provides the possibility of a much more economic backup
strategy. This AIX LVM mirroring setup is considered to have the mySAP DB
server on a production system running either
v in a single machine environment, or
v in a 2-machine environment (either as the primary or takeover machine) using
HACMP (as shown in Figure 13 on page 166), where the mirrors are properly
distributed within 2 hardware units (when working with 2 copy sets).
27
The latter is often referred to as a disaster-tolerant solution. Both environments will
have the two sets of copies, each residing in a different hardware unit and
managed by AIX LVM. Such an AIX LVM mirrored environment is used in such a
way that in case of the loss of one site (for example, the local machine and local
hardware unit) the other site (with the remote machine and remote hardware unit)
can still operate and perform a takeover. If the failure of the disk subsystem is just
temporary, the AIX LVM takes care of the synchronization after the disk subsystem
comes up again. In case of a single-machine setup, the environment is protected
only against the outage of one of the 2 hardware units.
The goal of the DP for Snapshot Devices support for the LVM mirroring
functionality is to leave the general DB backup/restore procedures (as described in
Chapter 4, Backup Methods, on page 73 and Chapter 5, Restore Methods, on
page 81) unchanged, but to allow a customer having a setup with AIX LVM
mirrors to deal with much fewer target volumes within a FlashCopy backup
request compared to previous DP for Snapshot Devices code levels.
FlashCopy Backup Process
The FlashCopy backup request will be started on the backup system. Identify
which of the 2 (source) copy sets will be part of the FlashCopy Backup; this
depends on the parameters of started backup and the conditions from preceding
backups.
26. This number is limited by the maximum number of concurrent FlashCopy relationships a source volume in the various
hardware models can have and by the capacity of the hardware unit(s) used.
27. It is clear that, in order to be protected against any physical loss, the hardware units and also the HA machines should be kept
in different physical locations.
Chapter 8. DP for Snapshot Devices Functionality for AIX LVM Mirrored Environments 163
A target set is identified in the DP for Snapshot Devices target volumes file (.fct)
by
v a target set number x (part of the topic name volumes_set_x), and
v a hardware unit number or SVC cluster ID (value of the
HARDWARE_ID_LVM_MIRROR parameter).
The existence of the HARDWARE_ID_LVM_MIRROR parameter enables DP for
Snapshot Devices to use its special functionality to back up, using FlashCopy, only
one of the two copy sets. Depending on whether
v specific target selection or
v automated target selection
was specified for the backup, an algorithm provided for the respective type of
selection will be used (see Chapter 10, Multiple Backup Generations (Target Sets)
on Disk, on page 219).
In addition to the already established functionality (summarized in Integration
with DB2 Functions on page 13), DP for Snapshot Devices performs the following
tasks on the production system, once control is given from the backup system to
the production system:
v Check whether the conditions of the selected target set allow a new FlashCopy
backup of one of the two copy sets. DP for Snapshot Devices will terminate if, in
a previous FlashCopy operation, the background copy tasks running in the
storage system for the volumes of this copy have not yet terminated.
v Check whether the Requirements for Proper Setup and Customization with AIX
LVM Mirrors on page 170 have been met for the identified (source) copy set..
v Define which of the source volumes can be selected for a FlashCopy request
(only source volumes in the hardware unit specified on the
HARDWARE_ID_LVM_MIRROR parameter are eligible for selection).
v In the DP for Snapshot Devices target volumes file (.fct ), find in the identified
target set a suitable target volume for each previously identified source volume.
v Check the logical volumes (LVs) on the selected source volumes for any stale
physical partitions (PPs) and terminate the backup request immediately if any
are found. The backup cycle status indicator PSI will not be changed; this means
that no special cleanup with DP for Snapshot Devices is required. In order to
run another new FlashCopy backup request, the user must resolve the reason for
the stale PPs and resynchronize the affected LVs.
If no stale PPs are found, perform the FlashCopy for all source/target pairs
established above.
v Again check the LVs on the selected source volumes for any stale PPs. If any are
found, automatically perform an storage-system-oriented withdraw function and
prematurely terminate the backup process. The backup cycle status indicator PSI
is changed to PSI_FLASHCOPY_DONE. On the backup system, the FlashCopy
backup process will terminate immediately with message IDS1016E. In order to
run another FlashCopy backup request, the user must resolve the reason for the
stale PPs and resynchronize the affected LVs.
v Return control to the caller on the backup system and continue there with the
general steps of DP for Snapshot Devices (importvg, fsck, and mount) which
ultimately give control back to the calling program (tdphdwdb2), which then (on
the backup system) calls DP for mySAP to back up the DB files.

These tasks can only be performed when
v a complete copy set
28
exists in the selected hardware unit and
v requirements for proper setup and customization have been satisfied as
described under Requirements for Proper Setup and Customization with AIX
LVM Mirrors on page 170.
FlashBack Restore Process
In addition to the FlashBack Restore functionality as described in FlashBack
Restore on page 16, the DP for Snapshot Devices functionality for AIX LVM
mirrored environments has been extended to
v allow the selection from n
29
FlashCopy type backups (each representing a
FlashCopy backup of one of the two copy sets to one of the n target sets
30
) for
a restore, assuming the FlashCopy agent has signaled that the background copy
has completed the work for the source/target volume pairs in the relevant copy
set.
v offer the administrator the capability to do this selection in one of the menus of
the DP for Snapshot Devices restore command
v perform the DP for Snapshot Devices FlashBack Restore and the DB recovery
with the volumes of the target set of the selected FlashCopy type backup, for
performance reasons; in addition, the DP for Snapshot Devices restore function
will run all the commands required to prepare the AIX LVM environment again
for the second mirror; the administrator will be informed with message
EEP0299I that the VGs are ready for synchronization, which he can run later at a
more suitable time.
DP for Snapshot Devices and Copy Sets in an AIX LVM Mirror
Environment
The following figure shows a typical setup as it could run with the DP for
Snapshot Devices mirroring functionality:

28. The set of source or target volumes involved in a FlashCopy operation.
29. With V1.1.10.2, a maximum of 2 FlashCopy backups (INCR, COPY, or mixed) could be used; as of V5.3.0, a maximum of 2
FlashCopy backups with the FLASHCOPY_TYPE of INCR and/or others with the value COPY can be used.
30. Assuming n target sets with either FLASHCOPY_TYPE of INCR or COPY are available.
This is a high-availability environment with 2 AIX mirrors distributed over 2
hardware units using HACMP and running production on the primary machine.
Note that instead of the 2 machines running with HACMP, a single-machine

Figure 13. DP for Snapshot Devices and Copy Sets in an AIX LVM Mirror Environment for DB2

environment could also be used for the DB server activities connected to an AIX
LVM mirror setup. The takeover machine currently does not perform any DB
related activities; however, in case of an HACMP takeover, there are no special
considerations for this machine compared to the primary system discussion.
The database files that are the object of the FlashCopy backup process reside on
logical volumes (LVs) that are mirrored by the AIX LVM. Because all file systems
are running as JFS, a mirrored jfslog LV for each volume group is required as well.
The sum of all these LVs in one of the mirrors constitutes a complete copy set; a
copy set resides on a set of source volumes, which themselves, when a symmetrical
setup is in place, are completely located within one of the 2 hardware units. The
other copy set is located with its source volumes in the other unit.
Both copy sets can be used alternately in different FlashCopy backup runs when
DP for Snapshot Devices initiates the FlashCopy process.
Although both copy sets are consistently mirrored on the production system by
AIX LVM, only one will be required for the FlashCopy process and the subsequent
DP backup running on the backup system.
31
In order to focus on the DP for Snapshot Devices functionality for AIX mirrored
environments, this chapter will discuss a setup with 2 copy sets, each one having
only one target set as shown in Figure 13 on page 166, even if DP for Snapshot
Devices would permit more target sets to be used.
If you alternately choose one of the two targets sets (specific target set selection),
you can run this either with the target set parameter -n x, specifying either 1 or 2
for the target set number x, or you can specify the COPY parameter -C with
FlashCopy type INCR (automatically alternate the target set selection).
32
The decision as to which of the 2 copy sets will be used by DP for Snapshot
Devices for the FlashCopy backup is based on the value of the target set parameter
(see Target Set Parameter on page 174) specified in conjunction with the
FlashCopy backup. The selected target set, as defined in one of the two topics of
the DP for Snapshot Devices target volumes files (.fct), can be used only for a
FlashCopy backup of one (source) copy set if
v for an ESS or DS configuration, both sets reside in the same hardware unit, and
the HARDWARE_ID_LVM_MIRROR parameter specifies the number of this unit.
v for an SVC configuration, both sets reside in the same SVC cluster and the
HARDWARE_ID_LVM_MIRROR parameter specifies an ID for this cluster.
If the selected hardware unit does not contain a complete copy set of all LVs (in
which the DB files are allocated that are the object of the FlashCopy backup), DP
for Snapshot Devices will terminate; the same will occur if certain attributes have
not been given either to the LVs or the involved volume groups (VG). The
requirements for proper setup and customization are summarized later in this
chapter.
DP for Snapshot Devices, having started the FlashCopy operation on the
production system, will continue on the backup system with importvg/fsck/mount
31. You could also consider using an additional backup system so each site would have its own complete environment in case a
disaster hits one site.
32. In case you run a storage system without the licensed feature for the incremental support (if available), the type COPY is
recommended. While NOCOPY can also be specified, it is not practical or recommended for large databases.
with only those target volumes in the hardware unit specified in the
HARDWARE_ID_LVM_MIRROR parameter within the topic (of the DP for
Snapshot Devices target volumes file) pointed to by the value of the chosen target
set parameter. In the preceding figure, either the target volumes with copy set A in
hardware unit 1 or the other target volumes with copy set B in hardware unit 2
will be selected.
Note: Currently, with the DP for Snapshot Devices LVM mirroring functionality,
only one hardware unit can be specified for the FlashCopy backup request,
which therefore does not allow a copy set that is to undergo a FlashCopy
and then be backed up over as many units as there are AIX LVM mirrors. A
separate unit must be provided for each copy set; each database LV
(including the jfslog LV) will have 2 mirrors, making up a total of 2 copy
sets.
With the DP for Snapshot Devices multiple target set support, however,
more than one target set is supported for each copy set.
Supported AIX LVM Mirrored Environments and DP for Snapshot
Devices
With AIX LVM, the LV mirrors can be set up in various ways; the possible
environments can be divided into
v symmetrical and
v asymmetrical
The symmetrical environment is the most favorable. The consequences of using the
different environments will now be discussed.
Symmetrical Environment
A symmetrical setup of all logical volumes (which are part of the database) is
imperative for the high availability offered by AIX LVM mirroring, such that, if
another subsystem with a mirror is still available, full operation can be maintained
even in the case of the physical loss of a complete subsystem. Such a symmetrical
setup would be the use of 2 hardware units with equal distribution of 2 AIX LVM
mirrors for the DB relevant logical volumes (LVs). It requires that one complete set
of the first mirror of all LVs (also called a complete copy set) be allocated in one
hardware unit and the second mirror of those LVs in the other unit. Two copy sets
are located as an entity, each set in a separate hardware unit. Therefore, only target
volumes for one copy set within one unit need to be specified for one FlashCopy
backup request.
33
Since the symmetrical environment not only provides the highest
availability for the database but also allows DP for Snapshot Devices to work with
the lowest possible number of target volumes in the FlashCopy backup process, it
is the ideal setup for a production environment.
Within this target set, the HARDWARE_ID_LVM_MIRROR parameter matches the
unit name in which the copy set resides. For each source volume of the one copy
set, a target volume must be planned and set up.
33. For the same copy set, however, additional target sets can be set up if multiple targets are desired for different FlashCopy
backups.

Asymmetrical Environment
In contrast to the symmetrical database setup, the asymmetrical setup by its nature
would never cover the outage of either of the 2 hardware units. The following
combinations of such an asymmetrical setup and the impacts/implications on the
high availability requirement as well as on the capabilities of the DP for Snapshot
Devices support for the LVM mirroring capability are summarized in the
following:
1. One unit (determined through either the specific (-n) or automated target set
selection, and the topic and HARDWARE_ID_LVM_MIRROR parameter value
derived therefrom) has a complete copy set and in addition one or more LV
copies of the second copy set.
Impact on high availability target:
v The outage of this unit, with the complete copy set, would cause a
production outage because of the incomplete database within the other unit
Action taken by DP for Snapshot Devices with the LVM mirroring functionality:
v The unit contains a complete copy set of all LVs and one or more LV mirrors
from the other copy set; FlashCopy backup can be done, but more target
volumes than in the symmetrical case are required because the selection will
be done against all source volumes that make up the VG residing in the
selected unit and including the database files to be backed up.
2. The unit (determined through either the specific (-n) or automated target set
selection, and the topic and HARDWARE_ID_LVM_MIRROR parameter value
derived therefrom) has an incomplete copy set, because the other unit (see 1.)
has a complete copy set and parts of the 2nd copy set.
v The loss of this unit (which has fewer than half of all DB LV mirrors) leaves
the production operation working with a complete DB copy set in the other
unit.
v DP for Snapshot Devices cannot perform a FlashCopy backup process for
this unit when it is selected, because the copy set of the source volumes
making up the database in this unit is incomplete.
3. Each unit has an incomplete copy set.
One unit might have 2 AIX copies of an LV, and the other unit might form
another LV with its 2 AIX copies. Neither of the 2 units now would have a
complete copy set of its own.
v The outage of one of the 2 units would result in an outage of the database.
Such a setup is the worst of all possibilities because there is really no
protection against an outage should one of the 2 units be physically lost.
v DP for Snapshot Devices cannot perform a FlashCopy Backup with either
unit when one of the two incomplete copy sets has been selected via the
target set selection algorithm. Running such a setup is certainly the least
desirable alternative and must be resolved without delay by the system
administrator.
Note: Asymmetrical setups must be avoided in order to prevent unforeseen
problems. If such setups occur over time for the sake of
v high availability and
v the planned FlashCopy backup capabilities
an asymmetrical setup should be restored to a symmetrical one.
Requirements for Proper Setup and Customization with AIX LVM
Mirrors
In order to run a sound high availability environment, certain requirements are
imposed on such an environment; others are specifically needed to allow the
FlashCopy of only such source volumes containing one LVM mirror of the logical
volumes when they are the subject of a FlashCopy backup request using the DP for
Snapshot Devices functionality.
The following summarizes the DB setup requirements which must be fulfilled
when using an AIX 2-mirror environment:
1. The topic within the DP for Snapshot Devices target volumes file (determined
through either the specific (-n) or automated target set selection for the
FlashCopy backup) needs the parameter HARDWARE_ID_LVM_MIRROR to
specify the hardware unit in which the FlashCopy is to be performed. In
addition, a complete copy set (all LVs must have at least 1 mirror in this copy
set) is required.
DP for Snapshot Devices action:
If the HARDWARE_ID_LVM_MIRROR parameter has not been set, DP for
Snapshot Devices needs all the target volumes that correspond to the source
volumes (with all LV copies) to be specified in the .fct file, and no special
checks are performed.
2. Each file that is the object of the FlashCopy backup request (see Overall Disk
Layout Considerations on page 34, item 2) must reside on an LV which has
its physical disks (hdisks, or vpaths in case of SDD) in a hardware unit. These
disks are referred to as the source volumes.
Terminates immediately if a file is not found on a volume.
The same applies to the jfslog LV associated with the aforementioned LV.
3. Each of the above DB LVs and its jfslog LV must have 2 mirrors.
Terminates immediately if other values are found.
4. All source volumes which belong to one LV mirror must reside in the same
hardware unit.
Terminates immediately if other conditions are found and this is the unit
specified in 1.
5. All source volumes which belong to the other LV mirror should reside in
another unit (see Supported AIX LVM Mirrored Environments and DP for
Snapshot Devices on page 168).
Terminates immediately if unsuitable conditions are found (see Supported
AIX LVM Mirrored Environments and DP for Snapshot Devices on page 168).
6. Two hardware units are required (this is the maximum supported by DP for
Snapshot Devices in an AIX 2-mirror environment)
For details, see Supported AIX LVM Mirrored Environments and DP for
Snapshot Devices on page 168. DP for Snapshot Devices will terminate if it
cannot find a complete copy set in the selected unit (see 1.) If one of the 2
units is temporarily not available and the other is properly set up, production

and the FlashCopy backup process are not functionally impacted (symmetrical
environment) if the target set is used that resides in the available unit; the
HARDWARE_ID_LVM_MIRROR parameter matches the unit name.
7. All source volumes of one copy set (the entity of one AIX LVM mirror of all
involved LVs) are highly recommended to be in the same unit; accordingly,
the other complete copy set needs to be set up in the other unit); this
addresses the symmetrical environment, which is the one the system
administrator should implement. The consequences of using the asymmetrical
environment are discussed in Asymmetrical Environment on page 169.
For details, see Supported AIX LVM Mirrored Environments and DP for
Snapshot Devices on page 168.
8. A logical volume (LV) must have a complete mirror with the same mirror
number for all of its physical partitions on a set of logical volumes within the
selected hardware unit (see 1 on page 170 and 4 on page 170). The command
lsvg -M <vgname> displays various information concerning mirrored logical
volumes, including the mirror number. The following is a sample lsvg output
for volume group sapfcs1 with 4 LVs (including the jfslog LV) as mirrored
over 2 SDD disks:

$ lsvg -M sapfcs1

sapfcs1
vpath2:1-62
vpath2:63 fslv03:1:2
... ...
... ...
vpath2:125 fsloglv01:1:2
... ...
vpath2:318 fslv05:193:2
vpath2:319 fslv05:194:2
vpath2:320 fslv05:195:2
vpath2:321 fslv05:196:2
vpath2:322-619
vpath28:1-62
... ...
... ...
vpath28:121 fslv03:28:1
vpath28:122 fslv03:29:1
vpath28:123 fslv03:30:1
vpath28:124 fslv03:31:1
vpath28:125 fsloglv01:1:1
... ...
vpath28:318 fslv05:193:1
vpath28:319 fslv05:194:1
vpath28:320 fslv05:195:1
vpath28:321 fslv05:196:1
vpath28:322-619
The -M parameter lists the following fields for each logical volume on the
physical volume (this information is taken from the man page):

PVname:PPnum [LVname: LPnum [:Copynum] [PPstate]]
where:
PVname
Name of the physical volume as specified by the system.
PPnum
Physical partition number. Physical partition numbers can range from
1 to 1016.
LVname
Name of the logical volume to which the physical partitions are
allocated. Logical volume names must be system-wide unique names,
and can range from 1 to 64 characters.
LPnum
Logical partition number. Logical partition numbers can range from 1
to 64,000.
Copynum
Mirror number
PPstate
Only the physical partitions on the physical volume that are not
current are shown as stale.
Within one hardware unit, the mirror numbers of the various LVs might be
different (see Example 7: Symmetrical Configuration with LVs (Different
Mirror Numbers) in the Same ESS on page 189).
Terminates immediately if a complete LV is not found within the specified
hardware unit (see 1.) and the PPs of this LV in this hardware unit do not
have the same copy number (see Copynum value in the output of the lsvg -M
<vgname> command).
9. Target volumes must have been
v set up in the above specified hardware unit and

v defined in the DP for Snapshot Devices .fct file for each source volume in
the selected unit (see 1.).
Terminates immediately if not set up or the .fct file is incomplete.
10. It is highly recommended not to have LVs other than the DB LVs
34
and the
required jfslog LVs in the VGs because, if they have source volumes in the
selected unit, they require target volumes to be specified as well. In addition,
this can result in unforeseen problems such as impacts of the metastructure of
their embedded JFS structure.
Ignores this situation within the FlashCopy backup process as long as enough
target volumes have been defined.
11. The volume group (VG) that hosts the LVs (DB and jfslogs) must have been
set up with the parameters:
MIRROR WRITE CONSISTENCY = YES
QUORUM = NO (turned off)
Terminates immediately if other values are found.
12. Each of the involved LVs (database and logs) must have been set up with
COPIES : 2
SCHED POLICY : PARALLEL or STRIPED
Note: According to mySAP requirements (as stated in mySAP.com
Fundamentals of Database Layout (8/2000)) when using a database setup
with striping, the stripe size should be a multiple of the data block size
(8K) and at least 16K. DP for Snapshot Devices imposes the same
requirement.
Each of the jfslog LVs used by the database logical volumes must have been
set up with
COPIES : 2
SCHED POLICY : PARALLEL
All of its LPs for one copy must be allocated to one OS disk (AIX physical
volume) only.
Terminates immediately if other values are found. The schedule policy
SEQUENTIAL is not supported with DP for Snapshot Devices.
Note: In order to have the 2 LVM mirrors of the LVs allocated on separate
logical volumes and located in different hardware units, suitable source
volumes must be chosen when creating the LVs.
13. The LVs of the involved copy set are not permitted to have stale physical
partitions (PP), either prior to or immediately after the FlashCopy operation.
Terminates immediately if any stale PPs are found.
34. See Overall Disk Layout Considerations on page 34, point 2.
Target Set Parameter
In an AIX LVM mirrored environment, DP for Snapshot Devices can handle 2 copy
sets of source volumes, each one residing in a different hardware unit. The 2 copy
sets of source volumes can be used to alternately run the FlashCopy Backup to
different sets of target volumes.
The 2 copy sets of source volumes make up the total of all AIX LVM mirrored
logical volumes of a mySAP DB2 database (for definitions and set up requirements
see the previous sections of this chapter).
The target volumes which are used for one copy set of source volumes need to be
specified with the DP for Snapshot Devices target volumes file (see below).
The target set parameter (-n x) was introduced to allow the various functions
such as backup/split, unmount, and withdraw to select different target sets.
Note: A similar capability was previously provided using the copy set parameter.
This capability, however, was limited to
v the special environment discussed in this chapter
v one target set for each source copy set
The above limitations have been eliminated:
v multiple target sets can be used, even on a database not using mirrors
v multiple target sets can also be used for each of the 2 source copy sets.
The copy set parameter (used to select a copy set with -n 1 or -n 2) is now
referred to as the target set parameter (used to select a target set with -n x).
On the backup system, DP for Snapshot Devices commands will run
v the FlashCopy backups from one source volume set (a copy set) residing in the
one hardware unit to the set of target volumes residing in this unit or from the
other copy set of source volumes residing in the other unit to their defined
target volumes.
v the unmount to perform the unmount of the file systems, vary off and export
the volume groups, and remove the devices/paths which belong to the target
volumes of the selected copy set
v the withdraw to perform the unmount (as above) if not yet done and in addition
run a hardware-oriented withdraw for the source and target volumes of the
selected copy set
Note: If no target set parameter is specified when using the DP for Snapshot
Devices command with function resync, unmount, or withdraw, the
command will use the most recent target set by default.
If one copy set will be used again for a new FlashCopy Backup, depending on the
FLASHCOPY_TYPE (INCR, COPY, or NOCOPY), the DP for Snapshot Devices
unmount or withdraw (with the appropriate target set parameter) must be done
first. Use the resync function, which automatically runs either the unmount or
withdraw function for you.
If you want to preserve the FlashCopy Backup objects (the target volumes) of a
copy set of source volumes as long as possible for a Flashback Restore, you need to
run the DP for Snapshot Devices unmount function (if not already done by the

additional parameter specified when you run the FlashCopy Backup) to allow the
FlashCopy Backup to be done with the other copy set of source volumes.
At restore time, no target set need be specified. The copy set and target set to be
selected are automatically determined with the backup [x] you selected for a
restore using the tdphdwdb2 menu. A FlashBack Restore from a FlashCopy target
set of a copy set can only be started when the background copy, initiated by
FlashCopy Backup (INCR or COPY) running with this copy set, has completed.
To demonstrate how the DP for Snapshot Devices commands and parameters can
be used, see Samples Using the DP for Snapshot Devices Functionality for AIX
LVM Mirrored Environments on page 179 which provides:
v a sample for the various DP for Snapshot Devices commands using the target set
parameter -n (with the arguments 1 or 2) for alternating FlashCopy Backup
runs and the required unmount and withdraw.
v a sample of a DP for Snapshot Devices profile
v a sample of a DP for Snapshot Devices target volumes file
For a general description of the functions, parameters, and usage of the DP for
Snapshot Devices splitint command, see Chapter 6, Description and Usage of the
DP for Snapshot Devices Commands, on page 105.
DP for Snapshot Devices Parameters Needed for a Later FlashBack
Restore
If you plan to use the target sets for a FlashBack Restore, you have to ensure that
the FLASHCOPY_TYPE is specified as INCR or COPY either
v in the DP for Snapshot Devices profile (.fcs) with the FLASHCOPY_TYPE
parameter, or
v on the tdphdwdb2 command line using the copy parameter -C, which will
override the value defined in the .fcs file.
when running the FlashCopy backup.
A detailed description of all parameters of the DP for Snapshot Devices profile is
shown in Parameters of the DP for Snapshot Devices Profile on page 144.
For details about FlashBack Restore, see Chapter 5, Restore Methods, on page 81;
also see Chapter 10, Multiple Backup Generations (Target Sets) on Disk, on page
219 when using multiple target sets for one copy set.
DP for Snapshot Devices Target Volumes File in a Mirrored
Environment
The structure of this file is similar to that described in DP for Snapshot Devices
Target Volumes File on page 155, with the exception of the
HARDWARE_ID_LVM_MIRROR parameter.
The parameter HARDWARE_ID_LVM_MIRROR is specified for each target set, in
the respective target set topic.
Note: A complete copy set, as well as its target set(s), must reside in the same
hardware unit or SVC cluster.
The HARDWARE_ID_LVM_MIRROR parameter specifies the hardware unit or
SVC cluster in which the one copy set and its target set(s) are set up. The
parameter needs to be the first parameter in each target set topic.
For the AIX LVM mirrored setup assuming both copy sets, each with one target
set, will be used for backup/FlashCopy the two topics look as follows:
>>>volumes_set_1
HARDWARE_ID_LVM_MIRROR XXXXX
TARGET_VOLUME ...
...
...
TARGET_VOLUME ...
<<<volumes_set_1

>>>volumes_set_2
HARDWARE_ID_LVM_MIRROR YYYYY
TARGET_VOLUME ...
...
...
TARGET_VOLUME ...
<<<volumes_set_2
where XXXXX and YYYYY reflect the serial numbers of the 2 hardware units or the
IDs of the SVC clusters. The value (target set number 1 or 2) of the target set
parameter, used with the DP for Snapshot Devices commands, refers to either the
volumes_set_1 or volumes_set_2 topic.
For an example, see Sample DP for Snapshot Devices target volumes file:
/db2/E01/dbs/initE01.fct on page 182.
Parameters for ESS or DS
Each target volume planned for use must be specified by its serial number as
shown in Table 16 on page 177. When DP for Snapshot Devices is executing the
FlashCopy function, it will, for each source volume which was identified as a
candidate for a FlashCopy, look for
In addition, DP for Snapshot Devices will when it finds the
HARDWARE_ID_LVM_MIRROR parameter in the selected target set check for a
proper setup of the AIX LVM mirrors of the LVs used for the database.

Table 16. Parameters of the DP for Snapshot Devices Target Volumes File for AIX LVM Mirrored Environments Using
an ESS or DS
HARDWARE_ID_LVM_MIRROR unit name In an AIX LVM mirror environment, specifies the hardware
unit that contains a complete set of at least one copy of all DB
logical volumes (LVs) that are subject to the backup process.
Only the source volumes of the specified hardware unit will
be used on the production system by DP for Snapshot Devices
for the FlashCopy process.
unit_name must match the unit name that is part of the target
volume serial number specified on the TARGET_VOLUME
parameters that follow the HARDWARE_ID_LVM_MIRROR
parameter.
This parameter can be used only if an appropriate setup of the
logical volumes of the database has been done as defined in
Chapter 8, DP for Snapshot Devices Functionality for AIX
Default: None. Not used if not defined.
TARGET_VOLUME
<target volume serial number>
<source volume serial number>
This parameter specifies the serial number of the target
volume to which the database is to be copied. Each target
volume planned for use for a FlashCopy operation must be
specified by its serial number in the volumes_set_1,
volumes_set_2, etc., topics which will be selected by the DP for
Snapshot Devices backup/flashcopy command depending
on the specified target set parameter value.
In one FlashCopy backup run, only one topic will be the
subject of the DP for Snapshot Devices search and update
depending on the selected target set number (also referred to
as a data container ID) with the value 1, 2, etc.
The source volume serial number and size are optional. If they
are given, they must correctly reflect the current storage
system configuration and have the following format:
TARGET_VOLUME 401FCA90 40EFCA90 Size=2.0_GB
If they are omitted, dashes (hexadecimal 2D) must be entered
in both fields as placeholders, as shown in the following
example: TARGET_VOLUME 401FCA909 - - The dashes will be
replaced by DP for Snapshot Devices with the information
obtained from the hardware configuration. When DP for
Snapshot Devices has identified the target set number and
thus the copy set, it tries to find an appropriate target volume
for each source volume of the copy set.
Note the target volume requirements for a FlashCopy:
v the target volume must be available in the same hardware
unit in which the source volume can be accessed.
Note: Do not change the order of the parameters (target
volume serial number, source volume serial number, size of
source volume).

serial number) and a dash (-) for the other two fields. Once a FlashCopy
has been done, DP for Snapshot Devices will replace the two dashes with
the current values (source volume serial number, source volume size), and
these values will continue to be used in future runs. If the storage-system
configuration is subsequently altered, the source volume serial numbers and
sizes should be reset to dashes to allow the new values to be determined.
Samples of the different setup possibilities for the TARGET_VOLUME parameter
are shown in Sample for Defining a DP for FlashCopy Target Volumes File
(Mirror Setup, ESS or DS Configuration) on page 254.
Another sample of the DP for Snapshot Devices target volumes file for the AIX
LVM mirror environment is shown in Sample DP for Snapshot Devices target
volumes file: /db2/E01/dbs/initE01.fct on page 182.
Parameters for SVC
Each target volume planned for use must be specified by its virtual disk name as
shown in Table 17. When DP for Snapshot Devices is executing the FlashCopy
function, it will, for each source volume which was identified as a candidate for a
FlashCopy, look for
In addition, DP for Snapshot Devices will when it finds the
HARDWARE_ID_LVM_MIRROR parameter in the selected target set check for a
proper setup of the AIX LVM mirrors of the LVs used for the database.
an SVC
HARDWARE_ID_LVM_MIRROR cluster ID In an AIX LVM mirror environment, specifies the ID of the
cluster that contains a complete set of at least one copy of all
DB logical volumes (LVs) that are subject to the backup
process. Only the source volumes of the specified cluster will
be used on the production system by DP for Snapshot Devices
for the FlashCopy process.
This parameter can be used only if an appropriate setup of the
logical volumes of the database has been done as defined in
Chapter 8, DP for Snapshot Devices Functionality for AIX
Default: None. Not used if not defined.

an SVC (continued)
TARGET_VOLUME
<target volume virtual disk name>
<source volume virtual disk name>
This parameter specifies the virtual disk name of at least the
target volume of a volume pair involved in the FlashCopy.
Each target volume planned for use for a FlashCopy operation
must be specified by its virtual disk name in the
volumes_set_1, volumes_set_2, etc., topics, which will be selected
by the DP for Snapshot Devices backup/flashcopy
command depending on the specified target set parameter
value.
In one FlashCopy backup run, only one topic will be the
subject of the DP for Snapshot Devices search and update
depending on the selected target set number (also referred to
as a data container ID) with the value 1, 2, etc.
The source volume virual disk name and size are optional. If
they are given, they must correctly reflect the current storage
system configuration and have the following format:
If they are omitted, dashes (hexadecimal 2D) must be entered
in both fields as placeholders, as shown in the following
example: TARGET_VOLUME svdftgt1 - - The dashes will be
replaced by DP for Snapshot Devices with the information
obtained from the hardware configuration. When DP for
Snapshot Devices has identified the target set number and
thus the copy set, it tries to find an appropriate target volume
for each source volume of the copy set.
Note the target volume requirements for a FlashCopy:
v the target volume must be available in the same SVC
cluster.
Note: Do not change the order of the parameters (target
volume name, source volume name, size of source volume).

ID) and a dash (-) for the other two fields. Once a FlashCopy has been
done, DP for Snapshot Devices will replace the two dashes with the current
values (source volume name, source volume size), and these values will
continue to be used in future runs. If the storage-system configuration is
subsequently altered, the source volume names and sizes should be reset to
dashes to allow the new values to be determined.
Samples of the different setup possibilities for the TARGET_VOLUME parameter
are shown in Sample DP for FlashCopy Target Volumes File (SVC Configuration)
on page 253.
Samples Using the DP for Snapshot Devices Functionality for AIX LVM
Mirrored Environments
Note: The following examples are based on an ESS configuration.
In order to demonstrate the usage of the various backup and restore commands
and how the DP for Snapshot Devices parameter files could be used, the following
sample has been developed.
The sample is based on the following assumptions and requirements:
v A database (SID = E01) has been set up in an AIX LVM mirrored environment.
v 2 copy sets each containing a complete set of all logical volumes (LV) which
make up the database
v The copies of the LVs and the VGs will be set up as defined in the
Requirements for Proper Setup and Customization with AIX LVM Mirrors on
page 170; 2 hardware units (13158 and 12067) will be used for this purpose.
v Each day, a DP for Snapshot Devices backup run is to be started to get one copy
set flashed on an alternating basis (its source volumes on the production system
will be copied to target volumes by employing Copy Services)
v On the first of each two days, the target volumes are to be used for a Tivoli
Storage Manager backup after the target volumes become available on the
backup system ; this means that a FlashCopy and a Tivoli Storage Manager type
backup will be created.
v On the second day, the backup to the Tivoli Storage Manager server need not be
done (disk-only backup desired).
v Whenever a FlashBack Restore becomes necessary, at least one of the 2 copy sets
available on the target volumes will be available for a FlashBack Restore.
Using the DP for Snapshot Devices Commands for Backups
(Sample)
On the backup system as user db2e01 the following 2 scripts will be run
alternately each day to generate a disk-copy backup on target volumes and from
them to Tivoli Storage Manager :
v Script for first day:
cd /db2/E01/dbs
./tdphdwdb2 -f unmount -n 1 -p /db2/E01/dbs/initE01.fcs
./tdphdwdb2 -f backup -n 1 -p /db2/E01/dbs/initE01.fcs
v Script for second day:
cd /db2/E01/dbs
./tdphdwdb2 -f backup -n 2 -p /db2/E01/dbs/initE01.fcs
Explanation:
Running the tdphdwdb2 f unmount for a copy set (specified with copy set
parameter -n argument value 1 or 2) just prior to a FlashCopy Backup is only
used for safety reasons if the unmount call fails for some reason after the backup
call.
In any case there is always a completed FlashCopy copy set available for a
FlashBack Restore, assuming the background copy has completed within 24h.
In case only FlashCopy type backups (and not a Tivoli Storage Manager type
backup) are desired, you would slightly modify the scripts:
v Script for first day:
cd /db2/E01/dbs
./tdphdwdb2 -f flashcopy -n 1 -p /db2/E01/dbs/initE01.fcs

v Script for second day:
cd /db2/E01/dbs
./tdphdwdb2 f flashcopy -n 2 -p /db2/E01/dbs/initE01.fcs
The DP for Snapshot Devices profile (.fcs) points to a DP for Snapshot Devices
target volumes file that is set up with 2 target sets.
Alternative Solution
You can reduce these 2 samples to one script, running it each day as follows:
cd /db2/E01/dbs
./tdphdwdb2 -f unmount -p /db2/E01/dbs/initE01.fcs
#
# this will just perform an unmount if the unmount of the
# previous run was not executed
#
./tdphdwdb2 f flashcopy -C INCR -p /db2/E01/dbs/initE01.fcs
./tdphdwdb2 -f unmount -p /db2/E01/dbs/initE01.fcs
This uses the automated target set selection (see Chapter 10, Multiple Backup
Generations (Target Sets) on Disk, on page 219).
Running the FlashBack Restore/Recovery (Sample)
On the production system as user db2e01 start the command:
cd /db2/E01/dbs
tdphdwdb2 -f restore -p /db2/E01/dbs/initE01.fcs
A menu is presented, which can be used to select the FlashCopy Backup type
when shown to be eligible for a FlashBack Restore.
Assuming the backups were done on a regular basis, there should be always one
available for a FlashBack Restore. You will find details of what kind of information
is presented and requested when stepping through the above Flashback
Restore/Recovery panels in Restore Function on page 110. You might use the
command any time to check which backups (Tivoli Storage Manager or FlashCopy)
are available.
DP for Snapshot Devices Files Used for the Preceding Backup
and Restore/Recovery Commands (Sample)
In order to better understand how the two DP for Snapshot Devices parameter files
with a specification for the 2 copy sets used (each LV copy is in one copy set) have
to be set up, a sample of the DP for Snapshot Devices profile (.fcs) and for the DP
for Snapshot Devices target volumes file (.fct) is shown here. The description of the
various parameters has been removed from the files for clarity. Only the parameter
statements required have been retained.
Sample DP for Snapshot Devices profile : /db2/E01/dbs/
initE01.fcs
>>> global
LOGON_HOST_PROD s1 db2e01
LOGON_HOST_BACK t1
BACKUP_MAX 30
IDS_CONTROL_FILE /db2/E01/dbs/save/idssave
CONFIG_FILE /db2/E01/dbs/initE01.fcp
WORK_DIR /db2/E01/dbs/work
TRACE YES
LOG_TRACE_DIR /db2/E01/dbs/logtraces
TDPR3_CONFIG_FILE /db2/E01/dbs/initE01.utl
SUPPORT_ADMIN_ASSISTANT NO
COPYSERVICES_HARDWARE_TYPE ess800
<<< global
>>> DB2
DB2_REMOTE_DBALIAS R_E01
DB2_RECOVERY_LOG /db2/E01/dbs/tdprlf.E01.NODE0000.log
DB2_TDPR3_LIB /usr/tivoli/tsm/tdp_r3/db264/libtdpdb264.a
DB2_PARALLELISM 1
DB2_NUM_BUFFERS 2
DB2_BUFFER_SIZE 1024
<<< DB2
PRIMARY_COPYSERVICES_SERVERNAME 172.31.1.8
COPYSERVICES_USERNAME ess
VOLUMES_FILE /db2/E01/dbs/initE01.fct
FLASHCOPY_TYPE COPY
<<< copyservices_data#--------------------------------------------------------end of file

Important for FlashBack Restore: When running the above backup scripts, it is
required that the values for the FLASHCOPY_TYPE be set as shown in the DP for
Snapshot Devices profile.
Sample DP for Snapshot Devices target volumes file:
/db2/E01/dbs/initE01.fct
>>> volumes_set_1
HARDWARE_ID_LVM_MIRROR 13158
TARGET_VOLUME 40913158 - -
TARGET_VOLUME 40A13158 - -
TARGET_VOLUME 40B13158 - -
<<< volumes_set_1

>>> volumes_set_2
TARGET_VOLUME 65F12067 - -
<<<volumes_set_2
Note: Consider the setup of the target volumes using the 2 hardware units for the
2 different copy sets. Having once executed the DP for Snapshot Devices

backup/flashcopy DP for Snapshot Devices will replace the on the
TARGET_VOLUME of the chosen copy set with the source volume and the
size found for the target volume. To enable the special DP for Snapshot
Devices functionality for AIX LVM Mirrored Environments, the
HARDWARE_ID_LVM_MIRROR parameter with the hardware unit
employed is required.
AIX LVM Mirror/Copy Examples
The following examples are intended to demonstrate the conditions under which a
FlashCopy backup process using DP for Snapshot Devices will or will not initiate
the actual FlashCopy (FC) operation for a production system setup with an AIX
2-mirror environment in 2 hardware (in this case, ESS) units. The examples show
for each hardware unit and each complete/incomplete copy set, one target set, the
1:1 copy-set-to-target-set relationship that was originally supported.
35
The actual
FlashCopy operation runs only in the hardware unit specified with the
HARDWARE_ID_LVM_MIRROR parameter which was found in the topic of the
target set identified by specific or automated selection (here, 1 or 2 ) when the
FlashCopy backup is requested. After the FlashCopy operation, the backup system
will work only with the target volumes of the unit in which the FlashCopy
operation was done.
Examples 1 to 6 can be thought of as representing the AIX LVM mirrored hdisks
(or vpaths) of one LV setup with 2 mirrors.
36
Both symmetrical and asymmetrical
setups, with and without stale PPs, are shown. The digit 1 or 2 within the hdisk
symbol represents the AIX LVM mirror number, which you obtain when running
the command
lsvg -M <vgname>
Example 7 demonstrates that a complete copy set within one hardware unit can be
composed of LVs that have different AIX LVM mirror numbers. However, the AIX
LVM mirror numbers of all physical partitions of an LV must be the same if the LV
is in the unit that has been selected for the FlashCopy backup process. The
example shows a volume group with 2 LVs.
The hdisks represent the logical volumes (source/target volumes) in a hardware
unit; when working with SDD, you can substitute the term vpath for hdisk in
the samples.
A lightning-bolt symbol through an hdisk indicates at least 1 stale PP has been
found on that physical disk. In the examples shown, the production system still
runs with those damaged hdisks because the other mirror hdisk is still fully
operational. However, the FlashCopy backup process can be impacted, depending
on the condition. Only a complete copy set of all physical volumes, with no stale
PPs within the specified hardware unit(s), can be regarded as eligible for the
FlashCopy backup process.
35. A 1:n relationship between copy sets and target sets is now possible.
36. The number of AIX mirrors supported by the DP for Snapshot Devices functionality for AIX mirrored environments.
Example 1: Ideal Configuration, Symmetrical Setup

1. FlashCopy backup request for ESS 1: the flashcopy function runs correctly.
There is a complete copy set (A) within the selected ESS 1.
There is a complete copy set (B) within the selected ESS 2.
Example 2: Symmetrical Configuration with Stale Physical
Partitions in One ESS Unit

Figure 14. Ideal Configuration, Symmetrical Setup

Figure 15. Symmetrical Configuration with Stale Physical Partitions in One ESS Unit

1. FlashCopy backup request for ESS 1: the flashcopy function will not run and
terminates with error messages. One hdisk has one or more stale PPs.
2. FlashCopy backup request for ESS 2: the flashcopy function runs correctly. The
copy set hdisks within this ESS are all synchronized.
Example 3: Symmetrical Configuration with Stale Physical
Partitions in Both ESS Units

terminates with error messages. There are stale PPs on hdisk13.
terminates with error messages. There are stale PPs on hdisk31 and hdisk35.
The production system will still work because, for all logical partitions (LPs), there
is still at least one non-stale PP. However, the FlashCopy backup cannot be done
because a complete copy (with no stale PP) is not available in either of the
hardware units.

Figure 16. Symmetrical Configuration with Stale Physical Partitions in Both ESS Units
Example 4: Asymmetrical Configuration with Insufficient
Target Volumes

terminates with error messages. There is an incomplete copy set in ESS 1:
hdisk14 is in the other ESS.
terminates with error messages. There is a complete copy set in 2. However,
there are not enough target volumes in ESS 2 because there is none for hdisk14
in ESS 2.

Figure 17. Asymmetrical Configuration with Insufficient Target Volumes

Example 5: Asymmetrical Configuration with Sufficient Target
Volumes

terminates with error messages. There is an incomplete copy set in ESS 1;
2. FlashCopy backup request for ESS 2: the flashcopy function runs correctly. For
each source in ESS 2, there is a target volume; a complete copy set is available
in ESS 2 (hdisk31, hdisk32, hdisk33, hdisk34).
Note: Although the complete copy set comprises only 4 source volumes, the
FlashCopy backup request will require 5 target volumes to be specified
(see Asymmetrical Environment on page 169).

Figure 18. Asymmetrical Configuration with Sufficient Target Volumes
Example 6: Asymmetrical Configuration with Sufficient Target
Volumes But Stale Physical Partitions

terminates with error messages. There is an incomplete copy set in ESS1;
terminates with error messages. The complete copy set in ESS 2 has stale PP(s).

Figure 19. Asymmetrical Configuration with Sufficient Target Volumes But Stale PP(s)

Example 7: Symmetrical Configuration with LVs (Different
Mirror Numbers) in the Same ESS

1. FlashCopy backup request for ESS 1: The flashcopy function runs correctly.
LV1 has all hdisks with mirror number 1 within the same ESS. LV2 has all
hdisks with mirror number 2 within the same ESS. A complete copy set exists
in ESS 1.
LV1 has all hdisks with mirror number 2 within the same ESS. LV2 has all
hdisks with mirror number 1 within the same ESS. A complete copy set exists
in ESS 2.
Note: If the PPs of hdisk71 are allocated on hdisk51 with mirror number 1, and
the PPs of hdisk51 are allocated on hdisk 71 with mirror number 2, logical

Figure 20. Symmetrical Configuration with LVs (Different Mirror Numbers) in the Same ESS
volume 2 is not considered to have a complete LV copy in either hardware
unit, and the DP for Snapshot Devices function would immediately
terminate (see point 8 on page 171)

Chapter 9. Considerations for DB2 UDB ESE with DPF
Support for DB2 UDB ESE with Database Partitioning Feature (DPF) is
implemented in this product. This chapter describes all differences and extensions
which are needed for DP for Snapshot Devices to support multiple DB2 partitions.
DP for Snapshot Devices supports DB2 UDB V8 Enterprise Server Edition (ESE)
and DB2 UDB V9 Enterprise Server Edition (ESE).
EEE: Naming Conventions and DB2 UDB Instance Setup
1. Naming conventions:
v EEE node EEE partition (NODE<NNNN>)
In the DB2 UDB documentation, the term node is used with different
meanings. For example, the command db2 catalog tcpip node has nothing
to do with an EEE node. To avoid confusion about the two meanings of
node, we will only use the term EEE partition instead of EEE node in this
chapter.
v Only one EEE partition per server physical EEE partitions.
If an EEE instance has only one EEE partition on a database server, this
partition is called a physical EEE partition
v More than one EEE partition per server multiple logical EEE partitions.
If an EEE instance has more than one EEE partition on a database server,
these partitions are called logical EEE partitions
v SAP system name is <SID>
v SAP system name in lowercase letters is <sid>
v Database name is <DBName>. In SAP environments: <DBName> = <SID>
In case of an MCOD (multiple components one database) installation of
SAP, you can have multiple different <SID> in one database <DBName>
v DB2 UDB EEE instance name is <DBInst>. In SAP environments: <DBInst>
= db2<sid> The instance directory of a DB2 UDB EEE instance is different
from that of a DB2 UDB EE instance (/db2/<SID>/).
In case of EEE it looks like: /db2/db2<sid>/. The environment variable
$INSTHOME points to this directory.
v The production system <SID> consists of one or more production server(s).
The EEE production instance is spread (partitioned) over one or more
database servers (IBM System p)
v The backup system <SID> consists of one or more backup server(s).
The EEE backup instance is spread (partitioned) over one or more database
servers (IBM System p)
2. The DB2 UDB EEE instance <DBInst> consists of <numNode> EEE partitions.
These EEE partitions are spread over one or more production database
servers.
The instance layout is defined in the DB2 UDB EEE configuration file
db2nodes.cfg on the production system.
The catalog EEE partition must be located on NODE0000.
The coordinating EEE partition must be located on NODE0000.
3. The number of production database servers <numHost> is greater than or
equal to the number of backup servers.

|
|
|
|
|
4. The number of all logical and/or physical EEE partitions on all production
database servers is equal to the number of all EEE partitions on all backup
servers.
5. On the backup system the DB2 UDB EEE instance <DBInst> must have the
same number (<numNode>) of EEE partitions. These EEE partitions are
spread over one or more backup servers. The instance layout is defined in the
DB2 UDB EEE configuration file db2nodes.cfg on the backup system.
6. One backup server can handle multiple production servers (each of the
production servers can have multiple logical EEE partitions or just one
physical EEE partition).
7. In case of multiple logical EEE partitions per production server, all logical EEE
partitions on this production server will be handled from one backup server.
8. The production database <DBName> will be cataloged on all backup servers
as follows:
v A TCP/IP node will be cataloged with the following node name:
Node name = REM<SID>_<HostNumber>
Hostname = <HostName>
Service name = DB2_db2<sid>
v A database alias will be cataloged with the following name:
Database alias = R_<SID>_<HostNumber>
Database name = <SID>
Node name = REM<SID>_<HostNumber>
Directory entry type = Remote
<HostName> and <HostNumber> will be determined from the production
DB2 UDB EEE configuration file db2nodes.cfg. Each <HostName> in this
file will be represented by its unique <HostNumber>. For example, the
db2nodes.cfg looks like
0 s1 0
1 s1 1
2 s1 2
3 s2 0
4 s2 1
5 s2 2
This results in two TCP/IP node catalog entries as follows:
1.
Node name = REM<SID>_0
Hostname = s1
2:
Node name = REM<SID_1
Hostname = s2
The database catalog entries look like:
1.
Database alias = R_<SID>_0
2.
Database alias = R_<SID>_1
9. The backup database <DBName> will be cataloged as a local database on all
backup servers. A database alias will be cataloged with the following name:
Considerations for DB2 UDB ESE with DPF

Database alias = <SID>
Database name = <SID>
Local database directory = /db2/<SID>
Directory entry type = Indirect
10. The catalog entries (8.+9.) on all backup servers will be created by DP for
Snapshot Devices at runtime.
EEE: Customizing and Initializing DP for Snapshot Devices
The file system setup for DP for Snapshot Devices with DB2 UDB EEE is different
from the implementation of DB2 UDB EE. Apart from that, the socket server
configuration is also different from that with DB2 UDB EE.
The following file system setup (1.+2.) on the production database server that
holds the catalog partition (NODE0000) will be created by DP for Snapshot Devices
at setup time (see Installing DP for Snapshot Devices on page 58).
1. On the production server that holds the DB2 UDB EEE catalog partition
(normally NODE0000), the directory
/db2/<SID>/dbs/
must be exported via NFS. This NFS file system must be mounted on all other
production servers and on all backup servers. It contains global DP for
Snapshot Devices configuration files and executables and DP for mySAP
logfiles and tracefiles:
agent.lic license file for DP for mySAP
agentess.lic license file for DP for Snapshot Devices
init<SID>.utl configuration file for DP for mySAP
init<SID>.bki password file for DP for mySAP
init<SID>.fcp password file for DP for Snapshot Devices
splitint DP for Snapshot Devices executable (DB independent)
tdphdwdb2 DP for Snapshot Devices executable (DB specific)
tdplog/ DP for mySAP log and trace directory
2. For each production server a directory is created in the above mentioned NFS
file system
/db2/<SID>/dbs/<HostName>/
It contains DP for Snapshot Devices configuration, control, log and trace files
that must be separate for each production server:
init<SID>.fcs configuration file for DP for Snapshot Devices
init<SID>.fct DP for Snapshot Devices target volumes
file save/ contains the DP for Snapshot Devices control file
(idssave),
the DP for Snapshot Devices exchange files and others
work/ temporary working directory for DP for Snapshot Devices
logtraces/ DP for Snapshot Deviceslog and trace directory
The following DP for Snapshot Devices socket server configuration (3.-7.) will
be done be calling DP for Snapshot Devices with the configure function (see:
Initializing DP for Snapshot Devices on page 64).
3. DP for Snapshot Devices has implemented a TCP/IP client/server socket
communication for synchronization of all the running DP for Snapshot Devices
processes (tdphdwdb2) on all production or backup servers.
4. A socket server must be running on each production server. The TCP/IP port
in the file /etc/services must look like
idscntl<SID> 57330/tcp
Chapter 9. Considerations for DB2 UDB ESE with DPF 193
|
This port must be defined identically in the /etc/services file on all
production and backup servers. All DP for Snapshot Devices processes
(tdphdwdb2) running on the backup server read the DB2 UDB EEE configuration
file db2nodes.cfg via this socket server.
5. For synchronization of all DP for Snapshot Devices processes (tdphdwdb2)
running for different EEE partitions, the socket server on the production server
that holds the catalog partition is used. This socket server is used in case of
FlashCopy Backup or FlashBack Restore as well as for online/offline backup to
TSM or restore from TSM.
6. In addition, one socket server must be running for each logical and/or physical
EEE partition on each production server. The TCP/IP port in the file
/etc/services must look like
idscntl<SID>_<Port> <57330 + Port + 1>/tcp
where <Port> is determined by the third column of the db2nodes.cfg file
which represents the DB2 TCP/IP service port. For example, the file
db2nodes.cfg looks like
0 s1 0
1 s1 1
2 s1 2
3 s2 0
4 s2 1
5 s2 2
This results in the following TCP/IP ports in the /etc/services file:
On production server s1:
On production server s2:
On the backup server t1, which handles both production servers, the TCP/IP
ports in the /etc/services file look like:
These socket servers on the production server are used by DP for Snapshot
Devices to locally connect to each EEE partition on the production database
and to set each EEE partition of the production database in write suspend and
write resume mode. For each production EEE partition, one dedicated socket
server is used. This allows DP for Snapshot Devices to open and hold a local
connection to each EEE partition simultaneously
7. For each of the socket servers an entry in the /etc/inittab must be created. It
looks like
sock<SID>:2:respawn:su - db2<sid> -c cd /db2/<SID>/dbs ;
/db2/<SID>/dbs/tdphdwdb2 f initsocket p /db2/
<SID>/dbs/<HostName>/init<SID>.fcs >/dev/null 2>&1
or
sock<SID>_<Port>:2:respawn:su - db2<sid> -c cd /db2/<SID>/dbs ;
/db2/<SID>/dbs/tdphdwdb2f initsocket s <Port> p /db2/
<SID>/dbs/<HostName>/init<SID>.fcs >/dev/null 2>&1

|
|
|
|
|
|
|
where <Port> is determined by the third column of the db2nodes.cfg file
which represents the DB2 TCP/IP service port.
EEE: Description and Usage of the DP for Snapshot Devices
Commands
As mentioned previously in this chapter, if the production EEE database is spread
over more than one production database server, then
1. In case of a FlashCopy Backup:
For each production server one DP for Snapshot Devices process (tdphdwdb2)
must be started on a backup server. If one backup server handles multiple
production servers, then for each of these production servers, one DP for
Snapshot Devices process (tdphdwdb2) must be started on this backup server.
2. In case of a FlashBack Restore or online/offline backup to TSM or restore from
TSM:
on each production server one DP for Snapshot Devices process (tdphdwdb2)
must be started.
DP for Snapshot Devices profile: A DP for Snapshot Devices profile parameter
was introduced in release 1.2.1 to support DB2 UDB EEE (see Parameters of the
DP for Snapshot Devices Profile on page 144):
DB2_EEE_SYNCTIMEOUT nnnnn
The value of this parameter specifies the time in seconds that DP for Snapshot
Devices waits for synchronization of all DP for Snapshot Devices processes
running for multiple production EEE database servers. Make sure that the specified
value is large enough. For example, if you plan to do backups to TSM, you must
set this value at least as large as the backup time to TSM. If your EEE database
partition has 200GB of data and you back up to 4 tapes in parallel (each tape with
50GB/h), then this backup will take about 1 hour (3600 seconds). You should then
set DB2_EEE_SYNCTIMEOUT at least to 4000 seconds. If this value is too small,
the synchronization of all DP for Snapshot Devices processes will fail and the
backup of the database will fail as well.
DP for Snapshot Devices target volumes file: If your production EEE database
has logical EEE partitions (multiple EEE partitions on one EEE database server),
then you have to make sure that all volumes on which all these logical EEE
partitions are allocated are listed by their corresponding target volumes in the DP
for Snapshot Devices target volumes file in the same volumes_set topic.
EEE: Parallel Backup/Restore of DB2 UDB EEE and ESE
Databases with Multiple EEE Partitions
DP for Snapshot Devices supports parallel backup/restore of DB2 UDB EEE and
ESE databases with multiple EEE partitions. This new functionality was
implemented to improve the performance of TSM backups and restores using DP
for Snapshot Devices and DP for mySAP. It only applies to DB2 UDB ESE V8.x
databases with multiple EEE partitions (>2), and it only improves backup/restore
performance for customers using multiple logical EEE partitions on their backup
and production systems. For customers using only one physical EEE partition per
server, this new functionality brings no performance improvement.
In case of a parallel backup/restore, DP for Snapshot Devices will first back
up/restore EEE partition 0 (default EEE catalog partition). After the backup/restore
of this EEE partition is finished, DP for Snapshot Devices will back up/restore all
other EEE partitions in parallel.
To enable parallel backup/restore, some new DP for Snapshot Devices profile
parameters must be set:
v DB2_EEE_PARALLEL_BACKUP
v DB2_EEE_PARALLEL_RESTORE
Additionally a parameter must be set to allow the parallel backup/restore:
v DB2_VENDOR_ENV
Other parameters were added or enhanced to allow an extended parameterization
of the parallel backup/restore:
v TDPR3_CONFIG_FILE
v DB2_NUM_SESSIONS
v DB2_NUM_BUFFERS
v DB2_BUFFER_SIZE
v DB2_PARALLELISM
See Parameters of the DP for Snapshot Devices Profile on page 144 for the
standard parameterization of the parallel backup/restore with these parameters.
Extended Parameterization of the Parallel Backup/Restore
The standard parameterization of the parallel backup/restore does not allow
specifying different parameters for TSM server, TSM node, TSM management class,
number of TSM sessions, number of DB2 buffers, DB2 buffer size, or DB2
parallelism. For performance reasons, it is preferable to allow such an extended
parameterization so that a backup/restore can use different TSM server or TSM
management classes in parallel.
DP for mySAP Configuration: The simplified configuration of DP for mySAP
uses one vendor.env file, which refers to one DP for mySAP profile (init<SID>.utl).
Within the DP for mySAP profile, the CONFIG_FILE parameter is used with the
%DB2NODE phrase, which will be replaced by DP for mySAP with
NODE<NNNN>, where <NNNN> is the EEE partition number.

This configuration allows using only one TSM server, TSM node, and TSM
management class for all EEE partitions.
For a more flexible handling of TSM server, TSM node, and management class for
each EEE partition, the configuration of DP for mySAP must be enhanced. For each
EEE partition, one DP for mySAP profile (init<SID>.utl) must be created and
maintained. Each profile can have different settings for TSM node and
management class. In addition, for each EEE partition, a DP for mySAP vendor
environment file (vendor.env) must be created and maintained. Each vendor file
has an entry XINT_PROFILE, which refers to the corresponding DP for mySAP
profile.
The TDPR3_CONFIG_FILE parameter must be changed; it should no longer
contain the %DB2NODE phrase but rather a direct reference to the corresponding
configuration file (init<SID>.bki).
For example, a DB2 UDB V8.1 ESE database A01 has 4 EEE partitions on 2
production hosts (host1, host2). The following setup should then be used:
On production host1:


On production host2:

If some EEE partitions will use the same TSM configuration, the setup and
administration can be simplified by using a master DP for mySAP profile (such as
/db2/A01/dbs/initA01.utl.1) and creating symbolic links for all EEE partitions
using the same TSM configuration:
ln -s /db2/A01/dbs/initA01.utl.1 /db2/A01/dbs/initA01.utl.2
The vendor.env files must be created for all EEE partitions in any case, however.
DP for Snapshot Devices Configuration: For the standard configuration, the
parameters
TDPR3_CONFIG_FILE /db2/A01/dbs/initA01.utl
DB2_VENDOR_ENV /db2/A01/dbs/vendor.env
must be set in the DP for Snapshot Devices profile (initA01.fcs).
With this configuration, only one DP for mySAP profile (initA01.utl) will be used
and only one TSM server, TSM node, and TSM management class can be used for
all EEE partitions.
For the extended configuration, the parameters
TDPR3_CONFIG_FILE /db2/A01/dbs/initA01.utl.##
DB2_VENDOR_ENV /db2/A01/dbs/vendor.env.##
must be extended with a suffix ## in the DP for Snapshot Devices profile
(initA01.fcs). This suffix will later be replaced by DP for Snapshot Devices with the
EEE partition number. With this configuration, it is now possible to select a
different TSM server, TSM node and TSM management classes for each EEE
partition.
For a more flexible handling of the number of TSM sessions, number of DB2
buffers, DB2 buffer size, and DB2 parallelism, the parameters
v DB2_NUM_SESSIONS
v DB2_NUM_BUFFERS
v DB2_BUFFER_SIZE
v DB2_PARALLELISM
were extended. It is now possible to specify dedicated values for each EEE
partition. For example, if you want to use different numbers of sessions for the 4
EEE partitions of the above example, you have to specify the following in the DP
for Snapshot Devices profile:
DB2_NUM_SESSIONS 2:4:4:4
This will use 2 TSM sessions for EEE partition 0 and 4 TSM sessions for EEE
partitions 1, 2 and 3. If too few values separated by a : (colon) are specified, the
missing values will default to the value for EEE partition 0. The same extended
syntax can be used for all 4 parameters listed above.
A sample configuration for the EEE database A01 is shown below:
>>> global
...
TDPR3_CONFIG_FILE /db2/A01/dbs/initA01.utl.##
<<< global

>>> DB2
...
DB2_NUM_SESSIONS 2:4:4:4
DB2_NUM_BUFFERS 4:8:8:8
DB2_BUFFER_SIZE 1024:1024:1024:1024
DB2_PARALLELISM 32:16:16:16
DB2_VENDOR_ENV /db2/A01/dbs/vendor.env.##
DB2_EEE_PARALLEL_BACKUP YES
DB2_EEE_PARALLEL_RESTORE YES
<<< DB2
...
The extended parameterization requires that the parameter DB2_VENDOR_ENV be
set.

EEE: Configure Function
The configure function of DP for Snapshot Devices will create all needed entries
for the TCP/IP client/server socket communication in the files /etc/services and
/etc/inittab on the production system. In case of DB2 UDB EEE, the configure
function must be started on the coordinating production server (NODE0000) and it
will automatically create all entries in the above mentioned files on all production
servers (if the production EEE database is spread over multiple servers). In
addition, the configure function will store the passwords required for the database
user and storage-system user in the DP for Snapshot Devices password file (see
Password Function on page 129).
Usage
This function must be performed
v during installation and customization of the DP for Snapshot Devices product
v whenever the passwords of the db2<sid> user and/or storage-system user ID
are changed
v whenever the EEE configuration has changed (e.g. after adding an EEE partition
to the DB2 instance or moving an EEE logical partition from one production
server to a new production server), see section EEE: Modifying the DB2 UDB
EEE Instance on page 214.
When calling this function, the user will be asked for the TCP/IP port on which
the socket server will listen. After entering a correct TCP/IP port, the user will be
prompted to enter the appropriate passwords.
Syntax
-p /db2/<SID>/dbs/<HostName>/init<SID>.fcs
where
/db2/<SID>/dbs/<HostName>/init<SID>.fcs
is the DP for Snapshot Devices profile of the production server that holds the
catalog partition, named <HostName> (see EEE: Naming Conventions and DB2
UDB Instance Setup on page 191).
Number of processes running: only one process on the production EEE database
server that holds the catalog partition
EEE: Backup Function
The backup function can be used to back up the production database. DP for
FlashCopy supports two types of backups
v FlashCopy Backup (must be started on the backup system)
v online/offline backup (must be started on the production system)
When performing a FlashCopy Backup with FlashCopy type COPY, you will get
a backup on TSM and a point-in-time disk copy of your production database.
Make sure that the background copy process is finished before starting a withdraw.
You can use this point in time disk copy for a later FlashBack Restore. See
Chapter 5, Restore Methods, on page 81 and Restore Function on page 110 for
further information. For more information on the backup function see Backup
Function on page 107.
In EEE environments, this function only allows backups of the entire database. It is
not supported to back up just a single EEE partition or just all logical EEE
partitions on one production server.
In case of a FlashCopy Backup, the SAP database administrator must start multiple
DP for Snapshot Devices processes on the backup system at a time. The number of
processes to be started is the same as the number of production EEE database
servers.
The following figure shows a typical EEE setup:

From the above figure, you can see that the production system (production EEE
database) consists of 6 EEE partitions which are spread over 2 production servers
(s1 and s2). Each production server holds 3 logical EEE partitions. The catalog
partition (NODE0000) is located on production server s1. The coordinating
partition (NODE0000) is located on production server s1. The backup system
consist of 6 EEE partitions as well, but all of these EEE partitions are located on
one backup server (t1). The SAP system ID (<SID>) is P01.
In this example, to start a FlashCopy Backup with subsequent unmount but
without withdrawing the source/target relationships, you have to start two
processes on the backup server (t1) at a time:

Figure 21. Typical EEE Setup

/db2/P01/dbs/tdphdwdb2 -f backup -t flashcopy unmount nowithdraw -p
/db2/P01/dbs/s1/initP01.fcs
/db2/P01/dbs/tdphdwdb2 -f backup -t flashcopy unmount nowithdraw -p
where
are the DP for Snapshot Devices profiles for the production servers s1 and s2.
You can execute both processes in parallel in two ways:
1. Open two sessions (telnet, xterm, ...) and issue one command in each of the
sessions.
2. Use a script provided by DP for Snapshot Devices, which starts both processes
in the background. See Sample tdphdwdb2 EEE FlashCopy Script on page 272.
You have to adapt the script (<SID>, <HostName>, etc.) to your configuration
before you can use it.
To start an offline backup in the sample environment, you have to start two
processes on the production system at a time. One process on production server
(s1):
/db2/P01/dbs/tdphdwdb2 -f backup -t offline -p /db2/P01/dbs/s1/initP01.fcs
and one process on production server (s2):
/db2/P01/dbs/tdphdwdb2 -f backup -t offline -p /db2/P01/dbs/s2/initP01.fcs
where
are the DP for Snapshot Devices profiles for the production server s1 and s2.
1. Open two sessions (telnet, xterm, ...) and issue one command in each of the
sessions
in background. See Sample tdphdwdb2 EEE Online/Offline Backup Script on
page 273. You have to adjust the script (<SID>, <HostName>, etc.) to your
configuration before you can use it
Usage
The backup function was developed for the SAP database administrator to perform
a backup of a FlashCopy on the backup system. When tdphdwdb2 is started with
the backup option, the program will perform all the steps that need to be done
With the type options online/offline, the SAP database administrator can perform
backups on the production system and with the flashcopy type option on the
backup system. The SAP database administrator can perform most types of backup
with a single command.
Syntax
On the backup system:
/db2/<SID>/dbs/tdphdwdb2 -f backup [-t flashcopy [no/unmount] [no/withdraw]]
where
is the DP for Snapshot Devices profile of one production server named
<HostName> (see EEE: Naming Conventions and DB2 UDB Instance Setup on
page 191).
On the production system:
/db2/<SID>/dbs/tdphdwdb2 -f backup -t online/offline
where
page 191).
System to be performed on: Production system or Backup system
Number of processes running: one process for each production EEE database
server
EEE: FlashCopy Function
The flashcopy function can be used to perform a FlashCopy of the production
database.
When performing a FlashCopy with FlashCopy type COPY, you will get a point
in time disk copy of your production database. Make sure, that the copy process in
the background is finished before starting a withdraw. You can use this point in
time disk copy for a later FlashBack Restore. See Chapter 5, Restore Methods, on
page 81 and Restore Function on page 110 for further information. For more
information on the flashcopy function see FlashCopy Function on page 117.
In EEE environments, this function only allows to FlashCopy the entire database. It
is not supported to FlashCopy just a single EEE partition or just the logical EEE
partitions on one production server.
The SAP database administrator must start multiple DP for Snapshot Devices
processes on the backup system at a time. The number of processes to be started is
the same as the number of production EEE database servers.
In the example shown in EEE: Backup Function on page 201 to start a FlashCopy
you have to start two processes on the backup server (t1) at a time:
/db2/P01/dbs/tdphdwdb2 -f flashcopy -p /db2/P01/dbs/s1/initP01.fcs
where

1. Open two sessions (telnet, xterm, etc.) and issue one command in each of the
sessions.
in background. See Sample tdphdwdb2 EEE FlashCopy Script on page 272.
You have to adapt the script (<SID>, <HostName>, etc.) to your configuration
and adjust the f and t parameters in the script before you can use it.
Usage
The flashcopy function was developed for the SAP database administrator to
perform a FlashCopy on the backup system. When tdphdwdb2 is started with the
flashcopy option, the program will perform all the steps that need to be done
This function is identical to the function backup with option -t flashcopy up to
the step in which the backup function starts the backup, unmount, and withdraw.
Use the flashcopy function to perform a FlashCopy of the production database on
the backup system. After successful termination of the FlashCopy, and if you use
FlashCopy type COPY, you can use the point-in-time disk copy of the production
system, for example, to create a DB2 backup on disk or build up a snapshot or
clone of the production database for testing, or you can use other vendor libraries
to back up the copy.
You can also use the flashcopy function to create a disk backup for a later
FlashBack Restore using DP for Snapshot Devices, if you use FlashCopy type
COPY.
Syntax
/db2/<SID>/dbs/tdphdwdb2 -f flashcopy
where
page 191).
server
EEE: Restore Function
The restore function can be used to restore and recover the production database.
DP for Snapshot Devices supports two types of restore:
v Restore from TSM
v FlashBack Restore from a previous FlashCopy Backup
In EEE environments, this function only allows restores of the entire database. It is
not supported to restore just a single EEE partition or just all logical EEE partitions
on one production server.
tdphdwdb2 guides you through the restore and recovery process with a menu
driven user interface.
In the example shown in EEE: Backup Function on page 201 to start a restore
you have to start two processes on the production system at a time. One process
on production server (s1):
/db2/P01/dbs/tdphdwdb2 -f restore -p /db2/P01/dbs/s1/initP01.fcs
and one process on production server (s2):
/db2/P01/dbs/tdphdwdb2 -f restore -p /db2/P01/dbs/s2/initP01.fcs
where
You have to execute both processes in parallel by:
v opening two sessions (telnet, xterm, ...) and
v issuing one command in each of the sessions
The restore function is an interactive process, and DP for Snapshot Devices does
not provide a script for doing an automated EEE restore.
The following steps will be done in the sample environment:
v (s1 + s2): After starting the processes on both production servers, both processes
will present a menu from which the SAP database administrator can select the
backup to be restored:
--------------------------------------------------------------------------------
IBM Tivoli Storage Manager for Advanced Copy Services
Data Protection for Snapshot Devices for mySAP (R) (R) on DB2
--------------------------------------------------------------------------------

B a c k u p H i s t o r y f o r E S E D a t a b a s e
SystemID: A01

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
[1] - 21.09.2006 17:55:23 DB online ok running 32.5 ...
[2] - 21.09.2006 17:12:36 DB online ok invalid ...
[3] - 21.09.2006 17:09:58 DB online ok ok ...
[4] - 21.09.2006 17:06:06 DB offline ... invalid ...
[5] - 21.09.2006 16:56:41 DB offline - invalid ...

[d] - show details

Enter your selection: d


|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The menu option d will provide the following detailed view:
--------------------------------------------------------------------------------
IBM Tivoli Storage Manager for Advanced Copy Services
Data Protection for Snapshot Devices for mySAP (R) (R) on DB2
--------------------------------------------------------------------------------

B a c k u p H i s t o r y f o r E S E D a t a b a s e
SystemID: A01

--------------------------------------------------------------------------------
BSN HdwID FCType TargetID FlashBack RTime(min)
DB Node Backup timestamp (ID) 1st active Log
--------------------------------------------------------------------------------
[1] - 21.09.2006 17:55:23 DB online ok running 32.5 ...
00163 23376 COPY 1
Suspend Time: 21.09.2006 17:50:03
DB Node 0000: 21.09.2006 17:55:23 ok S0000177.LOG
DB Node 0001: 21.09.2006 17:55:59 ok S0000133.LOG
DB Node 0002: 21.09.2006 17:55:59 ok S0000104.LOG
DB Node 0003: 21.09.2006 17:56:00 ok S0000104.LOG
[2] - 21.09.2006 17:12:36 DB online ok invalid ...
00162 23376 COPY 3
Suspend Time: 21.09.2006 17:10:12
DB Node 0000: 21.09.2006 17:12:36 ok S0000176.LOG
DB Node 0001: 21.09.2006 17:13:11 ok S0000132.LOG
DB Node 0002: 21.09.2006 17:13:11 ok S0000103.LOG
DB Node 0003: 21.09.2006 17:13:12 ok S0000103.LOG
[3] - 21.09.2006 17:09:58 DB online ok ok ...
00161 22031 INCR 2
Suspend Time: 21.09.2006 17:07:45
DB Node 0000: 21.09.2006 17:09:58 ok S0000175.LOG
DB Node 0001: 21.09.2006 17:10:48 ok S0000131.LOG
DB Node 0002: 21.09.2006 17:10:49 ok S0000102.LOG
DB Node 0003: 21.09.2006 17:10:49 ok S0000102.LOG
[4] - 21.09.2006 17:06:06 DB offline ... invalid ...
00160 22376 NOCOPY 4
Suspend Time: 21.09.2006 17:00:23
DB Node 0000: 21.09.2006 17:06:06 ok S0000174.LOG
DB Node 0001: 21.09.2006 17:06:48 ok S0000130.LOG
DB Node 0002: 21.09.2006 17:06:49 - S0000101.LOG
DB Node 0003: 21.09.2006 17:06:48 ok S0000101.LOG
[5] - 21.09.2006 16:56:41 DB offline - invalid ...
DB Node 0000: 21.09.2006 16:56:41 - S0000173.LOG
DB Node 0001: 21.09.2006 16:57:20 - S0000129.LOG
DB Node 0002: 21.09.2006 16:57:21 - S0000100.LOG
DB Node 0003: 21.09.2006 16:57:21 - S0000100.LOG

[d] - hide details


The backup history information is identical to that of DP for Snapshot Devices
with DB2 UDB EE except for the columns TSM and 1st active log. For EE, the
column TSM shows only the values ok or -, which indicates whether a TSM
backup is available or not. The value ok* says that the TSM inquiry for
backups is not possible (the version of DP for mySAP is too old). For EEE, the
column TSM has one additional possible value, .... This value (see backup [4]
in the sample) indicates that this backup is valid only on some of the EEE
partitions. The detailed view shows on which node(s) the backup does not exist
in TSM.
For EE, the column 1st active log shows the first active log file at the time the
backup was taken. In the case of EEE, it is only shown as ..., which means that
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the information concerning the first active log file for all EEE partitions is shown
in the detailed view. For more information on how to read the backup history,
see Restore Function on page 110.
This backup history menu is shown in every DP for Snapshot Devices process
that is running on behalf of a restore of an EEE database. You have to select a
backup on each of the processes.
v (s1 + s2): If a backup is selected for which both FlashBack Restore and restore
from TSM are valid options, the following screen is presented and one of the
two possibilities must be selected. In the example above, backup no. 1. was
selected.
--------------------------------------------------------------------------------
[f] - FlashBack from FlashCopy run
[r] - Restore from TSM

v (s1 only): The next screen is only presented on the DP for Snapshot Devices
process running on the production EEE database server that holds the catalog
partition, if a FlashBack Restore is selected. In this case, the SAP database
administrator will be asked if the log files should be saved to a logsafe directory.
--------------------------------------------------------------------------------

R e c o v e r y o f E E E D a t a b a s e

--------------------------------------------------------------------------------

Do you want to save all active logfiles to logsafe directory?
!! This step may take several minutes and needs double space in the Log path !!

[s] - save to logsafe directory (this may take several minutes)

[n] - do not save logfiles



For more information about this step see Restore Function on page 110.
v (s1 only): In the next screen after selecting the backup to be restored and the
type of restore to be performed, tdphdwdb2 will show the information about the
first active log files for all logical EEE partitions, and tdphdwdb2 will then ask
for the point in time to rollforward to. This screen is only shown on the DP for
Snapshot Devices process running on the production EEE database server that
holds the catalog partition. All other processes running on other production EEE
database servers will use the same rollforward point in time. If the parameter
norollforward was specified, this screen and the rollforward of the database
will be skipped.

--------------------------------------------------------------------------------

R o l l f o r w a r d E E E D a t a b a s e

--------------------------------------------------------------------------------
EEE Node 1st active Log DB2 Log path
--------------------------------------------------------------------------------
0000 S0000084.LOG /db2/P01/log_dir/NODE0000/
--------------------------------------------------------------------------------

Enter the time to rollforward to:

[timestamp] - any timestamp with format YYYY-MM-DD-HH.MM.SS between
2002-12-05-18.26.40 and
2002-12-09-16.30.34 (Caution!! Use local time)

[e] - to end of logs


You can either choose to rollforward to end-of-logs or specify the point in time
to which the rollforward process should be performed. The rollforward point in
time must be entered in local time. DP for Snapshot Devices will convert this
time into coordinated universal time (UTC), because DB2 internally uses this
time format and needs the time given in UTC for the db2 rollforward
command.
v (s1 only): After selecting the rollforward point in time, tdphdwdb2 will ask for
confirmation of the input:

--------------------------------------------------------------------------------

05.12.2002 18:26:11 (local time)

(s2 only): On all production EEE database servers other than the catalog
partition EEE database server, only the information about the first active logfiles
for all logical EEE partitions will be shown.
--------------------------------------------------------------------------------

R o l l f o r w a r d E E E D a t a b a s e

--------------------------------------------------------------------------------
EEE Node 1st active Log DB2 Log path
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

05.12.2002 18:26:11 (local time)


v (s1 + s2): After you confirm on all processes running on the production EEE
database servers, tdphdwdb2 will stop the database and, if specified above, save
all log files that are currently located in /db2/<SID>/log_dir/NODE<NNNN> in the
directory /db2/<SID>/log_dir/NODE<NNNN>/logsafe. Make sure there is enough
space in the corresponding file system. If /db2/<SID>/log_dir/NODE<NNNN>/
logsafe is in the same file system as /db2/<SID>/log_dir/NODE<NNNN>, double the
space for this file system. If not enough space is provided, tdphdwdb2 will exit
with an error message. This step is important because the db2 restore command
will delete log files from /db2/<SID>/log_dir/NODE<NNNN>. To avoid this, you
must save all log files and use the option overflow log path with the db2
rollforward command. You must make sure that no old log files are located in
the logsafe directory. They can cause the rollforward command to fail under
certain circumstances. Refer to the DB2 Administration Guide for more
information.
v (s1 + s2): tdphdwdb2 then calls
in case of restore from TSM, the db2 restore command with all necessary
parameters, and DB2 calls DP for mySAP for the restore process
in case of a FlashBack Restore,splitint with all necessary parameters
After successfully performing the restore from TSM or the FlashCopy Restore,
and if you specified the parameter rollforward (which is the default),
tdphdwdb2 will ask if all log files required for the rollforward recovery of the
database were restored from TSM. tdphdwdb2 will wait until this is confirmed by
the SAP database administrator on all processes running on all production EEE
database servers.

In this example, on the production server (s1):
--------------------------------------------------------------------------------

S t a r t i n g t h e E E E R e c o v e r y


--------------------------------------------------------------------------------
EEE Node 1st active Log DB2 overflow Log path
--------------------------------------------------------------------------------
0000 S0000084.LOG /db2/P01/log_dir/NODE0000/logsafe/
--------------------------------------------------------------------------------

up to end of logs



and in this example on the production server (s2):
--------------------------------------------------------------------------------

S t a r t i n g t h e E E E R e c o v e r y


--------------------------------------------------------------------------------
EEE Node 1st active Log DB2 overflow Log path
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

up to end of logs



v (s1 + s2): If the current DP for Snapshot Devices restore is a FlashBack Restore
and if the SAP DB2 userexit is configured for indirect archiving with the SAP
DB2 administration database ADM<SID>, the SAP database administrator must
perform the following steps prior to pressing [ENTER]:
Make sure the latest patch level of the SAP DB2 administration tools is
installed
Log in on the production system as user db2<sid>
Drop the SAP DB2 administration database ADM<SID> with the command
db2 drop db ADM<SID>
Restore the latest SAR file of the ADM<SID> DB from TSM, or use the SAR
file archived in the directory /tmp/adminDB_<SID>/ during the last brarchive
run.
Refer to the SAP DB2 administration documentation. The SAP DB2
administration configuration file /usr/sap/<SID>/SYS/global/init<SID>.db6
contains a variable DB2DB6_TEMP_DIR which points by default to /tmp. In
HACMP environments, it could be necessary to change this variable to a
shared filesystem, such as /db2/<SID>/log_archive/. Make sure that user
<sid>adm has write permission on this directory.
Switch to user root without changing the user environment, using the
command
su root (without leading hyphen -)
Recreate the SAP DB2 administration database ADM<SID> without applying
an existing SAR file using the command
sddb6ins r
or applying an existing SAR file using the command
sddb6ins -r <complete path to SAR file>/adminDB.<TS>.SAR
These steps are required because the SAP DB2 administration database
ADM<SID> is located in the same local database directory as the SAP DB2
database <SID> and, for that reason, it will be flashed as well. In case of a
FlashBack, is will also be flashed back but with an outdated or invalid state.
v (s1 only): tdphdwdb2 then calls the db2 rollforward command. The rollforward
process will run either to end-of-logs or to the point in time you specified.
While the rollforward process is running, the DB2 user exit db2uext2 will
retrieve any log file that is not in the log directory or, in case of selection to copy
log files, in the logsafe directory (overflow log path)
If the userexit is configured for archiving with the SAP DB2 administration
tools:
from the DB2 archive path or the DB2 retrieve path (specified by the
environment variables DB2DB6_ARCHIVE_PATH, DB2DB6_RETRIEVE_PATH
set in the configuration file for the SAP DB2 administration tools
init<SID>.db6). The administrator must restore all logfiles needed for the
rollforward with the brrestore command or with the DP for mySAP tool
backom before DP for Snapshot Devices starts the DB2 rollforward
command. For information on the brrestore command and the configuration
of the SAP DB2 administration tools, see Database Administration Guide: SAP
on IBM DB2 Universal Database for UNIX and Windows. For information about
the DP for mySAP tool backom, see the DP for mySAP Installation and Users
Guide for DB2 UDB.
If the userexit is configured for direct archiving into TSM:
directly from the TSM server. In this case, the administrator does not need to
restore any log files manually via the brrestore command or with the DP for
mySAP tool backom.
v (s1 only): Once the rollforward recovery of the database has reached the point in
time, the following rollforward status screen is shown. In case of errors during
the rollforward recovery (such as userexit returns error code 36), the rollforward
status screen is also shown to help the administrator decide on the succeeding
steps.

Rollforward Status

Input database alias = P01

Node number Rollforward Next log Log files processed Last committed transaction
status to be read
----------- -------------------------- ------------------- ------------------------- --------------------------
0 DB working S0000084.LOG-S0000085.LOG 2002-12-09-15.43.28.000000

hdwIntRC: 0

Use the command

db2 rollforward database E01 stop

to stop the rollforward recovery.

--------------------------------------------------------------------------------

Recovery of database P01 finished successfully

(s1 only): Once the database is successfully rolled forward to the desired point in
time, the SAP DB2 administrator must stop the rollforward recovery by using
the command
db2 rollforward db <SID> stop
After successfully stopping the rollforward recovery as shown in the following:
Rollforward Status

Input database alias = P01

Node number Rollforward Next log Log files processed Last committed transaction
status to be read
----------- -------------------------- ------------------- ------------------------- --------------------------
0 not pending S0000084.LOG-S0000085.LOG 2002-12-09-15.43.28.000000

hdwIntRC: 0

--------------------------------------------------------------------------------

Recovery of database P01 finished successfully

you can start the SAP system for production use.
For more information about the restore/recovery of a DB2 database, see DB2
Data Recovery and High Availability Guide and Reference and DB2 Command
Reference.
Usage
The restore function was developed for the SAP database administrator to perform
a restore from TSM or a FlashBack Restore and a recovery of the production
system. When tdphdwdb2 is started with the restore option, the program performs
all the steps that need to be done within the restore or FlashCopy Restore and
rollforward processes. With the norollforward and rollforward options, the SAP
database administrator can decide whether he wants tdphdwdb2 to perform the
rollforward process as well.
Syntax
/db2/<SID>/dbs/tdphdwdb2 -f restore [database]
[no/rollforward] -p /db2/<SID>/dbs/<HostName>/init<SID>.fcs
where
page 191).
Number of processes running: one process on each production EEE database
server
EEE: Other Functions
All other functions of DP for Snapshot Devices such as unmount, withdraw, and
inquire do not require a special approach. You have to make sure that one DP for
Snapshot Devices (tdphdwdb2) process is started for each production database
server. These processes do not need any synchronization via the socket server.
Syntax
/db2/<SID>/dbs/tdphdwdb2 -f unmount|withdraw
where
is the DP for Snapshot Devices profile of the production server named
page 191).
server (without synchronization)
/db2/<SID>/dbs/tdphdwdb2 -f inquire
where
is the DP for Snapshot Devices profile of the production server named
page 191).
System to be performed on: Production or Backup system
Number of processes running: only one process at a time
EEE: Modifying the DB2 UDB EEE Instance
If modifications to the production DB2 UDB EEE instance are planned, such as
adding or dropping a EEE partition or moving a logical EEE partition to a new
production EEE database server, these changes on the production system will need
corresponding adaptations on the backup system and in the DP for FlashCopy
configuration as well. The following sections will look at the most common EEE
instance modifications:
v Add a new logical EEE partition to the production DB2 UDB EEE instance:
Adding a new logical EEE partition to the production DB2 UDB EEE instance
will change the DB2 UDB EEE configuration file db2nodes.cfg. A new entry
will be created in this file. After adding a new EEE partition, the DB2 UDB

administrator has to add additional file systems on the production server on
which the new EEE partition was created. These file systems are:
/db2/<SID>/log_dir/NODE<NNNN>
/db2/<SID>/sapdata<X>/NODE<NNNN> *)
/db2/<SID>/db2<SID>/NODE<NNNN> *)
where <NNNN> is the number of the newly added EEE partition. The file
systems denoted by *) must be allocated on source volumes with the
corresponding target volumes on the same hardware unit (or SVC cluster) used
for the other logical EEE partitions on this production EEE database server.
Additionally, the administrator must change the nodegroup definition on the
production EEE database and redistribute the data in the nodegroup.
Further adaptations on the production system:
- Run the following command to update the TCP/IP socket server configuration
on the production system:
where
catalog partition
Adaptations on the backup system:
Add a logical EEE partition on the backup server that handles the production
EEE server with the new logical EEE partition
Add the new source and target volumes to the DP for Snapshot Devices
target volumes file
On the backup system, add a new entry in the file /etc/services,
corresponding to the new entry created by the configure function call on the
production system
v Add a physical EEE partition to the production DB2 UDB EEE instance:
Adding a new physical EEE partition to the production DB2 UDB EEE instance
will change the DB2 UDB EEE configuration file db2nodes.cfg. A new entry
will be created in this file. After adding a new EEE partition, the DB2 UDB
administrator has to add file systems on the production server on which the
new EEE partition was created. These file systems are:
/db2/<SID>/sapdata<X>/NODE<NNNN> *)
/db2/<SID>/db2<SID>/NODE<NNNN> *)
where <NNNN> is the number of the newly added EEE partition. The file
systems denoted by *) must be allocated on source volumes with the
corresponding target volumes. A new physical EEE partition has to be created
on a new production server and the volumes can also be allocated on a new
hardware unit or SVC cluster.
Additionally, the administrator has to change the nodegroup definition on the
Make sure that the db2<SID> user and the db<SID>adm group are created on
the new production server
Make sure that the DB2 UDB EEE NFS exports are exported to and mounted
on the new production server
NFS-export the file system /db2/<SID>/dbs to the new production server
NFS-mount the file system /db2/<SID>/dbs on the new production server
Create a new directory
/db2/<SID>/dbs/<HostName>
in the NFS file system /db2/<SID>/dbs, where <HostName> is the name of
Copy the files init<SID>.fcs and init<SID>.fct into the new directory
Adapt the file init<SID>.fcs with the new production server
In the file init<SID>.fct, replace the volumes with the new source/target
volumes
Install DP for Snapshot Devices and DP for mySAP on the new production
server
Run the DP for Snapshot Devices setup script
Run the DP for mySAP installation.
Run the following command to update the TCP/IP socket server
configuration on the production system:
where
catalog partition.
Add a logical EEE partition on one backup server or add a new physical EEE
partition on a new backup server. If a new physical EEE partition is added on
a new backup server, then the following steps must be performed:
- Make sure that the db2<SID> user and the db<SID>adm group are created
on the new backup server
- Make sure that the DB2 UDB EEE NFS exports are exported to and
mounted on the new backup server
- NFS-export the file system /db2/<SID>/dbs to the new backup server
- NFS-mount the file system /db2/<SID>/dbs on the new backup server
- Install DP for Snapshot Devices and DP for mySAP on the new backup
server
- Run the DP for Snapshot Devices setup script for the backup system
/usr/tivoli/tsm/acssap/db2/setupDB2BS.sh
- Run the DP for Snapshot Devices setup script
- Run the DP for mySAP installation.
Add the new source and target volumes to the DP for Snapshot Devices
target volumes file
v Drop a logical EEE partition from the production DB2 UDB EEE instance:
Dropping a logical EEE partition from the production DB2 UDB EEE instance
will change the DB2 UDB EEE configuration file db2nodes.cfg. One entry will
be removed from this file. After dropping an EEE partition, the DB2 UDB

|
|
|
|
|
|
administrator should also remove the file systems on the production server on
which the dropped EEE partition was located. These file systems are:
/db2/<SID>/sapdata<X>/NODE<NNNN>
/db2/<SID>/db2<SID>/NODE<NNNN>
where <NNNN> is the number of the dropped EEE partition. Additionally the
administrator has to change the nodegroup definition on the production EEE
database and redistribute the data in the nodegroup.
- To update the TCP/IP socket server configuration on the production system,
you have to remove the corresponding entries from the files /etc/inittab and
/etc/services.
Drop the corresponding logical EEE partition on the backup server that
handles the production EEE server with the dropped logical EEE partition
Remove the source and target volumes that are no longer needed from the DP
for Snapshot Devices target volumes file
On the backup system, remove an entry in the file /etc/services that
corresponds to the removed entry on the production system
v Drop a physical EEE partition from the production DB2 UDB EEE instance:
Dropping a physical EEE partition from the production DB2 UDB EEE instance
be removed from this file. After dropping a EEE partition, the DB2 UDB
administrator should also remove the file systems on the production server on
which the dropped EEE partition was located. These file systems are:
where <NNNN> is the number of the dropped EEE partition.
Additionally, the administrator has to change the nodegroup definition on the
To update the TCP/IP socket server configuration on the production system,
you have to remove the corresponding entries from the files /etc/inittab
and /etc/services
Unmount the NFS file system /db2/<SID>/dbs on the production server
Remove the production server from the NFS file system /db2/<SID>/dbs
export list on the production system
Remove the directory /db2/<SID>/dbs/<HostName> from the NFS file system
/db2/<SID>/dbs, where <HostName> is the name of the removed production
server
Drop the corresponding logical or physical EEE partition on the backup
server that handles the production EEE server with the dropped physical EEE
partition
On the backup system, remove an entry in the file /etc/services that
corresponds to the removed entry on the production system
v Move a logical EEE partition from one production server to a new production
server:
Moving a logical EEE partition within the production DB2 UDB EEE instance
be changed in this file. Before moving a EEE partition, the DB2 UDB
administrator must stop the database and move file systems to the new
production server on which the new EEE partition is located. These file systems
are:
where <NNNN> is the number of the moved EEE partition.
The db2nodes.cfg file entry can then be changed to the new production server.
No additional change of the nodegroup definition on the production EEE
database or redistribution of the data in the nodegroup is needed.
Make sure that the db2<SID> user and the db<SID>adm group are created on
Make sure that the DB2 UDB EEE NFS exports are exported to and mounted
on the new production server
NFS export the file system /db2/<SID>/dbs to the new production server
NFS mount the file system /db2/<SID>/dbs on the new production server
Create a new directory
/db2/<SID>/dbs/<HostName>
in the NFS file system /db2/<SID>/dbs, where <HostName> is the name of the
new production server
Copy the files init<SID>.fcs and init<SID>.fct into the new directory
Adapt the file init<SID>.fcs with the new production server
In the file init<SID>.fct, adapt the source/target volumes
Install DP for Snapshot Devices and DP for mySAP on the new production
server
Run the DP for Snapshot Devices setup script
Run the DP for mySAP installation.
Run the following command to update the TCP/IP socket server
configuration on the production system:
where
catalog partition.
- No change in the EEE configuration file db2nodes.cfg is needed.

|
|
|
Chapter 10. Multiple Backup Generations (Target Sets) on
Disk

Note for SVC
See the README information for the current status of support for multiple
FlashCopy backups on multiple target sets in an SVC environment.
General Overview
To address the requirement for minimum outage for database restoration, the time
between backups must be decreased (having fewer log files to apply reduces
forward recovery duration). In order to maintain the capability for FlashBack
Restore, multiple backup generations must be kept on disk. DP for Snapshot
Devices supports this by managing multiple target sets.
More than one set of target volumes can now become the target set (or data
container) for one disk copy backup of the source volumes identified when
running the SAP DBA tool brbackup together with DP for Snapshot Devices.
Configuring multiple target sets as backup generations on disk increases the
availability of a best-fit backup on disk for FlashBack restore. For example,
consider the following backup schedule:
Table 18. Sample Backup Schedule Employing Multiple Target Sets
Daily
Backup
Number Time Target Set FlashCopy Type Backup Type
1 12:00 a.m. 1 INCR Disk-only
2 4:00 a.m. 2 COPY Disk and tape (TSM)
3 8:00 a.m. 1 INCR Disk-only
4 12:00 p.m. 1 INCR Disk-only
5 4:00 p.m. 2 COPY Disk-only
6 8:00 p.m. 1 INCR Disk-only

Maintaining multiple backup generations
v increases the probability that the DBA has a disk copy backup available for a
FlashBack Restore. In the past, as long a backup has been running (always using
the only target set which DP for Snapshot Devices could manage for one source
set), the one disk copy backup could have been rendered unusable if the
brbackup run was interrupted or was unsuccessful. In such a situation, no
FlashBack Restore from a disk copy backup could be done.
v gives the DBA the option of running the fast FlashBack Restore from older disk
copy backups.
37
In the past, with only one target set
38
and no alternative to
select another backup from other target sets, a restore from the TSM server was
37. In case the latest disk backup (with earlier DP releases, only one) already reflects the error or cannot be used for any other
reason.

always required. The time required for this restore, and thus the outage time, is
much longer than a FlashBack Restore requires.
v can speed up the recovery time (part of the outage), because now the DBA can
run the faster incremental backups more often, such as during the day, even
with high DB activity, and in times with low DB activity have a full disk copy
backup done to a target set other than the one (or two
38
) used during the day;
should a restore of a disk backup become necessary, the DB recovery time with
such more-current target sets can be significantly decreased.
When using an AIX LVM mirrored setup (see Chapter 8, DP for Snapshot Devices
Functionality for AIX LVM Mirrored Environments, on page 161 for this special
environment) not only can multiple disk backups be retained on the ESS, but two
of them can be created by employing the FlashCopy incremental-backup versions
retained on the storage system. This gives you the ability to run fast FlashCopy
backups alternately to two disk copies, thus reducing the downtime if a
restore/recovery should be required.
The maximum number of target sets you can allocate for your DB will depend on
the following:
v the size of the DB (residing on the so-called source volumes and logically
representing a source data container)
v the number of target sets that can be allocated in the hardware unit
v the maximum number the hardware supports; for accurate information please
contact your marketing representative
In order to use multiple target sets for the backup strategy along with DP for
Snapshot Devices, several aspects are discussed below:
v Selection algorithms which can be used
v Intended FLASHCOPY_TYPE
v Setup for multiple target sets in the DP for Snapshot Devices target volumes file
v Target set states
v Functions and commands providing status/usage information of a target set
v Parameters affecting the use of multiple target sets
v General prevention of simultaneous FlashCopy Backup runs
v Algorithm used for the intended FlashCopy type when working with automated
target set selection
v Algorithm used for the intended FlashCopy type when working with specific
target set selection
v Requirements for using multiple target sets
v Multiple target sets and their implications for a FlashBack Restore
Practical examples of the use of multiple target sets are provided in Case 9:
Backup with Multiple Target Sets (Without AIX Mirrors) on page 265 and Case
10: Backup with Multiple Target Sets (With AIX Mirrors) on page 267).
38. Prior to DP for ESS 5.3.0, when working with AIX mirrors, a maximum of two target sets could be used due to the fact that 2
mirror sets of source volumes were involved.
Multiple Backup Generations (Target Sets) on Disk

Selection Algorithms Available
Having included more than one target set in a backup/restore strategy, the DBA,
based on his strategy and schedules, needs a capability to decide which target set
is to be used in the various different FlashCopy backups. For this purpose, DP for
Snapshot Devices gives him the option, for each planned backup, to choose
between 2 selection algorithms:
v Specific target set selection, where the DBA explicitly determines, via the target
set parameter (-n; see below for more details), which target set is to be used by
DP for Snapshot Devices within the FlashCopy backup, or
v Automated target set selection, where the DBA allows DP for Snapshot Devices
to determine which of several target sets should/can be used. This depends on
the intended FLASHCOPY_TYPE value (see Intended FLASHCOPY_TYPE) that
DP for Snapshot Devices determined based on the FLASHCOPY_TYPE values
found in Customizing the DP for Snapshot Devices Profile on page 61).
Target set selection will be done only if the backup system has been left in a state
allowing a new backup to be started. This requires that at least the DP for
Snapshot Devices unmount function have been done, either during or after the
backup (see Unmount Function on page 124 and Withdraw Function on page
121).
Intended FLASHCOPY_TYPE
In the context of multiple target support, the term intended FLASHCOPY_TYPE has
been introduced. This is the value specified by the DBA in a profile or on the
command line. DP for Snapshot Devices determines the intended
FLASHCOPY_TYPE when checking for the FLASHCOPY_TYPE value in the
tdphdwdb2 command line and DP for Snapshot Devices profile:
v If the value of the copy type option ( -C <flashcopy_type>) is specified on the
tdphdwdb2 command line, use this value; see below for details in Parameters
Affecting the Use of Multiple Target Sets on page 224
v If there is no FLASHCOPY_TYPE value on the tdphdwdb2 command line, use
the FLASHCOPY_TYPE parameter value from the DP for Snapshot Devices
profile (.fcs); its default value is COPY.
Setup for Multiple Target Sets in the DP for Snapshot Devices Target
Volumes File
This section describes the requirements for defining multiple target sets in the
target volumes file. The DP for Snapshot Devices target volumes file (.fct) contains
information as to which of a number of target sets can be used.
The file is made up of multiple volumes_set_x topics; each topic comprises all the
target volumes that will be used within one FlashCopy backup; these volumes
make up one target set.
Target set number/data container ID: Each topic (and thus each target set) is
identified by a topic name comprised of a prefix (volumes_set_ ) and a target set
number (up to 2 digits); in DP for Snapshot Devices messages, the latter is also
referred to as a data container ID. The target set number (data container ID) is the
value (x) to be used when you run the specific target selection with the target set
parameter -n x (see Parameters Affecting the Use of Multiple Target Sets on
page 224).
Chapter 10. Multiple Backup Generations (Target Sets) on Disk 221
A more detailed description of the setup of the DP for Snapshot Devices target
volumes file (.fct) is shown in DP for Snapshot Devices Target Volumes File on
page 155 and DP for Snapshot Devices Target Volumes File in a Mirrored
Environment on page 175.
After DP for Snapshot Devices is installed, the DBA needs to set up the DP for
Snapshot Devices target volumes file (.fct) with at least one target set; therefore, the
file contains at least one target set topic (such as volumes_set_1). In case you
extend your initial environment by one or more additional target sets, additional
target set topics need to be added to the DP for Snapshot Devices target volumes
file (.fct). Case 9: Backup with Multiple Target Sets (Without AIX Mirrors) on
page 265 and Case 10: Backup with Multiple Target Sets (With AIX Mirrors) on
page 267 show samples for the setup of a DP for Snapshot Devices target volumes
file with multiple target sets. These examples assume an ESS configuration.
In case you plan to change a target set in, or remove one from, the FlashCopy
backup process, you must first run a DP for Snapshot Devices splitint -f
withdraw to ensure that, based on the usage of this target set:
v any existing source/target relationships (such as INCR or NOCOPY) are
withdrawn and no potential problems remain for succeeding FlashBack Restores
and FlashCopy backups.
v any mounted file systems on the backup system will be released (unmount fs, ...,
exportvg)
Target Set States
Each target set defined in the DP for Snapshot Devices target volumes file (.fct) can
have one of the following two states:
AVAILABLE
This is the initial state of the target set after you have set up the target sets
in the hardware unit(s) and the DP for Snapshot Devices target volumes
file (.fct); a target set will also be (re)set to this state once you free up a
target set with state IN_USE using the splitint function withdraw.
IN_USE
This is the target set state after DP for Snapshot Devices within a
FlashCopy backup has determined to
v select a target set which has the state AVAILABLE and add it to a logical
FlashCopy group (INCR, COPY or NOCOPY) that matches the intended
FLASHCOPY_TYPE, or
v reuse a target set with the state IN_USE in an existing logical FlashCopy
group
based on the intended FLASHCOPY_TYPE in the FlashCopy backup run,
Note: A target set with the state IN_USE is always associated with a
FlashCopy type (INCR, COPY or NOCOPY) used for a previous
FlashCopy Backup; such a target set cannot be reused if the
intended FLASHCOPY_TYPE value of a new FlashCopy backup
does not match the FLASHCOPY_TYPE value associated with the
selected target set using the specific target set algorithm.

Logical FlashCopy Group
A logical FlashCopy group consists of one or more target sets associated with the
same FLASHCOPY_TYPE value. A target set with state AVAILABLE, when selected
in a FlashCopy backup, is added to a logical FlashCopy group associated with a
certain FLASHCOPY_TYPE value if
v the FLASHCOPY_TYPE value matches the intended FLASHCOPY_TYPE value
of the current FlashCopy backup and
v the maximum number of target sets of the selected logical FlashCopy has not
been reached
The number of target sets used in the various logical FlashCopy groups depends
mainly on the FLASHCOPY_TYPE value associated with the group:
v A COPY group can have more than one target set.
v An INCR group can have only one target set.
Exception for mirrored environment only: When using the DP for Snapshot Devices
functionality for AIX mirrored environments, 2 INCR target sets can be used,
because the set of (AIX mirrored) source volumes can be divided into 2 (source)
copy sets, each one set up in a separate hardware unit; only one source copy set
will be involved within a FlashCopy Backup and only 1 target set, in the same
hardware unit as the source copy set, can be used for INCR FlashCopy backup
(see the setup requirements in Chapter 8, DP for Snapshot Devices
Functionality for AIX LVM Mirrored Environments, on page 161).
v A NOCOPY group can theoretically have more than one target set if a used
target set is unmounted prior to the next FlashCopy backup and other target sets
would be used for a FlashCopy backup.
However, for practical reasons, it is recommended to use the resync function if
the FlashCopy backup runs with FLASHCOPY_TYPE NOCOPY, in order to free
up the source/target relationship. In this way, after a FlashCopy backup, the
temporarily used target set again receives the status AVAILABLE. Another
reason not to have target sets left IN_USE with FLASHCOPY_TYPE NOCOPY is
the potential for conflicts when running a FlashBack Restore (see Multiple
Target Sets and Implications for a FlashBack Restore on page 228).
The upper limit for a logical FlashCopy group is the limit which is given by the
capacity of the hardware unit(s) (or SVC cluster) and the number of source/target
relationships for one source volume imposed by the storage system; this number
needs to be adjusted to the number already planned/used in the other logical
FlashCopy groups.
Functions and Commands Providing Target Set Status and Usage
Information
The following commands can be used to find out the status information about the
established and allocated target sets that are used in a FlashCopy backup or are
reset with the withdraw function of the splitint command:
v ts_inquire (function of tdphdwdb2): you will see the IN_USE/AVAILABLE
status for each target set
v tdphdwdb2 command: you will see the target sets that are IN_USE, whether
they can be used in a FlashBack Restore, and to which backup runlog a target
set was or is still related.
For details, see Chapter 6, Description and Usage of the DP for Snapshot Devices
Commands, on page 105.
Parameters Affecting the Use of Multiple Target Sets
The following two command-line parameters are available for the purpose of
covering various specific customer needs, such as using specific or automated
target set selection and minimizing the complexity for the setup of DP for
FlashCopy (the number of involved control and profiles):
v the target set parameter (-n x), to select a specific target set, where x specifies
the number of a target set used in the FlashCopy backup; the target set number
is part of the topic name used for the setup of the target set in the DP for
Snapshot Devices target volumes file (.fct).
Note: This parameter will cause DP for Snapshot Devices to run the so-called
specific target set selection; without this parameter, automated target set
selection is performed.
v the parameter (-C <flashcopy_type>), where flashcopy_type can be INCR,
COPY or NOCOPY, used by DP for Snapshot Devices to resolve the type of
FlashCopy operation when initiating the background copy. This parameter will
override the value you have specified in the FLASHCOPY_TYPE parameter in
the DP for mySAP profile (.fcs).
Both parameters are optional; however the use of -C is highly recommended so
that DP for Snapshot Devices can do what the DBA expects it will.
In addition, the target set parameter is an optional parameter in most of the
tdphdwdb2 functions (see Chapter 6, Description and Usage of the DP for
Snapshot Devices Commands, on page 105).
The target set parameter (-n x) was available prior to DP for ESS 5.3.0 when using
the DP for Snapshot Devices functionality for AIX mirror environments; however,
it was termed the copy set parameter and allowed a selection between 2 copy
(mirror) sets; the copy set parameter (-n x) has now been replaced for the
mirrored environment in the context of the general multiple target set functionality
for 5.3; for the specifics for copy sets, see Target Set Parameter on page 174.
General Prevention of Simultaneous FlashCopy Backups
As long as a background copy (initiated by a FlashCopy backup) is running, the
target set involved with this copy cannot be used for a FlashBack Restore. This
requires that DP for Snapshot Devices prevent the DBA from accidentally running
too many backups simultaneously, with the risk that there are no disk backups
available if a FlashBack Restore is needed.
There are two mechanisms in place that control the FlashCopy backups when
using tdphdwdb2:
v The DBA tool mechanism, which prevents two backups from running at the
same time; however, for one source set, multiple background copies (initiated
from different backup runs executing in succession) can run concurrently. This
would have the negative effect that all disk backups of a logical FlashCopy
group could become invalid at the same time. Therefore, further control is
required.
v The DP for Snapshot Devices mechanism that, when a new FlashCopy backup is
requested, checks for any background copies still running on behalf of a
previous backup request; DP for Snapshot Devices will prevent a new
FlashCopy with a target set selected from an existing logical FlashCopy group

(INCR or COPY
39
) from being started if a background copy is still running for
the same logical FlashCopy group; however, any target set (state AVAILABLE)
which does not yet belong to a logical FlashCopy group could be selected if this
is not in a conflict with the algorithms for the intended FlashCopy type (see the
following sections).
Algorithm Used for Automated Target Set Selection Using the Intended
FlashCopy Type
When running a FlashCopy backup with automated target set selection (without
the -n parameter), the decision as to which target set will be used depends on
v the value of the intended FlashCopy found, and
v the state of the target set(s)
For mirrored environments only, if multiple target sets are defined in the two
hardware units, DP for Snapshot Devices tries to select the target sets in a balanced
manner.
Table 19. Automated Target Set Selection
Value of Intended
FLASHCOPY_TYPE Target Set Selection
INCR
v If one of the target sets is in the state IN_USE with
FLASHCOPY_TYPE INCR, reuse this one for the FlashCopy
backup request (if a background copy is running for this one,
then fail). For a mirrored environment, see below.
v If none of the target sets is in the state IN_USE with an INCR
disk copy, and at least one target set is in the state
AVAILABLE, select the first AVAILABLE one encountered in
the DP for Snapshot Devices target volumes file for the
FlashCopy backup request.
v If all target sets are in the state IN_USE but none is an INCR
disk copy, then fail.
For mirrored environment only:
v If one of at most 2 target sets is in the state IN_USE (assigned
to one hardware unit) and associated with
FLASHCOPY_TYPE INCR, DP for Snapshot Devices will
check in the target sets assigned to the second hardware unit
for one in the state AVAILABLE; if there is none, reuse the
one which is already in the state IN_USE (if a background
copy is running for this one, then fail), otherwise select the
target set found in the second hardware unit.
v If 2 target sets are in the state IN_USE and associated with
FLASHCOPY_TYPE INCR, each associated with a source
copy set, select the target set with the oldest disk copy for the
FlashCopy backup request if there is no background copy
running for one of the two target sets; otherwise, fail.
39. Since NOCOPY never generates a FlashCopy backup whose target set can be used for a FlashBack Restore, the use of multiple
target sets is a hypothetical case, although this is technically possible. For this reason, such a procedure will not be discussed
further.
Table 19. Automated Target Set Selection (continued)
Value of Intended
FLASHCOPY_TYPE Target Set Selection
COPY
v If all the target sets are in the state IN_USE and one or more
is associated with a FLASHCOPY_TYPE of COPY, select the
target set with the oldest disk copy for the FlashCopy backup
request. However, if there is a background copy running for
one of the target sets, then fail.
v If at least one target set is in the state AVAILABLE, select the
first AVAILABLE one encountered in the DP for Snapshot
Devices target volumes file for the FlashCopy backup request.
v If all target sets are in the state IN_USE, but none is
associated with a FLASHCOPY_TYPE of COPY, then fail.
NOCOPY
v If at least one target set is in the state AVAILABLE, select the
first AVAILABLE one encountered in the DP for Snapshot
Devices target volumes file for the FlashCopy backup request.
v If all target sets are in the state IN_USE and one or more are
associated with a FLASHCOPY_TYPE NOCOPY, then, despite
having the same FLASHCOPY_TYPE value, none can be
selected for the FlashCopy backup request because the target
set must first be withdrawn (a source/target relation exists)
prior to running a new FlashCopy backup with
FLASHCOPY_TYPE NOCOPY.
v If a target set is in the state IN_USE with a NOCOPY disk
copy, and all other target sets are IN_USE other than with
INCR/COPY, DP for Snapshot Devices will fail. The reason
for this is that there is still a source/target relationship
created by a previous FlashCopy backup; the target set must
first be withdrawn (to remove the source/target relationship)
prior to running a new FlashCopy backup with
FLASHCOPY_TYPE NOCOPY
v If all target sets are in the state IN_USE, then fail.

Algorithm Used for Specific Target Set Selection
When running a FlashCopy backup with specific target set selection (the -n
parameter is used), DP for Snapshot Devices can change the value of the intended
FLASHCOPY_TYPE depending on
v the state of the target set (IN_USE or AVAILABLE), and
v the FLASHCOPY_TYPE of the target set when it is in the state IN_USE.
When determining the actual FLASHCOPY_TYPE value to use, DP for Snapshot
Devices also considers the conditions under which it is not logical to run the actual
FlashCopy or the resync task based upon the intended FLASHCOPY_TYPE value.
DP for Snapshot Devices will therefore use an effective FLASHCOPY_TYPE value
that is set depending on the following conditions:
v The function -f flashcopy or -f backup ... -t flashcopy is used in tdphdwdb2 to
perform a FlashCopy only (disk-only backup), Even if the user has specified
NOCOPY as the FLASHCOPY_TYPE, DP for Snapshot Devices uses COPY or
INCR as the effective FLASHCOPY_TYPE value (see below).

v The state of the target set is IN_USE and the FLASHCOPY_TYPE of this target
set is INCR. Under the assumption that the user has specified COPY or
NOCOPY as the FLASHCOPY_TYPE value, DP for Snapshot Devices uses INCR
as the effective FLASHCOPY_TYPE.
The various conditions when
v using the target set parameter -n x, where x is the number of the target set in
the DP for Snapshot Devices target volumes file, and
v the target set state of the selected target set is AVAILABLE or IN_USE (with
either COPY or INCR).
are summarized in the following table, which shows
v the intended FLASHCOPY_TYPE value (the result of the FLASHCOPY_TYPE
values in the .fcs file and the -C copy parameter)
v the effective FLASHCOPY_TYPE value DP for Snapshot Devices has calculated
based on the detected conditions and which will be used for the FlashCopy
request
v the DP for Snapshot Devices function (unmount or withdraw) which will be
performed by the DP for Snapshot Devices splitint f resync at cleanup time to
complete a backup cycle based upon the effective FLASHCOPY_TYPE value at
FlashCopy backup time.
Table 20. Effective FLASHCOPY_TYPE Value Determination
Intended
FLASHCOPY_ TYPE
value NOCOPY/
COPY/ INCR
Effective FLASHCOPY_TYPE DP for Snapshot Devices splitint -f resync
action
Not disk-only
backup
Disk-only backup Not disk-only
backup
Disk-only backup
Target set is
AVAILABLE or
IN_USE with
FLASHCOPY_TYPE
COPY
NOCOPY
COPY
INCR

NOCOPY
COPY
INCR [1,2]

COPY
COPY
INCR [1,2]

withdraw
unmount
unmount

unmount
unmount
unmount
Target set is IN_USE
with
FLASHCOPY_TYPE
INCR

NOCOPY
COPY
INCR

INCR
INCR
INCR

INCR
INCR
INCR

unmount
unmount
unmount

unmount
unmount
unmount
[1] If another target set is in the state IN_USE and the FLASHCOPY_TYPE of this target set is INCR, DP for
Snapshot Devices will terminate with an error message.
[2] If using the DP for Snapshot Devices AIX LVM mirror functionality, the selection of a target set determines
which of the two hardware units units is chosen; if another target set is IN_USE in this hardware unit, and the
FLASHCOPY_TYPE of this target is INCR, DP for Snapshot Devices will terminate with an error message.

Depending on the effective FLASHCOPY_TYPE value used in the backup cycle,
DP for Snapshot Devices automatically selects the proper DP for Snapshot Devices
function (either withdraw or unmount) to complete the backup cycle and have the
disk copy retained for a restore. In addition, as soon the background copy is
completed (monitored by the FlashCopy agent), a new FlashCopy backup request
can be started. Thus, all DP for Snapshot Devices activities can be done within one
FlashCopy backup request.
If the selected target set is IN_USE and associated with FLASHCOPY_TYPE
NOCOPY, such a FlashCopy Backup will always terminate with an error message.
The effective FLASHCOPY_TYPE value of a FlashCopy backup is reported in
message EEP0366I in the backup detail log.
If there is a reason to reset an effective FLASHCOPY_TYPE of INCR to COPY or
NOCOPY, the DP for Snapshot Devices function withdraw can be used, which
will change the state of the target set to AVAILABLE.
Requirements for Using Multiple Target Sets

Note
In the following sections, the term hardware unit applies to an ESS or DS
configuration. For an SVC configuration, hardware unit is equivalent to SVC
cluster.
v Plan storage system space requirements for the source volume (DB size) and for
one or more target set(s) for the involved hardware unit(s). Observe
the FlashCopy requirement to have each source and target pair in the same
hardware unit (the source volumes can reside in different hardware units),
and
the DP for Snapshot Devices requirements when working with AIX mirrors
(see Chapter 8, DP for Snapshot Devices Functionality for AIX LVM Mirrored
Environments, on page 161); two hardware units can be used for the (mirror)
copy sets.
v In the hardware unit(s), define the set of source volumes and those belonging
one or more target sets.
v Define the target set(s) in the .fct file, which itself is specified in the DP for
Snapshot Devices profile (.fcs); you can use the ts_inquire function to check the
status of the target sets you have defined in the .fct file.
v Decide which FLASHCOPY_TYPE you want to use for the target set:
the parameter -C <flashcopy_type> and
optionally, if the specific target set selection is planned, the target set
parameter -n y parameter (with y = 1, 2, etc.) depending on the number of
available target sets defined in the .fct file
Multiple Target Sets and Implications for a FlashBack Restore
This section discusses considerations when performing a FlashBack Restore in a
multiple-target-set environment.
Required Checks Prior to FlashBack Restore
The FlashBack Restore steps, including the pre- and post-restore activities, when
several target sets are eligible for a FlashBack Restore are the same as the case
where you have a setup with one target set only. First, you can check whether a
background copy is still running; if this is the backup you want for the FlashBack

Restore, you need to wait for its completion; otherwise, you need to terminate it
with a DP for Snapshot Devices splitint -f withdraw ... (on the backup system).
However, the FlashCopy concept has a basic requirement you need to observe
when using several target sets for one source set: a target volume cannot have
multiple source/target relationships. This means that you cannot perform a
FlashCopy back to the original source volume, which now becomes the target
volume, as long as a source/target relationship exists for the original source. This
restriction requires that, prior to a DP for Snapshot Devices FlashBack Restore, the
DBA needs to check for any relationships the original source volumes have
(tdphdwdb2 -f restore or -f ts_inquire provide this information).
Such source/target relationships are created when you
v used FLASHCOPY_TYPE INCR or NOCOPY in the backup.
Note: No such source/target relationship exists if you have used resync for the
NOCOPY case. In the INCR case, the resync will keep the source/target
relationship for succeeding backups and restores. This functionality is
intended.
v have a background copy running.
Note: For each backup with FLASHCOPY_TYPE COPY, there is a temporary
source/target relationship. As soon as the background copy completes,
there is no longer a source/target relationship.
The DP for Snapshot Devices tdphdwdb2 program can be used to view the current
source/target relationships, and it will refuse ( via message IDS1410E) to run a
tdphdwdb2-based restore as along as unacceptable source/target relationships still
exist.
The conditions and consequences for breaking or not breaking the relationships are
as follows:
1. If the backup and/or background copy of a backup you want to restore is still
running, you must wait until both have completed. In the meantime, however,
you can check whether other existing source/target relationships must be
withdrawn.
2. If a NOCOPY source/target relationship exists for the original source, its target
set cannot be used in a FlashBack Restore anyway. The required action is:
withdraw in any case on the backup system by running splitint -f withdraw -n
x ....
3. If the backup and/or the background copy is still running and this is not the
backup you want to use for a FlashBack Restore, the required action on the
backup system is to terminate (kill) the backup and/or terminate the
source/target relationship by running -f withdraw -n x
4. If an INCR source/target relationship exists for the original source, and the
backup level on this target set is the one you want to select for a FlashBack
Restore, then no action required. This assumes that you have resolved either of
the first two conditions if they are applicable.
5. If an INCR source/target relationship exists for the original source and the
backup level on this target set is not the one you want, then only other target
sets created with FLASHCOPY_TYPE COPY and in the state IN_USE can be
used for a FlashBack Restore. However, in this case, the required action to
break the source/target relationship is to withdraw on the backup system by
running splitint -f withdraw -n x .... .
6. If a source/target relationship exists for the original source because a
background copy is still running as a result of a FlashCopy backup using
FLASHCOPY_TYPE COPY, you cannot run a FlashBack Restore to this source.
In this case, you either wait for completion or run splitint -f withdraw -n x ....
In case an AIX-mirrored database with a setup as specified in the Chapter 8, DP
for Snapshot Devices Functionality for AIX LVM Mirrored Environments, on page
161 is the subject of a FlashBack Restore, the storage systems restriction on
multiple source/target relationships to an original source volume must be followed
for the source copy set that will be involved in the FlashBack Restore. The
FlashCopy backups of the other (source) copy set and its target sets do not need
any check for multiple source/target relationships as long they will not be chosen
for a FlashBack Restore.
tdphdwdb2 can be used to select the target set (on the basis of the selected mySAP
backup run log) for a restore (see Chapter 6, Description and Usage of the DP for
Snapshot Devices Commands, on page 105); if a target set is selected that first
requires the withdraw of other source/target relationships, DP for Snapshot
Devices will show the source/target relationship in question and terminate the
requested restore immediately. The DBA needs to do the required withdraw actions
first.
Checking the Source and Target Relationships Using
tdphdwdb2
Before running the FlashBack Restore, you need to check for any source/target
relationships that are not acceptable when performing a FlashBack Restore. In
order to do this, you run tdphdwdb2 and check for the conditions as discussed in
the previous section.
The information shown and the required action will be discussed based on the
following tdphdwdb2 sample (the output is viewed using the option f in the
restore menu).
The values in the column FCType (COPY, INCR, NOCOPY) must be used to
determine any source/target relationships that may exist. If, in addition, the word
running is indicated in the FlashCopy column, there is a source/target
relationship for a backup with FLASHCOPY_TYPE COPY. This relationship is
terminated, however, as soon as the background copy has finished and the entry
running changes to ok.
40
The tdphdwdb2 option f shows all target sets in the DP for Snapshot Devices
target state IN_USE and having one or more source/target relationships. The
FLASHCOPY_TYPE for each target set, as it was used in the FlashCopy Backup, is
shown under the column FCType. To show the possible types of source/target
relationships, a NOCOPY relationship is also shown in the samples below.
Sample of an Environment Without AIX LVM Mirrors
Note: No value is shown for HdwID because in this case the source volumes can
be spread over several hardware units.
This example uses 5 target sets to show the various source/target relationships that
might exist. When working with an AIX unmirrored environment, the source
40. tdphdwdb2 does not dynamically perform a refresh. This requires the user to use r option.

volumes can reside in different hardware units. Unlike the case with an AIX mirror
setup and working with the DP for Snapshot Devices functionality for an AIX LVM
mirrored environment, the HdwID column value is empty because there is only
one set of source volumes. For this set of source volumes, the following
source/target relationships exist:
v Entry #1 with TargetID (target set ID) 5, because a background copy is still
running; as soon as this copy completes, there will no longer be a source/target
relationship shown.
v Entry #5 with TargetID (target set ID) 1, which shows a NOCOPY source/target
relationship (after the backup., only a DP for Snapshot Devices unmount was
done for the purpose of this sample).
From the tdphdwdb2 restore menu, the DBA runs the f option, which shows the
target sets IN_USE. Based on the FCType and FlashCopy columns (check for
running) the DBA can infer the existing source/target relationships:
Enter your selection => f
--------------------------------------------------------------------------------
BSN HdwID FCType TargetID
--------------------------------------------------------------------------------
00163 - COPY 5
[2] - 21.09.2004 17:12:36 DB online ok ok S0000009.LOG
00162 - INCR 3
[3] - 21.09.2004 17:09:58 DB online - ok S0000004.LOG
00161 - COPY 4
00158 - COPY 2
[5] - 21.09.2004 16:56:41 DB online ok nocopy S0000002.LOG
00160 - NOCOPY 1

Enter your selection => 2
If the DBA now attempts to run a restore by selecting #2 (Enter your selection =>
2), he will receive the messages
IDS1410E You cannot run a FlashBack Restore from target set 3 if the sources are
involved in a relationship of type NOCOPYwith target set 1.

involved in a relationship of type COPY with target set 5.
On the backup system, the DBA performs a DP for Snapshot Devices withdraw for
target sets 5 and 1; after running the refresh display option r and again using the
f option, the following target set information is now shown:
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
00162 - INCR 3
[3] - 21.09.2004 17:09:58 DB online - ok S0000004.LOG
00161 - COPY 4
00158 - COPY 2

The selected #2 will now be restored, running the FlashBack Restore process.
The DBA could also do a restore with #3 or #4; however, he would first have to
remove the source/target relationship of #2. Otherwise, the restore will be refused
with message IDS1410E, instructing the DBA to first withdraw the source/target
relationship of #2.
Sample Using the DP for Snapshot Devices Functionality for AIX
LVM Mirrored Environments
This example uses 5 target sets to show the various source/target relationships that
might exist. Because this setup uses the DP for Snapshot Devices functionality for
AIX LVM mirrored environments, each source copy set is in one hardware unit
(22031 and 23376, respectively), with its own source/target relationships as follows:
v For the source copy (mirror) set in hardware unit 22031:
#3 with TargetID 4, an INCR source/target relationship
v For the source copy (mirror) set in hardware unit 23376:
#4 with the TargetID 2, an INCR source/target relationship
#5 with the TargetID 1, a NOCOPY source/target relationship
From the tdphdwdb2 restore menu, the DBA runs the f option, which shows the
target sets IN_USE, and based on the FCType and FlashCopy columns (check for
running) the DBA can infer the existing source/target relationships:
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
00163 22031 COPY 5
00162 23376 COPY 3
[3] - 21.09.2004 17:09:58 DB online - ok S0000004.LOG
00161 22031 INCR 4
00158 23376 INCR 2
[5] - 21.09.2004 16:56:41 DB online ok nocopy S0000002.LOG
00160 23376 NOCOPY 1


involved in a relationship of type NOCOPYwith target set 1.

involved in a relationship of type INCR with target set 2.
Note: Only the source/target relationships with the target sets residing in ESS ID
(23376), where the source volumes of this copy set reside, are relevant and
need to be withdrawn with the DP for Snapshot Devices withdraw function.
On the backup system, the DBA performs a DP for Snapshot Devices withdraw for
target sets 1 and 2; after running the refresh display option r and again the f
option, the following target set information is now shown:

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
00163 22031 COPY 5
00162 23376 COPY 3
[3] - 21.09.2004 17:09:58 DB online - ok S0000004.LOG
00161 22031 INCR 4

The selected #2 will now be restored, running the FlashBack Restore process. If the
DBA does the restore with #3, this will also run, because #1, with FCType COPY,
has no existing source/target relationship. However, if the DBA tries a restore with
#1, this will be refused with IDS1410E, instructing the DBA to first withdraw the
source/target relationship of #3.
Running the FlashBack Restore
As soon as the DBA has checked and resolved any conflicting source/target
relationships, he uses the tdphdwdb2 restore function to initiate a restore as
described in Restore Function on page 110.
For the restore itself, there is no difference between a setup with one target set and
one with multiple target sets.
Performing a FlashBack Restore Rerun with a Different Target
Set
Depending on the existing backups on the various target sets in a multiple target
set setup, the DBA could run a restore from a target set different from the one used
in the initial restore.
This also requires checking for existing source/target relationships.
Note: In case your environment on the production system does not have database
file systems mounted and the database logical volumes do not exist, you
cannot rerun a restore with a backup for which you do not have a valid
disk-copy backup on a target set (for example, if there is only a TSM backup
available on the TSM server).
Appendix A. Samples
This appendix presents the following:
v Sample of an Overall Disk Layout
v Sample NFS Server Setup on the Production System on page 237
v Sample NFS Client Setup on the Backup System on page 238
v Sample .rhosts for Remote Shell Connection Setup on the Production System
on page 238
v Sample TSM Client Options Files on page 239
v Sample DP for mySAP DB2 Vendor INI File on page 239
v Sample DP for mySAP Profile on page 239
v Sample DP for Snapshot Devices Profile on page 241
v Sample DP for FlashCopy Target Volumes File (ESS or DS Configuration) on
page 251
v Sample DP for FlashCopy Target Volumes File (SVC Configuration) on page
253
v Sample for Defining a DP for FlashCopy Target Volumes File (Mirror Setup,
ESS or DS Configuration) on page 254
v Sample DP for mySAP Installation and Customization on page 256
v Sample DP for Snapshot Devices Installation and Customization on page 258
v Sample tdphdwdb2 Usage on page 259
v Sample tdphdwdb2 FlashCopy Shell Script on page 271
v Sample tdphdwdb2 EEE FlashCopy Script on page 272
v Sample tdphdwdb2 EEE Online/Offline Backup Script on page 273
v Sample DP for Snapshot Devices Scripts for HACMP Environments on page
273

Note
The samples in this section reflect the use of a DB2 system ID (SID) with the
value D01. This SID is also present in the delivered DP for Snapshot Devices
profile. If a different system ID is employed, the new value must be specified
during installation and the DP for Snapshot Devices profile must be modified
accordingly.
Sample of an Overall Disk Layout
The following figure shows the file systems used in the sample installation,
including NFS.

The respective disk categories contain the following disk types that are used for
the various file systems:
1. Local disks on the production system (p_disk category) for the file systems
/db2/D01
/db2/D01/db2dump
/db2/D01/saparch
/db2/D01/saprest
/db2/D01/db2event
/db2/D01/sqllib
/sapmnt/D01
/usr/sap/D01
/usr/sap/trans
/usr/lpp/db2_07_01
2. Source volume disks on the production system (db_disk category) for the file
systems
/db2/D01/sapdata1
/db2/D01/sapdata2
/db2/D01/sapdata3
/db2/D01/sapdata4
/db2/D01/sapdata5
/db2/D01/sapdata6
/db2/D01/sapdatat
/db2/D01/db2d01
3. Shared disks on the production system (NFS_disk category) for the
directory/file system
/db2/D01/dbs
4. Local disks on the production system (p_db_disk category) for the file systems
/db2/D01/log_dir
/db2/D01/log_archive
/db2/D01/log_retrieve
5. Local disks on the backup system (b_disk category) for the file systems
/db2/D01
/usr/lpp/db2_07_01
6. Disks for the TSM server (TSM_disk category) for the file systems
/tsmdb

Figure 22. Disk Layout Used in Sample Installation
Samples

Sample NFS Server Setup on the Production System

Change Attributes of an Exported Directory

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

[Entry Fields]
* PATHNAME of Directory to Export /db2/D01/dbs
* MODE to export directory read-write +
HOSTS & NETGROUPS allowed client access []
Anonymous UID [-2]
HOSTS allowed root access [magellan]
HOSTNAME list. If exported read-mostly []
Use SECURE OPTION? no +
Public filesystem? no +
* CHANGE export now, system restart or both both +
PATHNAME of alternate Exports file []

F1=Help F2=Refresh F3=Cancel F4=List
Esc+5=Reset F6=Command F7=Edit F8=Image
F9=Shell F10=Exit Enter=Do

Figure 23. smitty Panel for Exporting Directories
Samples
Appendix A. Samples 237
Sample NFS Client Setup on the Backup System

Sample .rhosts for Remote Shell Connection Setup on the Production
System
************************************************************************
* $HOME/.rhosts *
************************************************************************
magellan root
magellan db2d01
Change / Show Attributes of an NFS File System

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

[Entry Fields]
* PATHNAME of mount point /db2/D01/dbs
* PATHNAME of Remote Directory [/db2/D01/dbs]
* HOST where remote directory resides [columbus]
Mount type NAME [NFS]
* Use SECURE mount option? no +
* Remount file system now, both +
update /etc/filesystems or both?
* /etc/filesystems entry will mount the directory yes +
on system RESTART.
* MODE for this NFS file system read-write +
* ATTEMPT mount in foreground or background? background +
NUMBER of times to attempt mount [] #
Buffer SIZE for read [] #
Buffer SIZE for writes [] #
NFS TIMEOUT. In tenths of a second [] #
NFS version for this NFS filesystem any +
Transport protocol to use any +
Internet port NUMBER for server [] #
* Allow execution of SUID and sgid programs yes +
in this file system?
* Allow DEVICE access via this mount? yes +
* Server supports long DEVICE NUMBERS? yes +
* Mount file system soft or hard soft +
Allow keyboard INTERRUPTS on hard mounts? yes +
Minimum TIME, in seconds, for holding [] #
attribute cache after file modification
Maximum TIME, in seconds, for holding [] #
attribute cache after file modification
Minimum TIME, in seconds, for holding [] #
attribute cache after directory modification
Maximum TIME, in seconds, for holding [] #
attribute cache after directory modification
Minimum & Maximum TIME, in seconds, for [] #
holding attribute cache after any modification
The Maximum NUMBER of biod daemons allowed [] #
to work on this file system
* Use acls on this mount? no +
Number of NFS retransmits [] #
* Exchange POSIX pathconf information? no +
* Inherit group IDs? no +

F1=Help F2=Refresh F3=Cancel F4=List
F5=Reset F6=Command F7=Edit F8=Image
F9=Shell F10=Exit Enter=Do

Figure 24. smitty Panel For Mounting NFS Files
Samples

Sample TSM Client Options Files
Sample Client User Options File (dsm.opt)
************************************************************************
* Tivoli Distributed Storage Manager *
* *
* Sample Client User Options file for AIX and SunOS *
************************************************************************

SErvername server_b
Sample Client System Options File (dsm.sys)
************************************************************************
* Tivoli Distributed Storage Manager *
* *
* Sample Client System Options file for AIX and SunOS *
************************************************************************

SErvername server_b
COMMmethod TCPip
TCPPort 1500
TCPServeraddress magellan
Sample DP for mySAP DB2 Vendor INI File
We used two different versions of DP for mySAP in our test environment. For
Version 3.2.0.8, we used the following DB2 Vendor INI file:
PROLE_PORT=57321
XINT_PROFILE=/db2/D01/dbs/initD01.utl
DB2_DIAGPATH=/db2/D01/dbs
For version 3.2.10 or higher we used the following DB2 Vendor INI file:
XINT_PROFILE=/db2/D01/dbs/initD01.utl
TDP_DIR=/db2/D01/dbs/logtraces
TDP_RLF=/db2/D01/dbs
Sample DP for mySAP Profile
Note: For a current sample profile, See the documentation for DP for mySAP.
The name chosen for the sample profile used was:
/db2/D01/dbs/initD01.utl
The following parameters and values were used:
#
-------------------------------------------------------------------------
#
# Data Protection for mySAP interface for SAP R/3 for DB2
#
# Sample profile for Data Protection for mySAP 3.1 for UNIX
#
#------------------------------------------------------------------------
#
# See the Data Protection for mySAP Installation & Users Guide
# for a full description.
#
# For comment symbol the character # can be used.
# Everything following this character will be interpreted as comment.
Samples
|
#
# Data Protection for mySAP V3R1 accesses its profile in "read only"
# mode only. All variable parameters like passwords, date of last
# password change, current version number will be written into the file
# specified with the CONFIG_FILE parameter. The passwords will be encrypted.

#--------------------------------------------------------------------------
# Prefix of the Backup ID which will be stored in the description field
# of the Tivoli Storage Manager archive function.
# Maximum 6 characters.
# Default: none.
#--------------------------------------------------------------------------
BACKUPIDPREFIX D01___

#--------------------------------------------------------------------------
# Number of total parallel sessions which will be established by Data
# Protection for mySAP. Note: this number should correspond with the number
# of simultaneously available tape drives specified for the Tivoli Storage
# Manager server.
# Default: none.
#--------------------------------------------------------------------------
MAX_SESSIONS 2 # 1 Tivoli Storage Manager client session is default

#--------------------------------------------------------------------------
# Specifies the block size for disk I/O (in bytes). The valid range is
# from 4 KB to 256 KB.
# The default values have been chosen from our performance experiments in
# standard hardware environments.
# Default: 131072 (128 KB) on UNIX, 32768 (32 KB) on Windows NT
#--------------------------------------------------------------------------
BUFFSIZE 131072 # block size in bytes

#--------------------------------------------------------------------------
# Controls generation of a trace file.
# Note: we recommend using the trace function only in cooperation with
# the hotline.
# Default: NO.
#--------------------------------------------------------------------------
#TRACE 100

#--------------------------------------------------------------------------
# Specify the trace file for Data Protection for mySAP to store all
# trace information (if TRACE ON), full path and name of file.
# Note: for an actual trace the string %BID will be replaced by
# the current backupid.
# (.../tdpr3_db2_%BID.trace changes to .../tdpr3_db2_D01___9809182300.trace).
# Default: stdout.
#--------------------------------------------------------------------------
#TRACEFILE /db2/D01/dbs/tdpr3_db2.trace
#TRACEFILE /db2/D01/dbs/tdpr3_db2_%BID.trace

#--------------------------------------------------------------------------
# Specify the configuration file for Data Protection for mySAP to
# store all variable parameters, full path and name of the file.
# Default: none.
#--------------------------------------------------------------------------
CONFIG_FILE /db2/D01/dbs/initD01.bki

Samples

#--------------------------------------------------------------------------
# Shall Data Protection for mySAP send error/status information
# to a Tivoli Storage Manager server. The statement for servername must
# match one of the servers listed in a SERVER statement. Statements for
# verbosity can be ERROR, WARNING, or DETAIL.
# Default: none.
#--------------------------------------------------------------------------
#LOG_SERVER servername [verbosity]
#LOG_SERVER server_b ERROR

#--------------------------------------------------------------------------
# Shall Data Protection for mySAP send error/status information
# to a network management program via SNMP traps?
# Default: none.
#--------------------------------------------------------------------------
#SNMPTRAP Hostname community level
#SNMPTRAP server_b public detail

#**************************************************************************
# Statement for multiple Servers and multiple Paths.
# may be used multiple times (one for each server).
#**************************************************************************

SERVER server_b # Servername
SESSIONS 2 # Max sessions
PASSWORDREQUIRED YES # Use a password
ADSMNODE db2d01 # Tivoli Storage Manager Nodename
BRBACKUPMGTCLASS mdb # Mgmt-Classes
BRARCHIVEMGTCLASS MLOG1 MLOG2 # Mgmt-Classes
# USE_AT 0 1 2 3 4 5 6 # Days for backup

#SERVER server_b # Servername
# SESSIONS 2 # Max sessions
# PASSWORDREQUIRED YES # Use a password
# ADSMNODE db2d01 # Tivoli Storage Manager Nodename
# BRBACKUPMGTCLASS mdb # Mgmt-Classes
# BRARCHIVEMGTCLASS MLOG1 MLOG2 # Mgmt-Classes
# USE_AT 0 1 2 3 4 5 6 # Days for backup

#**************************************************************************
# USE_AT : 0=Su 1=Mo 2=Tu 3=We 4=Th 5=Fr 6=Sa
# Default: all days
#**************************************************************************

#--------------------------------------------------------------------------
# End of profile
Sample DP for Snapshot Devices Profile
This sample (/db2/D01/dbs/initD01.fcs) is included in the DP for Snapshot
Devices installation package. It contains the parameters which are required for the
DP for Snapshot Devices program tdphdwdb2:
v to perform a FlashCopy of source volumes to target volumes, or
v to perform a withdraw of the source/target volume relationship
In the sample profile, all SID values have been replaced with D01.
Samples
|
|
|
|
|
|
|
###############################################################################
# 5.4.0.0
###############################################################################
# This profile contains setup information for the two components of
# Tivoli Storage Manager for Advanced Copy Services
#
# Data Protection for FlashCopy Devices for mySAP(R)
# Data Protection for N Series Snapshot for mySAP(R)
#
# hereafter collectively DP for Snapshot Devices.
# Unless otherwise stated, the term "FlashCopy" also applies to snapshots
# taken on N series devices.
#
# File name: initSID.fcs
#
# Directory: /db2/<SID>/dbs
# where <SID> stands for the DB2 System ID used.
# In mySAP(R) environments, 3 character System IDs are
# used. In the sample, D01 is used as the System ID.
#
# Usage :
# Whenever DP for FC will be used, a profile has to be passed
# along with the DP for Snapshot Devices command tdphdwdb2
# as the value of the -p parameter,
# for example:
#
# tdphdwdb2 -f xxxxxx -p /db2/<SID>/dbs/init<SID>.fcs
#
# where xxxxxx stands for a function of DP for Snapshot Devices
# (backup, flashcopy, restore, unmount, inquire,
# configure, query, withdraw or withdraw_force) being performed by tdphdwdb2.
#
#
# With the product deliverables, you get the sample file
# initSID.fcs. If you have not used the install script,
# rename it to $INSTHOME/dbs/init$DB2DBDFT.fcs,
# where $INSTHOME is the home directory of the DB2 instance.
#
# In the sample the name /db2/D01/dbs/initD01.fcs is used.
#
#
# Rules for the profile setup must be followed as shown:
# - Directory names and files names are case sensitive
# - All directories and file names must be available
# via NFS mounts on the production (here: columbus)
# or backup system (here: magellan)

# Any comments must start with the character # in column 1.
#
# Tabs should not be used.

# Layout of the profile
# The profile is divided into topics. The present
# release contains the following topics:
# global
# DB2
# copyservices_data
# Each topic has a unique set of specific parameters, of which
# some are required and some will default to a value.
# Each topic is enclosed by a topic begin statement (>>>) and a
# topic end statement (<<<) followed by the topic name separated
# by a blank character.
#
# Topic and parameter names are not case sensitive. By convention,
# topic names are shown in lowercase and parameters in uppercase.
#
# Parameters of the global topic
Samples

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>>> global

#------------------------------------------------------------------#
# LOGON_HOST_PROD
# Defines the parameters needed to reach the production system
# on which the mySAP(R) database server is running.
#
# The syntax with 2 parameters is :
#
# LOGON_HOST_PROD tcp_name userid
#
# where tcp_name is the TCP/IP name or the dot address under
# which the production system can be reached
# (here called columbus_et)
#
# userid is the DB2 userid db2<sid> (here called db2d01)
# which the mySAP(R) DBA tools will work with.
# The password for this userid has to be provided
# - once DP for Snapshot Devices has been installed - using
# the password function of DP for Snapshot Devices and will be
# encrypted and stored in the file specified in
# CONFIG_FILE.
#
#
#
# The following syntax with 3 parameters (introduced with 1.1.0.3) is
# still supported, but the first parameter is no longer checked.
#
# LOGON_HOST_PROD hostname tcp_name userid
#
# where hostname is the host name (result of hostname command)
# of the production system (here called columbus).
# tcp_name is the TCP/IP name or the dot address of the
# production system.
# (here called columbus_et)
# userid is the DB2 userid db2<sid> (here called db2d01)
# which the mySAP(R) DBA tools will work with.
# The password for this userid has to be provided
# - once DP for Snapshot Devices has been installed - using
# the password function of DP for Snapshot Devices and will be
# encrypted and stored in the file specified in
# CONFIG_FILE.
#
# Parameter definition is required.
#------------------------------------------------------------------#
LOGON_HOST_PROD columbus db2d01

#------------------------------------------------------------------#
# LOGON_HOST_BACK
# Defines the host name of the backup system (as a result of the
# hostname command) on which DP for Snapshot Devices (tdphdwdb2)
# will be started with a FlashCopy request.
# (here called magellan)
#
# Once the task for this request has finished, tdphdwdb2 will
# start the backup on the backup system by calling
# Data Protection for mySAP(R).
#
#------------------------------------------------------------------#
LOGON_HOST_BACK magellan

#------------------------------------------------------------------#
# BACKUP_MAX
# Defines the number of backup cycles kept in the directory of the
Samples
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# IDS_CONTROL_FILE path; if BACKUP_MAX is reached,
# the logs and traces belonging to a backup cycle will also be
# deleted (see also LOG_TRACE_DIR).
#
# Parameter definition is optional.
# Default: 30
#------------------------------------------------------------------#
BACKUP_MAX 30

#------------------------------------------------------------------#
# IDS_CONTROL_FILE
# Defines the file which contains the summary information
# of such a backup cycle entry. DP for Snapshot Devices will create an entry
# in this file each time it starts a FlashCopy.
#
# This file must be reachable via an NFS setup from the production
# and backup systems.
# In the sample, /db2/D01/dbs is already available
# as an NFS directory.
#
#------------------------------------------------------------------#
IDS_CONTROL_FILE /db2/D01/dbs/save/idssave

#------------------------------------------------------------------#
# CONFIG_FILE
# Defines the file which contains the information required
# when the backup system needs to work with other hosts
# like the production system.
#
# The file will be created by calling the configure function of
# DP for Snapshot Devices, once it had been installed, and each time the
# password of the db2<sid> user (here in our sample db2d01) or
# the password for the CIM agent user has been changed.
#
#
#------------------------------------------------------------------#
CONFIG_FILE /db2/D01/dbs/initD01.fcp

#------------------------------------------------------------------#
# WORK_DIR
# Specifies the directory where temporary files will be written
# by DP for Snapshot Devices.
#
#------------------------------------------------------------------#
WORK_DIR /db2/D01/dbs/work

#------------------------------------------------------------------#
# TRACE
# Controls the generation of a trace file.
# Note: We recommend using the trace function
# - at implementation time and
# - in cooperation with the hotline
Samples

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#
# Possible parameter values : YES or NO
#
# Default : YES
#------------------------------------------------------------------#
TRACE YES

#------------------------------------------------------------------#
# LOG_TRACE_DIR
# Specifies the directory for log and trace files to be written
# by DP for Snapshot Devices.
# Trace files will be written to this directory if YES is
# specified in the TRACE parameter.
#
#
# Default : if not specified, logs and traces will be written to the
# directory specified as the WORK_DIR parameter.
#------------------------------------------------------------------#
LOG_TRACE_DIR /db2/D01/dbs/logtraces

#------------------------------------------------------------------#
# TDPR3_CONFIG_FILE
# Specifies the name of the DP for mySAP(R) for DB2 UDB
# configuration profile.
# For more information about this profile see Data Protection
# for mySAP(R) Installation and Users Guide for DB2 UDB.
#
#
#------------------------------------------------------------------#
TDPR3_CONFIG_FILE /db2/D01/dbs/initD01.utl

#------------------------------------------------------------------#
# SUPPORT_ADMIN_ASSISTANT
# Defines whether DP for Snapshot Devices sends its log records to
# the DP for mySAP Administration Assistant.
# For proper setup of the Administration Assistant see the
# DP for mySAP Installation and Users Guide
#
# If you specify YES, you must set up PROLE_SERVICE_NAME if a service
# name other than the default was defined at installation time.
#
# Possible parameter values : YES or NO
#
# Default : NO
#------------------------------------------------------------------#
SUPPORT_ADMIN_ASSISTANT NO

#------------------------------------------------------------------#
# PROLE_SERVICE_NAME
# This parameter specifies the service name with which DP for Snapshot
# Devices communicates with the DP for Snapshot Devices acsprole
Samples
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# process to launch the DP for Snapshot Devices splitint process
# on the production system and to provide information to the
# Administration Assistant. The service name is defined by
# DP for Snapshot Devices at installation time in /etc/services.
#
# Default value: tsmacsdb2
#------------------------------------------------------------------#
# PROLE_SERVICE_NAME tsmacsdb2

#------------------------------------------------------------------#
# COPYSERVICES_HARDWARE_TYPE
# specifies the type of disk subsystem to be used
#
# Supported values : ESS800 or SVC or DS6000 or DS8000 or SAN_NSERIES
#
#------------------------------------------------------------------#
COPYSERVICES_HARDWARE_TYPE DS8000

#------------------------------------------------------------------#
# LVM_FREEZE_THAW
# Specifies whether a freeze will be performed prior to taking
# the FlashCopy/snapshot and a thaw operation afterward. Under AIX
# it only takes effect for JFS2 file systems
#
# Supported values: YES or NO
#
# Default: NO
#------------------------------------------------------------------#
# LVM_FREEZE_THAW NO

#------------------------------------------------------------------#
# LVM_FREEZE_TIMEOUT
# If LVM_FREEZE_THAW is set to YES, specifies the maximum amount
# of time (in minutes) the file system will remain frozen. This
# ensures that the file systems do not remain frozen indefinitely.
#
#
# Default: 12
#------------------------------------------------------------------#
# LVM_FREEZE_TIMEOUT 12

#------------------------------------------------------------------#
# SNAPSHOT_POLICY
# For an N series configuration, determines whether a fixed number
# of snapshots will be kept (VERSIONING) or whether the number is
# based on the free space provided in the volumes (ADAPTIVE).
# If VERSIONING is selected, the number of snapshots is defined by
# the MAX_VERSIONS parameter.
# If ADAPTIVE is specified, and a failure occurs due to lack of
# space, the earliest snapshot will be deleted until sufficient
# space is available. The user can therefore indirectly control
# the number of snapshots by assigning the amount of space to be
# used for them.
#
# Default: VERSIONING
#------------------------------------------------------------------#
# SNAPSHOT_POLICY VERSIONING

#------------------------------------------------------------------#
# MAX_VERSIONS
# For an N Series configuration, this parameter specifies the maximum
# number of snapshot versions to be maintained if SNAPSHOT_POLICY
Samples

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# has the value VERSIONING. When this limit is reached, the oldest
# snapshot is deleted.

# Default: 256
#------------------------------------------------------------------#
# MAX_VERSIONS 10

<<< global

# Parameters of the DB2 topic
>>> db2
#------------------------------------------------------------------#
# DB2_REMOTE_DBALIAS
# Specifies the database alias on which the DB2 remote database is
# cataloged on the backup system. The remote database aliasname
# will be cataloged on the remote node REM<SID> (in the sample
# the remote node is REMD01).
# For more information see Configuring DP for Snapshot Devices on the backup
# System (setupDB2BS).
#
#------------------------------------------------------------------#
DB2_REMOTE_DBALIAS R_D01

#------------------------------------------------------------------#
# DB2_RECOVERY_LOG
# Specifies the name of the DP for mySAP(R) for DB2 UDB recovery
# logfile. DP for mySAP(R) writes all information of backups in this
# file.
# For more information about this file see Data Protection
#
#------------------------------------------------------------------#
DB2_RECOVERY_LOG /db2/D01/dbs/tdplog/tdprlf.D01.NODE0000.log

#------------------------------------------------------------------#
# DB2_TDPR3_LIB
# Specifies the name of the DP for mySAP(R) for DB2 UDB vendor
# library which is called by the db2 backup and db2 restore commands.
# For more information about the vendor library see Data Protection
#
#------------------------------------------------------------------#
DB2_TDPR3_LIB /usr/tivoli/tsm/tdp_r3/db264/libtdpdb264.a

#------------------------------------------------------------------#
# DB2_PARALLELISM
# Determines the number of tablespaces which can be read in parallel
# by the DB2 backup utility.
# For more information about this parameter see backup command in
# the DB2 Command Reference guide.
#
# Possible parameter values : # of parallel DB2 processes to read
# data from tablespaces at a db2 backup
# and db2 restore
#
# Default : 1
#------------------------------------------------------------------#
DB2_PARALLELISM 1
Samples
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#------------------------------------------------------------------#
# DB2_NUM_BUFFERS
# The number of buffers to be used for db2 backup and db2 restore
# commands. When creating a backup to multiple locations, a larger
# number of buffers may be used to improve performance.
# For more information about this parameter see backup and restore
# commands in the DB2 Command Reference guide.
#
# Possible parameter values : # of buffers to be used for db2
# backup and db2 restore
#
# Default : 2
#------------------------------------------------------------------#
DB2_NUM_BUFFERS 2

#------------------------------------------------------------------#
# DB2_BUFFER_SIZE
# The size, in 4-KB pages, of the buffer used when building the
# db2 backup image and restoring a backup image.
# The minimum value for this parameter is 8 pages; the default
# value is 1024 pages. If a buffer size of zero is specified, the
# value of the database manager configuration parameter <backbufsz>
# will be used as the buffer allocation size.
# For more information about this parameter see backup and restore
# commands in the DB2 Command Reference guide.
#
# Possible parameter values : <size> in 4-KB pages of the buffer
# for db2 backup and db2 restore
#
# Default : 1024
#------------------------------------------------------------------#
DB2_BUFFER_SIZE 1024

#------------------------------------------------------------------#
# DB2_AUTHENTICATION

# Authentication methods for the DB2 database server
#
# Access to a DB2 instance or DB2 database first requires that the user be authenticated.
# The authentication type for each instance determines how and where a user
# will be verified. The authentication type is stored in the database manager
# configuration file at the server.
#
# The following authentication types are provided:
#
# SERVER
# Specifies that authentication occurs on the server using local operating
# system security. This is the default security mechanism.
#
# SERVER_ENCRYPT
# Specifies that the server accepts encrypted SERVER authentication schemes.
#
# CLIENT
# Specifies that authentication occurs on the database partition where
# the application is invoked using operating system security
#
# If you change the DB2_AUTHENTICATION method, you must uncatalog the
# DB2 aliases (R_<SID>, R_<SID>_<NN>) on the backup system. On the
# next FlashCopy or snapshot run, all DB2 aliases will be re-cataloged
# with the new DB2_AUTHENTICATION method.
#
# Default value: SERVER
Samples

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#
# This parameter is optional.
#
#------------------------------------------------------------------#
# DB2_AUTHENTICATION SERVER

#------------------------------------------------------------------#
# DB2_RESTART_TSM_BACKUP
# This parameter must be specified to enable the function restart_backup.
# If this parameter is set to YES, then a FlashCopy Backup (with function -f
# backup) will no longer be automatically unmounted/withdrawn if the TSM backup
# fails for one (or more) DB2 partitions. With the filesystems left mounted
# on the backup system, customers can then investigate the reason for the failed
# TSM backup. When the problem has been resolved, the TSM backup of the failed
# DB2 partitions can be restarted.
#
# Default value: NO
#------------------------------------------------------------------#
# DB2_RESTART_TSM_BACKUP NO

<<< db2

# Parameters of the copyservices_data topic
#------------------------------------------------------------------#
# The copyservices_data topic contains all the parameters
# required to let DP for Snapshot Devices use the CIM agent or N series API
# to request FlashCopy, withdraw, inquire and query
# operations on the storage box cluster in which the
# volumes of interest reside.
#
# To access the storage box via the CIM agent or N series API, a username and password
# are required. You will get the username and the password from the storage
# administrator, who likely has also set up for you the source volumes
# to allow you to install mySAP(R) with a DB2 DB. You also need the target
# volumes to store a FlashCopy backup.
# For N series, the target volumes are assigned automatically.
#
# The password for this username has to be provided - once
# DP for Snapshot Devices has been installed - using the password function
# of DP for Snapshot Devices and will be encrypted and stored in the file
# specified in CONFIG_FILE (see above).
#------------------------------------------------------------------#

#------------------------------------------------------------------#
# PRIMARY_COPYSERVICES_SERVERNAME
# Defines the TCP/IP address of the host running the CIM Agent
# (or the SVC master console) or of the filer for N series.
#
#------------------------------------------------------------------#
PRIMARY_COPYSERVICES_SERVERNAME 174.31.1.3

#------------------------------------------------------------------#
# COPYSERVICES_SERVERPORT
# Defines the port number of the CIM agent that can
# access the copy services of the storage box.
#
# Default: 5988
#------------------------------------------------------------------#
COPYSERVICES_SERVERPORT 5988

#------------------------------------------------------------------#
Samples
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# BACKUP_COPYSERVICES_SERVERNAME
#
# Reserved for future use
#------------------------------------------------------------------#
# BACKUP_COPYSERVICES_SERVERNAME 174.31.1.4

#------------------------------------------------------------------#
# COPYSERVICES_USERNAME
# username which was set up by the CIM agent to access the
# storage box, or (for N series) the NetApp user name assigned to
# access the filer via the API.
#
#------------------------------------------------------------------#
COPYSERVICES_USERNAME superuser

#------------------------------------------------------------------#
# COPYSERVICES_TIMEOUT
# Defines the maximum amount of time (in minutes) the CIM Client
# will wait for the response to a call issued to the CIMOM
# (CIM Agent). If the CIM Client does not receive a response within
# this time, DP for Snapshot Devices will issue a timeout error message.
#
# Default: 12
#------------------------------------------------------------------#
# COPYSERVICES_TIMEOUT 12

#------------------------------------------------------------------#
# COPYSERVICES_COMMPROTOCOL
# Defines the protocol to be used for communication between Data
# Protection for Snapshot Devices and the CIM Agent.
#
# Supported values: HTTP or HTTPS
#
# Default: HTTP
#------------------------------------------------------------------#
# COPYSERVICES_COMMPROTOCOL HTTP

#------------------------------------------------------------------#
# COPYSERVICES_CERTIFICATEFILE
# If COPYSERVICES_COMMPROTOCOL is set to HTTPS, defines the fully
# qualified certificate file name, or NO_CERTIFICATE to select
# null trust provider mode. Use of NO_CERTIFICATE is recommended
# only when both the production and backup systems, as well as
# the storage system, are protected by a firewall.
#
# Supported values: file name or NO_CERTIFICATE
#
# Default: NO_CERTIFICATE
#------------------------------------------------------------------#
# COPYSERVICES_CERTIFICATEFILE NO_CERTIFICATE

#-----------------------------------------------------------------#
# FLASHCOPY_TYPE
# Defines the type of FlashCopy type to be performed: NOCOPY, COPY or
# INCR. For the copy services provided by the SAN VC, the value INCR
# (incremental) is not supported.
# For N series, only the COPY option is supported.
#
# Default: COPY
#------------------------------------------------------------------#
FLASHCOPY_TYPE COPY

Samples

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#------------------------------------------------------------------#
# VOLUMES_FILE
# Defines the fully qualified file name containing a list of
# at least the target volumes.
# This file must be reachable via the NFS setup.
#
# To distinguish this from other profiles and control files,
# define the character string fct as the name suffix.
#
# Parameter definition is required only for FlashCopy devices.
# N series devices determine the target volumes automatically when
# a snapshot is requested.
#------------------------------------------------------------------#
VOLUMES_FILE /db2/D01/dbs/initD01.fct

#------------------------------------------------------------------#
# SVC_COPY_RATE
# Effective only if the parameter COPYSERVICES_HARDWARE_TYPE is set to the
# value SVC.
# The copy rate specifies the priority that the SVC will assign to the
# FlashCopy background process. A value of 100 is the highest,
# a value of 0 means that there is no background copy process.
#
# Default:
# 100 if FLASHCOPY_TYPE is COPY
# 0 if FLASHCOPY_TYPE is NOCOPY.
#------------------------------------------------------------------#
#SVC_COPY_RATE 100

<<< copyservices_data
Sample DP for FlashCopy Target Volumes File (ESS or DS
Configuration)
The following three samples illustrate the same environment setup. It is clear that
the first one is the most convenient to implement.
#=====================================================================#
#===
#=== This file contains setup information about source/target volumes
#=== as they will be used in the flashcopy function.
#===
#=== The file will be pointed to by the file name specified
#=== in the VOLUMES_FILE parameter of the
#=== Data Protection for FlashCopy profile
#=== (if standard naming conventions have been used then
#=== this would be /db2/<SID>/dbs/init<SID>.fcs)
#===
#=== It is required to embed the TARGET_VOLUME parameter
#=== between the topic start parameter (>>> volumes_set_x)
#=== and topic end parameter (<<< volumes_set_x) where x
#=== indicates the target volume set you would like to use.
#===
#===
#=== Example:
#=== File name (suggested) : init<SID>.fct
#=== Directory (suggested) : /db2/<SID>/dbs
#===
#=== ATT: on the parameter statement TARGET_VOLUME
#=== 1st value is target_volume_serial_number
#=== 2nd value is source_volume_serial_number or -
#=== 3rd value is Size=2.0_GB or -
#===
#=== If you specify source volume serial number and size,
#=== you must ensure the target volume size is the same.
Samples
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#===
#=== A target volume must be available in the same hardware unit in
#=== which the source volume is accessed.
#=====================================================================#

#
#*************************** first sample ****************************#
#

>>> volumes_set_1
#=====================================================================#
# For e a c h target volume which is planned to be used in the
# FlashCopy operation the volume serial number must be specified as
# the 1st parameter followed by - -
# The characters - will be filled up with a (source) volume serial
# number and the Size found for that source volume (if the size matches
# that of the target volume) by DP for FlashCopy once the flashcopy function
# has been started on the backup system and identified all (source)
# volumes on the production system.
#
#
# Replace all statements below with your installation values.
#
# Definition is required for each target volume.
#=====================================================================#
<<< volumes_set_1

#=====================================================================#

#
#************************** second sample ****************************#
#

#=====================================================================#

>>> volumes_set_1
TARGET_VOLUME 11815089 11C15089 -
TARGET_VOLUME 11915089 11D15089 -
TARGET_VOLUME 11A15089 11E15089 -
TARGET_VOLUME 11B15089 11F15089 -
TARGET_VOLUME 41015089 41515089 -
TARGET_VOLUME 41115089 41415089 -
<<< volumes_set_1

#=====================================================================#

#
#*************************** third sample ****************************#
#

#=====================================================================#

>>> volumes_set_1
TARGET_VOLUME 11815089 11C15089 Size=6.1_GB
TARGET_VOLUME 11915089 11D15089 Size=6.1_GB
TARGET_VOLUME 11A15089 11E15089 Size=6.1_GB
Samples

TARGET_VOLUME 11B15089 11F15089 Size=6.1_GB
TARGET_VOLUME 41015089 41515089 Size=1.2_GB
<<< volumes_set_1
Sample DP for FlashCopy Target Volumes File (SVC Configuration)
The following three samples illustrate the same environment setup. It is clear that
the first one is the most convenient to implement.
#=====================================================================#
#===
#=== as they will be used in the flashcopy function.
#===
#=== in the VOLUMES_FILE parameter of the
#=== Data Protection for FlashCopy profile
#=== (if standard naming convention have been used then
#===
#=== It is required to embed the TARGET_VOLUMES parameter
#=== between the topic start parameter (>>>volumes_set_x)
#=== and topic end parameter (<<<volumes_set_x) where x should
#=== indicate the target volume set you would like to use.
#===
#===
#=== Example:
#===
#=== 1st value is target_volume virtual disk name
#=== 2nd value is source_volume virtual disk name or -
#===
#=== If you specify source volume name and size,
#===
#=== A target volume must be available in the same SVC cluster in
#=====================================================================#

#
#*************************** first sample ****************************#
#

>>> volumes_set_1
#=====================================================================#
# FlashCopy operation the virtual disk name must be specified as
# The characters - will be filled up with a (source) volume name
# and the Size found for that source volume (if the size matches
#
#
#
# Definition is required for each target volume.
#=====================================================================#
TARGET_VOLUME cluster1 - -
Samples
<<< volumes_set_1

#=====================================================================#

#
#************************** second sample ****************************#
#

#=====================================================================#

>>> volumes_set_1
TARGET_VOLUME cluster1 svdfsrc1 -
TARGET_VOLUME svdftgt1 svdrsrc2 -
TARGET_VOLUME svdftgt2 svdfsrc3 -
<<< volumes_set_1

#=====================================================================#

#
#*************************** third sample ****************************#
#

#=====================================================================#

>>> volumes_set_1
TARGET_VOLUME cluster1 svdfsrc1 Size=6.1_GB
TARGET_VOLUME svdftgt1 svdrsrc2 Size=6.1_GB
<<< volumes_set_1
Sample for Defining a DP for FlashCopy Target Volumes File (Mirror
Setup, ESS or DS Configuration)
The following sample illustrates the setup of a DP for FlashCopy target volumes
file as it is required to run the FlashCopy Backup once with the AIX LVM mirrors
set up in the ESS unit 13158 (see the definition in the volumes_set_1 topic) and
for another FlashCopy backup run with the mirrors set up in the ESS unit 12067
(see the definition in the volumes_set_2 topic).
The two copy sets of LVs have been set up according to the requirements for
setting up a copy set (see Chapter 8, DP for Snapshot Devices Functionality for
AIX LVM Mirrored Environments, on page 161); this means 2 ESS units are
needed. Only one of the 3 parameter setup possibilities for the parameter
TARGET_VOLUME will be used in this sample:
#-----------------Begin of sample setup file -----------------------
#===
#=== as they will be used in the FlashCopy function.
#===
Samples

#=== in the VOLUMES_FILE parameter of the DP for FlashCopy profile
#=== (if standard naming convention have been used then
#===
#=== It is required to embed the TARGET_VOLUME parameters
#=== between the topic start parameter (>>>volumes_set_x)
#=== and topic end parameter (<<<<<volumes_set_x) where x should
#=== indicate the target volume set you would like to use.
#===
#=== Example:
#===
#=== 1st value is target_volume_serial_number
#=== 2nd value is source_volume_serial_number or -
#===
#=== If you specify source volume serial number and size,
#===
#=== A target volume must be available in the same hardware unit in
#------------------------------------------------------------------#

>>> volumes_set_1
#------------------------------------------------------------------#
# HARDWARE_ID_LVM_MIRROR
# Defines in an AIX LVM Mirror environment the hardware unit which
# contains a complete set of at least 1 copy of all DB LVs
# which are to be the object of the backup process.
# Only the source volumes of the specified unit will be used
# on the production system by DP for FlashCopy for the flashcopy process.
#
# Possible parameter values : XXXXX
# where XXXXX is the 5 digit hardware unit number.
#
# Parameter definition can o n l y be used if an appropriate
# setup has been done as defined in the DP for FlashCopy manual.
#
# DEFAULT : NOT DEFINED
#
#------------------------------------------------------------------#

#------------------------------------------------------------------#
#
# FlashCopy operation the volume serial number must be specified as
# The characters - will be filled up with a (source) volume serial
# number and the Size found for that source volume (if the size matches
#
#
#
#------------------------------------------------------------------#

Samples
<<< volumes_set_1

>>> volumes_set_2
TARGET_VOLUME 65F12067 - -
<<< volumes_set_2

#-----------------End of sample setup file ----------------------

The above definitions will have been updated by DP for FlashCopy
once 2 flashcopy backups - one with the copyset as defined in
volumes_set_1 and one with the copyset as defined in
volumes_set_2 - have been completed to :

>>> volumes_set_1
TARGET_VOLUME 40A13158 40713158 Size=5.0_GB
TARGET_VOLUME 40B13158 40813158 Size=5.0_GB
TARGET_VOLUME 50A13158 50713158 Size=5.0_GB
TARGET_VOLUME 50B13158 50813158 Size=5.0_GB
<<< volumes_set_1
>>> volumes_set_2
TARGET_VOLUME 65F12067 63F12067 Size=5.0_GB
TARGET_VOLUME 66B12067 66A12067 Size=1.5_GB
<<< volumes_set_2
Sample DP for mySAP Installation and Customization
Prerequisites to be Checked on the Production System
It is assumed that the following products have already been installed:
v Tivoli Storage Manager Clients (Backup/Archive Client for file system backups,
API Client for interface programs)
v mySAP, DB2, and mySAP Database Utilities
If not, you should first install the above products.
Samples

Installation/Customization of DP for mySAP on the Production System
1. Follow the steps as they are shown in Installation on AIX in the Data
At the end of this installation, you will have a profile init<SID>.utl in the
directory /db2/<SID>/dbs. This directory will be used (due to the NFS setup) on
the production and backup systems.
2. In our sample environment, this profile was customized as shown in Sample
DP for mySAP Profile on page 239. We are using password control with DP
for mySAP. Be aware that you should at this point initialize the CONFIG file of
DP for mySAP:
a. Log in as db2<sid> on the production system
b. /usr/tivoli/tsm/tdp_r3/db264/backom -c password -e <profile>
where in the sample configuration the -e parameter would have the profile
value
/db2/D01/dbs/initD01.utl
(see Sample DP for mySAP Profile on page 239).
3. You can now run all mySAP DBA utilities on the production system.
Prerequisites to be Checked on the Backup System
It is assumed that the following products have already been installed:
v Tivoli Storage Manager Clients (Backup/Archive Client for file system backups,
API Client for interface programs)
v DB2 UDB
If not, you should first perform the installation; otherwise the DP for mySAP
installation cannot be performed properly.
Installation/Customization of DP for mySAP on the Backup System
Make sure you have the NFS export done on the production system for the
directory
/db2/<SID>/dbs
so you can share all profiles and log files between the production and backup
systems. This directory will be used (due to the NFS setup) on the production and
backup systems.
Check for the existence of /db2/<SID>/dbs/init<SID>.utl
v Detailed steps regarding installation are shown in the section Installation on
AIX in Data Protection for mySAP Installation and Users Guide for DB2 UDB.
At the end of the installation, you should see the proper profile init<SID>.utl
in the directory /db2/<SID>/dbs, since it was created/customized during the
installation/customization on the production system.
v Because we are using (see Sample DP for mySAP Profile on page 239)
password control with DP for mySAP and have already initialized the CONFIG
file of DP for mySAP, we are ready to use DP for mySAP at this point.
You can now run the DP for mySAP functions backup, inquire, restore, password.
However, calling the db2 backup command will fail because the FlashCopy target
volumes, and thus the DB2 database file systems, are not yet available on the
backup system. Running a tdphdwdb2 backup is required to get the target volumes
(as a copy of the source volumes on the production system).
Samples
However, at this point, you should first install/customize the DP for Snapshot
Devices product to be able to perform the FlashCopy (see Chapter 3, Installing
and Customizing DP for Snapshot Devices, on page 43). A sample DP for
Snapshot Devices installation is described in the following section.
Sample DP for Snapshot Devices Installation and Customization
The purpose of this sample is to show in summary form, with focus on DP for
Snapshot Devices, all the steps needed to be able to run a FlashCopy
41
backup.
In this sample, the following values were selected for the DP for Snapshot Devices
installation and customization. These values must be adapted according to your
environment:
db2d01
msSAP DB administrator user ID
D01 mySAP SID and database name
columbus
TCP/IP name of the production system running the DB2 RDBMS.
magellan
Hostname of the backup system running tdphdwdb2.
/db2/D01/dbs
Directory of columbus (hostname of production system) available to
magellan via NFS.
Only a few steps are necessary to install and customize DP for Snapshot Devices.
Prior to this work, we:
v ensured that all prerequisite products were installed and customized and the
storage system was set up to support tdphdwdb2 FlashCopy backup requests
using FlashCopy source/target volumes.
v ensured that at this point on our production system db2 backup and brarchive,
in concerted interaction with DP for mySAP, could run backups of the DB2
database and log files.
v verified that the NFS setup for the environment existed as documented.
Installation and Customization for DP for Snapshot Devices on the Production
System
v Followed
42
all steps as shown in Chapter 3, Installing and Customizing DP for
Snapshot Devices, on page 43, running with the user ID root.
The following steps were done with user ID db2d01:
v Customized the DP for Snapshot Devices profile (/db2/D01/dbs/initD01.fcs),
which we got from the previous step.
v Updated
42
the PATH environment variable with /usr/sbin; using the Korn shell
with user ID db2d01, we inserted in the /db2/D01/.profile:
PATH=${PATH}:/usr/sbin
export PATH
v Initialized the CONFIG_FILE on the production system (columbus) by running
tdphdwdb2 -f configure -p /db2/D01/dbs/initD01.fcs
41. In SAP R/3 documentation, normally called a split-mirror disk backup.
42. This work was done on both the production (columbus) and backup (magellan) systems.
Samples

and also entered the passwords for
the AIX user ID db2d01
the ESS username
when prompted. The prompted user ID and user name were taken from the
fields specified in the parameters LOGON_HOST_PROD and
COPYSERVICES_USERNAME previously defined in the DP for Snapshot
Devices profile.
At this point, DP for Snapshot Devices was now ready for use on the production
system.
Continuation on the Backup System (magellan)
v As user root ran the script setupDB2BS with:
/usr/tivoli/tsm/tdpessr3/db2/setupDB2BS D01 columbus
v Started the first backup with tdphdwdb2, which completed successfully:
cd /db2/D01/dbs
./tdphdwdb2 -f backup -p /db2/D01/dbs/initD01.fcs
v Copied the sample script backup_flashcopy.ksh to/db2/D01/sapscripts and
made sure to change the SIDs.
v Added a schedule to the crontab to run regular backups using the script
backup_flashcopy.ksh, in order to also cover certain unplanned restart
conditions.
Sample tdphdwdb2 Usage
The following samples are intended to demonstrate
v in which sequence the functions of DP for Snapshot Devices can be used
v in which situations tdphdwdb2 requests might fail and what can be done to
resolve such a situation or to avoid it.
Case 1: Backup with Target Withdrawal in tdphdwdb2 Run
This sample demonstrates the request for a backup of the database and
withdrawing the target volumes within the tdphdwdb2 run.
Command:
tdphdwdb2 -f backup -p /db2/<SID>/dbs/init<SID>.fcs
where FLASHCOPY_TYPE is set to NOCOPY.
Result:
Backup from FlashCopy target volumes will be done within the tdphdwdb2 call.
After the completion of the FlashCopy, tdphdwdb2 will request DP for mySAP to
perform the backup of the DB2 DB files residing on the target volumes.
As a consequence of this setup (no delay), the file systems used will be
immediately unmounted after the backup is completed, and the FlashCopy
relationship between the source and target volumes will be withdrawn.
Note: FLASHCOPY_TYPE NOCOPY caused the DP for Snapshot Devices function
backup to run the DP for Snapshot Devices withdraw function.
Samples
If, during the backup steps of the tdphdwdb2, a reboot (such as required by a power
failure) occurs, you have a situation as described in this case, and it will be
necessary to run the unmount or, better yet, withdraw function as a separate
command, as illustrated in cases 3 and 4.
Case 2: Backup Without Subsequent Unmount or Withdraw
This sample demonstrates the request for a backup of the database without
unmounting the target volumes in or outside of the tdphdwdb2 run.
This case will fail in running a further tdphdwdb2 FlashCopy request. You have
the situation of a run failure due to still mounted file systems on the backup
system.
Command:
tdphdwdb2 -f backup -t flashcopy nounmount nowithdraw
Result:
Successful backup will be done only within the first tdphdwdb2 call. All further
tdphdwdb2 calls will fail (see Table 6 on page 138).
perform the backup. As a consequence of this setup, the first backup cycle will be
left in a PSI_MOUNT_DONE status. All succeeding tdphdwdb2 requests will fail
because the backup system according to the last backup cycle still has a
PSI_MOUNT_DONE status, which means that all file systems of the first backup
request are still mounted on the backup system.
Resolution:
To resolve the current problem, run tdphdwdb2 with the withdraw function (if
FLASHCOPY_TYPE is NOCOPY):
tdphdwdb2 -f withdraw -p /db2/<SID>/dbs/init<SID>.fcs
or with the unmount function (if FLASHCOPY_TYPE is COPY or INCR):
tdphdwdb2 -f unmount -p /db2/<SID>/dbs/init<SID>.fcs
and provide a setup as shown in the ones in cases 1, 3, and 4.
Case 3: Backup with Delayed Withdrawal Outside tdphdwdb2
Run
This sample demonstrates the request for a backup of the database and running
the cleanup action on the backup system (unmounting file systems and
withdrawing the source/target volume relationship) outside the tdphdwdb2 run.
The cleanup action will be done just before the next tdphdwdb2 request is done.
This sample is not suitable if you want to perform the FlashCopy Backup (with
FLASHCOPY_TYPE INCR) for a FlashBack Restore, because it withdraws the
persistent FlashCopy relationship for the database volumes.
Command:
Samples

Instead of initiating the backup request using a simple command line, you could,
in order to work properly with a kind of delayed cleanup of system resources (also
called delayed withdrawal), use a script consisting of two commands such as
tdphdwdb2 -f backup -t flashcopy nounmount nowithdraw
Result:
Backup from the FlashCopy target volumes will be done within the tdphdwdb2 call.
After completion of the FlashCopy, tdphdwdb2 will request DP for mySAP to
perform the backup.
As a consequence of this setup, all file systems will now remain mounted (as the
FlashCopy target volumes, if FLASHCOPY_TYPE COPY or INCR was specified,
are also kept); this could now be used either to
v perform a special recovery process on the backup system, or
v use the FlashCopy target volumes for a recovery process
for the database running on the production system, by means of user-written
procedures.
Note: From a safety aspect, this is not the optimum situation (see Case 4: Backup
with Unmounting of File Systems in tdphdwdb2 Run for resolution).
Running tdphdwdb2 -f withdraw ... just before tdphdwdb2 is a safe way to ensure
that the backup system is not left in a state (such as file systems still mounted or
target volumes still in a source/target volume relationship) which would further
cause tdphdwdb2 -f flashcopy of another, subsequent tdphdwdb2 run to fail because
either the environment of the LVM on the backup system was not reset properly or
the source/target volumes are still in a source/target relationship.
Case 4: Backup with Unmounting of File Systems in tdphdwdb2
Run
unmounting the file systems within the tdphdwdb2 run. This will avoid withdrawal
of FlashCopy target volumes within the tdphdwdb2 run. This can avoid the reuse of
a set of target volumes while another set could be used for the next tdphdwdb2.
Withdrawal will be done just before the next tdphdwdb2 request is done (another
way to establish delayed withdrawal).
This sample is not suitable if you want to perform a FlashCopy Backup (with
FLASHCOPY_TYPE INCR), because it withdraws the persistent FlashCopy
relationship for the database volumes.
Command:
Instead of initiating the backup request by means of a simple command line, you
could, in order to work properly with resynchronization with delay, use a script
consisting of two commands like
tdphdwdb2 -f backup -t flashcopy unmount nowithdraw
Samples
Result:
perform the backup.
As a consequence of this setup, all file systems will now remain unmounted (but
the FlashCopy target volumes are also kept if FLASHCOPY_TYPE was specified as
COPY or INCR); this could now be used to either
v perform a recovery process on the backup system, based on user-written
procedures, or
v use the set of FlashCopy target volumes for a FlashBack Restore of the database
running on the production system.
This will also resolve the safety issue raised in Case 3: Backup with Delayed
Withdrawal Outside tdphdwdb2 Run on page 260.
Using the script as shown in this case will result in some error messages when
trying to unmount the already unmounted file systems, and these can therefore be
ignored. However, it would withdraw any target volumes from a FlashCopy
source/target relationship if there are any at the time a new FlashCopy is planned.
Running tdphdwdb2 -f withdraw ... just before tdphdwdb2 is a safe way to ensure
cause a subsequent tdphdwdb2 -f backup run to fail because either the environment
of the LVM on the backup system was not reset properly or the source/target
volumes are still in the COPY state.
Case 5: FlashCopy with Delayed Withdrawal Outside
tdphdwdb2 Run
This sample demonstrates the request for a disk-only FlashCopy Backup of the
database and running the cleanup action on the backup system (unmounting file
systems), and withdrawing the source/target volume relationship outside the
tdphdwdb2 run. The cleanup action will be done just before the next tdphdwdb2
request is done.
This sample is not suitable if you want to perform a FlashCopy Backup (with
FLASHCOPY_TYPE INCR), because it withdraws the persistent FlashCopy
relationship for the database volumes.
Command:
Instead of initiating the backup request using a simple command line, you could,
in order to work properly with a kind of delayed cleanup of system resources (also
called delayed withdrawal), use a script consisting of three commands such as
tdphdwdb2 f flashcopy -p /db2/<SID>/dbs/init<SID>.fcs
tdphdwdb2 f unmount -p /db2/<SID>/dbs/init<SID>.fcs
Result:
A disk-only backup from the FlashCopy target volumes will be done within the
tdphdwdb2 call. After completion of the FlashCopy, tdphdwdb2 will do the
Samples

cleanup action on the backup system As a consequence of this setup, all file
systems will be unmounted (but the FlashCopy target volumes will be kept); this
could now be used to either
v perform a special recovery process on the backup system, or
v use the FlashCopy target volumes for a FlashBack Restore for the database
Running tdphdwdb2 -f withdraw just before tdphdwdb2 is a safe way to ensure that
the backup system is not left in a state (such as file systems still mounted or target
volumes still in a source/target volume relationship) which would further cause
tdphdwdb2 -f flashcopy of another, subsequent tdphdwdb2 run to fail because
the source/target volumes are still in a source/target relationship.
Case 6: Setup Test with the Query Function
This sample demonstrates how the setup on the production and backup systems
can be tested without impacting the DB2 database running on the production
system.
Command:
On the backup system, start the query function of DP for Snapshot Devices:
tdphdwdb2 -f query -p /db2/<SID>/dbs/init/<SID>.fcs
Result:
The query function of DP for Snapshot Devices stops when
v an erroneous setup condition has been encountered, to allow the system
administrator to resolve the problem, or
v all checks have been performed (for details, see Query Function on page 119).
Note: Be aware that, by design, the use of this function does not cause any file
systems to be mounted (as the flashcopy function of DP for Snapshot
Devices would do).
Case 7: INCR/COPY Backup Run
unmounting the file systems within the tdphdwdb2 run. This will avoid withdrawal
of FlashCopy target volumes within the tdphdwdb2 run. This can avoid the reuse of
a set of target volumes while another set could be used for the next tdphdwdb2.
Unmounting will be done just before the next tdphdwdb2 request.
This is a very fast way to run a FlashCopy backup. In addition, the (incremental)
background copies running in the ESS are expected to run faster than a complete
copy of the source volumes to the target volumes.
Note: Conceptually, the same results could have been obtained if the
FLASHCOPY_TYPE had been COPY.
Command:
Samples
tdphdwdb2 -f backup -t flashcopy unmount nowithdraw
Notes:
1. It is assumed that the FLASHCOPY_TYPE INCR is in effect to do an
incremental backup.
2. The next INCR backup cannot be done before the INCR backup (the
incremental background copies running in the ESS or DS) is completed.
Result:
perform the backup.
the FlashCopy target volumes will be kept because FLASHCOPY_TYPE INCR was
used); this could now be used to either
procedures, or
Running the backup function without any options will result in
v unmounting the file systems and exporting the volume groups on the backup
system after the backup to TSM is finished, if FLASHCOPY_TYPE is set to
COPY or INCR
v unmounting the file systems, exporting the volume groups, and withdrawing the
source/target relationships on the backup system, if FLASHCOPY_TYPE is set to
NOCOPY.
Running tdphdwdb2 -f unmount ... just before tdphdwdb2 is a safe way to ensure
cause tdphdwdb2 -f backup of another, subsequent tdphdwdb2 run to fail because
the source/target volumes are still in the COPY state.
Case 8: INCR/COPY Disk-Only Backup Run
This sample demonstrates the request for a disk-only backup of the database and
running the cleanup action on the backup system (unmounting the file systems)
outside the tdphdwdb2 run. This will avoid withdrawal of FlashCopy target
volumes within the tdphdwdb2 run.
This is a very fast way to run a FlashCopy backup. In addition, the (incremental)
background copies are expected to run faster than a complete copy of the source
volumes to the target volumes.
Note: Conceptually, the same results could have been obtained if the
FLASHCOPY_TYPE had been COPY.
Command:
Samples

tdphdwdb2 -f flashcopy -p /db2/<SID>/dbs/init<SID>.fcs
Notes:
1. It is assumed that the FLASHCOPY_TYPE INCR is in effect to do an
incremental backup.
2. The next INCR backup cannot be done before the INCR backup (the
incremental background copies running in the ESS or DS) has completed.
Result:
After the completion of the FlashCopy, tdphdwdb2 will not request DP for mySAP
to perform a TSM backup.
the FlashCopy target volumes will be kept because FLASHCOPY_TYPE INCR was
used); this could now be used to either
procedures, or
Running tdphdwdb2 -f unmount ... just before tdphdwdb2 is a safe way to ensure
cause ttdphdwdb2 -f backup of another, subsequent tdphdwdb2 run to fail because
the source/target volumes are still in the COPY state.
Case 9: Backup with Multiple Target Sets (Without AIX Mirrors)
This case and Case 10: Backup with Multiple Target Sets (With AIX Mirrors) on
page 267 are samples focusing on the use of multiple target sets within the backup
of a database without and with AIX mirrors on the source volumes, respectively.
This sample demonstrates how you can take advantage of the DP for Snapshot
Devices capability to use more than one target set in your backup strategy working
with a non-mirrored AIX DB setup and thus
v have, for one set of source volumes, different disk-copy backup versions
available, and
v more frequently run the fast disk-only FlashCopy backup in conjunction with
the fast FlashCopy method (INCR) during the day, for example (even at peak
workload hours).
Should a restore (running a FlashBack Restore) with a recovery become necessary,
the overall outage can be drastically reduced. Running a backup more frequently
will mean that the latest backup you can use for a restore now needs much less
database recovery activity. Using the multiple target set capability of DP for
Snapshot Devices thus reduces the restore and recovery times.
Samples
This sample shows different variations for running backups depending on your
specific needs and explains how to initiate the DP for Snapshot Devices
functionality within a backup run using
v specific target selection
v automated target set selection
Assumptions for this sample are:
v During the day, periodically run an INCR disk-only backup. Prior to the first
run, all target sets have the status AVAILABLE (see the ts_inquire command).
v Each day, in the evening hours, a complete DB backup to the TSM server is
planned, but alternately using two sets of target volumes for the disk-copy
backup.
v Only online backups are to be done
v Three target sets are used, assuming the database is spread over 6 source
volumes residing in 4 hardware units (00001, 0002, 0003, 00004). The sample
setup for the DP for Snapshot Devices target volume file (.fct) is shown at the
end of this sample.
Command:
On the backup system, set up the following commands for
v daytime schedule:
tdphdwdb2 -f flashcopy -n 1 -C INCR -p /db2/<SID>/dbs/init<SID>.fcs
v evening schedule:
tdphdwdb2 -f backup -C COPY -p /db2/<SID>/dbs/init<SID>.fcs
Notes:
1. -f flashcopy represents the disk-only backup request, -n 1 will cause the first
target set to be selected from the .fct file, and C determines the flashcopy type
to be used.
2. It is assumed that the daytime schedule (with INCR) is the first one run.
For this sample, the parameter VOLUMES_FILE in the DP for Snapshot Devices
profile /db2/<SID>/dbs/init<SID>.fcs points to /db2/<SID>/dbs/init<SID>.fct
(see the following example), the DP for Snapshot Devices target volumes file.
Each FlashCopy backup run must free up the created file systems and volume
groups at the end of its run (unmount and varyoffvg), so that a new FlashCopy
backup run can be initiated; this is done by specifying the DP for FlashCopy
unmount function. The backup function automatically runs the unmount function.
Note: It is practical to check the tdphdwdb2/splitint results and status of the
backup objects by using either tdphdwdb2 -f restore (and the f menu
option) or tdphdwdb2 -f ts_inquire.
Result:
Running the INCR backup will pick up the first target set (initially with target set
state AVAILABLE ) and reuse it in succeeding daytime backups if the FlashCopy
has terminated. If the background copy of a previous FlashCopy backup has not
terminated, then it will fail; the termination can be checked by running
tdphdwdb2 -f restore -p /db2/<SID>/dbs/init<SID>.fcs (select f in menu) or
tdphdwdb2 -f ts_inquire -p /db2/<SID>/dbs/init<SID>.fcs
Samples

The status running will change to OK once the FlashCopy has completed.
On the first day, when running the evening backup, DP for Snapshot Devices will
automatically select the second target set; the third target set will be automatically
selected in the next days evening backup and this would in turn go on for the
succeeding runs. Thus, in general, you always have a minimum of two target sets
for a FlashBack Restore, and even three if the backup has completed successfully
by the time you want to start the FlashBack Restore and your disk-copy backup
versions are not affected by the problem that makes a restore necessary.
Note: tdphdwdb2 -f flashcopy specifies the disk-only backup request, and -n x
causes the target set with the target set number x (last part of the target set
topic name, see sample below) to be selected.
Sample DP for Snapshot Devices target volumes file initE01.fct:
# Sample of a fct file (for a AIX LVM setup without AIX mirrors) .
# 3 Targetsets (6 source volumes are spread over 4 hardware units)
# 21D00001,21E00001,21F00001,11D00002,43100003,14E200004)
# A source volume must have a counterpart in the same hardware unit
# for each volume in a target set (ESS microcode level 2.2.0.448 or later)
# The following target volumes are planned to be used:
>>> volumes_set_1
<<< volumes_set_1

>>> volumes_set_2
<<< volumes_set_2

>>> volumes_set_3
<<< volumes_set_3
Case 10: Backup with Multiple Target Sets (With AIX Mirrors)
Case 9: Backup with Multiple Target Sets (Without AIX Mirrors) on page 265
focused on the use of multiple target sets within the backup of a database without
AIX mirrors.
Case 10: Backup with Multiple Target Sets (With AIX Mirrors) demonstrates how
you can take advantage of the DP for Snapshot Devices capability to use more
than one target set in your backup strategy when working with an mirrored AIX
DB setup (as specified in Chapter 8, DP for Snapshot Devices Functionality for
AIX LVM Mirrored Environments, on page 161) and thus
v have different disk-copy backups versions available
Samples
v more frequently run the fast disk-only FlashCopy backup during the day, for
example (even during peak workload hours)
Should a restore (running a FlashBack Restore) with a recovery become necessary,
the overall outage can be drastically be reduced. Running a backup more
frequently will mean that the latest backup you can use for a restore now needs
much less database recovery activity. Using the multiple target set capability of DP
for Snapshot Devices thus reduces the restore and recovery times.
This sample shows different variations for running backups depending on your
specific needs and explains how to initiate the DP for Snapshot Devices
functionality within a backup run using
v specific target selection
v automated target set selection
Note: In the AIX mirrored environment, 2 target sets can be used alternately for an
INCR FlashCopy backup, whereas in the non-mirrored environment (as
shown in Case 9: Backup with Multiple Target Sets (Without AIX Mirrors)
on page 265), besides the n different target sets to be used for a COPY
FlashCopy backup, only one target set for an INCR FlashCopy backup is
possible.
Assumptions for this sample are:
v During the day, periodically run an INCR disk-only backup.
v Each day, during the week in the evening, a complete DB backup to the TSM
server is planned, but alternating between two sets of target volumes for the
diskcopy backup.
v Only online backups are to be done during the week.
v On the weekend, a complete, online DB backup to the TSM server is planned.
v Three target sets are used, assuming one AIX mirror of the database is spread
over 6 source volumes residing in one hardware unit (88888), and the second
AIX mirror of the DB is spread over 6 source volumes residing in another
hardware unit (99999). The sample setup for the DP for Snapshot Devices target
volume file (.fct) is shown at the end of this sample.
v Prior to the first run, all target sets are in the AVAILABLE state (see TS_Inquire
Function on page 126).
Note: The two mirror copies of the logical volumes (LVs) must be set up as
needed to use the DP for Snapshot Devices functionality for AIX mirrored
environments (for details, see Chapter 8, DP for Snapshot Devices
Functionality for AIX LVM Mirrored Environments, on page 161). One AIX
mirror set of the database must reside completely in one hardware unit and
the other AIX mirror set in a second hardware unit.
Command:
On the backup system, set up the following commands for
v daytime schedule (at least 2 for a weekday):
tdphdwdb2 -f flashcopy -C INCR -p /db2/<SID>/dbs/init<SID>.fcs
v evening schedule during the week (Monday through Saturday):
tdphdwdb2 -f backup -C COPY -p /db2/<SID>/dbs/init<SID>.fcs
Samples

Note: tdphdwdb2 -f flashcopy specifies the disk-only backup request. One target
set in the two hardware units will be selected by DP for Snapshot Devices
automatically from the .fct file, and C determines the flashcopy type to be
used.
For this sample, the parameter VOLUMES_FILE in the DP for Snapshot Devices
profile points to initE01.fct (see the following example), the DP for Snapshot
Devices target volumes file.
Each FlashCopy backup run must free up the created file systems and volume
groups at the end of its run (unmount and varyoffvg), so that a new FlashCopy
backup run can be initiated; this is done by specifying the unmount function.
Note: It is practical to check the backup results and status of the backup objects by
using either tdphdwdb2 -f restore (and the f menu option) or splitint with
the function ts_inquire .
Result:
When planning to use the automatic target set selection within DP for Snapshot
Devices, it is important that the initial use of the target sets occur as planned; this
means, in this sample, that at least 2 INCR FlashCopy backups have been executed
prior to running the second COPY FlashCopy backup. Thus, two target sets have
the status IN_USE for INCR backups and the remaining one is then always used
for the COPY FlashCopy backup. Be aware that if a FlashCopy backup is then
started with FlashCopy and a previous backup and/or the background copy
initiated in this run
43
have not terminated, the latest backup started will fail; the
termination can be checked by running
tdphdwdb2 -f restore p ... or
splitint -f ts_inquire -p ...
The status running will change to ok once the FlashCopy has completed.
On the first day, DP for Snapshot Devices when running the evening backup will
automatically select the second target set; the third target will be automatically
selected in the next days evening backup and this would be in turn go on for the
following evenings. Thus, in general, you always have a minimum of two target
sets for a FlashBack Restore, and even three if the background copy has completed
successfully at the time you want to start the FlashBack Restore and the error that
requires a restore is not yet reflected in your disk-copy backup versions.
Sample DP for Snapshot Devices target volumes file initE01.fct:
# Sample of a fct file (for a AIX LVM setup with AIX mirrors).
# 3 Targetsets
# 2*6 source volumes are spread over 2 hardware units(88888,99999):
# mirror1:21188888,30088888,40288888,50088888,60188888,70388888
# mirror2:63199999,63299999,63399999,63499999,63599999,63699999
#
# A source volume must have a counterpart in the same hardware unit
# for each volume in a target set (microcode level 2.2.0.448 or later)
#
# 1 target set is planned to reside in hardware unit 888888
# to be the targets for mirror1 source volumes
43. In case the FLASHCOPY_TYPE is INCR, the background copy usually completes much earlier than the backup itself, especially
when a TSM backup is done to the TSM server as well. In case the FLASHCOPY_TYPE is COPY, then the TSM backup might
have been completed earlier.
Samples
# 2 target sets are planned to reside in hardware unit 999999
# to be the targets for mirror2 source volumes
# The following target volumes are planned to be used:
>>> volumes_set_1
<<< volumes_set_1

>>> volumes_set_2
<<< volumes_set_2

>>> volumes_set_3
<<< volumes_set_3

Samples

Sample tdphdwdb2 FlashCopy Shell Script
The following is a sample shell script for a FlashCopy operation via tdphdwdb2.
This file (backup_flashcopy.ksh) is provided in the DP for Snapshot Devices
installation directory. It illustrates a situation similar to that of Case 3: Backup
with Delayed Withdrawal Outside tdphdwdb2 Run on page 260.
#!/bin/ksh
# ----- -----------------------------------------------------------
# backup_flashcopy.ksh:
# Sample DP for Snapshot Devices for mySAP backup shell script
# ----- -----------------------------------------------------------
# Tasks:
# Invokes Data Protection for FlashCopy for mySAP to
# - perform a w i t h d r a w of the target volumes
# just before the next flashcopy is done
# Invokes the Data Protection for FlashCopy for mySAP (tdphdwdb2)
# in order to
# - perform a f l a s h c o p y of source volumes to
# target volumes using DP for FlashCopy
# - perform a full backup of the DB2 database
# using Data Protection for mySAP
# - unmount, using Data Protection for FlashCopy,
# all filesystems (unmount file systems and export the volume groups)
#
#
# This is an example for a delayed withdraw .
# ----- -----------------------------------------------------------
# The target volumes will not be withdrawn immediately once the
# backup has been completed.
# However, before the next tdphdwdb2 call, it will be ensured that
# any source/target flashcopy relationship will be withdrawn before
# the next flashcopy/backup begins.
#
#------------------------------------------------------------------
# ***** NOTE ***** NOTE ***** NOTE *****
#
# This script is intended only as a model and should be
# carefully tailored to the needs of the specific site.
#
# ***** NOTE ***** NOTE ***** NOTE *****
#------------------------------------------------------------------
#
# For the following examples, the system ID of the DB2 database
# is assumed to be D01.
#
#------------------------------------------------------------------
#
# A full backup of the DB2 database. This includes
# at least files located in the following filesystems:
# /db2/D01/sapdata1
# /db2/D01/sapdata2
# /db2/D01/sapdata3
# /db2/D01/sapdata4
# /db2/D01/sapdata5
# /db2/D01/sapdata6
# /db2/D01/sapdatat
# /db2/D01/db2d01
#
#------------------------------------------------------------------
#
/db2/D01/dbs/tdphdwdb2 -f withdraw -p /db2/D01/dbs/initD01.fcs
#
/db2/D01/dbs/tdphdwdb2 -f backup -t flashcopy unmount nowithdraw
# -p /db2/D01/dbs/initD01.fcs
Samples
Sample tdphdwdb2 EEE FlashCopy Script
The following is a sample shell script for a FlashCopy operation of a DB2 UDB
EEE database via tdphdwdb2 . This file (EEE_flashcopy.ksh ) is provided in the DP
for Snapshot Devices installation directory. It illustrates a situation similar to that
of Case 5: FlashCopy with Delayed Withdrawal Outside tdphdwdb2 Run on
page 262
#!/bin/ksh
#----------------------------------------------------------------
#EEE_flashcopy.ksh:
#Sample DP for Snapshot Devices for mySAP FlashCopy shell script for EEE
#----------------------------------------------------------------
#Tasks:
#Invokes Data Protection for FlashCopy to
#-perform a w i t h d r a w of the target volumes
#just before the next flashcopy is done
#Invokes Data Protection for FlashCopy (tdphdwdb2)
#in order to
#-perform a f l a s h c o p y of the source volumes to
#target volumes using Data Protection for FlashCopy
#Invokes Data Protection for FlashCopy (tdphdwdb2)
#in order to
#-perform a u n m o u n t of the target volumes to
#unmount file systems and export the volume groups
#If the FlashCopy type is set to COPY, this disk backup can be used
#for a later FlashBack restore with DP for Snapshot Devices.
#
#This is an example for a delayed withdraw .
#----------------------------------------------------------------
#The target volumes will not be withdrawn immediately once the
#backup has been completed.
#However, before the next tdphdwdb2 call, it will be ensured that
#any source/target flashcopy relationship will be withdrawn before
#the next flashcopy/backup begins.
#
#------------------------------------------------------------------
#*****NOTE *****NOTE *****NOTE *****
#
#This script is intended only as a model and should be
#carefully tailored to the needs of the specific site.
#
#*****NOTE *****NOTE *****NOTE *****
#------------------------------------------------------------------
#
#For the following examples, the system ID of the DB2 UDB EEE
#database is assumed to be P01. Also the production system consists
#only of on production server with one or more logical EEE partitions.
#The production server is named s1.
#
#------------------------------------------------------------------
#
#A full FlashCopy disk backup of the DB2 UDB EEE database. This includes
#at least files located in the following filesystems:
#/db2/P01/sapdata1
#/db2/P01/sapdata2
#/db2/P01/sapdata3
#/db2/P01/sapdata4
#/db2/P01/sapdata5
#/db2/P01/sapdata6
#/db2/P01/sapdatat
#/db2/P01/db2P01
#
#------------------------------------------------------------------
#
/db2/P01/dbs/tdphdwdb2 -f withdraw -p /db2/P01/dbs/s1/initP01.fcs
Samples

#
/db2/P01/dbs/tdphdwdb2 -f unmount -p /db2/P01/dbs/s1/initP01.fcs
Sample tdphdwdb2 EEE Online/Offline Backup Script
The following is a sample shell script for an online/offline Backup operation of a
DB2 UDB EEE database via tdphdwdb2. This file (EEE_OnlineOfflineBackup.ksh ) is
provided in the DP for Snapshot Devices installation directory.
#!/bin/ksh
#----------------------------------------------------------------
#EEE_OnlineOfflineBackup.ksh:
#Sample DP for Snapshot Devices for mySAP FlashCopy shell script for EEE
#----------------------------------------------------------------
#Tasks:
#Invokes Data Protection for FlashCopy to
#-perform a b a c k u p of the production database
#This script must be called on the production system.
#
#----------------------------------------------------------------
#*****NOTE *****NOTE *****NOTE *****
#
#This script is intended only as a model and should be
#carefully tailored to the needs of the specific site.
#
#*****NOTE *****NOTE *****NOTE *****
#------------------------------------------------------------------
#
#For the following examples, the system ID of the DB2 UDB EEE
#database is assumed to be P01. Also the production system consists
#only of on production server with one or more logical EEE partitions.
#The production server is named s1.
#You have to change the type of the backup from online to offline,
#if you want to perform an offline backup.
#
#------------------------------------------------------------------
#
/db2/P01/dbs/tdphdwdb2 -f backup t online -p /db2/P01/dbs/s1/initP01.fcs
Sample DP for Snapshot Devices Scripts for HACMP Environments
The following sample shell scripts shows an sample for the integration of the DP
for Snapshot Devices socket server configuration in the HACMP start- and
stop-scripts for the mySAP central instance.
These files (start_asdb242, stop_asdb242, set_ha_tdp_env, get_ha_tdp_env) are
provided in a HACMP subdirectory in the DP for Snapshot Devices installation
directory.
start_asdb242:
This script starts the mySAP central instance with the System ID T23. The
production server is named asdb242. After starting the mySAP central instance, the
script calls set_ha_tdp_env, which removes and recreates all DP for Snapshot
Devices socket server entries in the file /etc/inittab. This will make sure, that all
DP for Snapshot Devices socket server will be started.
#!/usr/bin/ksh
#----------------------------------------------------------------
/usr/sap/HACMP/startsap_CI T23
/usr/local/bin/set_ha_tdp_env T23
stop_asdb242:
This script stops the mySAP central instance with the System ID T23. The
Samples
production server is named asdb242. Before stopping the mySAP central instance,
the script calls set_ha_tdp_env with parameter remove, which removes every DP
for Snapshot Devices socket server entry from the file /etc/inittab, which stops
all DP for Snapshot Devices socket server.
#!/usr/bin/ksh
#----------------------------------------------------------------
/usr/local/bin/set_ha_tdp_env T23 remove
/usr/sap/HACMP/stopsap_CI T23
set_ha_tdp_env:
This script reads the file /db2/<SID>/dbs/ha_tdp_itab, created by the script
get_ha_tdp_env and removes every DP for Snapshot Devices socket server entry
from the file /etc/inittab, which stop all DP for Snapshot Devices socket server.
After all DP for Snapshot Devices socket server are stopped and if the parameter
remove is not specified, the script creates all entries again, which then starts all
DP for Snapshot Devices socket server automatically.
#!/bin/ksh
#----------------------------------------------------------------
SID=$1

if [[ -n $SID ]]
then
cat /db2/$SID/dbs/ha_tdp_itab | while read line; do
item=$(echo $line | cut -d : -f1)
lsitab $item && rmitab $item
done
sleep 3
init q
if [[ "$2" != "remove" ]]
then
cat /db2/$SID/dbs/ha_tdp_itab | while read line; do
mkitab "$line"
done
sleep 3
init q
fi
fi
get_ha_tdp_env:
This script writes the file /db2/<SID>/dbs/ha_tdp_itab, needed by the script
set_ha_tdp_env. It reads all DP for FlashCopy socket server entries from the file
/etc/inittab and writes them in the file /db2/<SID>/dbs/ha_tdp_itab. This will
make sure, that all DP for Snapshot Devices socket server can be started on the
production system by calling the HACMP start script start_asdb242 for the
mySAP central instance.
#!/bin/ksh
#----------------------------------------------------------------
SID=$1

if [[ -n $SID ]]
then
lsitab -a | cut -d : -f1 | grep sock$SID | while read item; do
lsitab $item
done > /db2/$SID/dbs/ha_tdp_itab
fi
Samples

Appendix B. Data Protection for Snapshot Devices for mySAP
(DB2) Messages
This chapter describes the messages issued by DP for Snapshot Devices. The
messages begin with the prefix EEP or IDS and are listed in numerical order.
For each message, the following information is provided:
v Message number
v Severity code
The following letters give an indication of the severity of the action that
generated the message. The severity codes and their meanings are as follows:

E Error Processing cannot continue.
W Warning Processing can continue, but problems may occur later.
I Information Processing continues. User response is not necessary.

v Explanation
v User Response
A list of codes returned by the CIM components is also provided (see CIM Error
Codes on page 321).
Note: References to the term hardware unit should be understood as meaning SVC
cluster in the case of an SVC configuration.
Messages from splitint
EEP0020I ====>Performing DP for Snapshot
Devices <v1> command.
Explanation: This message is displayed starting the
specified function.
User response: None.
EEP0022I AIX Version: <var1> Oslevel: <var2>.
Explanation: Displays AIX version and oslevel.
EEP0030I Number of volumes involved in the
FlashCopy: <v1>
Explanation: Number of volumes to be processed by
FlashCopy.
EEP0056I Received error errno while disabling
the new resources.
Explanation: An error occurred when the process
attempted to disable the resources obtained for
performing the DB backup.
User response: Check the error log for details.
EEP0058I Received error errno while resetting
the target volumes.
Explanation: An error occurred when the process
attempted to withdraw the FlashCopy relationship
between the source and target volumes.
User response: Check the error log for details.
EEP0059E The database was backed up using
NOCOPY type of FlashCopy. The data
in the target volumes is not valid, and
cannot be used to perform a FlashBack
Restore.
Explanation: In order to restore the database using
FlashBack Restore, the database needs to be backed up
using the COPY or INCR type of FlashCopy.
User response: Restore the database from TSM Server.

EEP0062E The source/target LUN information in
the setup file has been modified.
FlashBack Restore is currently not
supported for restoring the database to a
new location.
Explanation: The source/target information in the
setup file cannot be modified. In order to back up the
database to different target LUNs, use a different setup
file. At this time, FlashBack Restore is only supported
for restoring the database to the original source LUNs.
User response: The source/target information in the
setup file cannot be modified. In order to backup the
database to different target LUNs, use a different setup
file. If you want to restore the database to a new
location, restore it from the Tivoli Storage Manager
server.
EEP0065E IBM2105 Copy Service CLI is not
installed.
Explanation: The ibm2105cli.rte file is not installed.
lslpp -lc ibm2105cli.rte command failed.
User response: Make sure Copy Service CLI is
installed on your host machine.
EEP0068W WARNING!!! Incremental Change
Recording is enabled. Performing
incremental FlashCopy instead of
NOCOPY type of FlashCopy.
Explanation: Incremental Change Recording is
enabled. Performing a NOCOPY type of FlashCopy will
fail in this case.
User response: Withdraw the persistent FlashCopy
relationship for all the source volumes for this
database, using the DP for Snapshot Devices withdraw
command, if you are interested in a NOCOPY type of
FlashCopy.
EEP0069W WARNING!!! Incremental FlashCopy
feature is not supported on this version
of AIX: <v1>. A generic FlashCopy will
be performed instead.
Explanation: Incremental FlashCopy is only supported
on AIX versions 5.1.0 or later. As this version of AIX is
lower than 5.1.0, an incremental FlashCopy cannot be
performed.
User response: Upgrade to AIX version 5.1.0 or later
in order to take advantage of the Incremental
FlashCopy feature.
EEP0070E Some of the volumes belonging to this
database have Incremental Change
Recording enabled while others do not.
Explanation: In order to perform an incremental
FlashCopy, all the volumes belonging to the database
must have Incremental Change Recording enabled.
User response: Withdraw the FlashCopy relationships
for those volumes that have Incremental Change
Recording enabled, using the DP for Snapshot Devices
withdraw command, and then retry the command. In
the case of the monitor command (FlashCopy agent),
withdraw the FlashCopy relationships and retry both
the backup and monitor (FlashCopy agent) commands.
In an SAP environment, you only need to retry the
backup, because the FlashCopy agent is started
automatically.
EEP0071I Source volume: <v1> Target volume:
<v2> Pending Sectors: <v3>
Explanation: Displays the number of sectors yet to be
copied from source volumes to target volumes in case
of backup or from target volumes to source volumes in
case of restore.
EEP0120E A null logical volume has been detected.
Explanation: DP for Snapshot Devices could not
determine a logical volume name from the list of
database files.
User response: Verify that the calling program has
passed the list of database files. Check for preceding
errors.
EEP0121E A null volume group has been detected.
Explanation: DP for Snapshot Devices could not
determine a volume group name from the list of
database files.
User response: Verify that the calling program has
passed the list of database files. Check for preceding
errors.
EEP0122E An error is detected in volume group :
vg1.
Explanation: An error was returned from specified
volume group.
User response: Verify the target database information
is specified correctly in the setup file. Verify that the
AIX volume manager is running. If the problem
persists, gather information from the trace file and log
file and contact your IBM service representative.
EEP0123E The physical volumes of the volume
group <v1> were not found.
Explanation: DP for Snapshot Devices will issue the
command lsvg -M <vgname> in an LVM mirror
environment to determine the physical and logical
volumes on which the production database resides.
This command failed.
Messages and Codes

User response: Check the return code of lsvg. Consult
the AIX system documentation.
EEP0124I Mounting filesystem : fs1.
Explanation: Currently attempting to mount the file
system.
User response: None
EEP0125E The serial number for the device
logdev could not be found.
Explanation: DP for Snapshot Devices will determine
the volume serial numbers from the list of database
files passed. In order to do that, several system
commands will be used such as: lscfg -pvl devname or
lsvpcfg or hdwmap.sh. One of these commands has
failed or the specified device was not displayed.
User response: Check the specific error message. Issue
the commands above from the command line and
check that the specified device is displayed in the list.
Consult the AIX system documentation.
EEP0126I Trying to find new devices to match the
source device. This process will take
some time...
Explanation: Currently trying to find a target device
to match the source device.
EEP0127I Removing device : devname
Explanation: DP for Snapshot Devices will remove the
logical devices from the Device Configuration database
(ODM) on the backup system after the backup has
ended and prior to withdrawing the relationships of
the volumes.
User response: None
EEP0128E Configuring the target volume would
cause duplicate physical volume ID :
pvid1
Explanation: A different set of target volumes that
were previously associated with the same source
volumes was detected.
User response: Perform one of the following:
1. Delete the disk on the backup system only:
a. find the disk using the AIX lspv command
b. run smitty and choose the following from the
menu: devices- fixed disk- remove a disk- select
the disk to be removed
c. press return
2. Clear the pvid of each physical volume hdisk by
issuing the AIX chdev command with the following
arguments: chdev -1 (hdisk#) -a pv=clear .
EEP0129E Removing device parm1 failed.
Explanation: DP for Snapshot Devices will remove the
logical devices from the Device Configuration database
(ODM) on the backup system after the backup ended
and prior to the withdraw of the relationships of the
volumes. The rmdev command has failed.
User response: Check the specific error message.
Consult the AIX system documentation. Check if the
device is a member of an active volume group. Check
for preceding errors.
EEP0130W Removing the mount point directory
<mntpt1> failed with rc: <rc1>.
Explanation: An error occurred while trying to
remove a mount point. Processing continues.
EEP0131E The physical volume ID <pvid1> is
duplicated on the production machine.
Explanation: The output of the command lspv shows
that two logical devices (hdisk/vpath) have the same
physical volume id.
User response: Perform one of the following:
v If the hdisks with the same pvid belong to the same
multipath, convert the hdisk device volume group to
a Subsystem Device Driver vpath device volume
group.
v If the problem is the result of a corrupt ODM,
consult the AIX Troubleshooting documentation
v If the physical volume involved neither belongs to a
volume group nor contains file systems to be
imported in the future, you can clear the pvid by
issuing the AIX chdev command with the following
arguments: chdev -l hdisk# -a pv=clear
EEP0132W The umount command failed with rc
<rc> for mount point <mntpt>.
remove a mount point. Processing continues.
EEP0138I FlashCopy type is set to NOCOPY.
Removing disk meta data for all target
disks.. This backup is NOT valid for a
FlashBack Restore. Please restore from
TSM Server.
Explanation: Target PVIDs are cleared. This process
removes disk metadata for all target disks. These target
volumes can now be used as targets for source volumes
from multiple databases. However, this backup is not
valid for a FlashBack Restore. You can only restore
from a TSM Server.
Messages and Codes
Appendix B. Data Protection for Snapshot Devices for mySAP (DB2) Messages 277
EEP0139W Removing the file system on the mount
point <mntpt1> failed with rc: <rc1>.
remove a file system during the FlashBack Restore.
Processing continues. The restore will resolve this
problem.
EEP0140I FlashCopy type is set to COPY or INCR.
Leaving disk meta data intact for all
target disks.. This backup is valid for a
FlashBack Restore.
Explanation: The target PVIDs are not cleared. This
process leaves disk metadata intact for all target disks.
This backup can be used for a FlashBack Restore.
EEP0143E Unsupported volume group <v1> has
been detected.
Explanation: The volume group to which the database
has been allocated is an unsupported type.
User response: Make sure that volume group is not
rootvg.
EEP0146E A physical disk from the volume group
vgname was not found.
Explanation: A physical disk from the specified
database volume group was not found in the Device
Configuration database.
Consult the AIX system documentation. Check if this
device is a member of one active volume group. Check
for preceding errors.
EEP0147I Exporting volume group vgname
failed.
Explanation: DP for Snapshot Devices will issue the
command exportvg prior to the withdraw of the
FlashCopy relationships to remove the volume group
from the Device Configuration database. This command
has failed.
Consult the AIX system documentation. Check for
preceding errors during the unmount of the file
systems.
EEP0148I Importing volume groups now...
Explanation: Processing an importing volume group
command.
User response: None
EEP0149I Newly imported volume group:
vgname
Explanation: DP for Snapshot Devices has successfully
imported this new volume group on the backup system
after the FlashCopy.
User response: None
EEP0150E Logical Volume cannot be found for the
file fnm1.
Explanation: An error has occurred determining the
logical volume of a file in the list of database files.
Consult the AIX system documentation.
EEP0151E Varying off volume group vgname
failed.
Explanation: Prior to the withdraw of the FlashCopy
relationships, DP for Snapshot Devices will vary off the
database volume group on the backup system. The
command varyoffvg has failed.
preceding errors during the unmount process.
EEP0152I Removing volume group fnm1 ....
Explanation: Attempting to remove the volume
groups.
EEP0153I Varied off and exported volume group :
vgname
Explanation: The specified volume group was varied
off and exported successfully.
User response: None
EEP0154I <lvname> <copy> <pv> <serialno>
<status>
Explanation: Finding the source volumes of the
production database in an LVM mirror environment,
DP for Snapshot Devices will display a list of all the
logical volumes with the number of copies, the physical
volumes, the serial number and the status. The status is
only displayed for the case of stale partitions.
Messages and Codes

EEP0156I Finding the serial numbers ...
Explanation: DP for Snapshot Devices gets as input a
list of database files to be backed up and from them
determines the logical volumes, volume groups and
serial numbers of the physical volumes where the
production database resides.
User response: None
EEP0161E No volume group was found.
Explanation: The AIX command lsvg failed on the
backup system, and the newly added volume groups
after the FlashCopy could not be determined.
User response: Check the operating system error
issued by lsvg. Consult the AIX documentation.
EEP0162E Volume group <vg1> cannot be found.
Explanation: The AIX commandlsvg failed on the
production system and the source volumes of the
production database could not be determined.
User response: Check the operating system error
issued by lsvg. Consult the AIX documentation.
EEP0164E Quorum of the volume group vgname
must be off.
Explanation: In a high-availability LVM mirror
environment, DP for Snapshot Devices requires that the
quorum of the volume group be set to off. If a mirror is
inactive due to a failure, the database should continue
working properly.
User response: Set the quorum of the volume group
off.
EEP0166E Logical volume vgname must have at
least 2 copies.
Explanation: If the parameter for working with LVM
mirrors is active, DP for Snapshot Devices requires that
two copies of each logical volume exist.
User response: Create a copy of each logical volume
on separate machines. Ensure that, for each source
volume, you have a target volume for the FlashCopy in
the same hardware unit.
EEP0168E Logical volume lvname must have the
parallel scheduling policy.
Explanation: DP for Snapshot Devices requires the
parallel scheduling policy. With the parallel scheduling
policy, there is no primary or secondary mirror. All
copies in a mirror set are referred to as copies,
regardless of which one was created first.
User response: Set the scheduling policy of this logical
volume to parallel.
EEP0170W Logical volume lvname has number
stale partitions.
Explanation: DP for Snapshot Devices first checks all
the logical volumes for stale partitions and initially
issues only a warning if it finds any. The mirror set that
resides in the hardware unit that was chosen for the
FlashCopy on this specific run must be free of stale
partitions.
User response: Check why you have stale partitions.
If necessary, synchronize the logical volumes of the
production database.
EEP0172E Logical volume lvname must have
mirror write consistency on.
Explanation: Mirror write consistency ensures data
consistency among mirrored copies of a logical volume
during normal I/O processing. If a system or volume
group is not shut down properly, then mwc will
identify which logical partitions may be inconsistent.
DP for Snapshot Devices requires that this capability be
set for the logical volumes of the production database.
User response: Set mirror write consistency on.
EEP0174E None of the mirror copies of the logical
volume lvname resides completely on
the specified hardware unit identifier.
Explanation: DP for Snapshot Devices requires that all
the partitions of one mirror set reside on the physical
volumes of one hardware unit.
User response: You have to reconfigure the allocation
EEP0176E Some of the partitions of lvname are
stale on the specified hardware unit
identifier.
Explanation: DP for Snapshot Devices first checks all
the logical volumes for stale partitions and initially
issues only a warning if it finds any. The mirror set that
resides in the hardware unit that was chosen for the
FlashCopy on this specific run must be free of stale
partitions.
User response: Check the reason you have stale
partitions. Synchronize the logical volumes of the
EEP0178I Could not determine the number of
paths to target volumes. Using default
value of 1.
Explanation: DP for Snapshot Devices supports SDD
(Subsystem Device Driver). SDD is a pseudo device
driver designed to support the multipath configuration
environments in the storage system and is used to
enhance data availability. DP for Snapshot Devices will
determine the number of multiple paths by querying
Messages and Codes
the Device Configuration database (ODM).
User response: If you want to take advantage of SDD,
check the Subsystem Device Driver Users Guide for a
correct configuration.
EEP0180E Failure in changing the mount point
mp, return code rc from command
chfs.
environment, DP for Snapshot Devices will use the
recreatevg command to create the volume groups after
the FlashCopy on the backup system. Because
recreatevg inserts the prefix /fs at the start of the
mount point, DP for Snapshot Devices must remove it
by calling the command chfs to the original names.
preceding errors.
EEP0182E The same hdisk devname cannot be
associated with two different vpaths
(serial numbers serial#1 and serial#2).
Explanation: DP for Snapshot Devices has
encountered a corrupted configuration in your system.
User response: By issuing the command lsvpcfg you
can identify this error. Check the Subsystem Device
Driver Users Guide for a correct configuration.
EEP0184E lsvg command failed.
Explanation: DP for Snapshot Devices uses the
command lsvg to determine the physical and logical
volume of the volume group. This command has failed.
preceding errors.
EEP0186I Recreating the new volume groups...
environment, DP for Snapshot Devices will use the
recreatevg command to create the volume groups after
the FlashCopy on the backup system.
User response: None
EEP0188E lvm queryvg failed.
Explanation: DP for Snapshot Devices uses the system
routine lvm_queryvg to read information of the VGDA
of the volumes.
preceding errors.
EEP0190E The number of new volume groups is
limited to 256.
Explanation: DP for Snapshot Devices can support a
database with a maximum of 256 volume groups.
User response: You have to reconfigure your
EEP0191I Varying on volume group vgname
failed.
Explanation: After the importvg or recreatevg, DP for
Snapshot Devices will vary on the database volume
group on the backup system. The command varyonvg
has failed.
preceding errors.
EEP0272I Flushing the buffers to disk...
Explanation: Currently synchronizing to force the
buffers to disk.
User response: None
EEP0273I Unmounting the file system mntpt1...
Explanation: Currently attempting to unmount the file
system from the mount point.
User response: None
EEP0274I Bringing up the volume groups...
Explanation: The new resources will be available after
the FlashCopy.
User response: None
EEP0275I There are too many file systems.
Explanation: The number of file systems exceeds the
compiled limit of 4096.
User response: You have to reconfigure your
EEP0290E The source volume with serial number
serial # is no longer attached to the
production system.
Explanation: The specified physical volume was
found during the FlashCopy backup as part of the
database volumes on the production system. Now,
during the FlashBack Restore, it could no longer be
found on the production system.
User response: Logon with the user root and issue the
command lsvpcfg. Check if the volume is displayed.
Use the storage-system user interface to find out to
which host this volume is attached. You will be able to
Messages and Codes

restart the FlashBack Restore anytime, as long as you
have a valid disk backup on the target volumes.
EEP0291E The source volume with serial number
serial # belongs to another volume
group.
Explanation: The specified physical volume was
found during the FlashCopy backup as part of the
database volumes on the production system. Now,
during the FlashBack Restore, DP for Snapshot Devices
found it as a member of another volume group and
cannot proceed with the restore.
User response: You must remove this volume from
the other volume group if you want to use the
specified FlashCopy backup for the FlashBack Restore.
You will be able to restart the FlashBack Restore
anytime, as long as you have a valid disk backup on
the target volumes.
EEP0292W The logical volume lvname on the
mount point mp was renamed or
newly added.
Explanation: DP for Snapshot Devices found a
difference between the names of the logical volumes
which were on the production database at the time of
FlashCopy backup and the current logical volumes at
the time of the FlashBack Restore.
User response: DP for Snapshot Devices will ask you
during the FlashBack Restore if you are sure you want
to continue, before all the file systems and logical
volumes are removed. After that, DP for Snapshot
Devices will only reconstruct the file systems which
were backed up with FlashCopy. You have to manually
add all the additional system changes that were made
after the FlashCopy backup.
EEP0293I List of the current file systems on the
backed up volume groups ...
Explanation: Prior to the start of the FlashBack
Restore, DP for Snapshot Devices will display a list of
all the file systems which are currently on the
production database system.
User response: None
EEP0294I List of file systems which will be
restored...
Explanation: Prior to the start of the FlashBack
Restore, DP for Snapshot Devices will display a list of
all the file systems that were on the production
database system at the time of the FlashCopy backup.
User response: None
EEP0297W The newly added volume logdev will
be deleted from the database volume
group vgname.
Explanation: The reducevg command removes
physical volumes from a volume group. DP for
Snapshot Devices will call this command during the
FlashBack Restore to remove the physical volumes
added to the database volume groups after the
FlashCopy backup.
User response: None
EEP0299I The following commands should be run
after the FlashCopy process in the
background is finished to synchronize
the LVM copies.
Explanation: DP for Snapshot Devices will not
automatically synchronize the copies after the
reconstruction of the LVM mirror. A basic command
will be created and displayed.
User response: You have to start the synchronization
of the LVM mirror manually after the FlashCopy
process in the background has finished. If necessary
you have to add additional parameters to the
commands to improve the performance of the
synchronization.
EEP0300E Error converting the hdisk device
volume group vgname to a Subsystem
Device Driver vpath device volume
group.
Explanation: For the function FlashCopy backup, DP
for Snapshot Devices will use the command hd2vp to
convert the hdisk device volume group to a Subsystem
Device Driver vpath volume group. This will take effect
after the importvg and prior to the mount of the file
systems on the backup system.
User response: Check the return code and the error
message of the hd2vp command. Consult the AIX
system documentation.
EEP0301W The rmlv command lv ended with
return code rc.
Explanation: For the function FlashBack Restore, DP
for Snapshot Devices will use the command rmlv to
remove the logical volumes onto which the production
database should be restored. This will take effect after
the unmount and prior to the exportvg and the actual
FlashCopy reverse.
message of the rmlv command. Consult the AIX system
documentation. You will be able to restart the
FlashBack Restore anytime, as long as you have a valid
disk backup on the target volumes.
Messages and Codes
EEP0302E DP for Snapshot Devices encountered a
problem when using the FlashCopy
function of Copy Services.
Explanation: DP for Snapshot Devices requested, for a
set of source/target volume pairs, that a FlashCopy be
done by the Copy Services. If the request fails within
the storage system with a non-zero return code for one
or more pairs, DP for Snapshot Devices will provide
the return code and then terminate.
User response: In order to identify which volume(s)
were the cause of the problem, you need to view the
Copy Services status log for failures. There, you will
find the failing volume(s) along with details about
possible causes of the problem.
EEP0303E The file system fs already has an entry
in /etc/filesystems.
Explanation: On the backup system after the
FlashCopy, DP for Snapshot Devices found that the
specified file system still exists in /etc/filesystems.
User response: Normally the command exportvg will
remove the corresponding file systems from
/etc/filesystems. Check for errors during the
unmount and withdraw process.
EEP0304W The reducevg command cmd ended
with return code rc.
Explanation: The reducevg command removes
physical volumes from a volume group. DP for
Snapshot Devices will call it
1. on FlashBack Restore to remove the physical
volumes added after the FlashCopy backup
2. on FlashBack Restore with LVM mirroring to
remove the physical volumes which reside in the
hardware unit that is not yet involved in the
FlashBack.
3. on FlashCopy backup with LVM mirroring if the
environment variable IMPORTVG is set, to remove
the physical volumes which reside in the hardware
unit that is not yet involved in the FlashCopy
message of the reducevg command. Consult the AIX
EEP0305W The extendvg command cmd ended
Explanation: The extendvg command adds physical
volumes to a volume group. DP for Snapshot Devices
will call it to add the volumes which reside in the
hardware unit that is not yet involved in the FlashBack
to the database volume groups.
message of the extendvg command. Consult the AIX
EEP0306W The mklvcopy command cmd ended
Explanation: DP for Snapshot Devices will call the
command mklvcopy to add a copy of a logical volume
on the physical volumes residing in the second
hardware unit. This call will only take effect in an LVM
mirroring environment, after the FlashBack Restore was
initiated. The FlashBack Restore and the recovery will
continue, but the second copy of the logical volumes
will be missing.
message of the mklvcopy command. Consult the AIX
system documentation. Check for errors during the
disabling process (unmount, rmfs, rmlv, varyoffvg,
exportvg). You will be able to restart the FlashBack
Restore anytime, as long as you have a valid disk
backup on the target volumes.
EEP0307I Removing copies from the logical
volumes ...
Explanation: For the function FlashBack Restore, DP
for Snapshot Devices will use the command rmlvcopy
to remove the copies of the logical volumes residing in
the second hardware unit. This will take effect after the
unmount and prior to the exportvg and the actual
FlashCopy reverse.
User response: None
EEP0308I Removing physical volumes from the
volume groups ...
Explanation: For the function FlashBack Restore, after
the rmlvcopy and prior to the exportvg and the actual
FlashCopy reverse, DP for Snapshot Devices will use
the command reducevg to remove the physical
volumes residing in the second hardware unit.
User response: None
EEP0309I Adding physical volumes to the volume
groups ...
Explanation: On the function FlashBack Restore, after
the FlashCopy reverse and the import of the volume
groups, DP for Snapshot Devices will add the physical
volumes residing in the second hardware unit to the
database volume groups.
User response: None
EEP0310I Adding copies to the logical volumes ...
Explanation: On the function FlashBack Restore, DP
for Snapshot Devices will use the command mklvcopy
to add the copies of the logical volumes on the second
hardware unit. This will take effect after the importvg
and the extendvg.
User response: None
Messages and Codes

EEP0311W The command cmd ended with return
code rc.
Explanation: The execution of the system command
ended with the displayed return code.
message of the specified command. Consult the AIX
EEP0312E Importing the volume group from hdisk
logdev failed.
Explanation: DP for Snapshot Devices will use the
command importvg on the function FlashCopy backup.
This command will be issued on the backup system
after the actual FlashCopy and the run of the
configuration manager (cfgmgr). It takes a volume from
each volume group making up the production
database, reads its VGDA and makes this information
available to the operating system.
message of the importvg command. Consult the AIX
EEP0313E Recreating the volume group from the
hdisks hdisks failed.
Explanation: DP for Snapshot Devices will use the
command recreatevg for the function FlashCopy
backup if the production database resides in a
high-availability LVM mirror environment. This
command will be issued on the backup system after the
actual FlashCopy and the run of the configuration
manager (cfgmgr). The difference from the command
importvg is that recreatevg will create the volume
group only with the specified volumes. These form
exactly the one copy on the hardware unit where the
FlashCopy was issued.
message of the recreatevg command. Consult the AIX
EEP0314W Removing the logical device logdev
with the same PVID pvid in the ODM.
Explanation: There is still a logical device (hdisk or
vpath) in the state defined with the same PVID as one
of the source volumes.
User response: None
EEP0315I Could not mount all the filesystems
originally present.
Explanation: This message will appear if, when
running the function FlashBack Restore, a file system
was found that was added after the FlashCopy backup.
User response: The user is responsible for creating the
new file system after the FlashCopy reverse, but before
the recovery, if this file system was already used from
the production database.
EEP0316W The database volume groups do not
currently contain any file system.
running the function FlashBack Restore, no file system
was found on the original database volume group.
Following this, DP for Snapshot Devices will display a
list of the file systems that reside on the FlashCopy
target volumes. These will be restored by means of
FlashBack.
EEP0317W One or more errors were found
disabling the production system
resources. However, the FlashBack
Restore will continue.
running the function FlashBack Restore, an error occurs
unmounting the existing file systems and removing the
volume groups. However, DP for Snapshot Devices will
continue with the FlashBack Restore.
EEP0320E Although the pvid <pvid> is contained
in the descriptor area of the volume
group <vgname>, no logical device
(hdisk/vpath) has this on the production
system.
Explanation: The output of the command lspv shows
that no physical volume hdisk/vpath exists with this
pvid, although the pvid was found on the descriptor
area of the volume group.
User response: You very likely have an ODM
corruption for the involved volume group. Check this
volume group with the command lsvg -l <vgname>
and lsvg -p <vgname>. Depending on the error, you
have to take different actions. Consult the AIX
troubleshooting documentation to repair the ODM.
EEP0321E Physical volume <hdisk> is in the
descriptor area of the volume group
<vgname> but does not belong to this
volume group.
Explanation: The output of the command lsvg -p
<vgname> does not show that the hdisk/vpath belongs
to this volumegroup, but its pvid is registered in the
descriptor area of the volume group.
User response: If the hdisks with the same pvid
belong to the same multipath, convert the hdisk device
volume group to a Subsystem Device Driver vpath
device volume group. If you have ODM corruption,
check the involved volume group with the command
lsvg -l <vgname> and lsvg -p <vgname>. Depending
Messages and Codes
on the error, you have to take different actions. Consult
the AIX troubleshooting documentation to repair the
ODM.
EEP0322W The major number of the volume group
<vgname> could not be determined.
Explanation: The command getlvodm, which is used
to determine the major number of the specified volume
group, failed. The option -V of the command
importvg will not be used on a FlashBack Restore of
this backup.
User response: Check for error messages issued by
getlvodm.
EEP0323W Major number major already exists on
the production machine. The system
will assign the next available major
number to the volume group vgname.
Explanation: DP for Snapshot Devices found that the
major number of the given volume group is being used
by another device. The importvg command will be
issued without the option -V <major number>. The
system will then generate the next available major
number automatically.
User response: Check the major numbers on the
system with the command ls -al /dev.
EEP0324E Production database does not reside in
an LVM mirror environment.
Explanation: The LVM mirroring capability of DP for
Snapshot Devices is on, but the database logical
volumes do not have a mirror copy.
User response: Set the parameter for LVM mirroring
off, or set up your system in a high-availability LVM
mirror environment.
EEP0325E Error reading the status information of
the file system fsname: txtmsg.
Explanation: The system call 'stat' failed. Check the
specific error message appended to this message. In
some cases the user will need administrator rights to
execute this command.
System action: None.
Ensure that the user has sufficient rights.
EEP0326W The file system fsname is not of type
jfs2. The freeze/thaw function will be
applied only on file systems of type
jfs2.
Explanation: The freeze/thaw function will be applied
only on file systems of type jfs2.
EEP0327E Error freezing the file system fsname:
txtmsg.
Explanation: The function FREEZE failed for this file
system.
System action: Check the specific error reported by
the operating system, which is appended to this
message.
EEP0328E Error thawing the file system fsname:
txtmsg.
Explanation: The function THAW failed for this file
system.
System action: Check the specific error reported by
the operating system, which is appended to this
message.
EEP0329I Freezing file system : fs1.
Explanation: Currently attempting to freeze the file
system.
EEP0330I Thawing file system : fs1.
Explanation: Currently attempting to thaw the file
system.
EEP0331I Performing snaprestore of the source
volume srcvol to the snapshot snapid
(LUN lunpath).
Explanation: The function 'snaprestore' will revert the
source volume to the specified snapshot name. This
message will appear for each LUN involved in the
restore process. The snap restore is performed based on
the volume.
EEP0332I Performing snapshot of the source
volume srcvol (LUN lunpath).
Explanation: A snapshot will be taken of this volume.
This message will appear for each LUN involved in the
snapshot process. However, when several LUNs belong
Messages and Codes

||
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
||
|
|
|
|
||
|
|
|
|
||
|
|
|
|
|
|
|
|
|
||
|
|
|
|
to the same volume, only one snapshot of this volume
is taken.
User response: None
EEP0333I The snapshot snapid was generated for
the source volume srcvol (LUN lunpath).
Explanation: A snapshot with the name displayed was
taken from this volume. This message will appear for
each LUN involved in the snapshot process. However,
when several LUNs belong to the same volume, only
one snapshot of this volume is taken.
EEP0350E Error to get the size of the target volume
src1 with return code rc1.
Explanation: The storage-system query command
cannot determine the size of the target volume.
User response: Issue a query command from the Copy
Services Web Interface to verify that the disk exists. If
the problem persists, save the diagnostic information
and contact IBM service.
EEP0351E The sizes of source volume src1 and
target volume tgt1 are different.
Explanation: The sizes of the source volume and
target volume are different. The source volume and
target volume must be the same size and reside in the
same hardware unit.
User response: Issue a query command from the Copy
Services Web Interface to verify that the disk exists. If
the problem persists, save the diagnostic information
and contact IBM service.
EEP0352E Wrong volume size for the target
volume tgt1 is specified in the setup
file.
Explanation: The TARGET_VOLUME parameter specifies
an incorrect size for the target volume.
User response: Make sure the parameter in the setup
file specifies a correct size for the target volume. If you
do not know the exact size of the target volume,
specify a dash (-) for both the source value and size
value. The size of the target volume will be determined
automatically.
EEP0353E Unable to open file file1.
Explanation: An error was detected when trying to
open the file. The file may not exist.
User response: Make sure the file exists.
EEP0354I Performing <fctype> FlashCopy of
source volume <src1> to target volume
<tgt1>
Explanation: A FlashCopy from the source volume to
the target volume was requested.
EEP0355E The FlashCopy command failed.
Explanation: The FlashCopy command failed. This
could be due to various reasons:
1. Some library or jar files may be missing from the
Copy Services command line interface package.
2. The source volumes or target volumes are in
another FlashCopy relationship.
3. The Copy Services command line interface package
and Copy Services microcode are not in sync.
User response: If the command line interface package
is missing files, install the command line interface
package again. If the source volumes or target volumes
are in another FlashCopy relationship, wait until the
concerned volumes exit the relationship or use other
target volumes. If the command line interface package
and Copy Services microcode are not in sync, check
with the storage system administrator to obtain the
appropriate level of Copy Services command line
interface and microcode.
EEP0356E Cannot find a target volume to match
the source volume parm1.
Explanation: A target volume could not be found.
User response: Make sure that the target volumes are
available to the backup system and that the syntax is
correct for the following parameters:
1. TARGET_VOLUME
2. PRIMARY_COPYSERVICES_SERVERNAME
3. COPYSERVICES_USERNAME
EEP0357I Performing FlashCopy withdraw of
source volume <src1> from target
volume <tgt1>
Explanation: A FlashCopy withdraw of the source
volume from the target volume was requested.
EEP0358E No target volume is available.
Terminating......
Explanation: No target volume was found.
User response: Make sure that the target volumes are
available to the backup system and that the syntax is
correct for the following parameters:
1. TARGET_VOLUME
Messages and Codes
|
|
|
|
||
|
|
|
|
|
|
|
|
EEP0359I Incremental Change Recording: <val1>
Explanation: Value of Incremental Change Recording.
EEP0360I Querying the storage system for the size
of volume volser1...
Explanation: A query of the target volume was
requested.
User response: None
EEP0361I A NOCOPY FlashCopy was performed.
Withdrawing the NOCOPY FlashCopy
relationship
Explanation: The FlashCopy relationship between the
source and target volumes terminates after the
NOCOPY FlashCopy is performed.
User response: None
EEP0362I Checking the status of the primary Copy
Services server...
Explanation: Currently verifying the primary Copy
Services server status.
User response: None
EEP0363I Primary Copy Services server is ready.
Explanation: The primary Copy Services server is
ready.
User response: None
EEP0365I Checking the status of the backup Copy
Services server...
Explanation: Currently verifying the backup Copy
Services server status.
User response: None
EEP0366I FlashCopy was performed with
<parm1> option.
Explanation: This is the type of FlashCopy that was
actually performed. It may be different from the value
specified by the user, since DP for Snapshot Devices
overrides this value under certain conditions.
EEP0367I Source and target volumes have been
switched due to a previous incremental
FlashBack Restore operation. Previous
target volume: <parm1> is now the
source volume. Previous source volume:
<parm2> is now the target volume.
Explanation: Whenever the user performs an
incremental FlashBack Restore operation, the source
and target volumes will be reversed.
EEP0368I The backup Copy Services server is
ready...
Explanation: The backup Copy Services server is
ready.
User response: None
EEP0371I Value of FlashCopy type is: <parm1>.
Explanation: None.
EEP0372I A primary Copy Services server has not
been specified.
Explanation: The primary Copy Services server is not
defined in the setup file. An attempt to use the backup
Copy Services server is made.
User response: None
EEP0374I Querying the storage system for the
status of volumes volser1...
Explanation: A query of all the source and target
volumes was requested to ensure that they are not
involved in a FlashCopy or PPRC operation.
EEP0375E Error: Volumes are involved in a
FlashCopy or a PPRC operation.
Explanation: Source or target volumes are involved in
a FlashCopy or a PPRC operation. FlashCopy backup
or restore command will not be performed.
User response: Ensure that the source and target
volumes are not in use in a FlashCopy or PPRC
operation, before issuing the FlashCopy backup or
restore command.
EEP0376E Error: target volume v1 involved in the
previous backup does not exist in the
setup file.
Explanation: The list of target volumes specified in
the setup file for restoring a specified database using
FlashBack Restore needs to be the same as those
specified in the setup file at the time of FlashCopy
Backup. This is necessary to ensure that a complete
image of the database is available to the restore
process.
User response: Ensure that the target volumes
specified in the setup file are accurate.
Messages and Codes

EEP0380E An invalid value: <parm1> has been
specified for FlashCopy type.
Explanation: FlashCopy type can only be NOCOPY,
COPY or INCR.
User response: Specify NOCOPY, COPY or INCR for
the option FlashCopy type and retry the command.
EEP0381I Querying storage system for pending
sectors for volume: <volser1>
Explanation: A query of all the source and target
volumes was requested to ensure that a background
copy is not in progress between them.
EEP0400E Error on running command: parm1
Explanation: An error was detected while running a
system command.
User response: Gather log file information and contact
your IBM service representative.
EEP0630E A memory allocation error has occurred.
Explanation: Not enough memory was available to
continue processing.
User response: Ensure that your system has sufficient
real and virtual memory. Close unnecessary
applications.
EEP0640E Could not open trace file <v1>.
Explanation: There were some problems opening
tracefile. Make sure you can open the trace file which
was specified in the setup file.
EEP0641E Could not create the trace object.
Explanation: There was a problem creating the trace
class object.
EEP0647E A FlashCopy association exists between
source volume: source volume and a
different target volume: target volume.
Explanation: A FlashCopy association exists between
the source volume and a target other than the
designated target volume.
System action: The restore command will fail.
User response: Withdraw the FlashCopy association
between the source and target volumes and retry the
restore command.
EEP0648E An unexpected error was encountered.
TSM function name : function-name
TSM function : function-desc
TSM return code : TSM-rc
TSM file :
file-name (line-number)
Explanation: None.
System action: Processing stops.
User response: Contact the TSM administrator with
the information provided in this message.
EEP0649E Error while querying volume properties
of volume <volume name>. Please
verify that the volume specified in the
target volumes file exists.
Explanation: The volume information of <volume
name> cannot be found in the copy services
configuration. This can be the result of a typographical
error for the specified volume in the target volumes file
(.fct). This error can also occur if the specified storage
hardware unit cannot be found in the current copy
services configuration.
User response: Verify that the volume <volume
name> specified in the target volumes file exists. In
case of ESS 800, DS6000 or DS8000, verify the CIM
Agent configuration with the command
/opt/IBM/cimagent/verifyconfig u <CIM user>
-p <CIM user password>
If the specified storage hardware unit is not found in
the CIM Agent configuration, contact CIM Agent
support.
EEP0651E A FlashCopy background copy is in
progress between source volume: source
volume and target volume: target volume.
Explanation: A FlashCopy background copy from a
previous operation is not complete for the given source
and target volumes.
System action: The command will fail.
User response: Wait until the background copy is
complete and retry the command.
EEP1625I Number of volumes to be processed by
FlashCopy: v1
Explanation: Number of volumes to be processed by
FlashCopy.
Messages and Codes
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EEP1626E An unexpected error was encountered
processing a Tivoli Storage Manager for
Advanced Copy Services function.
TDP function name : function-name
TDP function : function-desc
TDP return code : TSM-rc
TDP file : filename (line-number)
Explanation: None.
User response: Contact the TDP administrator with
EEP1627E SVC virtual disk v1 is not valid.
Explanation: The specified virtual disk was not found
in the list of virtual disks provided by the connected
SVC cluster.
System action: Process stops.
User response: Ensure that this virtual disk exists in
the SVC cluster.
EEP1628E The source v1 and target v2 virtual disks
are in different SVC clusters.
Explanation: The SVC source and target virtual disks
have to be assigned to the same SVC cluster.
virtual disks are in the same SVC cluster.
EEP1629E The source v1 and target v2 virtual disks
are of different size.
Explanation: The SVC source and target virtual disks
have to be of the same size.
virtual disks have the same size.
EEP1630E An error was returned calling an
operation of the Common Information
Model (CIM).
TDP CIM return code: 0xCIM-rc
Explanation: An error occurred calling a CIM
operation of the disk subsystem.
User response: See CIM Agent Return Codes (SVC)
on page 323 for possible values of CIM-rc.
EEP1631E A memory allocation error has occurred
in file filename, line number linenumber.
System action: Processing ends.
applications.
EEP1635I The ONTAP filer version on this
appliance is: n.
Explanation: None.
System action: Process continues.
EEP1636I The option fractional reserve on volume
vol_name was reduced to less than 100
percent.
Explanation: When using N series devices, it is
strongly recommended that, when the fractional reserve
is set to less than 100%, you actively monitor space
consumption and the rate of change of data on the
volume to ensure you do not run out of space reserved
for overwrites. In this case, if you run out of overwrite
reserve space, writes to the active file system fail and
the host application or operating system might crash.
System action: The process continues.
User response: Ensure that you monitor the space
consumption. Consult the NetApp vendor for tools to
monitor available space on your volume.
EEP1650E The execution of command lscfg failed.
Please verify that the command tset -I
-Q is not set in the user's environment
files .profile, .login,
.dbenv_<hostname>.sh,
.dbenv_<hostname>.csh, and
.sapenv_<hostname>.sh,
sapenv_<hostname>.csh.
Explanation: If the command tset -I -Q is set in the
user's environment files .profile,
.dbenv_<hostname>.sh, and .sapenv_<hostname>.sh,
the command lscfg will fail with the output Not a
terminal and will not return any configuration. This
will cause the DP for Snapshot Devices script
hdwmap.sh to fail.
User response: Ensure that the command tset -I -Q is
not set in the user's environment files .profile,
.dbenv_<hostname>.sh, and .sapenv_<hostname>.sh.
Messages and Codes

||
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EEP2051W The local snapshot repository was not
found on location.
Explanation: The specified directory for the local
snapshot location does not exist.
System action: Processing continues.
User response: A new local snapshot repository will
be built in the specified directory.
EEP2052E Information about the disk subsystem is
missing.
Explanation: The local snapshot repository could not
be initialized due to missing information about the disk
subsystem.
User response: The application ensures that the disk
subsystem is initialized properly. Check for preceding
error messages.
EEP2053E A memory allocation error has occurred
in file filename, line number linenumber.
applications.
EEP2054E Operating system error errno: messagetext.
Explanation: The application encountered an
unexpected-message error during the execution of a
system function. The respective operating system error
and message text will be displayed.
EEP2055I The local snapshot manager could not
be locked.
Explanation: The local repository is locked by another
application. This process will proceed when the other
application unlocks the local repository.
EEP2056I Waiting maximal timeout seconds until
the lock is released by the other
application.
Explanation: While the local repository is locked by
another application, the program will wait a specific
period of time to proceed. In the mySAP environment,
that time is 1 hour.
EEP2057E Local snapshot manager not initialized.
Explanation: The local snapshot repository was used
without previous initialization.
User response: The system normally ensures that the
local repository is initialized. Check for preceding error
messages.
EEP2058E The data container with ID dcID could
not be updated in the local repository.
Explanation: During a FlashCopy backup the target
set record in the local repository is updated with the
corresponding properties. A failure occurred during
that process.
User response: Check for preceding error messages
such as memory allocation error or other system error.
EEP2059W Cannot find a target data container that
matches the source data container.
Explanation: During a FlashCopy backup, TSM for
Advanced Copy Services tries to find a target data
container that matches the source data container to
satisfy the FlashCopy backup. A matching target data
container could not be found.
User response: See the rules for selecting one of
multiple target data containers. For example, this
message will be displayed if the user is trying to start a
FlashCopy backup of type INCR and all the target sets
are being used for the FlashCopy type COPY. Make
sure also that the target volumes are available to the
backup system and the syntax is correct for the
following parameters:
1. TARGET_VOLUME
EEP2060W Cannot find a volume in the target data
container dcID to match the source srcvol.
Explanation: This warning message indicates that for
the specific source no target volume could be found in
this target data container that matches for a FlashCopy
operation. If multiple target data containers are being
used, the processing will continue checking the
volumes of the next target data container.
Messages and Codes
EEP2061W The target data container with ID dcid
was not found in the local repository.
Explanation: An inquiry of the data container with the
specified ID could not be satisfied because that target
set does not exist in the local repository.
System action: Processing may continue. The
application that is requesting the inquiry will decide
whether or not the error should end the program.
User response: Check for succeeding messages.
EEP2062W Could not find a target data container in
the state state to fulfill the requested
criteria.
Explanation: A data container in the specified state
was not found in the local repository to satisfy specific
criteria requested by the application.
application will decide whether or not the warning
should end the program.
User response: Which criteria have been passed is
application specific. Check for succeeding messages.
EEP2063W The local snapshot repository already
exists on the directory location.
Explanation: An application tried to create the local
repository in a directory that already exists.
application will decide whether or not the warning
should end the program.
User response: Check for succeeding messages.
EEP2064I The local snapshot repository will be
created on the directory location.
Explanation: The local snapshot repository containing
information about the state of the data containers is
being created.
EEP2065I The local snapshot repository could not
be created on the directory location.
Explanation: A failure occurred creating the local
snapshot repository.
User response: Look for an operating system error
message.
EEP2066E Cannot read the .fct file filename.
Explanation: The .fct file containing the target data
containers was not found or is not accessible.
User response: Check the name, the path and the
permissions for the file.
EEP2067E The exception CLsmException was
thrown. Reason: txt.
Explanation: An unexpected error occurred processing
a function of the local snapshot repository.
User response: Check the specific reason.
EEP2068E No target LUNs were found for the data
container dcID in the .fct file filename.
Explanation: The program will search in the .fct file,
for each specific data container, for a list of entries with
the label TARGET_VOLUME. Either you have an
incorrect label for the target volumes of the specified
data container or this data container in the .fct file does
not have any target LUNs.
User response: This error can only occur if the
application does not have a GUI where the user
provides the input of the target data containers and the
format will be automatically checked. If so, please
check the format of the .fct file.
EEP2069E Cannot read the file filename of the local
snapshot repository.
Explanation: The system keeps some information
about the state of the data containers locally in a file.
This file was not found or is not accessible.
User response: Check the name, the path and the
permissions of the file.
EEP2070E The repository state file filename is
empty or has an incorrect format.
This file was found but the expected format of the data
in not correct.
User response: Normally the system ensures that the
format of this file is correct. Check for a preceding
error.
Messages and Codes

EEP2071E The data container dcID could not be
inserted in the local snapshot repository.
Inserting an entry for a new data container caused an
error.
User response: This is an unexpected error. Check for
preceding error. If no other error is indicated, collect
the logs and traces and contact support.
EEP2072E An unexpected error was encountered
processing a TSM for Advanced Copy
Services function.
TDP return code : TSM-rc
Explanation: None.
User response: Contact the TDP administrator with
EEP2073E The file filename of the local snapshot
repository could not be opened for
writing.
about the state of the data containers in the local
snapshot repository. Opening a file of this repository
generated an error.
User response: Check the permissions of the file.
EEP2727E Lun ID v1 is not valid.
Explanation: Length of LUN ID must be 8 characters.
User response: Make sure the length of the LUN ID is
8.
EEP2729E Operating system command command
failed; rc=rc.
Explanation: None.
User response: Check the return code from the
operating system for more information about the
failure. Issue the failing command manually to see if
the same failure occurs.
EEP2730E The primary and secondary Copy
Services servers are down.
Explanation: None.
User response: Start at least one of the Copy Services
servers.
EEP2731E Cannot open the command output file
v1 for writing.
Explanation: The file cannot be opened for writing.
User response: Make sure you have enough space on
your system and write permissions to the file.
EEP2732E The LUNs are already in use.
Explanation: None.
User response: Release LUNs in order to reuse them.
EEP7366E Unable to close trace output file filename.
Explanation: An error occurred during the closing of a
trace output filename (for example, not enough disk
space).
User response: Check the specific operating system
error message.
EEP7367E Unable to write to trace file tracefile.
Tracing disabled.
Explanation: An error occurred when writing to the
specified tracefile.
User response: Ensure the device for the tracefile is
available and has sufficient space for the file. Retry the
command.
EEP7826E Unable to open trace output file
<filename>.
Explanation: The DP for Snapshot Devices user does
not have permission to open the specified trace file.
User response: Check the access rights for the
directory of the specified trace file.
IDS0064E The parameter <parameter_name> in the
topic <topic_name> of the profile <.fcs
filename> is not known.
Explanation: In the section <topic_name> of the setup
file .fcs, a parameter was found that is not supported
by DP for Snapshot Devices.
Messages and Codes
User response: Remove the cited parameter from the
.fcs file.
IDS1000E Profile not specified
Explanation: DP for Snapshot Devices cannot locate
the profile.
User response: Ensure that a profile is available. Note
that the splitint call must have the following form:
<path>/splitint -p <path>/init<SID>.fcs -f
<function>....
IDS1001E Function not defined
Explanation: An invalid argument has been specified
for the -f option of DP for Snapshot Devices.
User response: Ensure that you pass a valid function
name with the option -f. Valid functions are: withdraw,
flashcopy, password, unmount, inquire, ts_inquire, and
query.
IDS1004E Subfunction not defined.
for the -s option of DP for Snapshot Devices. This
option has been designed for internal splitint use
only and should not be used externally.
User response: Do not use the -s option with the
splitint call.
IDS1005I Start of splitint program at: time.
Explanation: DP for Snapshot Devices started at time.
IDS1007I End of splitint program at: time.
Explanation: DP for Snapshot Devices ended at time.
Control will be returned to either the shell or to
tdphdwdb2 when splitint was called by tdphdwdb2.
IDS1008E Parameter <keyword> in the profile file
required.
Explanation: The parameter <keyword> in the profile
for DP for Snapshot Devices could not be found. It
must be defined.
User response: Set the parameter <keyword> and its
value in the profile for DP for Snapshot Devices.
IDS1009E Directory path <path> for the IDS
control file does not exist.
Explanation: Either the entry for the parameter
IDS_CONTROL_FILE is incorrect or the path does not
exist.
User response: Ensure that the parameter
IDS_CONTROL_FILE in the profile has a valid path. If
the path does not exist, you must create it.
IDS1010E Option -i <backup_list> not specified.
Explanation: The function -f getresources requires the
specification of the option -i <backup_list> too.
User response: Ensure that you transfer the list of the
files to back up when you call the function -f
getresources. Note that the splitint call must in this
case have the following form: <path>/splitint -p
<path>/init<SID>.fcs -f getresources -i <backup_list> ...
IDS1011E Option -f <function> not specified.
Explanation: splitint always requires the option -f
<function> with a valid function.
User response: Ensure that the splitint call has the
following form: <path>/splitint -p
<path>/init<SID>.fcs -f <function>....
IDS1014I <subsystem message>
Explanation: DP for Snapshot Devices received an
information message from the IDS subsystem.
IDS1015I Start of splitint program at <timestamp>
Explanation: Reports the activation of splitint.
IDS1015W <subsystem message>
Explanation: DP for Snapshot Devices received a
warning message from the IDS subsystem.
IDS1016E <subsystem message>
Explanation: DP for Snapshot Devices received an
error message from its IDS control part.
User response: See the subsystem error messages for
more information and perform required action.
IDS1020I The FlashBack Restore ended
successfully.
Explanation: The high-performance restore issued
with the FlashCopy from the target volumes to the
source volumes was completed successfully.
Messages and Codes

IDS1023I Exiting with return code <rc>.
Explanation: The splitint program issues this
message on terminating. The program returns the value
0 if successful, or nonzero if the execution of the called
function failed.
User response: If the called function has failed, check
for previous error messages.
Explanation: The splitint program issues this
function failed.
IDS1025I Time stamp: <current_time>
Explanation: DP for Snapshot Devices performs
several tasks in sequence (e.g. initiate the FlashCopy of
source volumes on the production system and mount
file systems on the backup system). Tracking the
various time stamps allows analyzing how long each
task took.
IDS1026I Start of splitint on the production
system ...
Explanation: DP for Snapshot Devices has issued a
call to the production system and is waiting for the end
of the execution.
IDS1027I splitint ended on the production
system successfully.
Explanation: DP for Snapshot Devices has ended the
call to the production system successfully.
IDS1028E splitint ended with errors on the
production system.
Explanation: The remote exec call to the production
system has ended with errors.
IDS1030I FlashCopy started ...
Explanation: The command with the flashcopy
function has been issued on the production system, and
the program splitint waits until this action has
finished.
IDS1031I FlashCopy successful.
Explanation: The command for the FlashCopy of the
volume pairs has terminated successfully on the
production system.
IDS1032W Information from DP for mySAP was
not found.
Explanation: The exchange data between DP for
Snapshot Devices and DP for mySAP was not found.
The information is exchanged through the call of the
DP for Snapshot Devicess function set_bki_info by
backint prior to the Tivoli Storage Manager backup. For
older versions, the information is first exchanged after
the Tivoli Storage Manager backup during the
execution of the unmount function. Either the DP for
mySAP you have installed does not support DP for
Snapshot Devices, or DP for mySAP has failed after a
successful FlashCopy and mount.
User response: Check the run logs of tdphdwdb2. This
error could have various reasons and should be
resolved depending on the specific situation:
Case 1: tdphdwdb2 has finished successfully.
Result: The backup on disk (FlashCopy target volumes)
as well as the one done to the TSM server are valid.
However, DP for Snapshot Devices cannot show the
backup ID in its report when using the function
inquire.
Reason for warning: It is very likely that DP for mySAP
(AIX version) does not have DP for Snapshot Devices
support (prior to version 3.1.0.3).
Action: Install the appropriate DP for mySAP version.
Case 2: tdphdwdb2 has terminated abnormally.
Result: Check carefully the run log of tdphdwdb2 for any
BKI, ANS or ANR error messages. Most likely, the
backup on disk (FlashCopy target volumes) is valid
(check with splitint -f inquire whether PSI is
PSI_MOUNT_DONE or PSI_UNMOUNT_DONE), but
the backup to the TSM server is invalid.
Cause: Problems with the network or on the TSM
server caused DP for mySAP to fail when running a
backup.
Action: Depending on the error message, eliminate the
reason for not getting a successful backup to the TSM
server.
IDS1033I Information from DP for mySAP has
been found with BACKUPID
<backupid>.
mySAP and DP for Snapshot Devices has been found
during the execution of the function unmount. The
Messages and Codes
backups on disk (FlashCopy target volumes) as well as
to the Tivoli Storage Manager server are valid. The list
of files has been saved in the Tivoli Storage Manager
with the backup ID <backupid>.
IDS1034E Entry <field_name> in the current
backup cycle of the IDS control file is
missing.
Explanation: The field with the name <field_name> in
the current backup cycle was unexpectedly empty.
User response: Check for preceding errors.
IDS1035I The IDS control file exists and a new
backup cycle entry has been created.
Explanation: At the start of the function -f
getresources, DP for Snapshot Devices inserts a record
in the IDS control file for the new backup cycle. This
record will be updated as the status of the new backup
cycle changes (e.g. FlashCopy target volumes/file
systems being mounted or unmounted).
IDS1038I The IDS control file <ids_control_file>
does not exist. It will be created.
Explanation: DP for Snapshot Devices will write the
first record to the IDS control file specified in the entry
IDS_CONTROL_FILE of the profile.
IDS1039E The IDS control file has no entry.
Explanation: DP for Snapshot Devices has found the
IDS control file, but it has no records. This error occurs
when you start one of the functions inquire, withdraw
or unmount before you have run the flashcopy
function for the first time.
User response: After you run at least one tdphdwdb2
with a successful FlashCopy, the problem will be
resolved.
IDS1040E The IDS control file must be read or
inserted before update.
Explanation: DP for Snapshot Devices has detected a
logical error when processing the IDS control file.
User response: Contact Data Protection for mySAP
support.
IDS1041W The value of the field field_name in
the file file_name is empty.
Explanation: The program tdphdwdb2 updates the
IDS repository after the Tivoli Storage Manager backup
but also in case of a disk-only backup. A temporary file
is created with the following format:
>>> backint_data
BID <backup id>
UTL <name of the application profile used>
INF <EEE or ESE backup ID>
EBC <log directory>
EBB <backup type>
EBR <first active log>
<<< backint_data

>>> input_file
<file list>
<<< input_file
If one of the fields of the topic backint_data is empty
(missing), this message is displayed. If the backup ID is
empty, the process terminates with error IDS1036E.
IDS1042W Info data from DP for mySAP
/tmp/bki<SID>.ids cannot be read.
Explanation: Before the unmount process, DP for
Snapshot Devices will read /tmp/bki<SID>.ids, which
contains information about the backup that was done
by DP for mySAP. Among the information read is:
v Backup id
v Util file used for the backup
v List of files used for the backup
v Backup type
This message will be issued if DP for mySAP
terminated unsuccessfully for some reason.
User response: Ensure that DP for mySAP runs
successfully.
IDS1043I The maximum number of backup cycles
in the IDS control file has been reached.
Explanation: The maximum number of backups
controlled via the parameter BACKUP_MAX will be
exceeded with the new inserted record. If the
parameter is not set, the program will use the default
value of 30.
IDS1044I Delete backup cycle with BSEQ_N =
<bseq_n> and all associated files ...
Explanation: Since the maximum number of records
has been reached, the program will delete the oldest
record with the backup sequence number <bseq_n>. In
addition, the oldest reports and traces associated with
Messages and Codes

that backup cycle will be deleted.
IDS1045W Directory path <directory> for the report
files does not exist. Using the current
directory.
Explanation: The directory entry of the parameter
LOG_TRACE_DIR in the profile could not be found.
The current directory will be used for the log and trace
files.
User response: In order to avoid directories cluttered
with reports and traces, the parameter
LOG_TRACE_DIR should be used, or the directory it
specifies must be created if necessary.
IDS1046I Start of listing of importing volume
groups/mounting file systems ...
Explanation: After initiating the FlashCopy
source/target volumes on the production system, DP
for Snapshot Devices will make the corresponding
target volumes available to the backup host. A list of
mount points or volume groups will be shown.
IDS1047I End of listing.
Explanation: Corresponds to start message IDS1046I.
IDS1048I The unmount process will be skipped
because the progress status indicator
(PSI) has a value of psi.
Explanation: When the withdraw function is started,
the unmount process will be performed only if the PSI
has a value of PSI_MOUNT_STARTED or
PSI_MOUNT_DONE.
User response: Table 6 on page 138 shows the
permissible functions depending on the backup
progress status indicator.
IDS1050E The version of the splitint program
must be the same on the backup and
production systems.
Explanation: The version of DP for Snapshot Devices
on the production system is different from the version
User response: Ensure that you install the same
version of DP for Snapshot Devices on the production
and backup systems. You get the version number when
you start splitint without parameters.
IDS1051I Enter the password for the user <user
ID>
Explanation: The password for the user ID <user ID>
has to be entered. It will be encoded and stored in a
file specified in the parameter CONFIG_FILE. Note that
this user ID and password have to be the same on the
production and backup systems. The DP for Snapshot
Devices program splitint uses the user ID to execute a
remote shell on the production system.
User response: Enter the password for the
corresponding user ID.
ID> again
Explanation: In order to avoid typing errors, you have
to enter the password twice.
User response: Enter the password again.
IDS1053I The password entry does not match,
please try again
Explanation: The two entered passwords are not
identical. You must enter the password again.
User response: Enter the password again. You are
permitted three attempts before the program
terminates.
IDS1054E No password stored.
identical. You have tried three times, and the
passwords were different in each case.
User response: You must start the splitint program
with the function -f password again. If no password is
stored, or it is invalid, splitint fails when the
flashcopy function is used.
IDS1055E The config file named <config_file>
could not be opened. Please call splitint
with the password function to create
that file.
Explanation: DP for Snapshot Devices is unable to
read the configuration file <config_file>.
User response: This error could have various reasons.
Try the following:
1. Call splitint with the password function to create
the file.
2. Check the path of the configuration file. The path
must be specified in the profile (parameter
CONFIG_FILE).
3. Make sure that the file access permissions are set
correctly.
Messages and Codes
IDS1056E The information of DP for mySAP could
not be set in the IDS repository.
Explanation: After the mount of the file systems on
the backup system was finished, the call of DP for
mySAP (backint) takes place. Backint then calls DP for
Snapshot Devices with the function -f set_bki_info to
set the Tivoli Storage Manager backup ID and other
information. This information is mandatory for using a
FlashCopy backup for restore. This information could
not now be set.
User response: Ensure that you have the version of
backint compatible for FlashBack Restore.
IDS1057E No target set entries were found in the
IDS repository.
Explanation: The target set entries in the IDS
repository are generated automatically from the entries
configured in the .fct file (set of target volumes). This
happens during the FlashCopy backup.
User response: Check the .fct file (set of target
volumes). Check the parameters IDS_CONTROL_FILE
(IDS repository) and VOLUMES_FILE (.fct file).
IDS1060I Start of listing of exported volume
groups/unmounting file systems ...
Explanation: A list of unmount points or exported
disk groups will be shown. Due to the use of the
unmount function on the backup host, DP for Snapshot
Devices will unmount the file systems and export
volume groups on the backup host that had been
imported or mounted when the DP for Snapshot
Devices flashcopy function was executed.
IDS1061I Start the withdraw of the target-source
pairs ...
Explanation: The command with a withdraw has been
issued from the backup system to the primary Copy
Services server for the storage system.
IDS1062I The progress status indicator (PSI) is
already PSI_UNMOUNT_DONE.
Explanation: DP for Snapshot Devices has been called
with the function withdraw or unmount, but the PSI
value of the latest backup cycle was already updated to
PSI_UNMOUNT_DONE in a previous splitint call.
IDS1063E Parameters LOGON_HOST_PROD/
LOGON_HOST_BACK in profile wrong
or missing.
Explanation: Either DP for Snapshot Devices is unable
to read one of the parameters LOGON_HOST_PROD or
LOGON_HOST_BACK from the profile, or the
parameter values are incorrect. Note that these
parameters must have the following format:
LOGON_HOST_PROD <hostname/TCP name> <user
ID>
LOGON_HOST_BACK <hostname>
The host names must match the respective host names
of the production and backup systems. The TCP/IP
address will be used for the communication between
the two systems. The user ID specified must match the
DB2 user ID (db2<sid>).
User response: Ensure that the profile contains valid
entries for LOGON_HOST_PROD and
LOGON_HOST_BACK.
IDS1064E The parameter <keyword> in the profile
is not known.
Explanation: An unknown parameter <keyword> has
been found in the profile.
User response: Check the specified parameter in the
profile and try again.
IDS1065E You cannot run the function function if
the progress status indicator (PSI) has a
value of psi.
Explanation: The backup cycle was left in a state that
does not allow DP for Snapshot Devices to start the
specified function.
User response: Table 6 on page 138 shows the
permissible functions depending on the backup
progress status indicator.
IDS1066E The option -f flashcopy can only be
used on the backup system.
Explanation: You cannot start the flashcopy function
User response: Make sure you start splitint with the
function -f flashcopy on the backup system only.
Ensure that the profile contains a valid entry for
LOGON_HOST_BACK.
IDS1067E The options -f flashcopy -s performsplit
can only be used on the production
system.
Explanation: The option -s was designed for internal
splitint use only and should not be used externally.
User response: Make sure you issue splitint -f
Messages and Codes

flashcopy on the backup system only. Ensure that the
profile contains valid entries for LOGON_HOST_PROD
and LOGON_HOST_BACK. Do not use the -s option
with the splitint call.
IDS1068E The option -f withdraw can only be
Explanation: You cannot start the function withdraw
function -f withdraw on the backup system only.
Ensure that the profile contains a valid entry for
LOGON_HOST_BACK.
IDS1069E The option -f unmount can only be used
Explanation: You cannot start the function unmount
function -f unmount on the backup system only. Ensure
that the profile contains a valid entry for
LOGON_HOST_BACK.
IDS1071E Topic named <topicname> could not be
found in the file <filename>.
Explanation: DP for Snapshot Devices was able to
read the file <filename> but the expected entry for the
topic <topicname> was not found.
User response: When the affected file is the field
value of the parameter VOLUMES_FILE, you need to
check whether the topic name has the format:
>>> volumes_set_#
where # is a placeholder for the volume set number (1,
2, etc.)
When the affected file is another file, you likely have
another error prior to this one. Otherwise, contact Data
Protection for mySAP support.
IDS1072E The source volume <serial number>
cannot be specified as a target volume
in the .fct file.
Explanation: DP for Snapshot Devices found one of
the source volumes in the list of target volumes in the
init<SID>.fct file.
User response: Ensure that the target volumes list in
init<SID>.fct does not contain any of the source
volumes.
IDS1073E No target volumes were specified for
the set <volumes_set_#> in file
<filename>.
Explanation: DP for Snapshot Devices has read file
<filename> contained in the parameter
VOLUMES_FILE. The format of the file is correct, but
the list of target volumes is missing.
User response: See the description of the FlashCopy
target volumes file under DP for Snapshot Devices
Target Volumes File on page 155.
IDS1074E The backup ID (timestamp) is empty.
This FlashCopy backup cannot be used
for FlashBack Restore.
Explanation: Prior to this error, the warning
IDS1041W is displayed. The backup ID (timestamp) is
mandatory for using a FlashCopy backup for the
restore. The program tdphdwdb2 was not able to
generate a timestamp.
User response: Check for preceding errors. Check if
the backup to Tivoli Storage Manager ended
successfully.
IDS1075I Creating a semaphore for the critical
part of importing/exporting ...
Explanation: When multiple production systems run a
backup via a single backup system at the same time,
DP for Snapshot Devices will ensure that the critical
parts of the code run for a single instance of the
program at a time. These phases are:
1. when the FlashCopy has been done and resources
(volume groups and file systems) are being enabled
2. before the FlashCopy relationship is withdrawn and
resources (volume groups and file systems) are
being disabled.
For this synchronization process, a semaphore with the
fixed key 0x88886666 will be created.
User response: None
IDS1076I Trying to set the semaphore for the
critical part of importing/exporting ...
Explanation: If the DP for Snapshot Devices
semaphore is already allocated, the program will wait
until it is released. Otherwise, the program will set it
and pass into the critical part of the run. Another
instance arriving at this point will now have to wait for
the release of the semaphore.
User response: None
Messages and Codes
IDS1077I Semaphore released.
Explanation: After the program has passed the critical
part of the run, the semaphore is released.
User response: None
IDS1078W The semaphore could not be created.
System error <sys_errno>:
<sys_message>.
Explanation: If DP for Snapshot Devices could not
create the semaphore, the system error number and
message will be issued as a warning. The concurrent
run of multiple production systems with a single
backup system will not work properly.
User response: Check the system error number and
message with your system administrator.
IDS1079W The semaphore could not be initialized.
<sys_message>.
initialize the semaphore, the system error number and
IDS1080W The semaphore could not be allocated.
<sys_message>.
allocate the semaphore, the system error number and
IDS1081W The semaphore could not be released.
System error <sys_error>:
<sys_message>.
allocate the semaphore, the system error number and
IDS1082E Duplicate target volume serial number
was found in the target list.
Explanation: DP for Snapshot Devices found a
duplicate serial number for a target volume in the file
specified in the VOLUMES_FILE parameter.
User response: Ensure that the serial numbers of the
target volumes in the file VOLUMES_FILE are unique.
IDS1084I This is your last chance to stop the
FlashBack Restore. Please enter c[ont]
to continue or s[top] to cancel.
Explanation: DP for Snapshot Devices will ask the
user a last time before the program begins with the
restore process. After that the original data will be
overwritten with the data of the FlashCopy backup.
User response: Be sure that you want to restore from
the FlashCopy backup.
IDS1085E You cannot restore from a FlashCopy
backup of the type NOCOPY.
Explanation: Only the FlashCopy backups made with
the parameter FLASHCOPY_TYPE set to COPY or
INCR can be used for the FlashBack Restore.
User response: Normally the calling program must
make sure to determine one backup sequence number
that contains a FlashCopy backup of type COPY or
INCR. Check for preceding errors.
IDS1086E You cannot run the function flashback
if the backup status indicator (BSI) has
a value of bsi_value.
Explanation: The flashcopy function can only be
called with a backup sequence number that has a
backup status of BSI_DISKONLY or
BSI_DISKANDTAPE. All other values such as
BSI_START, BSI_TAPEONLY or BSI_INVALID are not
allowed.
determine one backup sequence number that contains a
FlashCopy backup with one of the allowed values for
the backup status indicator. Check for preceding errors.
IDS1088W One or more errors were found
disabling the production system
resources.
Explanation: Before the actual FlashBack Restore to
the database volume occurs, DP for Snapshot Devices
will do the following: .
1. unmount of the database file systems .
2. in case of LVM mirroring
remove the mirror copies from the logical volumes
remove the mirror physical volumes from the
volume groups
3. remove the volume group from the AIX ODM .
Messages and Codes

One or more of these operations have ended with
errors. DP for Snapshot Devices will issue a warning
but the FlashBack Restore will continue.
User response: None
IDS1089I The FlashBack Restore was previously
started using the target set id. Please
enter c[ont] to restart again or s[top]
to cancel.
Explanation: Having a valid disk backup on the target
volumes, the user is always able to start the FlashBack
Restore again, even though the background copy of a
prior FlashBack Restore is still running. This can also
be necessary if, for example due to an unexpected
situation on the production system, the mounting of
the file systems fails after the successful FlashCopy
reverse of the volumes.
User response: If DP for Snapshot Devices fails for
some reason during the FlashBack Restore between the
statements #UNMOUNTING_FS and #FS_MOUNTED,
then the user should restart the FlashBack Restore.
Enter c to continue or s to stop.
IDS1091E You cannot run the function function if
the restore status indicator (RSI) on
target set id has a value of RSI_START.
Explanation: If the restore status RSI of the target set
has a value of RSI_START, then a FlashBack Restore is
still running in the background. You cannot start a
FlashCopy backup again until the background copy to
the database volume is finished. In this case the RSI
value is either RSI_DISKONLY or in case of LVM
mirroring RSI_DISKANDLVM.
User response: Wait until the FlashCopy background
process is finished.
IDS1092E FlashCopy failed.
Explanation: The procedure for establishing the
FlashCopy relationship between the source and target
volumes in the storage subsystem failed.
User response: This is a significant error because the
source/target pair could be left in a different state.
Check for prior errors, and check the connection to the
CIM agent and to the storage subsystem. In case of the
FlashCopy backup, you need to start the withdraw
function of splitint to clean up the relationships. In the
case of a FlashBack Restore, restart the restore. The
software will detect the state and ask you for the
withdraw.
IDS1093E The target set id was not found.
Explanation: For the handling of 2 different LVM
mirror sets, the user must now specify 2 different target
sets in the .fct file. The parameter
HARDWARE_ID_LVM_MIRROR, which determines
which hardware unit should be taken as the source,
will be specified here under the corresponding target
set as well. Internally DP for Snapshot Devices keeps
the status of each target set (progress status, backup
status, restore status, backup sequence number, etc) in
the housekeeping directory. After the FlashCopy, DP for
Snapshot Devices will reread the target set information.
This message will only be displayed if this information
was destroyed, is corrupt or something unexpected
occurs.
IDS1097E The option -f set_bki_info can only be
Explanation: DP for mySAP (backint) calls DP for
Snapshot Devices with the function -f set_bki_info for a
FlashCopy backup on the backup machine after the
mount of the file systems. This call is not allowed on
the production machine.
User response: Consult the documentation to
understand the flow of the FlashCopy backup in an
SAP environment.
IDS1100E The parameter
HARDWARE_ID_LVM_MIRROR has
to be moved from the profile
filename.fcs to the corresponding
target set in filename.fct
Explanation: In case of AIX LVM mirroring the
parameter HARDWARE_ID_LVM_MIRROR indicates
the identifier of the hardware unit to be selected for the
mirror copy that should be used for the FlashCopy.
This parameter is now contained in the target set
topic(s) in the .fct file.
User response: Move the parameter from the .fcs to
the .fct file.
IDS1102E The target set id target_set_id could
not be read or inserted.
Explanation: For the handling of 2 different LVM
mirror sets, the user must now specify 2 different target
sets in the .fct file. The parameter
HARDWARE_ID_LVM_MIRROR, which determines
which hardware unit should be selected for the
FlashCopy, will be specified under the corresponding
target set as well. Internally DP for Snapshot Devices
keeps the status of each target set (progress status,
backup status, restore status, backup sequence number,
etc) in the housekeeping directory. The file containing
the information of the target set could not be read or
written.
Messages and Codes
IDS1103W The restore status indicator (RSI) has a
value of RSI_INVALID on target set id.
Explanation: If the restore status RSI of the target set
has a value of RSI_INVALID, this means that a
FlashBack Restore was initiated but did not terminate.
Nevertheless, DP for Snapshot Devices will issue this
warning and continue with the FlashCopy backup.
User response: Check if the FlashCopy backup ended
successfully.
IDS1104E No target set assigned to the last backup
cycle. Specify the option -n target_set_ID.
Explanation: When called without the -n option, the
functions unmount and withdraw are applied to the
last backup cycle. However, one requirement for this is
that a target set was assigned to the last backup cycle.
The system ensures that a target set ID is always
assigned to the backup cycle during the FlashCopy
backup. This error can only occur as a consequence of
other very severe errors.
User response: Call the functions -f unmount or -f
withdraw together with the option -n target_set_ID.
To see the correlation of backup ID to target set ID call
the function -f ts_inquire. Check also for preceding
errors during the FlashCopy backup.
IDS1121I Getting the source volumes ...
Explanation: The first step of DP for Snapshot Devices
in a FlashCopy backup is to determine the source
volumes from the list of files passed by the
corresponding calling UI backup tool.
IDS1122I FlashCopying the sources to the target
volumes ...
Explanation: After finding the pairs of volumes to be
copied, DP for Snapshot Devices signals to the calling
program to set the database into backup mode or shut
down the database. Then the actual FlashCopy can be
requested to the Copy Services server.
User response: None
IDS1123I Enabling the volumes and filesystems ...
Explanation: After the FlashCopy, the target volumes
attached to the backup machine are imported in the
operating system and the file systems are mounted
User response: None
IDS1125I Checking AIX LVM mirroring ...
environment, DP for Snapshot Devices ensures that the
LVM mirror setup complies with the requirements
listed below prior to and after the actual FlashCopy:
1. The quorum of each involved volume group must
be off. This means that if a mirror set is inactive
due to a failure, the database can continue working
properly (see EEP0164E).
2. Each logical volume must have at least two copies
(see EEP0166E).
3. Each logical volume must have the parallel
scheduling policy (see EEP0168E).
4. The mirror set that resides in the hardware unit that
was chosen for the FlashCopy must be free of stale
partitions (see EEP0176E).
5. All the partitions of each logical volume copy must
reside on the physical volumes of the same
hardware unit (see EEP0174E).
6. Each logical volume must have the mirror write
consistency on (see EEP0172E). This ensures that the
mirror set used for the FlashCopy is consistent from
the point of view of the file system level.
User response: None
IDS1128I The parameter CLEAR_TARGET_PVID
in the profile filename.fcs is obsolete
and will be ignored.
Explanation: This parameter is no longer needed
because the clearing of the physical volume IDs now
depends directly on the value of the parameter
FLASHCOPY_TYPE and whether the backup is a
disk-only backup.
User response: Delete the parameter
CLEAR_TARGET_PVID from the .fcs file.
IDS1129E You cannot run an incremental
FlashCopy until all the changed tracks
are copied.
Explanation: If you set the parameter
FLASHCOPY_TYPE of the .fcs file to the value INCR,
then an incremental FlashCopy is issued. This means
that only the data that has changed since the last
time-zero (first incremental) or subsequent incremental
FlashCopy is copied. This helps reduce background
copy completion time when only a subset of the data
has changed.
User response: If you want to start a new time-zero
FlashCopy backup in any case, you must issue the
function withdraw.
Messages and Codes

IDS1130E The list of files passed by DP for
mySAP in the file temp_file is empty.
Explanation: DP for mySAP calls DP for Snapshot
Devices with the function set_bki_info to pass, among
other things, the backup ID and the list of files used by
backint. This list of files was now found to be empty.
User response: Check that you are using a compatible
version of backint for FlashBack Restore. The version of
backint must be v3.3.10 or higher.
IDS1131E DP for Snapshot Devices cannot be used
for partial restores. The following
database files are in the restore list but
were not on the backup list.
Explanation: Unlike other backup techniques, DP for
Snapshot Devices moves the complete data on a
physical volume instead of individual files. Two
requirements are necessary to build a backup of a
database:
1. The complete set of physical volumes making up a
so-called volume group must be moved.
2. Also, all the volume groups in which the database
resides must also be completely moved. The
operating system allows access to the data on each
physical volume only if all the volumes are
represented as a consistent group to the system.
Also, you can only start up a database if all the
volume groups containing the database files are
available.
User response: Restore the data using Tivoli Storage
Manager from tape.
IDS1133E Some of the production logical volumes
are mirrored. You have to set the
hardware unit ID in the parameter
HARDWARE_ID_LVM_MIRROR for
the corresponding target set in the .fct
file <filename>.
Explanation: DP for Snapshot Devices found that
some of the logical volumes on which the production
database resides are mirrored using the mirror
capability of the Logical Volume Manager. However,
the parameter HARDWARE_ID_LVM_MIRROR was
not specified in the .fct file. This parameter causes DP
for Snapshot Devices to make all the necessary checks
to get a consistent copy via the FlashCopy on the target
volumes in an LVM mirror environment.
User response: Set the parameter
HARDWARE_ID_LVM_MIRROR with the hardware
unit ID that is used for the FlashCopy.
IDS1134I Disabling the volumes and file systems
...
Explanation: Prior to the FlashBack Restore from the
backup to the production volumes, the production
volumes and file systems will be disabled. The
following actions will be started:
v unmount
v remove devices
v remove logical volumes
v vary off the volume group
v export volume groups.
IDS1135I FlashCopying the target to the source
volumes ...
Explanation: This message is displayed during the
FlashCopy restore process to the production volumes.
IDS1136I The parameter parameter_name was not
specified in the profile.
Explanation: The specified parameter was not found
in the .fcs profile. However, this does not impact the
program, and processing will continue with the default
value. If the parameter is FLASHCOPY_TYPE, the
default value will be used as the intended
FLASHCOPY_TYPE (see Intended and Effective
FLASHCOPY_TYPE on page 75).
User response: Add the specified parameter to the
profile if necessary.
IDS1137I The option -C copy_type will determine
the copy type. The parameter
FLASHCOPY_TYPE was not specified in
the profile.
Explanation: The argument of the command line
option -C specifies the FlashCopy type that should be
used. It overrides the default value of the parameter
FLASHCOPY_TYPE.
IDS1138E The parameter
HARDWARE_ID_LVM_MIRROR for
the target set target_set_id is set in the
.fct-file file_name, but the production
logical volumes are not mirrored.
Explanation: The HARDWARE_ID_LVM_MIRROR
parameter should only used in an LVM mirror
environment.
User response: If you want to use this feature you
need to mirror the production logical volumes on
source volumes residing on different hardware units.
Otherwise, remove the parameter
Messages and Codes
HARDWARE_ID_LVM_MIRROR parameter from the
.fct file.
IDS1141E The option -n <target_set_ID> must be
specified.
Explanation: The option -n is used to specify the
FlashCopy target set that should be used by DP for
Snapshot Devices. It is required for the function -f
modify_copyrate.
User response: Specify the target set involved using
the option -n <target_set_ID>.
IDS1142I The progress status indicator (PSI) is
already PSI_WITHDRAW_DONE.
Explanation: A rerun of the withdraw function will
detect that the progress status of the specified (option
-n) or last FlashCopy backup is already
PSI_WITHDRAW_DONE.
User response: If for some reason the status
PSI_WITHDRAW_DONE is not in sync with the status
of the source/target relationships, the withdraw_force
function can be used.
IDS1143E The function withdraw_force requires
src/tgt pairs to be specified in the .fct
file file_name. The matching list of
src/tgt volumes could not be set.
Explanation: In contrast to the normal withdraw
function, where the source/target volumes are taken
from the local repository, the withdraw_force function
needs to get this information from the .fct file. The
reason for that is that the withdraw function removes
the matching list from the local repository, because a
restore after a withdraw is not allowed.
User response: Check the .fct file.
IDS1147I Reconciling the local snapshot directory
with the storage system....
Explanation: In the case of N series, Tivoli Storage
Manager for ACS checks that, for each snapshot kept in
its Local Snapshot Manager, a valid snapshot exists on
the N series storage system.
User response: None
IDS1148I Deleting the snapshot 'snap id' of the
volumes in the data container 'dc id'.
Explanation: The specified snapshot will be deleted.
User response: None
IDS1174E The option -b backup ID or -b backup
sequence number must be specified.
Explanation: The call of splitint with the function -f
flashback requires a backup sequence number (also
called backup cycle number) or timestamp that is a
unique identifier for the backup to be restored. With
this identifier DP for Snapshot Devices will find the
volumes target set containing the disk backup to be
restored.
determine one valid backup ID or backup sequence
number to be passed. Check for preceding errors.
IDS1175E The backup ID or the backup sequence
number identifier was not found.
Explanation: DP for Snapshot Devices did not find
any entry in the IDSSAVE for the specified backup ID
or backup sequence number.
IDS1176I The target set target_number does not
contain a valid FlashCopy backup.
(backup ID identifier).
Explanation: This message can be displayed when DP
for mySAP calls DP for Snapshot Devices to inquire for
disk backups on the target sets. The target sets are
enumerated starting with 1.
IDS1177E The FlashCopy run backup sequence
number was not a valid disk backup.
Explanation: To do a FlashBack Restore, a valid disk
backup must exist on one of the target sets. The backup
status indicator (BSI) must have the value
BSI_DISKONLY or BSI_DISKANDTAPE.
User response: Check the backup status indicator
(BSI) of your target volumes calling the tdphdwdb2
executable: tdphdwdb2 -p initSID.fcs -f ts_inquire -n
target set number
IDS1178E The backup status indicator (BSI) for
the FlashCopy run backup sequence
number is not valid.
Explanation: The backup status indicator can accept
one of the following values in the IDSSAVE:
v BSI_START: a disk backup as background copy was
started and is still running
v BSI_TAPEONLY: only a backup on TSM is available
v BSI_DISKONLY: only a backup on disk is available
Messages and Codes

||
|
|
|
|
|
|
||
|
|
|
v BSI_DISKANDTAPE: both disk and TSM backups are
available
v BSI_INVALID: invalid entry for disk backup
Any other value is not allowed and makes the backup
cycle unusable.
(BSI) of your IDSSAVE calling the tdphdwdb2
executable with the option -f inquire : tdphdwdb2 -p
initSID.fcs -f inquire -b backup sequence number
Check for preceding errors.
IDS1179E The backup status indicator (BSI) for
target set number is not valid.
Explanation: The backup status indicator can accept
one of the following values for one specific target set:
v BSI_START: a disk backup as background copy was
started and is still running
v BSI_TAPEONLY: only a backup on TSM is available
v BSI_DISKONLY: only a backup on disk is available
v BSI_DISKANDTAPE: both disk and TSM backups are
available
v BSI_INVALID: invalid entry for disk backup
Any other value is not allowed and makes the backup
cycle unusable.
executable with the option -f ts_inquire (target set
inquire): tdphdwdb2 -p initSID.fcs -f ts_inquire -n
target set number Check for preceding errors.
number is a valid disk backup.
Explanation: DP for Snapshot Devices has found that
the selected backup to be restored has a valid disk
backup with an entry in the IDSSAVE.
User response: None
number is not the last backup of target
set number.
Explanation: The specified backup sequence number
cannot be used for FlashBack because on the target
volumes a newer FlashCopy run was already entered.
executable with the option -f ts_inquire (target set
inquire): tdphdwdb2 -p initSID.fcs -f ts_inquire -n
target set number Select another backup Id for
FlashBack.
IDS1182E No target set ID could be assigned to
the backup run backup_sequence_number.
Explanation: During a FlashCopy backup, TSM for
Advanced Copy Services tries to find a target set (data
container) that matches the source data container to
satisfy the FlashCopy backup. It can be a target set in
the state AVAILABLE or the state IN_USE (in which
case it will be re-used). A matching target data
container could not be found, however.
User response: See the rules for selecting one of
multiple target data containers. For example, this
message will be displayed if the user is trying to start a
FlashCopy backup of type INCR and all the target sets
are being used for the FlashCopy type COPY. Also
make sure that the target volumes are available to the
backup system and the syntax is correct for the
following parameters:
v TARGET_VOLUME
v PRIMARY_COPYSERVICES_SERVERNAME
IDS1183I A disk-only backup (option -d) was
invoked, forcing the parameter
FLASHCOPY_TYPE of the .fcs-file to
COPY.
Explanation: If the user specified a disk-only backup
via the parameter -d and the parameter
FLASHCOPY_TYPE of the .fcs file has the value of
NOCOPY, DP for Snapshot Devices sets the value to
COPY.
IDS1184I Checking the backup status on Tivoli
Storage Manager and on disk ...
Explanation: This message is displayed by DP for
Snapshot Devices during the inquiry of the backups on
Tivoli Storage Manager and on disk.
IDS1185I Reading the SAP backup log
<PATH>/back<SID>.log ...
Explanation: This message is displayed by DP for
Snapshot Devices while reading the backup of the SAP
system ID <SID>.
IDS1186E The parameter param in the profile
<.sap file name> or the environment
variable env_var is required.
Explanation: This error is issued by DP for Snapshot
Devices if the specified parameter of the .sap file
passed by the option -p could not be read.
User response: Check that the passed .sap file is a
Messages and Codes
valid setup file for the SAP environment.
IDS1189E The option -C copy_type will override
the value value of the parameter
FLASHCOPY_TYPE in the profile.
Explanation: The value of the copy type parameter in
the option -C copy_type, if specified in the command
line, will override the value found in the DP for
Snapshot Devices profile (.fcs)
IDS1190E The information of the source/target
volumes could not be found.
Explanation: The executable splitint will be started
automatically as a daemon (sometimes referred as
fcagent) to monitor the background copy. An attempt to
obtain the status of the copy process has failed.
User response: Check the error log
file splitint_[p|b]_runagent_jjjjmmddHHMMSS.log in
the directory specified in the parameter
LOG_TRACE_DIR of the .fcs file. Check the availability
of the storage system using the applicable tool
(STORWATCH Specialist, DS Storage Manager, or SVC
console).
Check the parameters in the .fcs file:
v PRIMARY_COPYSERVICES_SERVERNAME
v COPYSERVICES_SERVERPORT
Also verify the availability of the CIM agent and its
connection to the storage system as described in the
storage-system documentation.
IDS1191I The target volumes set number does
not contain a valid disk backup.
Explanation: This informational message is displayed
during the call of the function get_disk_backups of DP
for Snapshot Devices (which is issued by the calling UI
backint or DP for Snapshot Devices) if one of the target
sets contains an invalid disk backup.
IDS1192I No disk backups were found on the
target volumes.
backint or DP for Snapshot Devices) if none of the
target sets contains a valid backup.
User response: You will have to select a backup from
Tivoli Storage Manager.
IDS1193I The FlashCopy run with backup ID id
was of type NOCOPY.
backint or DP for Snapshot Devices) if one of the target
sets contains a FlashCopy backup of type NOCOPY.
IDS1194I The FlashCopy run
backup_sequence_number has a
backup status indicator (BSI) of status
and is therefore not valid for FlashBack.
backint or DP for Snapshot Devices). The values of the
backup status (BSI) BSI_DISKONLY and
BSI_DISKANDTAPE are valid values for a FlashBack
Restore. The values BSI_START and BSI_TAPEONLY
could be valid values at a later point in time. Any other
value is invalid.
IDS1196E The list of files to be restored does not
exist for the specified backup ID
identifier.
Explanation: A FlashCopy disk backup can only be
restored in coordination with DP for mySAP. At restore
time, DP for Snapshot Devices has to know about the
corresponding list that was passed at backup time.
User response: Check that you have the version of DP
for mySAP supporting FlashBack Restore. Otherwise,
you will have to restore from Tivoli Storage Manager.
IDS1197I The list of files to be restored does not
exist for the FlashCopy run
backup_cycle_number.
backint or DP for Snapshot Devices) if the list of files
was not found for one of the target sets.
IDS1200E The exception CIdsException was
thrown.
Reason: <reason text>
Explanation: At present, the only reason text is: Not
enough memory space. Allocation error in file <file
name>, line <line number>.
User response: Ensure that db2<sid> and the root
user have the right setting for memory allocation. The
Messages and Codes

output of ulimit shows these values. Check the SAP
documentation for the respective release installed.
Perform the following steps as recommended by SAP:
Checking Created Users
Check, as root, all existing users. To do this:
1. Enter the command smitty.
2. Select: Security & Users .Users .Change/Show
Characteristics of a User
3. Press F4 to get a list of users.
4. For user root and each created user <user>:
a. Select <user>.
b. Change field Soft CPU time to -1 (this is the
default value).
c. Change field Soft CORE file size to 2097151 (this
is the default value).
d. Change field Soft FILE size to 4194302.
e. Change field Soft DATA segment to -1.
f. Change field Soft STACK size to -1.
You must make sure that the system-wide default
HARD values are not explicitly defined to be lower
than the number indicated above. Check the file
/etc/security/limits under the default: stanza. If they
are not explicitly set, then the values are as shown in
the table at the top of the file.
IDS1212W One or more errors were found checking
the FlashCopy relations.
Explanation: This message can appear during the
FlashBack Restore if the check of the source/target
relations ended with any error that originated in the
storage subsystem. This check takes part before any
resource is removed.
User response: Examine the preceding message
output.
IDS1300E Cannot read file: <filename>.
read the data file <filename>. The affected files could
be, e.g.:
v <INSTHOME>/dbs/init<SID>.fcs
v the argument value of the option -i (file containing
the list of files to back up)
v <config_file>
v <ids_control_file>
v the field value of EXCHANGE_FILE in a backup
cycle record.
User response: Check the access permissions of the
affected file and try again.
IDS1301E Cannot write file: <filename>.
write to the data file filename. The affected files could
be, e.g.:
v <LOG_TRACE_DIR>/splitint_b_
<date_time_stamp>.log
v <LOG_TRACE_DIR>/splitint_p_
<date_time_stamp>.log
v <LOG_TRACE_DIR>/splitint_b_
<date_time_stamp>.trace
v <LOG_TRACE_DIR>/splitint_p_
<date_time_stamp>.trace
v <config_file>
v the field value EXCHANGE_FILE in a backup cycle
record.
IDS1302E The environment variable <env_var>
must be set.
Explanation: The environment variable <env_var> is
required. The following environment variables must be
set when running DP for Snapshot Devices:
v INSTHOME: to the home directory of the DB2 user
v DB2INSTANCE: to the DB2 instance
v DB2DBDFT: to the DB2 default database
User response: Set the missing environment variable
and try again.
IDS1303E The environment variable <env_var> is
not correct.
Explanation: This error can occur when the
environment variable is set but contains a non-existent
directory path.
User response: Check the value of the environment
variable and try again.
IDS1304E File not found or not accessible:
<filename>.
Explanation: The file <filename> was not found or is
not accessible to DP for Snapshot Devices. The affected
files could be: <INSTHOME>/dbs/init<SID>.fcs or the
argument value of the option -i (the file that contains
the list of files to back up).
User response: Check path, name and the permissions
of the file and try again.
IDS1305E The effective user ID of the process
could not be set to the user <userid>.
Explanation: One of the following cases can cause this
error:
v the access rights for splitint are not set to 4750.
Since the s-bit is not set, DP for Snapshot Devices
cannot switch between the users db2<sid> and
root during the execution of the program.
v the file system in which splitint is installed was
mounted with the NOSUID option.
User response:
Messages and Codes
||
|
|
|
|
|
|
|
|
v Check the splitint file in the directory
/usr/tivoli/tsm/acssap/db2/x.y.z, and set the access
rights for splitint with chmod 4750 splitint. After
the installation, the command
ls -l splitint.... outputs a line such as:
-rwsr-x--- 1 root dba 1918611 Apr 11 17:09 splitint
(This is what setup.sh would do if the user had used
it.)
v If the file system in which splitint is installed was
mounted with the NOSUID option, mount the file
system with SUID allowed.
IDS1306I Issuing command command_string ...
Explanation: DP for Snapshot Devices is running the
specified system command with the parameter as
shown.
IDS1308W Warning: File <file name> still exists on
the backup system.
Explanation: DP for Snapshot Devices checks at the
start of the function flashcopy if any of the files passed
in the file list still exist on the backup system. If so, this
warning will be issued. Normally, none of the files
should exist because the withdraw function, which
should run prior to the FlashCopy, unmounts the files
systems, varies them offline, exports the volume
groups, and removes the devices.
User response: Always run the function withdraw
prior to starting the FlashCopy again.
IDS1310W The free space in the file system
containing the directory path is only
amount MB.
Explanation: The existing free space of the file
systems containing the following directories will be
checked:
v the database home directory and
v the directory specified by the parameter
LOG_TRACE_DIR in the .fcs file and
v the directory containing the idssave file specified by
the parameter IDS_CONTROL_FILE in the .fcs file.
If the free space of these file systems falls below 50 MB,
DP for Snapshot Devices warns the user. If it is under 5
MB an error will be issued and the program fails,
throwing an exception.
User response: Ensure that the free space on these file
systems is large enough.
IDS1311W splitint requires free space of at least 5
MB in the file system containing the
directory path.
Explanation: If the free space of the checked file
systems (see the explanation for IDS1310W) is under 5
MB this error message will be issued and the program
fails throwing an exception.
User response: Ensure that the free space on the
database file system is large enough.
IDS1318E Operating system error <error_no>:
<message text>.
Explanation: DP for Snapshot Devices encountered an
unexpected-message error during the execution of a
system function. The respective operating system error
and message text will be displayed. The message will
appear, for example, as a result of
v an incorrect user ID on the parameter
LOGON_HOST_PROD in the .fcs file
v an incorrect password given for the user ID on the
parameter LOGON_HOST_PROD in the .fcs file
v an incorrect TCP/IP name on the parameter
LOGON_HOST_PROD in the .fcs file (for example:
connection timeout)
v a failure allocating memory using the function
malloc, and the operating system cannot satisfy the
request
IDS1322I The file filename is locked, waiting
one second and retry!
Explanation: DP for Snapshot Devices saves control
information for the FlashCopy process in an internal
repository that consists of several files. Some of these
files may need to be written concurrently by several
processes. To ensure consistency, DP for Snapshot
Devices uses a lock mechanism.
IDS1325I Please check the messages above. Enter
r[etry] to retry or any other key to stop
the process.
Explanation: This message is asking you to retry an
operation that previously failed.
User response: Check the specific message and decide
whether to retry or stop the process. In the case of
critical restore runs, it is recommended to retry the
operation after the reason for the failure has been
identified and remedied.
Messages and Codes

||
|
|
|
|
|
|
|
|
|
IDS1326E Password input file <input file> not
found.
Explanation: The input file specified by the i <input
file> option was not found.
User response: Specify a vaild filename with full path
for the input file for the password/configure function.
IDS1327I Topic named <topic name> could not
be found in the file <input file>. The
password of user <username> will not
be changed.
file> option doesnt have the topic <topic name>
specified. The user <username> will not be changed.
There are two topic names (DBUSER, CSUSER). If none
of these topics are found in the <input file>, then no
password will be changed.
IDS1328W Parameter named <parameter name>
could not be found in the file <input
file>. The password of user
<username> will not be changed.
file> option doesnt have a valid format. The parameter
<parameter name> is not found in it. The password of
the user <username> will not be changed.
User response: Please check for the valid format of
the <input file>. Parameter <parameter name> is
required in the topics DBUSER and CSUSER.
IDS1329I The password of user <username> will
be changed.
file> option has a valid format and the password of the
user <username> of either the DBUSER or the CSUSER
topic will be changed.
IDS1330E The file <diskmapper filename> could
not be found. Please check that the
parameter DISKMAPPER_SCRIPT is
specified as a full qualified
path/filename.
Explanation: The script <diskmapper filename>
specified by the parameter DISKMAPPER_SCRIPT in
the DP for Snapshot Devices profile is not valid.
User response: Specify a vaild filename with full path
for the DISKMAPPER_SCRIPT parameter.
IDS1331E The file <filename> could not be
found. Please check that this file exists
or that the symbolic link points to an
existing file.
Explanation: The file <filename> is not valid.
User response: Please check that the file <filename>
exists or that the symbolic link points to an existing
file.
IDS1400E The backup status on target set
targetSetID must be BSI_DISKONLY or
BSI_DISKANDTAPE for re-use with
incremental copy type.
Explanation: A FlashCopy backup of type INCR in a
non-AIX LVM mirror environment will re-use the
already existing target set with FlashCopy type INCR
only if the background process is already finished.
User response: Check the background process by
starting the program splitint with the function inquire
or ts_inquire.
IDS1401E The target set targetSetID does not match
the source volumes.
Explanation: DP for Snapshot Devices checks whether
the target set for the FlashCopy backup contains a
target volume for each source volume, residing in the
same hardware unit and with the same size.
User response: Check the volume list of this target set
and ensure that the volumes are in the same hardware
unit and have the same size as the source.
IDS1402E A background copy process of type
CopyType is still running on target set
targetSetID.
Explanation: DP for Snapshot Devices fails if a
background copy is still running for the same logical
FlashCopy group (see Logical FlashCopy Group on
page 223). However, any target set (state AVAILABLE)
that does not yet belong to a logical FlashCopy group
(state AVAILABLE) can be selected.
User response: Check the backup status of the
FlashCopy backups that may be running.
IDS1404I The target set with ID targetSetID is
selected for this run.
Explanation: DP for Snapshot Devices use two
procedures for the selection of a target set. See
Algorithm Used for Automated Target Set Selection
Using the Intended FlashCopy Type on page 225 and
Algorithm Used for Specific Target Set Selection on
page 226.
Messages and Codes
||
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
IDS1405E No target set found to accept a backup
of type copy_type.
Explanation: If all the target sets are being used with
the same type of logical FlashCopy group (either INCR
or COPY), you will not find a target set to make a
FlashCopy with a different copy type.
User response: To make a target set AVAILABLE, start
the function withdraw on the specific target set using
the option -n.
IDS1408E The copy type argument copy_type is not
valid.
Explanation: The argument (FLASHCOPY_TYPE) of
the command line option -C <FLASHCOPY_TYPE> can
have the following values: COPY, NOCOPY and INCR.
Any other value is not valid. Furthermore, INCR is not
valid for an SVC configuration.
User response: Specify one valid value.
IDS1410E You cannot run a FlashBack Restore
from target set targetSetID if the sources
are involved in a relationship of type
copytype with the target set targetSetID
Explanation: DP for Snapshot Devices exploits the
feature Multiple Relationship FlashCopy of the
storage system. This means that for DP for Snapshot
Devices the source set of volumes can participate in
multiple FlashCopy relationships with several target
sets of volumes. However, there are some limitations: -
v A source can have up to 12 targets
v A target can only have one source
v A target cannot be a source at the same time
User response: To start a FlashBack Restore
(FlashCopy in reverse, from the target to the source
volumes) you have to withdraw the relationship with
the specified target set.
IDS1411E The intended FlashCopy type has a
value of copy_type.
Explanation: See Intended and Effective
FLASHCOPY_TYPE on page 75.
IDS1413E An invalid value copy_type has been
specified for the FlashCopy type in the
profile .fcs file.
Explanation: The parameter FLASHCOPY_TYPE of
the DP for Snapshot Devices profile (.fcs file) can have
the following values: COPY, NOCOPY and INCR. Any
other value is not valid. INCR is invalid for an SVC
configuration.
User response: Specify one valid value.
IDS1418E The target set targetSetID is already
using incremental FlashCopy.
Explanation: Using the procedure of specific target set
selection, it is not allowed to select more the one target
set for incremental FlashCopy on the same storage
device.
User response: Re-use the same target set or
withdraw the existing relationship.
IDS1452E This version of Data Protection for
Snapshot Devices for mySAP has
expired.
Explanation: This is a test version that has expired.
User response: Order a release version of Data
Protection for Snapshot Devices for mySAP or contact
your IBM/Tivoli marketing representative.
IDS1453W This version of Data Protection for
Snapshot Devices for mySAP will expire
in number days.
Explanation: This is a test version with a time limit. It
will expire in number days.
User response: Order a release version of Data
Protection for Snapshot Devices for mySAP or contact
your IBM/Tivoli marketing representative before the
version expires.
IDS1454I *** This copy is NOT FOR RESALE. ***
Explanation: This version is not for resale.
IDS1455E License file filename does not exist.
Explanation: The license file agentess.lic was not
found where expected.
User response: Make sure that the agentess.lic file
resides in the same directory as the init<SID>.fcs
profile.
IDS1456E Unable to access license file file name.
Explanation: Unable to access license file.
User response: Make sure the access permissions
allow read/write access.
IDS1457E License file file name contains invalid
data/checksum.
Explanation: The license file is invalid.
User response: Make sure you have the right
agentess.lic file installed.
Messages and Codes

IDS1520E The FlashCopy agent can only be started
if the last FlashCopy run was of type
COPY or INCR.
Explanation: DP for Snapshot Devices will
automatically start a daemon called the FlashCopy
agent to monitor the background copy, provided the
parameter FLASHCOPY_TYPE of the .fcs file was set to
COPY or INCR.
User response: Normally, the calling program will
control this process. Check for preceding errors.
IDS1531E Timestamp string cannot be converted.
Explanation: The status of the background copy will
be written by the FlashCopy agent daemon to a file
named fc_exchange.bseq_number in the directory
containing the IDSAVE specified by the parameter
IDS_CONTROL_FILE. The file
fc_exchange.bseq_number has, for each volume pair,
the entry volume_pair: target source size state
YYYY-MM-DD-HH.MM.SS YYYY-MM-DD-HH.MM.SS
rate, where target is the serial number of the target
volume, source is the serial number of the source
volume, state can be active if the background copy is
running or none if the background copy is finished.
YYYY-MM-DD-HH.MM.SS represents approximate
times for the start and end of the background process
(in seconds since 00:00:00 GMT, January 1, 1970, which
is the time standard the operating system uses), and
rate is the transfer rate within the storage system. To
calculate the transfer rate some conversion is needed.
When doing this conversion, an error occurred. The
rate value will be invalid.
User response: Check the date and time setting of the
machine.
IDS1540I Start of the FlashCopy agent on the
backup system
automatically start a daemon (called the FlashCopy
agent) to monitor the background copy after the start
of a FlashCopy backup of type COPY or INCR on the
backup system.
User response: None
IDS1541I Removing the FlashCopy agent on the
backup system
automatically stop the FlashCopy agent daemon after
the background copy has finished on the backup
system.
User response: None
IDS1545I Start of the FlashCopy agent on the
production system
automatically start a daemon (called the FlashCopy
agent) to monitor the background copy after the start
of a FlashBack Restore on the production system.
User response: None
IDS1546I Removing the FlashCopy agent on the
production system
the background copy has finished the restore on the
production system.
User response: None
IDS1550E The FlashCopy agent could not be
added to /etc/inittab.
Explanation: DP for Snapshot Devices automatically
starts a daemon (called the FlashCopy agent) to
monitor the background copy after the start of a
FlashCopy backup of type COPY or INCR on the
backup system and after the start of the FlashBack
Restore on the production system. An entry in
/etc/inittab allows the daemon to be started
periodically. However, DP for Snapshot Devices was
unable to add an entry to /etc/inittab.
User response: Check the rights of the DP for
Snapshot Devices executable (splitint or tdphdwdb2).
IDS1551W The FlashCopy agent already exists in
/etc/inittab.
Explanation: DP for Snapshot Devices automatically
starts a daemon (called the FlashCopy agent) to
monitor the background copy after the start of a
FlashCopy backup of type COPY or INCR on the
backup system and after the start of the FlashBack
Restore on the production system. An entry in
/etc/inittab allows the daemon to be started
periodically. In an attempt to add such an entry, DP for
Snapshot Devices detected that an entry already
existed.
User response: None
IDS1552E The FlashCopy agent could not be
removed from /etc/inittab.
system or, in the case of FlashBack Restore, on the
production system. The entry in /etc/inittab will be
removed. However, DP for Snapshot Devices was
unable to remove the entry.
Messages and Codes
User response: Check the rights of the DP for
Snapshot Devices executable (splitint or tdphdwdb2).
IDS1553W The FlashCopy agent has already been
removed from /etc/inittab.
system or, in the case of FlashBack Restore, on the
production system. The entry in /etc/inittab will be
removed. However, DP for Snapshot Devices detected
that the entry no longer exists in the table.
IDS1602I Waiting for SyncPoint number on all
EEE nodes...
Explanation: DP for Snapshot Devices is waiting for
all running tdphdwdb2 processes to reach the specified
SyncPoint.
IDS1603E Timeout of number seconds on waiting
for SyncPoint number on all EEE
nodes reached.
Explanation: While DP for Snapshot Devices is
waiting for all running tdphdwdb2 processes to reach
the specified SyncPoint, a time out condition occurs.
This error can have the following reasons:
1. The DP for Snapshot Devices parameter
DB2_EEE_SYNCTIMEOUT is set too low. Check the
DP for Snapshot Devices parameter
DB2_EEE_SYNCTIMEOUT in the DP for Snapshot
Devices configuration file.
2. DP for Snapshot Devices is not started for each
production server.
3. One or more DP for Snapshot Devices processes
running for the production servers were terminated.
User response:
1. Check the DP for Snapshot Devices parameter
2. Check that DP for Snapshot Devices is running on
the backup system for all production servers.
3. Check for error messages in the DP for Snapshot
Devices log files for each process.
IDS1605I The last socket synchronization is still
active.
Explanation: The last DP for Snapshot Devices socket
synchronization was not stopped.
IDS1606E Socket synchronization could not be
started.
Explanation: The last DP for Snapshot Devices socket
synchronization was not stopped. DP for Snapshot
Devices failed in trying to stop and restart the socket
synchronization.
User response: Restart the socket server on the
production server which holds the EEE or ESE
coordination partition. Use the function stopsocket.
After stopping the socket server, it will automatically
be restarted because of the entry in the /etc/inittab
file.
IDS1607I Socket server was not running.
Explanation: tdphdwdb2 was called with function
stopsocket to stop the socket server, but the socket
server was not running.
IDS1610E Invalid user name or password.
Explanation: While tdphdwdb2 is sending a socket
request from the socket client to the socket server, the
user and the encrypted password are checked on the
socket server. The user and/or password sent to the
socket server are incorrect.
User response: If the password for the user db2<sid>
or the Copy Services user ID is changed, the socket
server has to be restarted. The password for the users
has to be changed by calling the tdphdwdb2 function
configure.
IDS1620E The TCPIP service port number could
not be found in /etc/services.
Explanation: This error occurs, if the TCP/IP port for
the socket server communication is not configured in
the file /etc/services.
User response: Make sure, that the socket service
configuration is done by calling tdphdwdb2 with
function configure on the production system and that
the backup system is configured with the script
setupDB2BS. If the DB2 UDB EEE or ESE configuration
is changed (e.g. a new EEE/ESE partition is added),
you have to reconfigure the socket server, see:
Chapter 9, Considerations for DB2 UDB ESE with
DPF, on page 191.
Messages and Codes

Messages from tdphdwdb2
IDS2000E Profile not specified.
Explanation: DP for Snapshot Devices cannot locate
the profile.
User response: Ensure that a profile is available. Note
that the tdphdwdb2 call must have the following form:
<path>/tdphdwdb2 -p <path>/init<SID>.fcs -f
<function>....
IDS2001E Function not defined.
for the -f option of DP for Snapshot Devices.
User response: Ensure that you pass a valid function
name with the option -f. Valid functions are: backup,
restore, query, flashcopy, withdraw, inquire, password.
IDS2005I Start of tdphdwdb2 program at: <time> .
Explanation: DP for Snapshot Devices started at time.
IDS2007I End of tdphdwdb2 program at: <time> .
Explanation: DP for Snapshot Devices ended at time.
Control will be returned to either the shell or to a script
when tdphdwdb2 was called by a script.
IDS2008E Parameter <keyword> in the profile file
required.
Explanation: The parameter <keyword> in the profile
for DP for Snapshot Devices could not be found. It
must be defined.
User response: Set the parameter <keyword> and its
value in the profile for DP for Snapshot Devices.
IDS2009E Directory path <path> for the IDS
control file does not exist!
Explanation: Either the entry for the parameter
CONTROL_FILE is incorrect or the path does not exist.
User response: Ensure that the parameter
CONTROL_FILE in the profile has a valid path. If the
path does not exist, you must create it.
IDS2010E Another instance of tdphdwdb2 is
running.
Explanation: DP for Snapshot Devices is already
running or the last run was abnormally terminated.
User response: If another DP for Snapshot Devices is
running, you must wait for the end of this run before
you can restart DP for Snapshot Devices. If no other DP
for Snapshot Devices is running, you must remove the
lock-file /db2/<SID>/dbs/work/.tdphdwdb2_lock
manually.
IDS2011E Option -f <function> not specified.
Explanation: tdphdwdb2 always requires the option -f
<function> with a valid function.
User response: Ensure that the tdphdwdb2 call has
the following form: <path>/tdphdwdb2 -p
<path>/init<SID>.fcs -f <function>....
IDS2012E The backup type <-t flashcopy> can
only be used on the backup system.
backup and backup type flashcopy. This combination of
parameters is only valid on the backup system.
User response: Ensure that tdphdwdb2 with function
backup and backup type flashcopy is called on the
backup system.
IDS2013E The arguments specified for the backup
type <-t flashcopy> are not valid.
backup and backup type flashcopy. You specified an
invalid argument for the backup type flashcopy.
User response: Ensure that you pass valid arguments
with backup type flashcopy. Valid arguments are:
no/unmount, no/withdraw.
IDS2014E The arguments <withdraw> and
<nounmount> for the backup type <-t
flashcopy> do not work together.
backup and backup type flashcopy and the optional
arguments nounmount and withdraw. This is an
invalid combination of the arguments for the backup
type flashcopy.
with backup type flashcopy. The combination
nounmount and withdraw is not valid.
IDS2015E The backup type -t online/offline can
only be used on the production system.
backup and backup type online/offline. This
combination of parameters is only valid on the
production system.
User response: Ensure that the tdphdwdb2 with
function backup and backup type online/offline is
called on the production system.
Messages and Codes
IDS2016E The option -f restore can only be used
restore. This parameter is only valid on the production
system.
function restore is called on the production system.
IDS2017E The option -f query can only be used on
the backup system.
query. This parameter is only valid on the backup
system.
function query is called on the backup system.
IDS2018E The option -f flashcopy can only be
flashcopy. This parameter is only valid on the backup
system.
function flashcopy is called on the backup system.
IDS2019E The option -f unmount can only be used
unmount. This parameter is only valid on the backup
system.
function unmount is called on the backup system.
IDS2020E The option -f withdraw can only be
withdraw. This parameter is only valid on the backup
system.
function withdraw is called on the backup system.
IDS2022E The backup type <type> is not valid.
Explanation: The backup type given with option t
<type> is not valid.
User response: Valid values for backup type are:
online, offline, flashcopy [no/unmount] [no/withdraw]
IDS2023E The socket options <-f initsocket> and
<-f stopsocket> can only be used on the
production system.
Explanation: You tried to start or stop the socket
server on the backup system but these functions can
only be used on the production system.
User response: None
IDS2024E The option -f dbresume can only be
used on the production system.
Explanation: You tried to resume the DB2 database on
the backup system but this function can only be used
User response: None
IDS2028E The arguments specified for the option
-f restore are not valid.
restore. You specified an invalid argument for the
function restore.
with function restore. Valid arguments are: database,
no/rollforward.
IDS2029E Error while checking filesystem size for
DB2 Logdir <logdir>.
Explanation: tdphdwdb2 checks the size of the DB2
Logdir filesystem. This check fails.
User response: Ensure that the DB2 Logdir filesystem
exists and is mounted.
IDS2030E Not enough freespace in DB2 logpath
(<logdir>). Need at least 55% freespace.
Explanation: tdphdwdb2 checks the freespace of the
DB2 Logdir filesystem. tdphdwdb2 needs at least 55%
freespace for copying all online logfiles to a
safe-directory in the same filesystem.
User response: Ensure that the DB2 Logdir filesystem
is large enough for the restore. You need twice the
space as usual for the DB2 logdir filesystem.
IDS2031E Backup Timestamp <time> cannot be
converted.
Explanation: tdphdwdb2 cannot read and convert the
backup timestamp from the db2 recovery logfile
(DB2_RECOVERY_LOG parameter).
User response: Ensure that the db2 recovery log file
can be accessed by tdphdwdb2 and is not corrupted.
Messages and Codes

IDS2032W Information from DP for mySAP has
not been found.
Snapshot Devices and DP for mySAP was not found
during the execution of the unmount function. Either
the DP for mySAP you have installed does not support
DP for Snapshot Devices, or DP for mySAP has failed
after a successful FlashCopy and mount.
User response: Check the run logs of tdphdwdb2. This
error could have various reasons and should be
resolved depending on the specific situation:
Case 1: tdphdwdb2 has finished successfully.
Result: The backup on disk (FlashCopy target volumes)
as well as the one done to the TSM server are valid.
However, DP for Snapshot Devices cannot show the
backup ID in its report when using the function
inquire.
Reason for warning: It is very likely that DP for mySAP
(AIX version) does not have DP for Snapshot Devices
support (prior to version 3.1.0.3).
Action: Install the appropriate DP for mySAP version.
Case 2: tdphdwdb2 has terminated abnormally.
Result: Check carefully the run log of tdphdwdb2 for any
BKI, ANS or ANR error messages. Most likely, the
backup on disk (FlashCopy target volumes) is valid
(check with splitint -f inquire whether PSI is
PSI_MOUNT_DONE or PSI_UNMOUNT_DONE), but
the backup to the TSM server is invalid.
Cause: Any problems with the network or on the TSM
server caused DP for mySAP to fail when running a
backup.
Action: Depending on the error message, eliminate the
reason for not getting a successful backup to the TSM
server.
IDS2033I Information from DP for mySAP has
been found with BACKUPID
<backupid>.
mySAP and DP for Snapshot Devices has been found
during the execution of the function unmount. The
backup on disk (FlashCopy target volumes) as well as
to the TSM server are valid. The list of files has been
saved in the Tivoli Storage Manager with the backup
ID <backupid>.
User response: None
IDS2035E The option -f restore can only be used
Explanation: You tried to start a restore on the backup
system but the function restore can only be used on the
production system.
User response: None
IDS2036E The options -b <backup sequence
number> or -b <backupID> must be
specified.
Explanation: The function you called needs the
additional parameter b <backup sequence number> or
-b <backupID>.
User response: Restart the function you called with
the b option.
IDS2037E The option -f configure can only be
Explanation: You tried to start the function configure
on the backup system but this function can only be
User response: None
IDS2038E The option -f configure can only be
used on the coordinating production
server.
Explanation: You tried to start the function configure
on a production server which does not hold the
coordinating EEE partition. This function can only be
used on the production server which holds the
coordinating EEE partition.
User response: None
IDS2039E The option -s <socket_port> can only be
used in EEE environments.
Explanation: Explanation: You called tdphdwdb2 with
option s but this option can only be used in DB2 UDB
EEE environments.
User response: None
IDS2040E The socket port <> specified with the
option -s <socket_port> is invalid.
Explanation: You specified an invalid port with the
option s. Valid numbers for this option can be found
in the DB2 EEE configuration file db2nodes.cfg.
User response: None
ID>
Explanation: The password for the user ID <user ID>
has to be entered. It will be encoded and stored in a
file specified in the parameter CONFIG_FILE. Note that
this user ID and password have to be the same on the
production and backup systems. The DP for Snapshot
Devices program splitint uses the user ID to access the
production system.
Messages and Codes
User response: Enter the password for the
corresponding user ID.
ID> again
Explanation: In order to avoid typing errors, you have
to enter the password twice.
User response: Enter the password again.
IDS2053I The password entry does not match,
please try again.
identical. You must enter the password again.
User response: Enter the password again. You are
permitted three attempts before the program
terminates.
IDS2054E No password stored.
identical. You have tried three times, and the
passwords were different in each case.
User response: You must start the tdphdwdb2
program with the function -f password again. If no
password is stored, or it is invalid, tdphdwdb2 fails
when the flashcopy function is used.
IDS2055E The config file named <config_file>
could not be opened. Please call
tdphdwdb2 with the function
configure to create this file.
read the configuration file <config_file>.
User response: This error could have various reasons.
Try the following:
1. Call tdphdwdb2 with the configure function to
create the file
2. Check the path of the configuration file. The path
must be specified in the profile (parameter
CONFIG_FILE)
3. Make sure that the file access permissions are set
correctly.
IDS2062E Invalid value <value> specified for
parameter <parameter> in the profile.
Explanation: The value specified for the parameter in
the profile is not valid.
User response: Check the specified value in the profile
and try again.
IDS2063E Parameters LOGON_HOST_PROD/
LOGON_HOST_BACK in Profile wrong
or missing.
Explanation: Either DP for Snapshot Devices is unable
to read one of the parameters LOGON_HOST_PROD or
LOGON_HOST_BACK from the profile, or the
parameter values are incorrect. Note that these
parameters must have the following format:
LOGON_HOST_PROD <tcp_name> <user ID>
LOGON_HOST_BACK <hostname>
The tcp_name must match the TCP/IP name via which
the production system can be reached from the backup
system. The host name must match the respective host
name of the backup system. The user ID specified must
match the DB2 user ID (db2<sid>).
User response: Ensure that the profile contains valid
entries for LOGON_HOST_PROD and
LOGON_HOST_BACK.
IDS2064E The parameter <keyword> in the profile
is not known.
Explanation: An unknown parameter <keyword> has
been found in the profile.
User response: Check the specified parameter in the
profile and try again.
IDS2065E You cannot run the function <function>
if the progress status indicator (PSI) has
a value of <psi>.
specified function.
User response: Refer to the permissible functions
depending on the backup progress status indicator.
IDS2071E Topic named <topicname> could not be
found in the file <filename>.
Explanation: DP for Snapshot Devices could read the
file <filename> but the expected entry for the topic
<topicname> was not found.
User response: When the affected file is the field
value of the parameter VOLUMES_FILE, you need to
check whether the topic name has the format:
>>> volumes_set_#
where # is a placeholder for the volume set number (1,
2, etc.) When the affected file is another file, you likely
have another error prior to this one. Otherwise, contact
IBM support.
Messages and Codes

IDS2090E The NLS catalog could not be loaded.
Make sure that the catalog <%s/%s>
exists.
Explanation: DP for Snapshot Devices uses an English
NLS catalog for the LVM and the storage-system part
of the product. The installation process will copy the
catalog to the displayed path.
User response: Check for errors during the installation
procedure.
IDS2094E You cannot use FlashBack Restore and
Restore from TSM together.
Explanation: In an EEE environment, for a restore of
the database, DP for Snapshot Devices must be started
on all production servers. You selected different types
of restore (FlashBack Restore and Restore from TSM)
for one restore run. This is not allowed by DP for
Snapshot Devices.
User response: You have to select the same type or
restore.
IDS2095W You have selected a different Backup ID
than on the coordinating server.
Explanation: In an EEE environment, for a restore of
the database, DP for Snapshot Devices must be started
on all production servers. You selected different Backup
IDs to restore. This is just a warning. DP for Snapshot
Devices allows to restore different Backup IDs.
User response: None
IDS2104E No target set assigned to the last backup
cycle. Specify the option -n
target_set_ID.
Explanation: When called without the -n option, the
functions unmount and withdraw are applied to the
last backup cycle. However, one requirement for this is
that a target set was assigned to the last backup cycle.
The system ensures that a target set ID is always
assigned to the backup cycle during the FlashCopy
backup. This error can only occur as a consequence of
other very severe errors.
User response: Call the functions -f unmount or -f
withdraw together with the option -n target_set_ID.
To see the correlation of backup ID to target set ID, call
the function -f ts_inquire. Check also for preceding
errors during the FlashCopy backup.
Explanation: The tdphdwdb2 program issues this
function failed.
IDS2174E The option -b backup ID or -b backup
sequence number must be specified.
Explanation: The call of splitint with the function -f
flashback requires a backup sequence number (also
called backup cycle number) or timestamp that is a
unique identifier for the backup to be restored. With
this identifier, DP for Snapshot Devices will find the
volumes target set containing the disk backup to be
restored.
IDS2175E The backup ID or backup sequence
number number was not found.
Explanation: The specified Backup ID or backup
sequence number could not be found in the DP for
Snapshot Devices housekeeping files.
User response: None
IDS2185I reading <DP for mySAP recovery log>
and checking backup status...
housekeeping files.
Explanation: DP for Snapshot Devices is reading the
information from the DP for mySAP recovery log file
and checks the entries with the DP for Snapshot
Devices
User response: None
IDS2200E The exception CIdsException was
thrown.
Reason: <reason text>
Explanation: At present, the only reason text is: Not
enough memory space. Allocation error in file <file
name>, line <line number>.
User response: Ensure that db2<sid> and the root
user have the right setting for memory allocation. The
output of ulimit shows these values. Check the SAP
documentation for the respective release installed.
Perform the following steps as recommended by SAP:
Checking Created Users
Check, as root, all existing users. To do this:
1. Enter the command smitty.
2. Select: Security & Users .Users .Change/Show
Characteristics of a User
3. Press F4 to get a list of users.
4. For user root and each created user <user>:
a. Select <user>.
b. Change field Soft CPU time to -1 (this is the
default value).
c. Change field Soft CORE file size to 2097151 (this
is the default value).
Messages and Codes
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
d. Change field Soft FILE size to 4194302.
e. Change field Soft DATA segment to -1.
f. Change field Soft STACK size to -1.
You must make sure that the system-wide default
HARD values are not explicitly defined to be lower
than the number indicated above. Check the file
/etc/security/limits under the default: stanza. If they
are not explicitly set, then the values are as shown in
the table at the top of the file.
IDS2300E Cannot read file: <filename>.
read the data file <filename>. The affected files could
be, e.g.: <INSTHOME>/dbs/init<SID>.fcs,
<config_file>, <ids_control_file> or the field value of
EXCHANGE_FILE in a backup cycle record.
IDS2301E Cannot write file: <filename>.
write to the data file filename. The affected files could
be, e.g.:
v one of the log/trace files as listed in Appendix C,
Summary of Log and Trace Files, on page 329.
v <config_file>
v the field value EXCHANGE_FILE in a backup cycle
record.
IDS2302E Environment variable <env_var> must
be set!
Explanation: The environment variable <env_var> is
required. The following environment variables must be
set when running DP for Snapshot Devices:
INSTHOME: to the home directory of the DB2 user
DB2INSTANCE: to the DB2 instance DB2DBDFT: to the
DB2 default database
User response: Set the missing environment variable
and try again.
IDS2303E Environment variable <env_var> is not
correct!
Explanation: This error can occur when the
environment variable is set but contains a non-existent
directory path.
User response: Check the value of the environment
variable and try again.
IDS2304E File not found or not accessible:
<filename>.
Explanation: The file <filename> was not found or is
not accessible to DP for Snapshot Devices. The affected
files could be: <INSTHOME>/dbs/init<SID>.fcs or the
argument value of the option -i (the file that contains
the list of files to back up).
User response: Check path, name and the permissions
of the file and try again.
IDS2305E The effective user ID of the process
could not be set to the user <userid>.
Explanation: One of the following cases can cause this
error:
v the access rights for tdphdwdb2 are not set to 4750.
Since the s-bit is not set, DP for Snapshot Devices
cannot switch between the users db2<sid> and
root during the execution of the program.
v the file system in which tdphdwdb2 is installed was
mounted with the NOSUID option.
User response:
v Check the tdphdwdb2 file in the directory
/usr/tivoli/tsm/acssap/db2/1.x.y.z, and set the
access rights for tdphdwdb2 with chmod 4750
tdphdwdb2. After the installation, the command
ls -l tdphdwdb2.... outputs a line such as:
-rwsr-x--- 1 root dba 1918611 Apr 11 17:09 tdphdwdb2
(This is what setup.sh would do if the user had used
it.)
v If the file system in which tdphdwdb2 is installed was
mounted with the NOSUID option, mount the file
system with SUID allowed.
IDS2306I Issuing command <cmd>
message when running a system command.
IDS2307I Issuing DB2 command <cmd>
message when running a DB2 command.
IDS2310W The free space in the file system
containing the directory <dir> is only
<freespace>.
Explanation: The existing free space of the file
systems containing the following directories will be
checked:
v the database home directory and
v the directory specified by the parameter
LOG_TRACE_DIR in the .fcs file and
Messages and Codes

v the directory containing the idssave file specified by
the parameter IDS_CONTROL_FILE in the .fcs file.
If the free space of these file systems falls below of 50
mega bytes, DP for Snapshot Devices warns the user. If
it is under 5 mega bytes an error will be issued and the
program fails throwing an exception.
User response: Ensure that the free space on these file
systems is large enough.
IDS2311E splitint requires free space of at least 5
MB in the file system containing the
directory <dir>.
Explanation: If the free space of the checked file
systems (see Explanation of IDS2310W) is under 5
mega bytes this error message will be issued and the
program fails, throwing an exception.
User response: Ensure that the free space on the
database file system is large enough.
IDS2315W Environment variable DB2NODE has
value <value>.
Explanation: In DB2 UDB EEE environments the
environment variable DB2NODE is used by DB2 to
attach or connect to a specified EEE partition. If this
variable is set prior to starting DP for Snapshot
Devices, then DP for Snapshot Devices must unset this
variable for the DP for Snapshot Devices execution.
User response: None
IDS2316E Environment variable DB2NODE could
not be unset!
Unset this variable and restart
tdphdwdb2.
Explanation: In DB2 UDB EEE environments the
environment variable DB2NODE is used by DB2 to
attach or connect to a specified EEE partition. If this
variable is set prior to starting DP for Snapshot
Devices, then DP for Snapshot Devices must unset this
variable for the DP for Snapshot Devices execution.
While trying to unset the variable DB2NODE, DP for
Snapshot Devices encountered an error.
User response: You have to unset the variable
DB2NODE manually and rerun DP for Snapshot
Devices.
IDS2317I Environment variable DB2NODE is
successfully unset.
Explanation: Explanation: In DB2 UDB EEE
environments the environment variable DB2NODE is
used by DB2 to attach or connect to a specified EEE
partition. If this variable is set prior to starting DP for
Snapshot Devices, then DP for Snapshot Devices must
unset this variable for the DP for Snapshot Devices
execution.
User response: None
IDS2326E The function -f restart_backup can only
be used on the backup system.
Explanation: You cannot start the restart_backup
function on the production system.
User response: Make sure you start tdphdwdb2 with
the function -f restart_backup on the backup system
only. Ensure that the profile contains a valid entry for
LOGON_HOST_BACK.
be started if the progress status
indicator (PSI) has a value of
PSI_MOUNT_DONE. Current value of
the progress status indicator (PSI) is
value.
restart_backup function. You can only use this function,
if the progress status indicator (PSI) has a value of
PSI_MOUNT_DONE.
User response: Specify the parameter
DB2_RESTART_TSM_BACKUP YES in the DP for
Snapshot Devices profile so that, on the next FlashCopy
backup run, the filesystems will be kept mounted on
the backup system so that the restart_backup function
can be used.
be used if the TSM backup failed for at
least one DB2 partition.
Explanation: The last FlashCopy backup run was
successful. The TSM backups of all DB2 partitions were
successfully completed or the restart_backup function
was already successfully started so that all DB2
partitions have been successfully backed up to TSM.
The function restart_backup can only be started if a
TSM backup of at least one DB2 partition has failed.
IDS2407E Not enough memory space.
Explanation: The operating system returned an error
while allocating memory.
User response: Check the memory settings for the
users root and db2<sid>. See message IDS2200E for
details.
IDS2408W Warning: File <file name> still exists on
the backup system.
Explanation: DP for Snapshot Devices checks at the
start of the function flashcopy if any of the files passed
in the file list still exist on the backup system. If so,
Messages and Codes
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
then this warning will be issued. Normally, none of the
files should exist because the withdraw function, which
should run prior to the FlashCopy, unmounts the files
systems, varies them offline, exports the volume
groups, and removes the devices.
User response: Always run the function withdraw
prior to starting the FlashCopy again.
IDS2500E DB2 command failed: <cmd>.
Explanation: The DB2 command <cmd> failed.
User response: Check for the SQL-Code returned by
the DB2 command and/or check for errors in the DB2
diag logfile.
IDS2501E DB2 connection to production database
<DBname> failed.
Please start the database manager on
production system.
Explanation: DP for Snapshot Devices tried to connect
to the DB2 database <DBname> on the production
system via a db2 remote connection. While trying to
connect, DP for Snapshot Devices encountered an error.
Typically in this error situation the database manager
on the production system was not started.
User response: If the database manager on the
production system was not started, the you have to
start it by calling db2start as user db2<sid> on the
production system. If the database manager was
already started, you have to check your network and
db2 setup. Possible reasons may be
v missing db2 instance level registry parameter
DB2COMM=TCPIP
v wrong db2 database manager configuration
parameter SVCENAME
v different db2 TCP/IP ports on the production and
backup system
IDS2502E Attachment to production DB2 instance
<instance> failed. Please check if the
database manager on production system
is started.
Explanation: DP for Snapshot Devices tried to attach
to the DB2 instance <instance> on the production
system via a db2 remote connection. While trying to
attach, DP for Snapshot Devices encountered an error.
Typically in this error situation the database manager
on the production system was not started.
User response: If the database manager on the
production system was not started, then you have to
start it by calling db2start as user db2<sid> on the
production system. If the database manager was
already started, you have to check your network and
db2 setup. Possible reasons may be
v missing db2 instance level registry parameter
DB2COMM=TCPIP
v wrong db2 database manager configuration
parameter SVCENAME
v different db2 TCP/IP ports on the production and
backup system
IDS2505E The DB2 instance <instance> is running
in <bitwidth> bit mode but tdphdwdb2
is running in <bitwidth> bit mode.
Explanation: DP for Snapshot Devices determined,
that the DB2 instance <instance> is running in
<bitwidth> bit mode. But the version of DP for
Snapshot Devices which is installed, is running in a
different bit mode. This is not allowed.
User response: You have to install the DP for
Snapshot Devices package with the correct bitwidth
IDS2510E The DB logretain mode is not
supported. Please switch logretain to
RECOVERY.
Explanation: The DB2 production database must be in
archival logging mode.
User response: Change the DB2 database
configuration parameter LOGRETAIN to RECOVERY
with the command: db2 update db cfg for <SID> using
LOGRETAIN RECOVERY Important: After changing
this parameter, you must restart the database and you
must perform a backup of the database.
IDS2511E The DB userexit mode is not supported.
Please switch DB userexit ON.
Explanation: The DB2 Userexit mode of the
production database must be set to on.
User response: Change the DB2 database
configuration parameter USEREXIT to ON with the
command: db2 update db cfg for <SID> using
USEREXIT ON
IDS2515E SMS tablespaces are not supported
Explanation: The DB2 production database must not
have any SMS tablespaces.
User response: Change the corresponding SMS
tablespace to be managed by database (DMS).
IDS2516E Tablespaces of type UNKNOWN are not
supported.
Explanation: DP for Snapshot Devices determined one
or more tablespaces with an unsupported type on the
production DB2 database. Only DMS tablespaces are
supported. .
User response: Change all tablespaces to DMS
Messages and Codes

IDS2517E Tablespace <TBSname> is not in
NORMAL state.
Explanation: DP for Snapshot Devices determined that
tablespace <TBSname> on the production DB2 database
is in an unsupported state.
User response: Make sure, that all tablespaces are in
state NORMAL
IDS2518E Tablespace container <CONTname> is
in exception state.
Explanation: DP for Snapshot Devices determined that
tablespace container <CONTname> on the production
DB2 database is in an unsupported state.
User response: Make sure, that all tablespace
containers are in state NORMAL
IDS2520I Node <nodename> has been created
Explanation: DP for Snapshot Devices has created a
new DB2 node <nodename> on the backup system. The
remote database on the production system will be
cataloged on this new node.
IDS2521I Database <DB alias name> has been
cataloged
Explanation: On the backup system DP for Snapshot
Devices has cataloged the remote database <DB alias
name> of the production system. This database alias
name is used to connect to the remote database on the
production system.
IDS2522I Press [ENTER] when all logfiles are
restored...
Explanation: DP for Snapshot Devices is waiting for
confirmation that all log files needed for the DB2
recovery process are restored from TSM.
User response: If you are performing a FlashBack
Restore and if you have configured the SAP DBA tools
(db2uext2, brarchive, brrestore) for indirect archiving
(using the SAP DBA administration database
ADM<SID>), you have to do the following steps, prior
to restoring the log files from TSM:
v drop the SAP DBA administration database
ADM<SID>
v recreate the SAP DBA administration database
ADM<SID> by calling sddb6ins r as user root.
IDS2550E Database <DBname> cannot be set to
write suspend mode
Explanation: DP for Snapshot Devices tried to
suspend the write activities on the production DB2
database.
User response: Make sure, the database is up and
running.
IDS2551E Database <DBname> cannot be set to
write resume mode
Explanation: DP for Snapshot Devices tried to resume
the write activities on the production DB2 database
User response: Make sure, the database is up and
running.
IDS2555E Connection to production system via
socket failed...
Explanation: DP for Snapshot Devices tried to connect
to the production system via TCP/IP socket
communication. Normally the cause for this error is,
that the DP for Snapshot Devices socket server on the
production system is not running or the configuration
for the DP for Snapshot Devices socket communication
on the production and / or backup system is incorrect.
User response: User Response: Check the DP for
Snapshot Devices socket configuration (/etc/services,
/etc/inittab) and check for a running DP for Snapshot
Devices socket server on the production system.
IDS2600E Starting synchronization for all EEE
nodes failed
Explanation: DP for Snapshot Devices tried to start
the synchronization for all DB2 logical / physical EEE
partitions on the production server which holds the
coordination EEE partition.
User response: Restart the socket server on the
production server which holds the EEE coordination
partition. Use the function stopsocket. After stopping
the socket server, it will automatically be restarted
because of the entry in the /etc/inittab file.
IDS2601E SyncPoint <port> was not reached for
all EEE nodes
Explanation: While DP for Snapshot Devices is
waiting for all running tdphdwdb2 processes to reach
the specified SyncPoint, one or more tdphdwdb2
processes have not reached this syncpoint. This error
can have the following reasons:
1. The DP for Snapshot Devices parameter
DB2_EEE_SYNCTIMEOUT is set too low. Check it
in the DP for Snapshot Devices configuration file
2. DP for Snapshot Devices is not started for each
production servers
Messages and Codes
3. One or more DP for Snapshot Devices processes
running for the production servers were terminated
User response:
1. Check the DP for Snapshot Devices parameter
2. Check that DP for Snapshot Devices is running on
the backup system for all production servers.
3. Check for error messages in the DP for Snapshot
Devices log files for each process.
IDS2607I Enter the TCPIP service port for the
socket server [57330]:
implemented a TCP/IP socket communication. For
configuration of the socket communication, a TCP/IP
service port must be defined on the production and
backup systems. The DP for Snapshot Devices function
configure will perform this configuration on the
production system. You have to enter a TCP/IP service
port to use for DP for Snapshot Devices.
User response: User Response: None
IDS2608E The TCPIP service port <port> is
already in use. Please select another
port.
backup system. The DP for Snapshot Devices function
User response: You have to enter a valid TCP/IP port,
which is not used.
IDS2609E The TCPIP service port <port> is
invalid. Please select another port.
backup system. The DP for Snapshot Devices function
User response: You have to enter a valid TCP/IP port.
Messages and Codes

CIM Error Codes
This section lists the error codes that can be returned by the CIM components.
CIM Agent Return Codes (ESS and DS)
The following error codes can be issued by the DS Open API CIM Agent:
Table 21. Codes Returned by the DS Open API CIM Agent
Symbolic Name Code Definition
CIM_ERR_FAILED 1 A general error occurred that is not
covered by a more specific error code.
CIM_ERR_ACCESS_DENIED 2 Access to a CIM resource was not
available to the client.
CIM_ERR_INVALID_NAMESPACE 3 The target namespace does not exist.
CIM_ERR_INVALID_PARAMETER 4 One or more parameter values passed to
the method were invalid.
CIM_ERR_INVALID_CLASS 5 The specified class does not exist.
CIM_ERR_NOT_FOUND 6 The requested object could not be found.
CIM_ERR_NOT_SUPPORTED 7 The requested operation is not supported.
CIM_ERR_CLASS_HAS_CHILDREN 8 The operation cannot be carried out on
this class because it has instances.
CIM_ERR_CLASS_HAS_INSTANCES 9 The operation cannot be carried out on
this class because it has instances.
CIM_ERR_INVALID_SUPERCLASS 10 The operation cannot be carried out since
the specified superclass does not exist.
CIM_ERR_ALREADY_EXISTS 11 The operation cannot be carried out
because an object already exists.
CIM_ERR_NO_SUCH_PROPERTY 12 The specified property does not exist.
CIM_ERR_TYPE_MISMATCH 13 The value supplied is incompatible with
the type.
CIM_ERR_QUERY_LANGUAGE_NOT_SUPPORTED 14 The query language is not recognized or
supported.
CIM_ERR_INVALID_QUERY 15 The query is not valid for the specified
query language.
CIM_ERR_METHOD_NOT_AVAILABLE 16 The extrinsic method could not be
executed.
CIM_ERR_METHOD_NOT_FOUND 17 The specified extrinsic method does not
exist.
CIM_ERR_LOW_ON_MEMORY 20 There is not enough memory.
XMLERROR 21 An XML error has occurred.
CIM_ERR_LISTNER_ALREADY_DEFINED 22 The listener is already defined.
CIM_ERR_INDICATION_NOT_COLLECTED 23 The indications are not collected.
CIM_ERR_NO_METHOD_NAME 24 The method name is null.
CIM_ERR_INVALID_QUALIFIER_DATATYPE 25 The datatype qualifier is invalid.
CIM_ERR_NAMESPACE_NOT_IN_MANAGER 26 The namespace value is not found.
CIM_ERR_INSTANTIATE_FAILED 27 The instantiation failed.
Messages and Codes
Table 21. Codes Returned by the DS Open API CIM Agent (continued)
Symbolic Name Code Definition
CIM_ERR_FAILED_TO_LOCATE_INDICATION_
HANDLER
28 The indication handler is not found.
CIM_ERR_IO_EXCEPTION 29 An IO exception has occurred.
CIM_ERR_COULD_NOT_DELETE_FILE 30 The file could not be deleted.
INVALID_QUALIFIER_NAME 31 The qualifier name is null.
NO_QUALIFIER_VALUE 32 The qualifier value is null.
NO_SUCH_QUALIFIER1 33 There is no such qualifier.
NO_SUCH_QUALIFIER2 34 There is no such qualifier.
QUALIFIER_UNOVERRIDABLE 35 The qualifier is unoverridable.
SCOPE_ERROR 36 A scope error has occurred.
TYPE_ERROR 37 A type error has occurred.
CIM_ERR_MISSING_KEY 38 The key is missing.
CIM_ERR_KEY_CANNOT_MODIFY 39 The key cannot be modified.
CIM_ERR_NO_KEYS 40 There are no keys found.
CIM_ERR_KEYS_NOT_UNIQUE 41 The keys are not unique.
CIM_ERR_SET_CLASS_NOT_SUPPORTED 100 The set class operation is not supported.
CIM_ERR_SET_INSTANCE_NOT_SUPPORTED 101 The set instance operation is not
supported.
CIM_ERR_QUALIFIER_NOT_FOUND 102 The qualifier value is not found.
CIM_ERR_QUALIFIERTYPE_NOT_FOUND 103 The qualifier type is not found.
CIM_ERR_CONNECTION_FAILURE 104 The connection failed.
CIM_ERR_FAIL_TO_WRITE_TO_SERVER 105 There is a fail to write to the server.
CIM_ERR_SERVER_NOT_SPECIFIED 106 The server not specified.
CIM_ERR_INDICATION_ERROR 107 There is an indication processing error.
CIM_ERR_FAIL_TO_WRITE_TO_CIMOM 108 There is a fail to write to the CIMOM.
CIM_ERR_SUBSCRIPTION_EXISTS 109 A subscription already exists.
CIM_ERR_INVALID_SUBSCRIPTION_DEST 110 The subscription destination is invalid.
CIM_ERR_INVALID_FILTER_PATH 111 The filter path is invalid.
CIM_ERR_INVALID_HANDLER_PATH 112 The handler path is invalid.
CIM_ERR_NO_FILTER_INSTANCE 113 The filter instance is not found.
CIM_ERR_NO_HANDLER_INSTANCE 114 The handler instance is not found.
CIM_ERR_UNSUPPPORTED_FILTER 115 There is an unsupported filter referenced
in the subscription.
CIM_ERR_INVALID_TRUSTSTORE 116 The CIMOM cannot be connected to
because there is a bad or missing
truststore or an incorrect truststore
password.
CIM_ERR_ALREADY_CONNECTED 117 The CIMOM cannot be connected to
because it is already connected.
CIM_ERR_UNKNOWN_SERVER 118 The server is unknown. The CIMOM
cannot be connected to.
CIM_ERR_INVALID_CERTIFICATE 119 The correct certificate cannot be found in
truststore.
Messages and Codes

CIM Agent Return Codes (SVC)
The following codes can be returned by SVC software components.
Table 22. Codes Returned by CIM Agent for SVC
CIM Return Code Description
0x0000 Success
0x0000 Job completed with no error
0x0000 Job started successfully
0x0001 Not supported
0x0002 Failed
0x0002 Unknown error
0x0004 Failed
0x0005 Wrong Parameter
0x0005 Invalid Parameter
0x0006 CopyType not supported
0x0006 Operation not supported
0x0006 SynchronizedSet is not empty
0x0006 User ID already exists
0x0006 In use
0x0007 StorageSynchronized not in the Set
0x0008 StorageSynchronized already in the Set
0x0009 StorageSynchronized incompatible with Set
0x1000 Parameters checked - Job started
0x1000 LogicalDevices associated to other ProtocolControllers not deleted
0x1000 Invalid LogicalDevice instance
0x1000 LogicalDevice not associated to Controller
0x1000 ID already created
0x1000 Specified instance not found
0x1000 Invalid HardwareID instance
0x1001 Size not supported
0x1001 Device Number Conflict
0x1001 Hardware implementation does not support specified IDType
0x8000 Invalid ComputerSystem
0x8000 Invalid Locale
0x8000 Invalid Type
0x8000 Connection refused
0x8000 Backup not found
0x8000 Delete failed
0x8000 IOGroup must have Nodes aggregated
0x8000 Invalid ID
Messages and Codes
Table 22. Codes Returned by CIM Agent for SVC (continued)
CIM Return Code Description
0x8000 Invalid Volume
0x8000 CopyType not supported
0x8000 Ports are from multiple IOGroups
0x8000 HardwareID still bound to AuthorizationSubject. Force required
0x8000 Host is member of a LUN mapping
0x8000 Record(s) not found
0x8000 Cannot connect to cluster
0x8000 Connection to cluster refused
0x8000 Connection to switch refused
0x8000 Cluster IP not found
0x8001 Maximum number of Nodes for Cluster exceeded
0x8001 Invalid Prefix
0x8001 File not found
0x8001 Backup script failed
0x8001 Restore script failed
0x8001 Operation not allowed for current state
0x8001 Operation not allowed for current SyncState
0x8001 Unsupported protocol
0x8001 Syntax error in ClusterName
0x8002 Invalid ExtraCapacitySet
0x8002 Secure copy failed
0x8002 Syntax error in Node or Node is invalid
0x8003 Maximum number of Nodes for IOGroup exceeded
0x8003 Creation of backup dir failed
0x8003 Clear command failed
0x8003 Invalid username or password
0x8004 Delete/rename of old backup files failed
0x8004 Wrong SwitchIP / cant connect to switch
0x8004 SwitchIP is not configured
0x8005 Syntax error in ClusterIP
0x8006 Invalid Slot
0x8007 Cannot upload public key to switch
0x8100 Cluster Scope Violation
0x8200 The method was run successfully but one or more parameters were
ignored.

Table 23. CIM Return Codes and Corresponding SAN Volume Controller CLI Error Codes
CIM Return Code
SAN Volume Controller CLI Error
Code Description
0x9001 CMMVC5700E The parameter list is not valid.
Messages and Codes

Table 23. CIM Return Codes and Corresponding SAN Volume Controller CLI Error Codes (continued)
CIM Return Code
Code Description
0x9002 CMMVC5701E No object ID was specified.
0x9003 CMMVC5702E [value] is below the minimum level.
0x9004 CMMVC5703E [value] is above the maximum level.
0x9005 CMMVC5704E [value] is not divisible by the
permitted step level.
0x9006 CMMVC5705E A required parameter is missing.
0x9007 CMMVC5706E [value] is not a valid argument for the
-x parameter.
0x9008 CMMVC5707E Required parameters are missing.
0x9009 CMMVC5708E The value parameter is missing its
associated arguments.
0x900A CMMVC5709E [value] is not a supported parameter.
0x900B CMMVC5710E No self describing structure for
identifier parameter [value].
0x900C CMMVC5711E [value] is not valid data.
0x900D CMMVC5712E Required data is missing.
0x900E CMMVC5713E Some parameters are mutually
exclusive.
0x900F CMMVC5714E There are no items in the parameter
list.
0x9010 CMMVC5715E There is no parameter list.
0x9011 CMMVC5716E Nonnumeric data was entered for a
numeric field ([value]). Enter a
numeric value.
0x9012 CMMVC5717E No match was found for the
specified unit.
0x9013 CMMVC5718E An unexpected return code was
received.
0x9014 CMMVC5719E A value of value2 requires the
parameter value1 to be specified.
0x9015 CMMVC5720E [value] is not a valid argument for the
-o parameter.
0x9016 CMMVC5721E [value] is not a valid time-stamp
format. The valid format is
MMDDHHmmYY.
0x9017 CMMVC5722E [value] is not a valid month.
0x9018 CMMVC5723E [value] is not a valid day.
0x9019 CMMVC5724E [value] is not a valid hour.
0x901A CMMVC5725E [value] is not a valid minute.
0x901B CMMVC5726E [value] are not valid seconds.
0x901C CMMVC5727E [value] is not a valid filter.
0x901D CMMVC5728E [value] must be in the format minute:
hour: day: month: weekday.
Messages and Codes
CIM Return Code
Code Description
0x901E CMMVC5729E One or more components in the list
are not valid.
0x901F CMMVC5730E value1 is only valid when value2 has a
value of value3.
0x9020 CMMVC5731E value1 can only be entered when
value2 has been entered.
0x9021 CMMVC5732E The shared memory interface (SMI) is
not available.
0x9022 CMMVC5733E Enter at least one parameter.
0x9023 CMMVC5734E A combination of values was entered
that is not valid.
0x9024 CMMVC5735E The name entered is not valid.
0x9025 CMMVC5736E -c is not a valid unit.
0x9026 CMMVC5737E The parameter value has been entered
multiple times. Enter the parameter
once.
0x9027 CMMVC5738E The argument value contains too
many letters.
0x9028 CMMVC5739E The argument value does not contain
enough letters.
0x9029 CMMVC5740E The filter flag value is not valid.
0x902A CMMVC5741E The filter value value is not valid.
0x903A CMMVC5987E value is not a valid command line
option.
0x903B CMMVC6007E The two passwords that were entered
do not match.
0x903C CMMVC6009E Unable to malloc a block of memory
to copy the returned data.
0x9101 CMMVC5742E A parameter specified is out of range.
0x9102 CMMVC5743E A parameter specified does not
comply with the step value.
0x9103 CMMVC5744E Too many objects were specified in
the request.
0x9104 CMMVC5745E Too few objects were specified in the
request.
0x9105 CMMVC5746E The requested operation cannot be
applied to the object specified.
0x9106 CMMVC5747E The action requested is invalid -
internal error.
0x9107 CMMVC5748E The action requested is invalid -
internal error.
0x9108 CMMVC5749E The dump filename specified already
exists.
0x9109 CMMVC5750E Could not create the dump file -
filesystem probably full.
Messages and Codes

CIM Return Code
Code Description
0x910A CMMVC5751E Could not write to the dump file.
0x910B CMMVC5752E Request failed, the object contains
child objects. You must delete the
child objects first.
0x910C CMMVC5753E The object specified does not exist or
is not a suitable candidate.
0x910D CMMVC5754E The object specified does not exist, or
the name supplied does not meet the
naming rules.
0x910E CMMVC5755E Cannot create because the sizes of the
specified objects do not match.
0x910F CMMVC5756E Cannot perform the request as the
object is already mapped.
0x9110 CMMVC5757E Defaults not found - internal error.
0x9111 CMMVC5758E Object name already exists.
0x9112 CMMVC5759E Cannot allocate memory - internal
error.
0x9113 CMMVC5760E Failed to add the node to the cluster
member list.
0x9114 CMMVC5761E Failed to delete the node from the
cluster member list.
0x9115 CMMVC5762E The request did not complete before
the timeout period expired.
0x9116 CMMVC5763E The node failed to go online.
0x9117 CMMVC5764E The mode change requested is
invalid - internal error.
0x9118 CMMVC5765E The object selected is no longer a
candidate - a change occurred during
the request.
0x9119 CMMVC5766E No association
0x911A CMMVC5767E One or more of the parameters
specified are invalid.
0x911B CMMVC5768E Not used.
0x911C CMMVC5769E The requested operation requires all
nodes to be online one or more
nodes are not online.
0x911D CMMVC5770E The ssh key file supplied is invalid.
0x911E CMMVC5771E The operation requested could not
complete. This usually occurs when a
child object exists. To force the
operation, specify the force flag.
0x911F CMMVC5772E The operation requested could not be
performed because software upgrade
is in progress.
0x9120 CMMVC5773E The object selected is in the wrong
mode to perform the requested
operation.
Messages and Codes
CIM Return Code
Code Description
0x9121 CMMVC5774E The user ID supplied is not valid.
0x9122 CMMVC5775E The directory attribute specified is
not valid.
0x9123 CMMVC5776E The directory listing could not be
retrieved.
0x9124 CMMVC5777E The node could not be added to the
IO Group because the other node in
the IO Group is in the same power
domain.
0x9125 CMMVC5778E Cannot create another cluster because
a cluster already exists.
0x9126 CMMVC5779E Too many clusters exist already.
0x9127 CMMVC5780E Cluster ID cannot be deleted.
0x9128 CMMVC5781E The cluster ID specified is invalid.
0x9129 CMMVC5782E The object specified is offline.
0x912A CMMVC5783E Information not available.
0x912B CMMVC5784E The cluster name specified is not
unique. You must specify the cluster
using the cluster id.
0x912C CMMVC5785E The filename specified contains an
illegal character.

Messages and Codes

Appendix C. Summary of Log and Trace Files
This appendix contains a summary of log and trace files written to during a
backup and restore; these files are created and written to by the various products
involved:
v DP for Snapshot Devices
v DP for mySAP
v Storage system
v AIX operating system
DP for Snapshot Devices Logs and Traces
The DP for Snapshot Devices commands tdphdwdb2 and splitint create log files
when running the various functions (except for inquire and password) on the
machine where the functions are initiated. When running the function flashcopy,
tdphdwdb2 and splitint will have two different logs:
v one recording all the activities on the backup system
v the other recording all the activities for the time splitint is running on the
production system
You can find the logs and traces in the directories specified in parameter
LOG_TRACE_DIR of the DP for Snapshot Devices profile. If no parameter is
specified, the logs and traces will be placed in the directory as specified in the
parameter WORK_DIR of the DP for Snapshot Devices profile. The file naming
convention for logs and traces is as follows:
v tdphdwdb2_p_<tdphdwdb2 function>.<date time stamp>.log
v tdphdwdb2_p_<tdphdwdb2 function>.<date time stamp>.trace
v tdphdwdb2_b_<tdphdwdb2 function>.<date time stamp>.log
v tdphdwdb2_b_<tdphdwdb2 function>.<date time stamp>.trace
v splitint_p_<splitint function>.<date time stamp>.log
v splitint_p_<splitint function>.<date time stamp>.trace
v splitint_b_<splitint function>.<date time stamp>.log
v splitint_b_<splitint function>.<date time stamp>.trace
where
v _b_ indicates the backup system and
v _p_ indicates the production system
Storage System Logs and Traces
Consult the documentation for the storage system configured.
CIM Logs and Traces
Consult the documentation (see Table 1 on page xiii) for the CIM Server (Pegasus),
DS Open API CIM Agent, and the SVC master console for logging and tracing
information pertaining to these components.

DP for mySAP
Important: A tracefile can be requested by specifying the TRACEFILE parameter
in the DP for mySAP profile. Do not place this file on NFS, because it
might cause certain network problems when requesting the TRACE 100
level, due to the very high volume of trace entries being written.
AIX Operating System
Problems in the disk environment can be isolated by running the AIX error
reporting command:
errpt -a
Log and Trace Files

Appendix D. Support Information
If you have a problem with your IBM software, you want to resolve it quickly. This
section describes the following options for obtaining support for IBM software
products:
v Using IBM Support Assistant
v Obtaining Fixes
v Receiving Weekly Support Updates on page 332
v Contacting IBM Software Support on page 333
Using IBM Support Assistant
The IBM Support Assistant is a free, stand-alone application that you can install on
any workstation. You can then enhance the application by installing
product-specific plug-in modules for the IBM products you use.
The IBM Support Assistant saves you time searching product, support, and
educational resources. The IBM Support Assistant helps you gather support
information when you need to open a problem management record (PMR), which
you can then use to track the problem.
The product-specific plug-in modules provide you with the following resources:
v Support links
v Education links
v Ability to submit problem management reports
For more information, see the IBM Support Assistant Web site at
http://www.ibm.com/software/support/isa/.
If your product does not use IBM Support Assistant, use the links to support topics
in your information center. In the navigation frame, check the links for resources
listed in the ibm.com and related resources section where you can search the
following resources:
v Support and assistance (includes search capability of IBM technotes and IBM
downloads for interim fixes and workarounds)
v Training and certification
v IBM developerWorks
v IBM Redbooks
v General product information
If you cannot find the solution to your problem in the information center, search
the following Internet resources for the latest information that might help you
resolve your problem:
v Forums and newsgroups
Obtaining Fixes
A product fix might be available to resolve your problem. To determine what fixes
are available for your IBM software product, follow these steps:

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. Go to the IBM Software Support Web site at http://www.ibm.com/software/
support.
2. Under Find product support, click All IBM software (A-Z). This opens the
software product list.
3. In the software product list, click on the product in question. This opens the
corresponding support site.
4. Under Solve a problem, click APARs to go to a list of fixes, fix packs, and
other service updates.
5. Click the name of a fix to read the description and optionally download the
fix. You can also search for a specific fix; for tips on refining your search, click
Search tips.
6. In the Find downloads and drivers by product section, select one software
category from the Category list.
7. Select one product from the Sub-category list.
8. Type more search terms in the Search within results if you want to refine
your search.
9. Click Search.
10. From the list of downloads returned by your search, click the name of a fix to
read the description of the fix and to optionally download the fix.
For more information about the types of fixes that are available, see the IBM
Software Support Handbook at http://techsupport.services.ibm.com/guides/
handbook.html.
Receiving Weekly Support Updates
To receive weekly e-mail notifications about fixes and other software support news,
follow these steps:
1. Go to the IBM Software Support Web site at http://www.ibm.com/software/
support.
2. Click My support in the far upper-right corner of the page under
Personalized support.
3. If you have already registered for My support, sign in and skip to the next
step. If you have not registered, click register now. Complete the registration
form using your e-mail address as your IBM ID and click Submit.
4. Click Edit profile.
5. In the Products list, select Software. A second list is displayed.
6. In the second list, select a product segment, for example, Systems
management. A third list is displayed.
7. In the third list, select a product sub-segment, for example, Application
Performance & Availability. A list of applicable products is displayed.
8. Select the products for which you want to receive updates.
9. Click Add products.
10. After selecting all products that are of interest to you, click Subscribe to email
on the Edit profile tab.
11. Select Please send these documents by weekly email.
12. Update your e-mail address as needed.
13. In the Documents list, select Software.
14. Select the types of documents that you want to receive information about.
15. Click Update.

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If you experience problems with the My support feature, you can obtain help in
one of the following ways:
Online
Send an e-mail message to erchelp@ca.ibm.com, describing your problem.
By phone
Call 1-800-IBM-4You (1-800-426-4968).
Contacting IBM Software Support
IBM Software Support provides assistance with product defects.
Before contacting IBM Software Support, your company must have an active IBM
software maintenance contract, and you must be authorized to submit problems to
IBM. The type of software maintenance contract that you need depends on the
type of product you have:
v For IBM distributed software products (including, but not limited to, Tivoli,
Lotus, and Rational products, as well as DB2 and WebSphere products that run
on Windows, or UNIX operating systems), enroll in Passport Advantage in one
of the following ways:
Online
Go to the Passport Advantage Web site at http://www-306.ibm.com/
software/howtobuy/passportadvantage/pao_customers.htm
By phone
For the phone number to call in your country, go to the IBM Software
Support Web site at http://techsupport.services.ibm.com/guides/
contacts.html and click the name of your geographic region.
v For customers with Subscription and Support (S & S) contracts, go to the
Software Service Request Web site at https://techsupport.services.ibm.com/ssr/
login.
v For customers with IBMLink, CATIA, Linux, OS/390, System i, System p,
System z, and other support agreements, go to the IBM Support Line Web site at
http://www.ibm.com/services/us/index.wss/so/its/a1000030/dt006.
v For IBM Systems (formerly eServer) software products (including, but not
limited to, DB2 and WebSphere products that run in System z, System p, and
System i environments), you can purchase a software maintenance agreement by
working directly with an IBM sales representative or an IBM Business Partner.
For more information about support for IBM Systems software products, go to
the IBM Technical Support Advantage Web site at http://www.ibm.com/
servers/eserver/techsupport.html.
If you are not sure what type of software maintenance contract you need, call
1-800-IBMSERV (1-800-426-7378) in the United States. From other countries, go to
the contacts page of the IBM Software Support Handbook on the Web at
http://techsupport.services.ibm.com/guides/contacts.html and click the name of
your geographic region for phone numbers of people who provide support for
your location.
To contact IBM Software support, follow these steps:
1. Determining the Business Impact on page 334
2. Describing Problems and Gathering Information on page 334
3. Submitting Problems on page 334

Appendix D. Support Information 333
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Determining the Business Impact
When you report a problem to IBM, you are asked to supply a severity level.
Therefore, you need to understand and assess the business impact of the problem
that you are reporting. Use the following criteria:
Severity 1
The problem has a critical business impact. You are unable to use the
program, resulting in a critical impact on operations. This condition
requires an immediate solution.
Severity 2
The problem has a significant business impact. The program is usable, but
it is severely limited.
Severity 3
The problem has some business impact. The program is usable, but less
significant features (not critical to operations) are unavailable.
Severity 4
The problem has minimal business impact. The problem causes little impact
on operations, or a reasonable circumvention to the problem was
implemented.
Describing Problems and Gathering Information
When describing a problem to IBM, be as specific as possible. Include all relevant
background information so that IBM Software Support specialists can help you
solve the problem efficiently. To save time, know the answers to these questions:
v What software versions were you running when the problem occurred?
v Do you have logs, traces, and messages that are related to the problem
symptoms? IBM Software Support is likely to ask for this information.
v Can you re-create the problem? If so, what steps were performed to re-create the
problem?
v Did you make any changes to the system? For example, did you make changes
to the hardware, operating system, networking software, and so on.
v Are you currently using a workaround for the problem? If so, be prepared to
explain the workaround when you report the problem.
Submitting Problems
You can submit your problem to IBM Software Support in one of two ways:
Online
Click Submit and track problems on the IBM Software Support site at
http://www.ibm.com/software/support/probsub.html. Type your
information into the appropriate problem submission form.
By phone
For the phone number to call in your country, go to the contacts page of
the IBM Software Support Handbook at http://techsupport.services.ibm.com/
guides/contacts.html and click the name of your geographic region.
If the problem you submit is for a software defect or for missing or inaccurate
documentation, IBM Software Support creates an Authorized Program Analysis
Report (APAR). The APAR describes the problem in detail. Whenever possible,
IBM Software Support provides a workaround that you can implement until the
APAR is resolved and a fix is delivered. IBM publishes resolved APARs on the

|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Software Support Web site daily, so that other users who experience the same
problem can benefit from the same resolution.

Appendix D. Support Information 335
|
|
Glossary
The terms in this glossary are defined as they pertain to the TSM library. If you do
not find the term you are looking for, you can view the IBM Glossary of Computing
Terms, available from: http://www.ibm.com/software/globalization/terminology.
This glossary may include terms and definitions from:
v The American National Standard Dictionary for Information Systems, ANSI
X3.172-1990, copyright (ANSI). Copies can be purchased from the American
National Standards Institute, 11 West 42nd Street, New York, New York 10036.
v The Information Technology Vocabulary, developed by Subcommittee 1, Joint
Technical Committee 1, of the International Organization for Standardization and
the International Electrotechnical Commission (ISO/IEC JTC2/SC1).
A
Administration Assistant. A Web-browser-based graphical interface to support and assist the customizing of Data
Protection for mySAP (System Configuration) and the analyzing of SAP database backup and restore operations
(Operations Monitor, Performance Monitor).
administrative client. A program that runs on a file server, workstation, or mainframe. This program lets
administrators monitor and control TSM servers using TSM administrator commands. Contrast with backup-archive
client.
administrator. A user who is registered to the server as an administrator. Administrators can be assigned one or
more privilege classes. Administrators can use the administrative client to enter TSM server commands and queries
according to their privileges.
B
backup. A function permitting users to copy one or more files to a storage pool to protect against data loss.
Contrast with restore.
backup-archive client. A program that runs on a file server, PC, or workstation and provides a means for TSM
users to back up, archive, restore, and retrieve files. Contrast with administrative client.
backup system. The secondary server environment that performs backup procedures with DP for Snapshot Devices.
C
central scheduling. A function permitting an administrator to schedule backup and archive operations from a
central location. The operations can be scheduled on a periodic basis or on an explicit date.
client. A program running on a file server, PC, workstation, or terminal that requests services of another program
called the server.
client-server. A communications network architecture in which one or more programs (clients) request computing or
data services from another program (the server).
cluster. A collection of servers that provide a set of resources to a client.
Common Information Model (CIM). An object model for data storage and management developed by the
Distributed Management Task Force (DMTF) . CIM makes it possible to organize devices and components of devices
in an object-oriented pattern.

concurrent copy. A Copy Services function that produces a backup copy and allows concurrent access to data
during the copy.
consistency group. An association of SVC virtual disks that are treated as a unit for FlashCopy backup and restore
purposes.
consistent copy. A copy of a data entity (for example, a logical volume) that contains the entire data entity as of a
single instant in time.
Copy Services. An optional feature of the IBM ESS and DS that provides replication and mirroring.
D
data container. Alternate term for a set of source or target volumes.
Data Protection (DP). A storage management software application that performs backup and recovery functions
across a wide variety of client and server platforms.
Data Protection for ESS (DP for ESS). Former name of the current product up to and including version 5.3.0.
Data Protection for Snapshot Devices (DP for Snapshot Devices). Generic designation used in this book for the
TSM for Advanced Copy Services component Data Protection for IBM Disk Storage and SAN VC for mySAP.
Data Protection for mySAP (DP for mySAP). Interface program between Tivoli Storage Manager and DP for
Snapshot Devices.
disk. An addressable part of the storage subsystem with a set of access arms, related disk surfaces, and electronics
for locating, reading, and writing data.
Distributed Management Task Force (DMTF). Group responsible for developing the Common Information Model
(CIM).
DPF. Database Partitioning Factility (DB2)
Distributed Management Task Force (DMTF). Group responsible for developing the Common Information Model
(CIM).
F
FlashCopy. A Copy Services function that can quickly provide an image copy from a source location to a target
location.
FlashBack Restore. A restore analogous to a FlashCopy backup, in which the target volumes (copies) are flashed
back to the source volumes.
freeze. The function of disabling access to a filesystem for the duration of a point-in-time copy.
H
hdisk. A logical disk volume on an AIX platform.
host. A computer that is connected to a network and provides an access point to that network. The host can be a
client, a server, or both a client and a server simultaneously.
I
Incremental Change Recording (ICR). A facility of the ESS and DS storage systems that records changes (at the
track level) and copies only these tracks to the target volumes.
Incremental FlashCopy. A mode of FlashCopy for the ESS and DS storage systems in which changes are recorded at
the track level and only these tracks are copied to the target volumes.
Glossary

|
|
input/output (I/O). A device, process, or channel involved in data input, data output, or both.
I/O group. A set of two SVC nodes defined by the configuration process. Each SVC node is associated with one I/O
group. The nodes in the I/O group provide access to the vDisks in the group.
L
Licensed Internal Code (LIC). Microcode that IBM does not sell as part of a machine but licenses to the customer.
LIC is implemented in a part of storage that is not addressable by user programs. Some IBM products use it to
implement functions as an alternative to hard-wired circuitry.
local area network (LAN). A variable-size communications network placed in one location. A LAN connects servers,
PCs, workstations, a network operating system, access methods, and communications software and links.
Local Snapshot Manager. The Local Snapshot Manager (LSM) is a generic component of Tivoli Storage Manager
that is responsible for managing any data containers. For TSM for Advanced Copy Services, it is the LUN manager
that administers a universe of LUNs grouped into target sets (also referred to as data containers) in a local
repository and tracks the state of the backups contained in them. The key functions of LSM include not only the
identification of a target set in the state AVAILABLE, which can therefore accept a new FlashCopy backup, but also
the decision as to when to re-use a target set in the state IN_USE. The local backup is referred to in generic terms as
a snapshot backup. In the context of DP for Snapshot Devices, it is referred to as a FlashCopy backup.
logical unit number (LUN). A volume identifier number for a storage subsystem logical disk drive.
logical volume. The storage medium associated with a logical disk drive. A logical volume typically resides on one
or more storage devices. A logical volume is referred to on an AIX platform as an hdisk, an AIX term for storage
space. A host system sees a logical volume as a physical volume.
M
master console (SVC). See SVC master console.
mirroring. The maintenance of more than one copy of stored data to prevent the loss of data.
N
Network Appliance (NetApp). The embedded technology within an N series device that supports snapshot
functions.
Network File System (NFS). A facility in UNIX systems for accessing files on a remote system.
node. An individual server in an SVC cluster on which the SVC software runs.
node name. A unique name used to identify a workstation, file server, or PC to the server.
null trust provider mode. A communication mode of the CIM Agent in which the CIM Agent does not verify that
the certificate passed by the client matches a known certificate. Rather, it accepts any certificate from the client
(including a null string for the filename). To enable this mode, the value of COPYSERVICES_CERTIFICATEFILE must
be set to NO_CERTIFICATE, which is the default setting. However, it is recommended to use this mode only if the
production and backup systems, as well as the storage system, are protected by a firewall.
O
options file. A file that contains processing options.
P
Pegasus. An open-source implementation of the DMTF CIM and WBEM standards. It is designed to be portable and
highly modular. It is coded in C++ so that it effectively translates the object concepts of the CIM objects into a
Glossary
Glossary 339
|
|
|
|
|
|
|
programming model but still retains the speed and efficiency of a compiled language. Pegasus is designed to be
inherently portable and builds and runs today on most versions of UNIX, Linux, and Microsoft
Windows.
production system. The active production environment that remains online during DP for Snapshot Devices backup
processing.
Q
quorum disk. In an SVC environment, a disk that serves as a tie-breaker if exactly half the nodes in a cluster fail at
the same time or if the cluster is divided so that exactly half the nodes in the cluster cannot communicate with the
other half.
R
replica. Synonym for target volume.
restore. A function that permits users to copy a version of a backup file from the storage pool to a workstation or
file server. The backup copy in the storage pool is not affected. Contrast with backup.
S
SAN Volume Controller (SVC, also SAN VC). A virtualization layer that allows addressing a heterogeneous
configuration of IBM and non-IBM open-system storage devices through one interface to an open-systems host.
SCSI address. The hexadecimal value that defines a physical I/O device on a SCSI channel path. A SCSI address
consists of a target ID and a logical unit number (LUN).
server. A program running on a mainframe, workstation, or file server that provides shared services such as backup
and archive to other various (often remote) programs (called clients).
SID. A unique identifier for a system defined within the database configuration.
sid. Lower-case version of SID.
snap restore. A restore from a snapshot (N series).
stale partition. In AIX LVM mirroring, a physical partition (belonging to a logical partition and, in turn, a logical
volume) that could not be updated at some point and is therefore different from the other mirror copies of that
partition.
storage area network (SAN). A high-speed special-purpose network (or subnetwork) that interconnects different
kinds of data storage devices with associated data servers on behalf of a larger network of users.
Subsystem Device Driver (SDD). A pseudo device driver that resides in the host server with the native disk device
driver for the storage system. It uses redundant connections between the host server and disk storage to provide
enhanced performance and data availability. These connections comprise many different components through which
data flows during input and output processes. Redundancy and the ability to switch between these components
provides different paths for the data to travel. In the event of failure in one input-output path (such as a cable or
controller failure), the SDD automatically switches to another input-output path. I/O operations sent to the
Subsystem Device Driver are passed to the AIX disk driver after path selection.
SVC master console. The platform on which the software runs that is used to manage the SAN Volume Controller.
It includes a Web interface and the CIM Agent for SVC.,
T
target set. The target volumes that will be copied from a set of source volumes that are the subject of a FlashCopy
backup when requested by the brbackup running a split mirror DB backup. The number of volumes of a target set
and the volume sizes must be equal and match the source volumes involved in a backup; in addition, the planned
source/target pairs must have been allocated within the storage system so that a FlashCopy can be requested (see
Hardware Requirements on page 44). When using a database set up with AIX mirrors (as defined in Hardware
Glossary

|
Requirements on page 44), the target volumes that will be copied from the set of source volumes constituting 2
source copy sets, each of which will be the subject of a FlashCopy backup when requested by tdphdwdb2.
thaw. The function to enable access to a filesystem that was frozen prior to performing a point-in-time copy.
Tivoli Storage Manager (TSM). A client/server program that provides storage management to customers in a
multivendor computer environment.
V
virtual disk (vDisk). An SVC device that appears to host systems attached to the SAN as a SCSI disk. Each vDisk is
associated with one I/O group.
volume. A general term referring to a single device visible to the host. For an SVC configuration, it is used in this
document synonymously with virtual disk.
W
withdraw. A storage system function that dissolves the relationship of source and target volumes initiated by the
flashcopy function.
workstation. A programmable high-level workstation (usually on a network) with its own processing hardware such
as a high-performance personal computer. In a local area network, a personal computer that acts as a single user or
client. A workstation can also be used as a server.
Glossary
Glossary 341
|
Glossary

Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the users responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785 U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Some states do not allow disclaimer of express or implied warranties in certain
transactions, therefore, this statement might not apply to you.
This information could include technical inaccuracies or typographical errors.
Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758 U.S.A.
Such information may be available, subject to appropriate terms and conditions,
including in some cases payment of a fee.
The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.
Any performance data contained herein was determined in a controlled
environment. Therefore, the results obtained in other operating environments may
vary significantly. Some measurements may have been made on development-level
systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurement may have been
estimated through extrapolation. Actual results may vary. Users of this document
should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of
those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.
All statements regarding IBMs future direction or intent are subject to change or
withdrawal without notice, and represent goals and objectives only.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which
illustrate programming techniques on various operating platforms. You may copy,
modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to

IBM for the purposes of developing, using, marketing, or distributing application
programs conforming to IBMs application programming interfaces.
Each copy or any portion of these sample programs or any derivative work, must
include a copyright notice as follows:
(your company name) (year). Portions of this code are derived from IBM Corp.
Sample Programs. Copyright IBM Corp. _enter the year or years_. All rights
reserved.
If you are viewing this information in softcopy form, the photographs and color
illustrations might not display.
Trademarks and Service Marks
The following terms are trademarks or registered trademarks of International
Business Machines Corporation in the United States or other countries or both:
v AIX
v AIX 5L
v DB2
v DB2 Universal Database
v developerWorks
v DS4000
v DS6000
v DS8000
v Enterprise Storage Server
v eServer
v FlashCopy
v HACMP
v IBM
v IBMLink
v ibm.com
v Lotus
v OS/390
v Passport Advantage
v POWER
v POWER5
v Rational
v RS/6000
v System i
v System p
v System z
v System Storage
v Tivoli
v TotalStorage
v WebSphere
v z/OS
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.

Notices 345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo,
Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or
registered trademarks of Intel Corporation or its subsidiaries in the United States
and other countries.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Linux is a registered trademark of Linus Torvalds in the United States, other
countries, or both.
Other company, product, or service names may be trademarks or service marks of
others.
Accessibility
Accessibility features help users with physical disabilities, such as restricted
mobility or limited vision, to use software products successfully. Depending on the
operating system and its environment, such users can:
v use assistive technologies, such as screen-reader software and digital speech
synthesizer, to hear what is displayed on the screen. Consult the product
documentation of the assistive technology for details on using those technologies
with this product.
v operate specific or equivalent features using only the keyboard.
v magnify what is displayed on the screen.
The product documentation includes features to aid accessibility:
v All documentation is available in both HTML and convertible PDF formats to
give the maximum opportunity for users to apply screen-reader software.
v All images in the documentation are provided with alternative text so that users
with vision impairments can understand the contents of the images.
Navigating the Interface Using the Keyboard
Standard shortcut and accelerator keys are used by the product and are
documented by the operating system. Refer to the documentation provided by
your operating system for more information.
Magnifying What is Displayed on the Screen
You can enlarge information on the product windows using facilities provided by
the operating system on which the product is run. For example, in some
environments you can lower the resolution of the screen to enlarge the font sizes of
the text on the screen. Refer to the documentation provided by your operating
system for more information.

|
|
|
|
|
|
|
|
|
|
Index
A
Admin Tools
description 21
profile 22, 83
Administration Assistant
understanding 24
AIX
error reporting command 330
automatic backup start 77
B
backup
backup status indicator (BSI) 139
cycles 134
FlashCopy backup with SVC 75
function of tdphdwdb2 107
function of tdphdwdb2 with
EEE 201
methods 73
multiple EEE partitions 195
multiple generations on disk 219
offline log files 76
partial 76
progress status indicator (PSI) 137,
138
restart_backup function 131
restore status indicator (RSI) 141
scheduling of 21
starting 77
starting via TSM 77
strategy and automation 78
user actions during 78
using FlashCopy 12
with FlashCopy backup disks 73
without FlashCopy disks 76
backup history file 84
backup scheduler
Tivoli Storage Manager 77
UNIX crontab 78
backup, incremental 23
C
CIM Agent 30
CIM Agent for SVC
installing 55
introduction 31
CIM Client 29
Common Information Model (CIM)
components 51
error codes 321
introduction 26
Concurrent I/O (CIO) 40
configuration on backup system
(setupDB2BS) 65
configure
configure (continued)
EEE 201
crontab
scheduling backups with 78
customer support
See Software Support
customizing DP for mySAP
with the configuration file 24
with the profile 24
D
Data Protection for mySAP
architecture and properties 22
augmentation by DP for Snapshot
Devices 21
components 22
database utilities 22
introduction 22
overview 22
sample installation and
customization 256
sample profile 239
shared vendor library 22
understanding 22
database instances
setup.sh 59
Database Partitioning Feature (DPF) 191
databases
multiple 59
DB2
integration with DP for Snapshot
Devices 13
DB2 EEE
backup/restore with multiple
partitions 195
commands for 195
customization 193
extended parameters for parallel
backup/restore 196
modifying instance 214
setup 191
DB2 UDB EEE 191
DB2 UDB ESE 191
dbresume
disk layout
considerations for installation 34
sample 235
Disk Storage (DS) system
description 2
sample target volume definitions 251
sample target volume file (mirror
setup ) definitions 254
source/target volumes 57
DP for mySAP
sample DB2 vendor INI file 239
DP for Snapshot Devices
splitint 105
tdphdwdb2 106
DP for Snapshot Devices (continued)
augmentation of DP for mySAP
functions 21
automatic backup start 77
backup methods 73
backups without FlashCopy disks 76
customization 61
customizing profile 61
FlashCopy disk backups 73
functions 11, 12, 21
initialization 61, 64
installation requirements 44
environment 48
hardware 44
LVM mirroring 49
software 45
volume groups 49
installing 58
LVM 161
messages 275
offline log files 76
operating environment 6
packages xv
profile 83, 143
restore methods 81
sample installation and
customization 258
sample profile 241
starting backups 77
target volumes file 143
understanding 1
uninstalling 71
version/maintenance levels 59
installing 54
introduction 31
E
Enterprise Storage Server (ESS)
description 2
sample target volume file (mirror
setup ) definitions 254
environment
variables 63
error messages 275
error reporting
AIX command 330
F
fixes, obtaining 331
FlashBack Restore
defined 16
description 84
limitations 87

FlashBack Restore (continued)
parameters required during
backup 175
required checks 228
rerunning 93
scenarios 95
with LVM mirrors 165
with multiple target sets 233
flashcopy
EEE 204
FlashCopy
logical FlashCopy group 223
FlashCopy Agent 136
FlashCopy backup
preventing simultaneous 224
with LVM mirrors 163
FlashCopy volumes
description 12
FLASHCOPY_TYPE
effective 75
intended 75, 221
H
HACMP 167
sample scripts 273
hardware
high availability 161
I
IBM support assistant, support assistant,
problem resolution, IBM Redbooks,
education, software support,
support 331
IBM System Storage N Series 4
incremental backup 23
incremental backup and restore 13
inquire
installation
checking environment variables 63
CIM Agent for SVC 55
CIM Server (Pegasus) 53
customization 61
customization requirements 36
disk layout 34
DS Open API CIM Agent 54
NFS file systems 55
of DP for Snapshot Devices 43, 58
of prerequisite products 49
Open SSL 52
preparations for DP for Snapshot
Devices 33
installation requirements
DP for Snapshot Devices 44
environment 48
hardware 44
LVM mirroring 49
software 45
volume groups 49
J
JFS2
Concurrent I/O (CIO) 40
JFS2 file systems 40
L
library, shared vendor 23
log files
backup of offline log files 76
CIM 329
DP for mySAP 330
summary 329
logical FlashCopy group 223
Logical Volume Manager (LVM)
advantages 162
asymmetrical environments 169
examples 183
overview 163
requirements 45
sample usage 179
setup and customization 170
symmetrical environments 168
utilizing for FlashCopy backup 161
LVM mirroring
M
messages
severity levels 275
mirror environment
modify_copyrate
multiple backup generations on disk
overview 219
multiple target sets
automated set selection 225
checking source/target
relationships 230
commands for status
information 223
FlashBack Restore 233
implications for restore 228
in LVM mirrored environment 163
overview 219
requirements 228
sample environment without AIX
LVM mirrors 230
sample with AIX LVM mirrors 232
specific set selection 226
states 222
N
N Series 4
Naming conventions xv
NFS
sample client setup 238
sample server setup 237
setting up 55
O
Open SSL
installation 52
overview, Data Protection for mySAP 22
P
password
password input file 128, 129
Pegasus CIM Server
installing 53
physical volume identifier (PVID) 155
platforms supported xv
problem determination
describing problems 334
determining business impact 334
submitting problems 334
profile information 83
progress status indicator (PSI) 137
Prole 23
Q
query
R
Remote shell (RSH) 56
remote shell connection
sample .rhosts for 238
restart_backup
restore
FlashBack Restore 84
EEE 205
methods 81
multiple EEE partitions 195
progress status indicator (PSI) 137
rerun with different target set 233
using FlashCopy 12
using tdphdwdb2 82
S
samples 235
SAN Volume Controller (SVC)
description 3
FlashCopy backup 75
scheduling
of backups 21
Tivoli Storage Manager 78
shared vendor library 23
sharing target volumes 58
software

Software Support
contacting 333
describing problems 334
determining business impact 334
receiving weekly updates 332
submitting problems 334
splitint
functions 105
storage system 1, 2
Subsystem Device Driver (SDD)
use and limitations 56
Subsystem Device Driver Path Control
Module (SDDPCM) 56
T
target set parameter 174
target set state 74
target volumes
sharing of 58
target volumes file
in LVM mirrored environment 175,
176, 178
structure and parameters 155
with multiple target sets 221
tdphdwdb2
flashcopy function 117
backup cycle description 15
backup function 107
configure function 127
dbresume function 130
functions 106
inquire function 126
modify_copyrate function 130
password function 129
query function 119
restart_backup function 131
restore function 110
restoring with 82
sample EEE FlashCopy script 272
sample EEE online/offline backup
script 273
sample HACMP scripts 273
sample shell script 271
sample usage 259
summary of functions 133
ts_inquire function 126
unmount function 124
with DB2 EEE 195
withdraw function 121
withdraw_force function 123
backup scheduler 77
sample client system options file 239
sample client user options file 239
scheduling function 78
trace files
summary 329
ts_inquire
TSM server
understanding 25
U
UNIX crontab, backup scheduler 78
unmount
V
volume groups
W
withdraw
withdraw_force

Index 349
Program Number: 5608ACS

Printed in USA

SC33-8208-01

Data Protection For Snapshot Devices For MySAPInstallation and User's Guide For DB2

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Data Protection For Snapshot Devices For MySAPInstallation and User's Guide For DB2

Transféré par

Droits d'auteur :

Formats disponibles

Tivoli Storage Manager

for Advanced Copy Services

Tivoli Storage Manager

Second Edition (January 2007)

Enterprise Storage Server

5.3 Common Information Model Guide SC23-4942

Restore (FlashBack Restore) functionality of DP for Snapshot

-based and UNIX-based) families of servers. Across all of

Server Technology in the

together with enhanced concurrent capable volume groups, DP for Snapshot

Program Number: 5608ACS

Vous aimerez peut-être aussi