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 User’s 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 User’s 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

Schönaicher Str. 220

71032 Böblingen

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 User’s 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 User’s 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 User’s 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 User’s 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 User’s 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 User’s 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 seriesv 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 Administrator’s Guide V5.3 GC32-0768

Tivoli Storage Manager for AIX Administrator’s 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 User’s Guide V5.3

GC32-0789

Tivoli Storage Manager for Enterprise Resource Planning: Data

Protection for mySAP Installation and User’s 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 AG51013686

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 ReferenceIBM DB2 Universal Database V8.1 See npte below.

SC09–4828

Data Recovery and High Availability Guide and ReferenceIBM DB2 Universal Database V8.1. See note beloe.

SC09-4831

IBM ESS and IBM DB2 UDB Working Together IBM RedbookSG24-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 User’s 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

Developer’s 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 User’s

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:


Support:


xiv Data Protection for Snapshot Devices for mySAP Installation and User’s 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

|

||||

|

|||

||

|

|

|

|

|

|

||

|||

|

||

http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.itsmreadme.doc/relnote_acfmd540.html

http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.itsmreadme.doc/relnote_acnmd540.html

xvi Data Protection for Snapshot Devices for mySAP Installation and User’s 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 (see“Storage 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

|

||||

|||

|

|

http://www.ibm.com/de/entwicklung/esd

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 User’s 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


||||

|||||||

http://www-1.ibm.com/servers/storage/support/software/sanvc/

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 create—typically 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

system’s 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 package1 (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 volumesv 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 FlashCopyv 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 runningv 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, continuev 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

copy3 from the source to the target volumes

v terminate execution on the production systemb. 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

successful7. 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 volumes4 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 databasev 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 EEP0302Ev 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 component3. 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 administrator’s 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 User’s 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 environment’s 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 User’s Guide for DB2 UDB.

Introduction


http://www.ibm.com/software/tivoli/products/storage-mgr-erp/

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 OpenPegasus5, 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


http://www.openpegasus.org/

http://www.dmtf.org/standards/cim

http://www.dmtf.org/standards/wbem

http://www.wbemsolutions.com/tutorials/CIM/cim.html

http://www.openssl.org

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 SVC’s Master Console (see Figure 6 on page 28). For

more information see IBM TotalStorage SAN Volume Controller CIM Agent Developer’s

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/withdraw6

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 User’s 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 tool7 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 systems8. 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 logs15. 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 user’s 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 User’s 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 User’s 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)



|

||||

||

||

||

|

|||||

|

|

||||||||

||||

||||||||

||||

|

||

http://www.ibm.com/servers/aix/products/aixos/linux/download.html

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.

DS Open API CIM Agent

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:



|||

http://www.ibm.com/servers/storage/support/software/cimdsoapi/installing.html

/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 user’s $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



|||

||||||||

||

||

||||

|

|

|

|||

http://www.ibm.com/support/

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 mechanism12 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



|

||||||||||||||||||

|||||

|

|||

|

|

|

|

|

|

||

||||

|

|

||

||

||||


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 User’s 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 FlashCopy13 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 techniques14 . 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 function14.

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 FlashCopy14 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 Devices’s 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 schedules15 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 Administrator’s 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 difficulties16 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 User’s 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 User’s 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 mySAP17 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

User’s 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 system’s 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 IDS2522I19, 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.

4. If one or more volumes have been deleted from the DB related 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).6. If one or more volumes have been deleted from the DB related volume groups

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:

FLASHCOPY_TYPE COPY or INCR

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 ID20 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, continuev 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 filesv 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 User’s 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 withdrawn3. 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

User’s 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 User’s

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> stopAfter 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 mounted21. 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 filesv 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 x1

-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 x1

-C <flashcopy_type>

PSI_MOUNT_DONE

query Backup system

only

-p ppp -n x1

-C <flashcopy_type>

n/a

unmount Backup system

only

-p ppp -n x1

(-C <flashcopy_type>

will be ignored if specified.)

PSI_UNMOUNT_DONE

withdraw Backup system

only

-p ppp -n x1



PSI_WITHDRAW_DONE

withdraw_force Backup system

only

-p ppp -n x1



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 x1 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 x1 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 state23 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_DISKANDTAPE2. 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

withdraw to clean up the






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, fsck’s,

and mounts have been

started.

’withdraw’ or ’unmount’

Start ’tdphdwdb2 -f

withdraw’ to clean up the






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 User’s 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 User’s 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

User’s 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 clusters24) 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 n26.

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 sets30) 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.).DP for Snapshot Devices action:

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

Node name = REM<SID>_0

2.

Database alias = R_<SID>_1

Node name = REM<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/tdphdwdb2–f 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).

System to be performed on: Production system only.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 –ror 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 User’s

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).

System to be performed on: Production system only.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 systemv 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 filev 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 systemv 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 systemv 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 COPY39) 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 system’s 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 ’NOCOPY’with 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 relationshipv 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 ’NOCOPY’with 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 & User’s 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 User’s 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 User’s 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

# that of the target volume) by DP for FlashCopy once the flashcopy function



#

#


#

# 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

# that of the target volume) by DP for FlashCopy once the flashcopy function



#

#


#

#------------------------------------------------------------------#







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 User’s 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 FlashCopy41 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 Followed42 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 Updated42 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 day’s 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 day’s 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 return2. 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 User’s 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 User’s 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 Devices’s 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

on the backup system.

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 doesn’t 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 doesn’t 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 / can‘t 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:


|

|

|||

|

|

|

|

||

|||

||||

|

|

|

|

||

||||

||

|

|

|

|

|||

|

||

||

http://www-306.ibm.com/software/support/isa

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.


||

||

||

||

|||

||

|

||

|

||

|||

||

||

||

||

|||

|

|

||

||

|

|

||

|

|

|

|

|

http://www.ibm.com/software/support


http://techsupport.services.ibm.com/guides/handbook.html

http://techsupport.services.ibm.com/guides/handbook.html



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 [email protected], 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

||

||

||

||

|

||||

||||

|||

||||

|||

|||

|||||||

||||||

|

|

|

|

http://www.ibm.com/software/howtobuy/passportadvantage/pao_customers.htm

http://www.ibm.com/software/howtobuy/passportadvantage/pao_customers.htm

http://techsupport.services.ibm.com/guides/contacts.html


https://techsupport.services.ibm.com/ssr/login

https://techsupport.services.ibm.com/ssr/login

http://www.ibm.com/services/us/index.wss/so/its/a1000030/dt006

http://www.ibm.com/servers/eserver/techsupport.html

http://www.ibm.com/servers/eserver/techsupport.html


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


|

|||

||||

|||

|||

||||

|

|||

|

||

||

||

||

|

|

||||

||||

|||||

http://www.ibm.com/software/support/probsub.html



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.


http://www.ibm.com/software/globalization/terminology

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 user’s 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 IBM’s 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 IBM‘s 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

AAdmin Tools

description 21

profile 22, 83

Administration Assistantunderstanding 24

AIXerror reporting command 330

automatic backup start 77

Bbackup

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 schedulerTivoli Storage Manager 77

UNIX crontab 78

backup status indicator (BSI) 139

backup, incremental 23

CCIM Agent 30

CIM Agent for SVCinstalling 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

configurefunction of tdphdwdb2 127

configure (continued)function of tdphdwdb2 with

EEE 201

crontabscheduling backups with 78

customer supportSee Software Support

customizing DP for mySAPwith the configuration file 24

with the profile 24

DData 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 instancessetup.sh 59

Database Partitioning Feature (DPF) 191

databasesmultiple 59

DB2integration with DP for Snapshot

Devices 13

DB2 EEEbackup/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

dbresumefunction of tdphdwdb2 130

disk layoutconsiderations for installation 34

sample 235

Disk Storage (DS) systemdescription 2

sample target volume definitions 251

sample target volume file (mirror

setup ) definitions 254

source/target volumes 57

DP for mySAPsample DB2 vendor INI file 239

DP for Snapshot Devicessplitint 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

DS Open API CIM Agentinstalling 54

introduction 31

EEnterprise Storage Server (ESS)

description 2


sample target volume file (mirror

setup ) definitions 254


environmentinstallation requirements 48

variables 63

error messages 275

error reportingAIX command 330

Ffixes, obtaining 331

FlashBack Restoredefined 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

flashcopyfunction of tdphdwdb2 117


EEE 204

FlashCopylogical FlashCopy group 223

FlashCopy Agent 136

FlashCopy backuppreventing simultaneous 224

with LVM mirrors 163

FlashCopy volumesdescription 12

FLASHCOPY_TYPEeffective 75

intended 75, 221

HHACMP 167

sample scripts 273

hardwareinstallation requirements 44

high availability 161

IIBM 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

inquirefunction of tdphdwdb2 126

installationchecking 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 requirementsDP for Snapshot Devices 44

environment 48

hardware 44

LVM mirroring 49

software 45

volume groups 49

JJFS2

Concurrent I/O (CIO) 40

JFS2 file systems 40

Llibrary, shared vendor 23

log filesbackup of offline log files 76

CIM 329

DP for mySAP 330

DP for Snapshot Devices 329

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 mirroringinstallation requirements 49

Mmessages

DP for Snapshot Devices 275

severity levels 275

mirror environmenttarget volumes file 175

modify_copyratefunction of tdphdwdb2 130

multiple backup generations on diskoverview 219

multiple target setsautomated 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

target volumes file 221

NN Series 4

Naming conventions xv

NFSsample client setup 238

sample server setup 237

setting up 55

OOpen SSL

installation 52

overview, Data Protection for mySAP 22

Ppassword


password input file 128, 129

Pegasus CIM Serverinstalling 53

physical volume identifier (PVID) 155

platforms supported xv

problem determinationdescribing problems 334

determining business impact 334

submitting problems 334

profile information 83

progress status indicator (PSI) 137

Prole 23

Qquery


RRemote shell (RSH) 56

remote shell connectionsample .rhosts for 238

restart_backupfunction of tdphdwdb2 131

restorebackup status indicator (BSI) 139

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


Ssamples 235

SAN Volume Controller (SVC)description 3

FlashCopy backup 75



schedulingof backups 21

Tivoli Storage Manager 78

shared vendor library 23

sharing target volumes 58

softwareinstallation requirements 45


Software Supportcontacting 333

describing problems 334

determining business impact 334

receiving weekly updates 332

submitting problems 334

splitintfunctions 105

storage system 1, 2


Subsystem Device Driver (SDD)use and limitations 56

Subsystem Device Driver Path Control

Module (SDDPCM) 56

Ttarget set parameter 174

target set state 74

target volumessharing of 58

target volumes filein 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

Tivoli Storage Managerbackup scheduler 77

sample client system options file 239

sample client user options file 239

scheduling function 78

trace filesDP for Snapshot Devices 329

summary 329

ts_inquirefunction of tdphdwdb2 126

TSM serverunderstanding 25

UUNIX crontab, backup scheduler 78

unmountfunction of tdphdwdb2 124

Vvolume groups

installation requirements 49

Wwithdraw


withdraw_forcefunction of tdphdwdb2 123

Index 349

��

Program Number: 5608–ACS

Printed in USA

SC33-8208-01