ibm tivoli storage manager v6.1 technical guide sg247718

ibm.com/redbooks

Front cover

Tivoli Storage Manager V6.1 Technical Guide

Mary LovelaceGerd Becker

Dan EdwardsShayne GardenerMikael Lindstrom

Craig McAllisterNorbert Pott

Learn the new features and function in Tivoli Storage Manager V6.1

Detailed installation, upgrade, and customization provided

Monitoring and reporting enhancement examples

http://www.redbooks.ibm.com/


International Technical Support Organization


December 2009

SG24-7718-00

© Copyright International Business Machines Corporation 2009. All rights reserved.Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP ScheduleContract with IBM Corp.

First Edition (December 2009)

This edition applies to Version 6, Release 1, of IBM Tivoli STorage Manager (product number 5698-B22).

Note: Before using this information and the product it supports, read the information in “Notices” on page xiii.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiThe team who wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiBecome a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xxComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xx

Part 1. IBM Tivoli Storage Manager introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. IBM Tivoli Storage Manager overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Product positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Overview of the development timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Upgrade path for clients and servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.2 Migration guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Overview of new features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4.1 Server enhancements, additions, and changes from Version 6.1. . . . . . . . . . . . . . 71.4.2 Client enhancements, additions, and changes from Version 6.1 . . . . . . . . . . . . . . 8

1.5 Additional functionality overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5.1 Tivoli Storage Manager for SAN, additions, and changes . . . . . . . . . . . . . . . . . . 101.5.2 Tivoli Storage Manager HSM for Windows Version 6.1, additions, and changes . 111.5.3 Tivoli Storage Manager for Space Management, additions and changes. . . . . . . 11

1.6 Additional information about Tivoli Storage Manager V6.1 . . . . . . . . . . . . . . . . . . . . . . 12

Chapter 2. IBM Tivoli Storage Manager for products. . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1 IBM Tivoli Storage Manager for Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Data Protection for Microsoft Exchange Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 IBM Tivoli Storage Manager for Microsoft SharePoint V6.1 . . . . . . . . . . . . . . . . . . . . . 152.4 IBM Tivoli Storage Manager for ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5 IBM Tivoli Storage Manager for Advanced Copy Services V6.1 and IBM Tivoli Storage

Manager for Copy Services V6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Part 2. Tivoli Storage Manager enhancements since V5.4 and V5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 3. Tivoli Storage Manager enhancements provided since V5.5 availability . 213.1 SAN Device Mapping for Virtual Tape Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 RELABELSCRATCH parameter for Virtual Tape Libraries . . . . . . . . . . . . . . . . . . . . . . 243.3 RECLAIMDELAY and RECLAIMPERIOD server options . . . . . . . . . . . . . . . . . . . . . . . 263.4 Tivoli Storage Manager HP-UX passthru driver support . . . . . . . . . . . . . . . . . . . . . . . . 27

Part 3. Tivoli Storage Manager V6.1 Server enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 4. Commands, utilities, and option changes . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1 New server commands, utilities, and options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2 Updated server commands, utilities, and options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3 Deleted server commands, utilities, and options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 5. IBM Tivoli Storage Manager database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

© Copyright IBM Corp. 2009. All rights reserved. iii

5.2 Transition to DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2.1 Database transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2.2 General DB2 configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2.3 Database and log configuration items. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.3 Database administration tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.3.1 DB2 commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.3.2 DB2 Control Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.4 Database maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.4.1 Backing up your database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.4.2 Restoring the database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1025.4.3 Increase database space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115.4.4 Diagnostic information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Chapter 6. IBM Tivoli Storage Manager Disaster Recovery Manager . . . . . . . . . . . . 1216.1 Introduction to disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.2 Disaster Recovery Manager changes in V6.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.2.1 New system requirements for V6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.2.2 Recovery plan limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236.2.3 DRM enhancements for V6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1236.2.4 Disaster Recovery Manager exclusions in V6.1 . . . . . . . . . . . . . . . . . . . . . . . . . 128

6.3 Recovery of a V6.1 Tivoli Storage Manager server . . . . . . . . . . . . . . . . . . . . . . . . . . 1286.3.1 Local disaster recovery of the Tivoli Storage Manager database . . . . . . . . . . . . 1286.3.2 DR site recovery of the Tivoli Storage Manager server . . . . . . . . . . . . . . . . . . . 1296.3.3 DR site recovery scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.4 Data deduplication considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1376.4.1 Data life cycle for a Tivoli Storage Manager server and DRM . . . . . . . . . . . . . . 1376.4.2 Data life cycle for a Tivoli Storage Manager server and DRM including deduplicated

storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1386.5 Seven tiers of disaster recovery solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

6.5.1 A breakdown of the seven tiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1406.5.2 Selecting the optimum Disaster Recovery solution. . . . . . . . . . . . . . . . . . . . . . . 142

6.6 Best practices for offsite data vaulting and security . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Chapter 7. Data deduplication in Tivoli Storage Manager V6.1 . . . . . . . . . . . . . . . . . 1457.1 Introduction to deduplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

7.1.1 Deduplication approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1467.1.2 Deduplication ratios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1477.1.3 Tivoli Storage Manager V6.1 deduplication overview . . . . . . . . . . . . . . . . . . . . . 1487.1.4 Should we use Tivoli Storage Manager, or VTL/Filer deduplication? . . . . . . . . . 150

7.2 Implementing deduplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Chapter 8. No-query restore changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1558.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

8.1.1 Proprietary NQR algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1568.1.2 Objectives of the new NQR process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1568.1.3 New NQR process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

8.2 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Chapter 9. Expiration enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

9.1.1 Proprietary expiration algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629.1.2 Objectives of the new expiration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639.1.3 Enhanced Tivoli Storage Manager V6.1 expiration algorithm. . . . . . . . . . . . . . . 164

9.2 Externals of the enhanced expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

iv Tivoli Storage Manager V6.1 Technical Guide

9.2.1 Command line changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1649.2.2 Administration Center integration: Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . 1669.2.3 Administration Center integration: maintenance script . . . . . . . . . . . . . . . . . . . . 1689.2.4 New server messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709.2.5 Expiration restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1729.2.6 Expiration retries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

9.3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Chapter 10. Changes to the TXNGROUPMAX default . . . . . . . . . . . . . . . . . . . . . . . . . 17710.1 Transaction handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

10.1.1 TXNGROUPMAX option examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17810.1.2 Server options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

10.2 Implementation example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17910.3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Part 4. Tivoli Storage Manager V6.1 Client enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Chapter 11. HSM for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18511.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18611.2 Automatic threshold migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

11.2.1 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18811.2.2 Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19111.2.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

11.3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Chapter 12. Active Directory Object Item Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19512.1 Active Directory overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19612.2 Version 6.1 Client Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

12.2.1 Design limitations for restore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19812.2.2 New client commands and parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19912.2.3 New client options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Chapter 13. Client restore statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20513.1 QUERYSUMMARY option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20613.2 QUERYSUMMARY output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Part 5. Complimentary products and NDMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Chapter 14. N Series support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21114.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

14.1.1 Large file system backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21214.1.2 IP address of server interface to receive NDMP backup data . . . . . . . . . . . . . 213

14.2 SnapMirror to Tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21514.2.1 How to set up, use, and control SnapMirror to Tape for backup. . . . . . . . . . . . 21714.2.2 How to restore a NAS Volume from SnapMirror to Tape backup . . . . . . . . . . . 219

14.3 The snapdiff option for NFS data stored on NetApp filers. . . . . . . . . . . . . . . . . . . . . 22014.3.1 Overview of SnapDiff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22014.3.2 How the Backup Archive Client interacts with the SnapDiff-API . . . . . . . . . . . . 22214.3.3 Preparation for using SnapDiff API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22214.3.4 Using snapdiff option to do Incremental Backup for NAS file systems . . . . . . . 22514.3.5 Hints and tips for troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23114.3.6 Performance issues and test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Chapter 15. IBM Tivoli Storage Manager Data Protection for Mail: Exchange 6.1 . . 23515.1 System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

Contents v

15.1.1 Data Protection for Microsoft Exchange V6.1 on Windows for x86. . . . . . . . . . 23615.1.2 Microsoft Exchange Server 2003 SP2 or later . . . . . . . . . . . . . . . . . . . . . . . . . 23615.1.3 Data Protection for Microsoft Exchange V6.1 on Windows for x64. . . . . . . . . . 23615.1.4 Compatibility issues with earlier versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23715.1.5 Backup methods supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

15.2 Individual Mailbox Restore feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23815.2.1 Individual Mailbox Restore limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23915.2.2 Tivoli Storage Manager 6.1 Mailbox Restore features . . . . . . . . . . . . . . . . . . . 23915.2.3 Exchange Server: Mailbox Restore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24015.2.4 Tivoli Storage Manager Mailbox Restore limitations . . . . . . . . . . . . . . . . . . . . . 24215.2.5 The restoremailbox command line parameter. . . . . . . . . . . . . . . . . . . . . . . . . . 242

Part 6. Tivoli Storage Manager V6.1 planning considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Chapter 16. Installation and upgrade planning for Tivoli Storage Manager V6.1 . . . 24516.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24616.2 Upgrade strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

16.2.1 What you can and cannot do with Tivoli Storage Manager V6.1 . . . . . . . . . . . 24616.2.2 Upgrade considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

16.3 Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24816.3.1 System requirements for the V6.1 server system . . . . . . . . . . . . . . . . . . . . . . . 24816.3.2 System requirements for the V6.1 reporting and monitoring. . . . . . . . . . . . . . . 25016.3.3 Client environment requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25016.3.4 Tivoli Storage Manager Client compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

16.4 Database capacity planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25116.4.1 Overview of the four different log types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25116.4.2 Recovery logs summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

16.5 Planning an upgrade from V5 to V6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25416.5.1 Database restructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25416.5.2 Estimating the upgrade time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25516.5.3 Space requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25716.5.4 Work sheet for planning space for the V6.1 server . . . . . . . . . . . . . . . . . . . . . . 26316.5.5 High level process for upgrading the server to V6.1 . . . . . . . . . . . . . . . . . . . . . 263

16.6 Naming best practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26416.7 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26516.8 Upgrading an existing system versus a new system. . . . . . . . . . . . . . . . . . . . . . . . . 266

16.8.1 Comparison of methods for moving data to the V6.1 database . . . . . . . . . . . . 26716.8.2 Details of the database upgrade process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27116.8.3 Tivoli Storage Manager V6.1 upgrade utilities . . . . . . . . . . . . . . . . . . . . . . . . . 274

16.9 Upgrade scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27516.9.1 Scenario 1: New system, media method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27616.9.2 Upgrading the server using the wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27616.9.3 Scenario 2: New system, network method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27716.9.4 Upgrading using the wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27816.9.5 Scenario 3: Same system, media method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27816.9.6 Summary of the wizard method scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27916.9.7 Scenario 4: Same system, network method . . . . . . . . . . . . . . . . . . . . . . . . . . . 28016.9.8 Upgrading the server using the wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28116.9.9 Hybrid upgrade migration method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

16.10 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28816.10.1 Testing the upgrade process for a server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28816.10.2 Test by extracting data from a separate copy of the server . . . . . . . . . . . . . . 28916.10.3 Test by extracting data from the production server. . . . . . . . . . . . . . . . . . . . . 290

vi Tivoli Storage Manager V6.1 Technical Guide

16.11 Planning for operational changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29116.12 Why use the database upgrade wizards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29316.13 An upgrade test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

16.13.1 Upgrading from V5.5 to V6.1, step by step . . . . . . . . . . . . . . . . . . . . . . . . . . . 29416.13.2 Additional preparation activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

16.14 Modifying the server before the upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29516.14.1 Performance tips for the V5 database extraction process . . . . . . . . . . . . . . . 29916.14.2 Performance tips for inserting data into the V6.1 database . . . . . . . . . . . . . . 300

16.15 Tivoli Storage Manager documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Part 7. Installation, customization, and upgrade of Tivoli Storage Manager V6.1 Server and Client 301

Chapter 17. Installation of Tivoli Storage Manager V6.1 on AIX . . . . . . . . . . . . . . . . . 30317.1 System requirements for AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

17.1.1 Planning the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30417.1.2 System requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

17.2 Installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30517.2.1 Prepare the installation source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30517.2.2 Choosing the installation method for AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

17.3 Installing Tivoli Storage Manager for AIX software . . . . . . . . . . . . . . . . . . . . . . . . . . 30717.4 Installation using the console installation wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

17.4.1 Setup of X11 environment for non-graphical environments . . . . . . . . . . . . . . . 31117.4.2 Installation wizard using X11 redirection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

17.5 Post-installation steps for Tivoli Storage Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 31617.5.1 Preparing the AIX server for Tivoli Storage Manager instances . . . . . . . . . . . . 31617.5.2 Post-completion tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32817.5.3 Configuring using the dsmicfgx and X11 redirection. . . . . . . . . . . . . . . . . . . . . 333

17.6 Upgrading from Tivoli Storage Manager V6.1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34217.7 Problem determination and recovery actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

17.7.1 Database queries and validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34317.7.2 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34617.7.3 Completely removing the Deployment Engine if required . . . . . . . . . . . . . . . . . 347

17.8 Backup considerations for production on V6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

Chapter 18. Installation of Tivoli Storage Manager V6.1 on Windows . . . . . . . . . . . . 35318.1 IBM Tivoli Storage Manager planning for installation . . . . . . . . . . . . . . . . . . . . . . . . 35418.2 System requirements for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

18.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35518.2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

18.3 Planning for space for the V6.1 server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35618.4 Tivoli Storage Manager V6.1 components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

18.4.1 Package names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35718.4.2 Package extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35718.4.3 Installing components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

18.5 Installing the Tivoli Storage Manager components . . . . . . . . . . . . . . . . . . . . . . . . . . 35818.6 Installation wizard installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36018.7 Command-line console wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37018.8 Silent mode installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

18.8.1 Silent mode without saving responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37418.8.2 Silent mode saving responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375

18.9 Creating directories and user ID for the server instance. . . . . . . . . . . . . . . . . . . . . . 37618.9.1 Creating the directories for the server instance . . . . . . . . . . . . . . . . . . . . . . . . 37618.9.2 Creating the user ID for the server instance . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

18.10 Configuring a new Tivoli Storage Manager Server instance . . . . . . . . . . . . . . . . . . 377

Contents vii

18.11 Using the Tivoli Storage Manager configuration wizard . . . . . . . . . . . . . . . . . . . . . 37818.12 Creating the server instance manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

18.12.1 Manually creating a Tivoli Storage Manager instance . . . . . . . . . . . . . . . . . . 39318.12.2 Running multiple server instances on a single system . . . . . . . . . . . . . . . . . . 39818.12.3 Configuring server and client communications . . . . . . . . . . . . . . . . . . . . . . . . 39918.12.4 TCP/IP options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39918.12.5 Named Pipes options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40018.12.6 Shared memory options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40018.12.7 SNMP DPI subagent options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40018.12.8 Monitoring the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40118.12.9 Network connection types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

18.13 Debugging techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40218.13.1 Investigating log messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40218.13.2 How to completely remove Deployment Engine . . . . . . . . . . . . . . . . . . . . . . . 403

18.14 Gathering logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

Chapter 19. Tivoli Storage Manager V6.1 Backup-Archive Client update and installation changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

19.1 Backup-Archive Client updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40819.1.1 New function in Tivoli Storage Manager V6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 40819.1.2 Related commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410

19.2 Installation of the Tivoli Storage Manager V6.1 client . . . . . . . . . . . . . . . . . . . . . . . . 41119.2.1 Migrating from earlier versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41119.2.2 Considerations for migrating between processor architectures . . . . . . . . . . . . 41219.2.3 Unicode considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41319.2.4 Additional migration information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41419.2.5 Upgrading Open File Support or online image . . . . . . . . . . . . . . . . . . . . . . . . . 41419.2.6 NDMP support requirements (Extended Edition only) . . . . . . . . . . . . . . . . . . . 41419.2.7 Installing from the Tivoli Storage Manager DVD. . . . . . . . . . . . . . . . . . . . . . . . 41519.2.8 Installation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41519.2.9 Installation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416

Part 8. Tivoli Storage Manager V6.1 monitoring, reporting, ISC, and Administration Center . . . . . . 429

Chapter 20. Monitoring and reporting in Tivoli Storage Manager V6.1 . . . . . . . . . . . 43120.1 Monitoring and reporting overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432

20.1.1 Administration Center: Health Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43220.1.2 Administration Center: Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43320.1.3 Tivoli Storage Manager Monitoring and Reporting . . . . . . . . . . . . . . . . . . . . . . 434

20.2 Monitoring and reporting installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43720.3 Installing the Monitoring and Reporting feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43820.4 Business Intelligence and Reporting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

Chapter 21. Integrated Solutions Console and Administration Center . . . . . . . . . . . 44921.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450

21.1.1 New installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45021.1.2 Upgrade and co-existence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45021.1.3 Upgrade considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

21.2 Administration Center updates and enhancements . . . . . . . . . . . . . . . . . . . . . . . . . 45221.2.1 Policy Domain configuration panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45221.2.2 Updated Integrated Solutions Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45221.2.3 WebSphere Windows service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

21.3 Administration Center features in V6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45221.3.1 Identify managing servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

viii Tivoli Storage Manager V6.1 Technical Guide

21.3.2 Hover help for table links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45221.3.3 Information links for server and Administration Center messages . . . . . . . . . . 45321.3.4 Maintenance script enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45321.3.5 Client nodes and backup sets enhancements . . . . . . . . . . . . . . . . . . . . . . . . . 45321.3.6 Centralized server-connection management . . . . . . . . . . . . . . . . . . . . . . . . . . 45321.3.7 Changes to management-class activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45321.3.8 DRM support for Active Data Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45421.3.9 Health Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45421.3.10 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45821.3.11 Creating a new server instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46021.3.12 Client nodes and backup set enhancements . . . . . . . . . . . . . . . . . . . . . . . . . 46721.3.13 Maintenance plan enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

21.4 Integrated Solutions Console changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48721.4.1 Tivoli Common Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48821.4.2 Single user ID signon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48821.4.3 Credential Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48921.4.4 Manage Global Refresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49021.4.5 Quick references. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

21.5 Additional notes of interest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492

Part 9. Tivoli Storage Manager V6.1 upgrade consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495

Chapter 22. Upgrading to Tivoli Storage Manager V6.1 . . . . . . . . . . . . . . . . . . . . . . . 49722.1 Upgrade strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

22.1.1 The process for upgrading the server to V6.1. . . . . . . . . . . . . . . . . . . . . . . . . . 49822.1.2 The DSMUPGRD upgrade utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499

22.2 Hardware and software server requirements for upgrade. . . . . . . . . . . . . . . . . . . . . 49922.2.1 Hardware and software requirements for V5 server upgrade . . . . . . . . . . . . . . 50022.2.2 Upgrade utility additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50122.2.3 Hardware and software requirements for the upgraded server. . . . . . . . . . . . . 50222.2.4 Server requirements on AIX systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50222.2.5 Server requirements on HP-UX systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50422.2.6 Server requirements on Linux systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50522.2.7 Server requirements for Linux on x86_64 systems. . . . . . . . . . . . . . . . . . . . . . 50622.2.8 Server requirements for Linux on System z systems . . . . . . . . . . . . . . . . . . . . 50822.2.9 Server requirements on Sun Solaris systems. . . . . . . . . . . . . . . . . . . . . . . . . . 50922.2.10 Server requirements on Microsoft Windows systems . . . . . . . . . . . . . . . . . . . 510

22.3 Planning space for the upgrade process and server. . . . . . . . . . . . . . . . . . . . . . . . . 51122.3.1 Space requirements for the V5 server system . . . . . . . . . . . . . . . . . . . . . . . . . 51222.3.2 Space requirements for the Tivoli Storage Manager V6 server system . . . . . . 51222.3.3 Estimating total space requirements for upgrade process and server . . . . . . . 514

22.4 Estimating the upgrade time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51522.4.1 Performance tips for the extraction process . . . . . . . . . . . . . . . . . . . . . . . . . . . 51522.4.2 Performance tips for inserting data into the V6.1 database . . . . . . . . . . . . . . . 516

22.5 Planning for upgrading multiple servers and components . . . . . . . . . . . . . . . . . . . . 51722.5.1 Compatibility with servers and components running at earlier versions . . . . . . 51722.5.2 Planning for upgrading multiple servers on a single system. . . . . . . . . . . . . . . 51722.5.3 Planning for upgrading library managers and library clients . . . . . . . . . . . . . . . 51722.5.4 Planning for upgrading clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51822.5.5 Planning for upgrading storage agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

22.6 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51822.7 Preparing for operational changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

Chapter 23. Tivoli Storage Manager V6.1 Upgrade Scenarios . . . . . . . . . . . . . . . . . . 521

Contents ix

23.1 The basics of planning the upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52223.2 Upgrade scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52223.3 Upgrading from V5.5 to V6.1 step by step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

23.3.1 Modifying the server before the upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52423.3.2 Upgrade steps: V5.5 server to V6.1 on Windows platform . . . . . . . . . . . . . . . . 52823.3.3 Summary of the upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551

23.4 Steps after V6.1 server is started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55523.4.1 Initial verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55523.4.2 Database backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556

23.5 Sample commands to run for database upgrade validation . . . . . . . . . . . . . . . . . . . 55723.6 Common database maintenance tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55823.7 Scripting and reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

23.7.1 SQL function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55923.7.2 SQL syntax enforcement examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560

23.8 How to rollback to V5 if needed or restart the process . . . . . . . . . . . . . . . . . . . . . . . 56023.9 Debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56123.10 Gathering logs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56223.11 Upgrade for NAS TOC data on AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562

23.11.1 Steps for the upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56223.11.2 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570

Part 10. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571

Appendix A. Configuring ODBC connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573DB2 configuration for ODBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574

ODBC target machine configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574ODBC client machine configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576ODBC connection examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584

Appendix B. DB2 and SQL commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597Commands to manage the database environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598Diagnosing and troubleshooting the database environment . . . . . . . . . . . . . . . . . . . . . . . 604Monitoring the status and health of the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610Changes to the SELECT command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

LIKE predicate for a nested SELECT statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613SELECT statements for time calculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613The index_keyseq and index_order columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614Access to database objects using the SELECT command. . . . . . . . . . . . . . . . . . . . . . 614Table joins and column labeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615Results of the SELECT command for the DISK device class . . . . . . . . . . . . . . . . . . . . 615Extra spaces appearing in output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616

Appendix C. Recovering from log exhausted conditions . . . . . . . . . . . . . . . . . . . . . . 617Preparing for the out of log space condition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618

The server crash scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618Recovering the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619Complete the recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629

x Tivoli Storage Manager V6.1 Technical Guide

Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631

Contents xi

xii Tivoli Storage Manager V6.1 Technical Guide

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.

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

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.

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.

© Copyright IBM Corp. 2009. All rights reserved. xiii

Trademarks

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. These and other IBM trademarked terms are marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml

The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

AIX 5L™AIX®DB2®DPI®DS6000™DS8000®FlashCopy®GDPS®GPFS™HACMP™HyperSwap®

IBM®MQSeries®NetView®OS/390®Passport Advantage®POWER5™POWER®ProtecTIER®Redbooks®Redbooks (logo) ®SANergy®

System i®System p®System Storage™System z®Tivoli®TotalStorage®WebSphere®XIV®z/OS®zSeries®

The following terms are trademarks of other companies:

ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office.

Snapshot, Network Appliance, SnapMirror, SnapLock, FlexVol, FilerView, Data ONTAP, NetApp, and the NetApp logo are trademarks or registered trademarks of NetApp, Inc. in the U.S. and other countries.

Data ONTAP, FilerView, FlexVol, NetApp, Network Appliance, SnapMirror, Snapshot, and the Network Appliance logo are trademarks or registered trademarks of Network Appliance, Inc. in the U.S. and other countries.

AMD, AMD Opteron, the AMD Arrow logo, and combinations thereof, are trademarks of Advanced Micro Devices, Inc.

SUSE, the Novell logo, and the N logo are registered trademarks of Novell, Inc. in the United States and other countries.

Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation and/or its affiliates.

ACS, Red Hat, and the Shadowman logo are trademarks or registered trademarks of Red Hat, Inc. in the U.S. and other countries.

mySAP, SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries.

VMware, the VMware "boxes" logo and design are registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions.

Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Microsoft, Windows NT, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Intel, Itanium, Pentium, Intel logo, Intel Inside logo, and Intel Centrino logo 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.

xiv Tivoli Storage Manager V6.1 Technical Guide

http://www.ibm.com/legal/copytrade.shtml

Linux is a 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.

Notices xv

xvi Tivoli Storage Manager V6.1 Technical Guide

Preface

This IBM® Redbooks® publication provides details of changes, updates, and new functions in IBM Tivoli® Storage Manager Version 6.1. We also cover all the new functions of Tivoli Storage Manager that have become available since the publication of IBM Tivoli Storage Manager Version 5.4 and Version 5.5 Technical Guide, SG24-7447.

This book is for customers, consultants, IBM Business Partners, and IBM and Tivoli staff who are familiar with earlier releases of Tivoli Storage Manager and who want to understand what is new in Version 6.1. Because we target an experienced audience, we use certain shortcuts to commands and concepts of Tivoli Storage Manager. If you want to learn more about Tivoli Storage Manager functionality, see IBM Tivoli Storage Management Concepts, SG24-7447, and IBM Tivoli Storage Manager Implementation Guide, SG24-5416.

This publication should be used in conjunction with the manuals and readme files provided with the products and is not intended to replace any information contained in them.

The team who wrote this book

This book was produced by a team of specialists from around the world working at the International Technical Support Organization, San Jose Center shown in Figure 1.

Figure 1 The team: Dan, Craig, Mary, Mikael, Gerd, Shayne, Norbert

Mary Lovelace is a Consulting IT specialist at the International Technical Support Organization. She has more than 20 years of experience with IBM in large systems, storage, and Storage Networking product education, system engineering and consultancy, and systems support. She has written many Redbooks publications about Tivoli lStorage Productivity Center and z/OS® storage products.

Gerd Becker is a Project Manager for EMPALIS GmbH, a Premium IBM Business Partner in Germany. He has more than 25 years of IT experience, including over 13 years experience with storage management products such as DFSMS and Tivoli Storage Manager. His areas of expertise include IBM Tivoli Storage Manager implementation projects and education at customer sites, including mainframe environments (OS/390®, VSE, VM, and Linux® for zSeries®). He holds several certifications, including technical and sales, and is an IBM Tivoli Certified Instructor. He has developed and taught several storage classes for IBM Education Services in Germany, Switzerland, and Austria. He has been Chairman of the Guide Share Europe (GSE) user group for more than six years. He is author of the Redbooks publication, IBM Tivoli Storage Manager Technical Guide 5.3, participated in the beta test for Tivoli Storage Manager Version 5.5 and 6.1, and is a member of the Tivoli Storage Manager Advisory Council.

© Copyright IBM Corp. 2009. All rights reserved. xvii

Dan Edwards is a Consulting I/T Specialist with IBM Global Services, Global Technology Services, based in Ottawa, Canada. Dan has over 31 years experience in the computing industry, including 19 years spent working on UNIX®, High Availability, Tivoli Storage Manager (ADSM), and other storage solutions. He holds multiple product certifications, including MCSE, Tivoli Storage Manager, AIX®, HACMP™, and Oracle. He is also an IBM Certified Professional and a member of the I/T Specialist Certification Board. Dan contracts with IBM clients globally, and over the past seven years, has primarily consulted on Tivoli Storage Manager, High Availability, and Disaster Recovery engagements. Dan has co-authored several books, including IBM Tivoli Storage Manager in a Clustered Environment, SG24-6679, and IBM Tivoli Storage Manager: Building a Secure Environment, SG24-7505.

Shayne Gardener is a Tivoli Storage Consultant based in the United Kingdom as a member of the EMEA Global Response Team. He has nearly 20 years of customer facing experience in Computer Support. He has an HND in Computing from Gloucestershire University in Cheltenham, United Kingdom. He has nearly 10 years of service with IBM. His skill areas include IBM Tivoli Storage Manager and its complementary products along with Professional and Technical Certification. He is certified as an IBM Certified Deployment Professional - Tivoli Storage Manager V6.1, an IBM Certified Specialist - Tivoli Storage Manager FastBack V5.5, an IBM Certified Solution Advisor - Tivoli Storage Solutions 2009 and is also certified for the ITIL® V3 Foundation Certificate in IT Service Management.

Mikael Lindstrom is a IT Specialist for IBM ITD Sweden working as a team leader for Storage and as a Technology lead for Tivoli Storage Manager. He has nine years of IT experience and has been working for IBM since 2006. Mikael has Tivoli Storage Manager server and client experience on Windows® and AIX platforms since 2002 including three years experience in designing and implementing Tivoli Storage Manager Solutions on Windows and AIX platforms. He has participated in the Tivoli Storage Manager V6.1 Beta program. He is a certified Tivoli Storage Manager Storage Administrator and certified Tivoli Storage Manager Deployment Professional in V5 and V6 and is the Tivoli Storage Manager officer of the Tivoli User Group in Sweden.

Craig McAllister is a Tivoli Consultant who has specialized in storage management and closely related topics since 1998. He has worked for IBM United Kingdom since the year 2000 and he supports clients all over the region for presales and services engagements with Tivoli Storage Manager and TotalStorage® Productivity Center. Craig has authored several Redbooks publications, including IBM Tivoli Storage Manager Versions 5.4 and 5.5 Technical Guide, SG24-7447.

Norbert Pott is an IBM Tivoli Storage Manager Support Specialist in Germany. He works for the Tivoli Storage Manager back-end support team and provides support to customers worldwide. He has 27 years of experience with IBM, over 18 years of experience in IT, and more than 11 years of experience with the Tivoli Storage Manager product, starting with ADSM Version 2.1.5. His areas of expertise include Tivoli Storage Manager client development skill and in-depth knowledge when it comes to problem determination. He is an author of the Redbooks publications, IBM Tivoli Storage Manager Version 5.3 Technical Workshop Presentation Guide, SG24-6774, IBM Tivoli Storage Manager Implementation Guide, SG24-5416, IBM Tivoli Storage Management Concepts, SG24-4877, and IBM Tivoli Storage Manager Versions 5.4 and 5.5 Technical Guide, SG24-7447.

xviii Tivoli Storage Manager V6.1 Technical Guide

Thanks to the following people for their contributions to this project:

Barry FruchtmanColin DawsonDonald MoxleyJo LayKen HanniganMatthew AnglinMichael G. SiscoTivoli Storage Manager Server development

Alexei KojenovStefan BenderTivoli Storage Manager Client Development

Andy RuhlBenjamin SchockertJohn WangTodd OwczarzakWolfgang BeuttlerTivoli Storage Manager Software Support

Clare M ByrneGary SpizizenHolly KingLiudyte BakerTivoli Storage Manager Information Development

Roger StakkestadIBM SWG Norway

Cyrus NiltchianTricia JiangTechnology Sales Enablement

Charles NicholsDave CananRandy LarsonRobert ElderTomas HepnerZong LingPerformance and ATS

Urs MoserIntegrated Technology Delivery, Server Systems Operations

Austen M CookTashfique HossainStorage System Test

Joerg PohlmannIBM Global Services, Canada

Roger StakkestadIBM SWG Norway

Preface xix

Peter KaskIBM Innovation Center - Stockholm, Sweden

Konstantin ArnoldBiozentrum Pharmazentrum Information Technology / Div. of BioinformaticsSwiss Institute of Bioinformatics (SIB)

Dieter UnterseherNetApp®

Become a published author

Join us for a two- to six-week residency program! Help write a book dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You will have the opportunity to team with IBM technical professionals, Business Partners, and Clients.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you will develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at:

ibm.com/redbooks/residencies.html

Comments welcome

Your comments are important to us!

We want our books to be as helpful as possible. Send us your comments about this book or other IBM Redbooks publications in one of the following ways:

� Use the online Contact us review Redbooks form found at:

ibm.com/redbooks

� Send your comments in an e-mail to:

[email protected]

� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400

xx Tivoli Storage Manager V6.1 Technical Guide

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/residencies.html



http://www.redbooks.ibm.com/contacts.html

Part 1 IBM Tivoli Storage Manager introduction

This part of the book provides an overview of the IBM Tivoli Storage Manager and Tivoli Storage Manager for Products.

Part 1

© Copyright IBM Corp. 2009. All rights reserved. 1

2 Tivoli Storage Manager V6.1 Technical Guide

Chapter 1. IBM Tivoli Storage Manager overview

In this chapter we present an overview of the new functionality and changes that come with the IBM Tivoli Storage Manager Version 6.1. In a separate chapter we detail the cumulative changes in the releases since Version 5.5.0, when the previous Technical Guide was published.

We discuss the following major areas of change:

� Server enhancements, additions, and changes� Client enhancements, additions, and changes� Additional Tivoli Storage Manager features

1


1.1 OverviewIBM Tivoli Storage Manager protects data from hardware failures, errors, and unforeseen disasters by storing backup and archive copies on offline and off-site storage. Scaling to protect hundreds to thousands of computers running more than a dozen operating systems, ranging from mobile computers to mainframes and connected together by the Internet, WANs, LANs, or SANs, Storage Manager Extended Edition's centralized Web-based management, intelligent data move and store techniques, and comprehensive policy-based automation all work together to minimize administration costs and the impact to both computers and networks.

Optional software modules allow business-critical applications that must run 24x365 to utilize Storage Manager's centralized data protection with no interruption to their service. Optional software extensions also allow SAN-connected computers to use the SAN for data protection data movements, and provide Hierarchical Storage Management to automatically move unused data files from online disk storage to offline tape storage. Storage Manager Extended Edition expands on the data backup and restore and managed data archive and retrieve capabilities of the base Storage Manager by adding disaster planning capability, NDMP control for NAS filers, and support for large tape libraries.

Figure 1-1shows the interrelation of the components in IBM Tivoli Storage Manager.

Figure 1-1 How the product components interrelate

Note: We recommend installing the standard Tivoli Storage Manager Administration Center and Tivoli Storage Manager Monitoring and Reporting on the same server to manage multiple mixed Tivoli Storage Manager Servers.

Integrated Solution Console with TSM Admin Center

TSM Server TSM Stgpools TSM Clients

Repository

IP Network

Servers, Clients, Application systems

Database

Storage

Log

ISC Server can be run on the same

server as the TSM server

TSM Monitoring and Reporting

TSM Monitoring & Reporting

A separate server is optional for the ISC but mandatory for the monitoring and reporting

server

Storage Area Network


With the initial shipment of the Tivoli Storage Manager V6.1, it was not supported to install additional products that deploy and use DB2® on the same system as the server was running. This restriction has now been partially lifted; check the following Technote for the current status:

http://www-01.ibm.com/support/docview.wss?uid=swg21386858

Disaster preparation and recovery Local copies of data do not protect against a local disaster. IBM Tivoli Storage Manager Extended Edition facilitates the tracking of the additional copies of your active data that IBM Tivoli Storage Manager creates for safekeeping at an off-site location. This is known as the Disaster Recovery Manager. IBM Tivoli Storage Manager Extended Edition prepares and keeps up to date a text file, the recovery plan, which contains detailed recovery steps and automated scripts to recover your server. Should a disaster strike and destroy your storage and computers, this plan and the off-site data copies will get your business back up and running quickly.

1.2 Product positioningIBM Tivoli Storage Manager and its complementary products provide a comprehensive solution focused on the key data protection activities of backup, archive, recovery, space management, and disaster recovery planning.

IBM Tivoli Storage Manager helps ensure recoverability through the automated creation, tracking, and vaulting of reliable recovery points.

IBM Tivoli Storage Manager Extended Edition provides the following support:

� Base IBM Tivoli Storage Manager (for basic backup-archive using a tape library with up to four drives and 48 slots)

� Disaster Recovery Manager

� NDMP (for selected network-attached storage devices)

� Large tape libraries (more than four drives or 48 slots)

IBM Tivoli Storage Manager for Storage Area Networks and IBM Tivoli Storage Manager for Space Management can be used with either IBM Tivoli Storage Manager or IBM Tivoli Storage Manager Extended Edition.

Additional Tivoli products working in conjunction with Tivoli Storage Manager are described in “IBM Tivoli Storage Manager for products” on page 13.

Chapter 1. IBM Tivoli Storage Manager overview 5



1.3 Overview of the development timelineIBM Tivoli Storage Manager started life as ADSTAR Distributed Storage Manager (ADSM). Figure 1-2 shows the release time line for the various versions of ADSM, and its subsequent and present name, IBM Tivoli Storage Manager, up to the current version.

Figure 1-2 IBM Tivoli Storage Manager overall product progression

1.3.1 Upgrade path for clients and servers

Generally, the migration plan for a Tivoli Storage Manager update allows clients and servers to be upgraded at different times. This configuration is supported as long as the older version is supported. Although Tivoli Storage Manager is very flexible as to the versions of client code used, and also functions with most of the old and unsupported client code versions according to their functionality, it is best to follow these rules for updating to Version 6.n. See the announcement letters for more specific examples related to particular versions.

1.3.2 Migration guidelines

To help prevent disruption to your backup and archive activities during the migration, follow these guidelines:

� NAS backups performed on a Tivoli Storage Manager Version 6.1 server using the server's BACKUP NODE command can only be restored using the server's RESTORE NODE command or a Tivoli Storage Manager Version 6.1 client.

� A Tivoli Storage Manager Version 5.5 client can perform backup, restore, archive, and retrieve functions to a Tivoli Storage Manager Version 6.1 server.

� A Tivoli Storage Manager Version 6.1 client can perform backup, restore, archive, retrieve, and query functions to a Tivoli Storage Manager Version 5.5 server.

ADSM V1.1ADSM V1.2

1993

ADSM Marketing/Sales moved from

IBM Storage Systems to

IBM Tivoli Software

01/1999

TSM V4.1

07/2000

06/2001

TSM V4.2

04/2002

TSM V5.1

1997

ADSM V3.1

1995

ADSM V2.1

09/1999

Tivoli Storage Manager

V3.7

TSM V5.1.5

TSM V5.2

06/2003

TSM V5.2.2

12/2003

TSM V5.3

12/2004

IBM Tivoli Storage Manager

ADSM

TSM V5.4

01/2007

TSM V5.5

11/2007

10/2002

TSM V6.1

03/2009


� A Tivoli Storage Manager Version 5.5 Space Management client can perform migrate and recall functions to a Tivoli Storage Manager Version 6.1 server.

� A Tivoli Storage Manager Version 6.1 Space Management client can perform migrate and recall functions to a Tivoli Storage Manager Version 5.5 server.

� If you back up or archive data from a Tivoli Storage Manager Version 5.4 or Version 5.5 client to any Tivoli Storage Manager server, you can restore or retrieve that data using a Tivoli Storage Manager Version 6.1 client. This is also true when recalling data that was migrated with the Version 5.4 or Version 5.5 Space Management client.

� If you back up or archive data from a Tivoli Storage Manager Version 6.1 client, you cannot restore or retrieve that data using a Tivoli Storage Manager Version 5.5 or earlier client.

� All administrative clients can administer Tivoli Storage Manager Version 5.5 and Version 6.1 servers.

� The format of the Tivoli Storage Manager passwords stored in the Windows Registry has changed. If you install the Version 5.4.0 or later IBM Tivoli Storage Manager API client or Tivoli Data Protection, which is using the Tivoli Storage Manager API, and you attempt to use the Version 5.3 or earlier IBM Tivoli Storage Manager Backup-Archive client, you will be unable to start the Tivoli Storage Manager Backup-Archive Client Scheduler service or client acceptor daemon service.

� The method for processing system state data changed in Tivoli Storage Manager Version 5.5, such that system state (and system service) backup from prior clients is supported but is no longer recommended. When you use the Tivoli Storage Manager Version 5.5 client, you will generate new system state backups using the new methods. For operations that you cannot perform, check the following Web site.

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.client.doc/c_inst_mig_upg.html

You can find information about upgrading to and from various versions of Tivoli Storage Manager server and client in the appropriate installation guides. Also, you can check the Tivoli Storage Manager Version 6.1 information center for new installation instructions:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.nav.doc/t_installing.html

Upgrade instructions can be found at the following Web site:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.nav.doc/t_upgrading.html

1.4 Overview of new featuresThis section summarizes the various new features and changes to different Tivoli Storage Manager components. Many of these are covered in greater detail in subsequent chapters of this book. We start with highlights for the most recent version, Version 6.1, then present more specific details for both server and client.

1.4.1 Server enhancements, additions, and changes from Version 6.1This section lists the functional enhancements, additions, and changes for the IBM Tivoli Storage Manager Server introduced in Version 6.1.0.


http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.client.doc/c_inst_mig_upg.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.nav.doc/t_installing.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.nav.doc/t_upgrading.html

IBM Tivoli Storage Manager Servers Version 6.1New features and enhancements are available in the Tivoli Storage Manager Version 6.1 server and related products. Here we summarize these features and enhancements in short, high-level descriptions, so that you can start thinking about the potential benefits to your storage-management operations. The changes introduced in Version 6.1.0 onwards are:

� Changes to the Version 6.1 Administration Center:

Many features in the Tivoli Storage Manager Administration Center Version 6.1 are new for previous users.

� Data deduplication:

Data deduplication is a method of eliminating redundant data in sequential-access disk (FILE) primary, copy, and active-data storage pools. One unique instance of the data is retained on storage media, and redundant data is replaced with a pointer to the unique data copy. The goal of deduplication is to reduce the overall amount of time that is required to retrieve data by letting you store more data on disk, rather than on tape.

� Storage devices:

New device support and other changes to storage devices are available in Tivoli Storage Manager Version 6.1.

� Disaster recovery manager support for active-data pools:

To restore your client systems more quickly and efficiently, you can now use active-data pools in your recovery plans and procedures.

� EXPIRE INVENTORY command enhancements:

The EXPIRE INVENTORY command is now enhanced with new functionality.

� No-query restore changes:

The no-query restore (NQR) function and the internal algorithms responsible for NQR were changed to take advantage of DB2 capabilities and to improve performance.

� Server database:

Tivoli Storage Manager version 6.1 provides a new server database. Advantages include automatic statistics collection and database reorganization, full-function SQL queries, and elimination of the need for offline audits of the database.

� Support for NetApp SnapMirror® to Tape feature:

With Tivoli Storage Manager you can create SnapMirror to Tape images of file systems on NetApp file servers.

� ODBC driver support:

Tivoli Storage Manager Version 6.1 uses the DB2 open database connectivity (ODBC) driver to query the database and display the results.

� Reporting and monitoring feature:

The reporting and monitoring feature uses a combination of the Tivoli Common Reporting tool, IBM Tivoli Monitoring, and the IBM Tivoli Data Warehouse to offer you reports and real time monitoring information about Tivoli Storage Manager servers and client activity.

1.4.2 Client enhancements, additions, and changes from Version 6.1This chapter lists all the functional enhancements, additions, and changes for the IBM Tivoli Storage Manager Backup Archive Client introduced as of Version 6.1.


IBM Tivoli Storage Manager Clients Version 6.1Here we list changes introduced with Version 6.1. IBM Tivoli Storage Manager Administration Center.

� Mac OS X-specific information now included in the UNIX and Linux publication:

The Tivoli Storage Manager for UNIX and Linux Backup-Archive Clients Installation and User's Guide includes the Mac OS X-specific information.

� Mac OS X NLS support:

The Tivoli Storage Manager for Mac OS X Backup-Archive Client now supports the NLS languages supported by the Tivoli Storage Manager.

� Mac OS X API support:

The Tivoli Storage Manager API is now supported on Mac OS X.

� Improved memory usage for backup of Hierarchical Storage Management (HSM) managed file systems:

The Tivoli Storage Manager Backup-Archive client can do a full incremental backup of very large HSM managed file systems containing 100,000,000 files or more.

� UTF-8 encoding support is added for Tivoli Storage Manager UNIX and Linux clients:

UTF-8 is added for the language locales that are already supported by the Tivoli Storage Manager Backup-Archive Client.

The Tivoli Storage Manager Version 6.1 client message catalogs and help files are encoded in UTF-8. If you are installing Tivoli Storage Manager client message catalogs for languages other than English, you must also have the appropriate iconv UTF-8 converters installed on your system. If the appropriate iconv UTF-8 converters are not installed, all Tivoli Storage Manager client messages will be displayed in English.

� Availability of 64–bit binaries:

The client packages for Linux on POWER®, Linux zSeries, and one of the AIX clients contain 64-bit binaries.

� NetApp Snapshot™ Difference API (SnapDiff API) support:

When used with the incremental command, the snapdiff option streamlines the incremental process by performing an incremental backup of the files reported as changed by the NetApp Snapshot Difference API, instead of scanning the volume looking for files that have changed.

� Full VM backup and restore support:

The Tivoli Storage Manager backup vm command has been enhanced to provide full VM backup capabilities in addition to the file-level backup capabilities previously provided. You can copy full VM virtual disk exports to the backup proxy from snapshots. The entire virtual machine is backed up as a single item, similar to a Tivoli Storage Manager image backup. The exports are broken into 2 GB file chunks that the Tivoli Storage Manager backup-archive client backs up at a file level.

� Support for restoring Active Directory individual objects:

You can use Active Directory individual object recovery and item-level restore during normal day-to-day operations to recover from accidental corruption or deletion of Active Directory objects by restoring one or more individual Active Directory objects. This feature does not require you to shut down or restart the Active Directory server.


� The Windows Native GUI has been replaced with the Java™ GUI:

The Windows GUI is a Java application. The non-Java Windows Native GUI is installed as dsmmfc.exe in the installation directory. However, it has not been updated with the new Tivoli Storage Manager Version 6.1 features.

� The querysummary option support:

You can use the querysummary processing option to extend the query archive and query backup commands. This support provides a restore preview so that you can determine whether to use the classic or no-query restore method.

� The srvoptsetencryptiondisabled option support:

You can use the srvoptsetencryptiondisabled processing option to ignore encryption options in a client options set from a Tivoli Storage Manager server.

� Enhanced help facilities:

The command-line client help command is enhanced so that you can specify the command, option, or message on which you want help information.

In the graphical user interface, message boxes are enhanced with a button that you can click to see detailed message information.

� New API function dsmUpdateObjEx

The dsmUpdateObjEx function call updates the meta information that is associated with backup or archive objects on the server. This provides the ability to select from several archive objects with the same name.

1.5 Additional functionality overviewThis section summarizes the status and new features and changes for different Tivoli Storage Manager components.

� Tivoli Storage Manager for SAN, additions, and changes� Tivoli Storage Manager HSM for Windows Version 6.1, additions, and changes� Tivoli Storage Manager Space Management, additions, and changes

1.5.1 Tivoli Storage Manager for SAN, additions, and changesIBM Tivoli Storage Manager for Storage Area Networks is a feature of Tivoli Storage Manager that enables LAN-free client data movement.

This feature allows the client system to directly write data to, or read data from, storage devices attached to a storage area network (SAN), instead of passing or receiving the information over the network. Data movement is thereby off-loaded from the LAN and from the Tivoli Storage Manager server, making network bandwidth available for other uses. For instance, using the SAN for client data movement decreases the load on the Tivoli Storage Manager server and allows it to support a greater number of concurrent client connections. The storage agent, a component of the feature, makes LAN-free data movement possible.

See also the relevant user guide for your system. For AIX it is IBM Tivoli Storage Manager for SAN for AIX Storage Agent User's Guide, Version 6.1, SC23-9797.


Enhancements in Version 6.1.0Enhancements in Version 6.1.0 are as follows:

� GPFS™ file system support for file device class:

With Tivoli Storage Manager for Storage Area Networks Version 6.1, you can use the file-device-sharing software IBM General Parallel File System.

� Tivoli SANergy® or IBM TotalStorage SAN File System:

You can also continue to use either Tivoli SANergy® or IBM TotalStorage SAN File System. IBM General Parallel File System is the preferred option for the operating systems on which it is supported.

1.5.2 Tivoli Storage Manager HSM for Windows Version 6.1, additions, and changes

IBM Tivoli Storage Manager HSM for Windows provides space management for Microsoft® Windows NTFS file systems. File migration policies can be defined by an administrator using the HSM for Windows GUI. File migration eligibility is determined by include and exclude policy criteria such as file type (extension) and various criteria related to the age of a file (creation, modification, last access).

HSM for Windows helps free administrators and users from file system pruning tasks. HSM for Windows is designed to assist administrators to more effectively manage Windows NTFS disk storage by automatically migrating files selected based on administrator established policy to less expensive storage devices, while preserving Windows NTFS file accessibility.

See also IBM Tivoli Storage Manager HSM for Windows Administration Guide, Version 6.1, SC23-9795, and Using the Tivoli Storage Manager HSM Client for Windows, REDP-4126.

Enhancements in Version 6.1Enhancements in Version 6.1 are:

� Automatic threshold migration:

Automatic threshold migration helps automatically maintain a certain amount of free space on protected file systems.

� Support for Microsoft Windows Server 2008 (64 bit)

� Support for Internet Protocol V6 (IPv6)

1.5.3 Tivoli Storage Manager for Space Management, additions and changesThe IBM Tivoli Storage Manager for Space Management client for UNIX and Linux (the HSM client) migrates files from your local file system to distributed storage and can then recall the files either automatically or selectively. Migrating files to storage frees space for new data on your local file system and takes advantage of lower-cost storage resources that are available in your network environment.

Tivoli Storage Manager for Space Management is available for AIX JFS2 and GPFS, Linux GPFS, Solaris VxFS, and HP-UX JFS file systems. Also refer to the IBM Tivoli Storage Manager for Space Management for UNIX and Linux User's Guide, Version 6.1, SC23-9794-00.


Enhancements in Version 6.1Enhancements in Version 6.1 are:

� GPFS 3.2 storage pool support:

– Tivoli Storage Manager 6.1 allows multiple General Parallel File System (GPFS) storage pools in one file system. Monitoring a file system includes monitoring each storage pool in the file system.

– The automigration command, dmsautomig, permits automatic migration of storage pools and file systems.

� Hierarchical Storage Management (HSM) for AIX and Linux for GPFS does not require RSCT fileset for cluster support.

A new responsiveness service function is being added. It provides:

– Node response monitoring– Node failure detection and initiate failover actions– Event notification processing

This function replaces the requirement of installing the RSCT Group Services. Do not use RSCT fileset for cluster support.

� Partial file recall enhancements for optimal tape access:

The dsmrecall command will recall partial files with the -OFFset and -SIZE options. With this command, you can specify the portion of a file that is to be recalled.

1.6 Additional information about Tivoli Storage Manager V6.1

For full details, always refer to the announcement letter, and to the installation and user guides for the relevant server. Announcement letters include the following information:

� Detailed product description, including description of new function� Product-positioning statement� Packaging and ordering details� International compatibility information

Announcement letters can be found using keyword Tivoli Storage Manager at:

http://www-01.ibm.com/common/ssi/index.wss

You can see the original Tivoli Storage Manager V6.1 announcement letter at:

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=897&letternum=ENUS209-004

Information about additional Tivoli Storage Manager V6.1 products can be found at:


The Tivoli Storage Manager V6.1 documentation is available at:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp



http://www-01.ibm.com/common/ssi/index.wss?DocURL=http://www-01.ibm.com/common/ssi/rep_ca/6/877/ENUSZP07-0476/index.html&InfoType=AN&InfoSubType=CA&InfoDesc=Announcement+Letters&panelurl=index.wss%3F&paneltext=Announcement%20letter%20search


http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?topic=/com.ibm.itsmc.doc/baclients.html

Chapter 2. IBM Tivoli Storage Manager for products

In this chapter we give you a brief description of the recent changes in the additional IBM Tivoli Storage Manager products:

� Tivoli Storage Manager for Mail (Microsoft Exchange)

� Tivoli Storage Manager for Microsoft SharePoint

� Tivoli Storage Manager for Enterprise Resource Planning (ERP)

� Tivoli Storage Manager for Advanced Copy Services and Tivoli Storage Manager for Copy Services

For further details about the separate products, see the relevant parts of the Tivoli Storage Manager announcement letters as found using the product keywords, for example, Tivoli Storage Manager for Mail, at:


You can also consult the installation and users guides for the different products and platforms at:


2

Note: Be aware that these products have separate license features. Be sure to register these licences to ensure the desired function.



http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?topic=/com.ibm.itsmc.doc/

2.1 IBM Tivoli Storage Manager for MailIBM Tivoli Storage Manager for Mail V6.1 consists of the following component:

� Data Protection for Microsoft Exchange V6.1

2.2 Data Protection for Microsoft Exchange Server

Data Protection for Exchange helps protect and manage Exchange Server data by making it easy to perform the following actions:

� Back up Exchange Server storage groups and transaction logs.

� Maintain multiple versions of Exchange Server storage group and transaction log backups.

� Restore storage group and transaction log backups and replay the transaction log files.

� Automatically inactivate previous backups when performing a full backup.

Data Protection for Exchange performs online backups and restores of Microsoft Exchange Server storage groups.

New featuresData Protection for Exchange 6.1 provides the new mailbox restore feature.

With the Data Protection for Exchange 6.1 mailbox restore feature, you can perform individual mailbox recovery and item-level recovery operations in Microsoft Exchange Server 2003 or Microsoft Exchange Server 2007 environments using Data Protection for Exchange backups.

Mailbox restore applies to backups that are taken with Data Protection for Exchange:

� For Exchange Server 2003 environments, mailbox restore applies to Data Protection for Exchange proprietary backups only. For Exchange Server 2003, mailbox restore operations cannot be performed using VSS backups.

� For Exchange Server 2007 environments, mailbox restore applies to any Data Protection for Exchange proprietary backups or VSS backups.

� Data Protection for Exchange 6.1 (and later) maintains mailbox location history. No mailbox location history is available for backups taken with prior versions. When restoring from these prior version backups, if the mailbox to be restored from has been moved or deleted since the time of the backup, the /mailboxoriglocation parameter is necessary.

Supported environmentsThe hardware and software requirements for IBM Tivoli Storage Manager for Mail Version 6.1 are documented at:

http://www-01.ibm.com/support/docview.wss?&uid=swg21318434

Note: Mailbox restore tracks and stores mailbox location history, which is used to automate mailbox restore operations. This causes a slight delay before each backup.


http://www-01.ibm.com/support/docview.wss?&uid=swg21318434

2.3 IBM Tivoli Storage Manager for Microsoft SharePoint V6.1Customers are increasingly depending on Microsoft SharePoint Portal and Windows SharePoint Services to store, manage and access documents across their enterprise. With this growth of business critical data and content within the SharePoint environment, customers want to manage and protect this data. IBM Tivoli Storage Manager for Microsoft SharePoint allows you to quickly and confidently restore your Microsoft SharePoint business data and content due to a business interruption of almost any kind.

New featuresThe following new features are provided:

� Automatic classification of Microsoft SharePoint content is based on business importance and modification frequency, which allows creation of custom backup plans to help optimize storage space and system resources.

� A new enhanced graphical user interface (GUI) can streamline user interaction for typical tasks and can improve the end-user experience.

� Added support is provided for reusable backup templates to assist in the standardization of common backup settings.

� Item level backup data can be indexed for easier retrieval of data on restore.

� A new fast backup method is available to help leverage SharePoint's change logs.

Supported environmentsThe Tivoli Storage Manager for Microsoft SharePoint supported operating systems and system requirements:

http://www-01.ibm.com/support/docview.wss?rs=667&uid=swg21378227

2.4 IBM Tivoli Storage Manager for ERP

Tivoli Storage Manager for Enterprise Resource Planning V6.1 provides automated data protection, helps reduce the impact of data backups and restores on the SAP database server, and helps reduce the administrator workload necessary to meet data protection and storage management requirements. It seamlessly integrates with the database-specific utilities of IBM DB2 UDB (db2 admin) and Oracle (RMAN), and with the SAP BR*Tools.

Tivoli Storage Manager for Enterprise Resource Planning is specifically optimized to help protect your vital SAP data. An administration assistant helps maximize administrator productivity by helping to simplify administration, configuration, and monitoring of Tivoli Storage Manager for Enterprise Resource Planning in production environments. This powerful solution helps enable administrators to effectively, consistently, and reliably manage backup and recovery of multiple SAP systems with large volumes of data.

The Tivoli Storage Manager for Enterprise Resource Planning software module allows multiple SAP database servers to share a single Tivoli Storage Manager server to automatically manage the backup data. As the intelligent interface to SAP databases, Tivoli Storage Manager for Enterprise Resource Planning V6.1 supports heterogeneous environments with large volume data backups, data recovery, data cloning, and disaster recovery of multiple SAP database servers.

Tivoli Storage Manager for Enterprise Resource Planning V6.1 has enhancements to take advantage of enhancements in Tivoli Storage Manager for Advanced Copy Services V6.1.

Chapter 2. IBM Tivoli Storage Manager for products 15


The supported versions of Oracle or DB2 are as supported by SAP, with some restrictions depending on operating system and version. Always consult the announcement letter or the actual installation and user guide for each product for additional details.

New featuresHere we describe the new functions and improvements in IBM Tivoli Storage Manager for ERP V6.1. Note that SAP AG has discontinued the use of the term mySAP in favor of SAP.

The following new functionality has been added to Version 6.1 of Data Protection for SAPOracle or DB2:

� Executable files on Windows platforms (except Java applets) now bear a digital signature.

� Install Anywhere has replaced Install Shield as the installation vehicle.

� As of version 7.1, the SAP BR*Tools components have a facility for invoking snapshot (in SAP terminology, volume) backups and restores. Such requests received by Tivoli Storage Manager for ERP are redirected to the Tivoli Storage Manager for Advanced Copy Services (ACS) product (if it is installed). To facilitate the interaction of Tivoli Storage Manager for ACS with Tivoli Storage Manager for ERP when the user wants to perform a Tivoli Storage Manager backup of the snapshots produced, certain parameters have been added to the Tivoli Storage Manager for ERP profile for use by Tivoli Storage Manager for ACS. For more information, refer to the Tivoli Storage Manager for ACS documentation.

� AIX 6.1 is now supported.

Other changes are that:

� Support for 32–bit platforms has been discontinued.

Supported environmentsThe list of IBM Tivoli Storage Manager for Enterprise Resource Planning V6.1.0 requirements is documented at:


2.5 IBM Tivoli Storage Manager for Advanced Copy Services V6.1 and IBM Tivoli Storage Manager for Copy Services V6.1

Tivoli Storage Manager for Copy Services and Tivoli Storage Manager for Advanced Copy Services can help protect your mission-critical data that requires 24 x 7 availability. They offer ready-to-use, application consistent, product-based solutions designed to implement high-efficiency backup and restore processes for business-critical applications, and help to eliminate backup-related performance impact on the production host.

By integrating hardware and software-based snapshot capabilities with IBM Tivoli Storage Manager and its data protection components for Microsoft Exchange, Microsoft SQL, IBM DB2 UDB, Oracle, and SAP, you can help manage your snapshot backup operations and leverage the performance, scheduling, and media management functions of Tivoli Storage Manager to help ensure that your application servers are operational 24 hours a day.

Tivoli Storage Manager for Copy Services provides the integration with Microsoft Volume Shadow Copy Service (VSS) and VSS providers for snapshots. Tivoli Storage Manager for Advanced Copy Services provides the integration with IBM FlashCopy® as supported by IBM System Storage™ SAN Volume Controller (SVC), IBM System Storage DS6000™, IBM System Storage DS8000®, and other snapshot mechanisms.



In today's business world, application servers often are operational 24 hours a day. The data on the application servers should be well protected. With the rapid increase in the amount of data on these servers, their critical business needs, and the shrinking backup windows, traditional backup and restore methods might be reaching their limits in meeting your challenging requirements. Snapshot operations can help minimize the impact caused by backups. Because a snapshot operation typically takes much less time than the time for a tape backup, the window during which the application must be aware of a backup can be reduced. The snapshots can be retained as backups on local disk, sent to Tivoli Storage Manager server storage pools, or both.

New features in Tivoli Storage Manager Advanced Copy ServicesThe following new features are provided:

� Enhanced Oracle application snapshot support when used in conjunction with the IBM System Storage SAN Volume Controller (SVC), IBM System Storage DS6000, IBM System Storage DS8000, IBM XIV® Storage System, IBM N series NAS, and NetApp NAS. Enhancements include:

– Support for multiple snapshot versions– Support for FlashCopy of a single mirror set in LVM mirrored environments– Support for IBM XIV Storage System snapshots

� Support for FlashCopy restore onto a Peer-to-Peer Remote Copy (PPRC) source volume. PPRC is a continuous disk-based mirroring function typically used for environments requiring high availability disaster recovery.

� Enhanced snapshot support for SAP environments. Through integration with the Backint interface, integration of Tivoli Storage Manager Advanced Copy Services snapshot functionality into conventional backup procedures in SAP is simplified.

� Enhanced backup performance by incremental FlashCopy support for the IBM SAN Volume Controller. Tivoli Storage Manager for Advanced Copy Services now exploits incremental FlashCopy. This can eliminate the need to perform a full background copy of the source data for each FlashCopy image that is created. After the initial FlashCopy image is created, only the changed blocks will be copied to the same set of target volumes, improving backup performance.

New features in Tivoli Storage Manager for Copy ServicesThe following new features are provided:

� Updates to take advantage of the enhancements in Tivoli Storage Manager for Mail V6.1.

� The hardware integration module, previously shipped with Tivoli Storage Manager, has been removed. It is now included with the Tivoli Storage Manager Backup-Archive client.

Supported environmentsThe IBM Tivoli Storage Manager for Advanced Copy Services V6.1 requirements are documented at:


The hardware and software requirements for IBM Tivoli Storage Manager for Copy Services V6.1 are documented at:


Chapter 2. IBM Tivoli Storage Manager for products 17



Part 2 Tivoli Storage Manager enhancements since V5.4 and V5.5

This part of the book covers the enhancements and integrated fixes since the previous version of this book was published.

Part 2


Chapter 3. Tivoli Storage Manager enhancements provided since V5.5 availability

In this chapter we discuss the enhancements in Tivoli Storage Manager since the previous version of this book was published. While the enhancements are included in V6.1, they are described here for completeness and include the following features:

� SAN Device Mapping for Virtual Tape Libraries� RELABELSCRATCH parameter for Virtual Tape Libraries� SnapLock® volume reclaim� HP-UX Passthru driver support

3


3.1 SAN Device Mapping for Virtual Tape Library

In a SAN environment, device IDs can change dynamically (for example, device or cabling changes). Tivoli Storage Manager uses a method that dynamically discovers and maps devices in the environment, even when the paths change. Tivoli Storage Manager V5.5 is enhanced to allow for the mapping and discovery of Virtual Tape Library (VTL) devices in the SAN:

� SAN Device Mapping is done by checking the Serial Number, not by WWN.

� Some VTLs present the same WWN for all virtual drives. In prior versions, if VTL presented the same WWN for all drives:

– When a change was detected in the Serial Number,Tivoli Storage Manager first checked for persistent WWN support in the library.

– It assumed that this was a drive swap with persistent WWNs, and thus changed the drive Serial Number and not the device address.

� In Version 5.5, if VTL presents same WWN for all drives

– When a change is detected in Serial Number, Tivoli Storage Manager will first continue to search for the matching S/N before checking for persistent WWNs.

– If a match is found, it will update the device address for the drive with that Serial Number.

In Example 3-1, you can see the relationship between the WWN and the Serial Number of the VTL to the SAN discovery on the Tivoli Storage Manager Server.

Example 3-1 WWN and Serial Number of the SAN Adapters and virtual drives on a VTL

1. Port:- Name: 0a Role: Frontend Port WWNN: 500a09800000de30 Port WWPN: 510a09820000de30 Topology: Link Down Port ID: 0x0 Loop ID: 0x0 2. Port:- Name: 0b Role: Backend Port WWNN: 500a09800000de30 Port WWPN: 510a09830000de30 Topology: Private Loop Port ID: 0xef Loop ID: 0x0..lines deleted..21. Virtual Drive:- Virtual Library: testpc_vtl Virtual Drive: Drive0 Serial Number: 77e846640f01a098045df0 Vendor ID: IBM Product ID: ULTRIUM-TD4 Barcode:22. Virtual Drive:-


Virtual Library: testpc_vtl Virtual Drive: Drive1 Serial Number: 77e85f960f01a098045df0 Vendor ID: IBM Product ID: ULTRIUM-TD4 Barcode:..lines deleted ..

Example 3-2 shows how the SAN devices are mapped in Tivoli Storage Manager, which we can query with the query san f=d command.

Example 3-2 Tivoli Storage Manager-command query san f=d

q san f=d Device Type: LIBRARY Vendor: NETAPP Product: VTLSerial Number: 77e696d40f01a098045df0 Device: lb0.0.0.3 Data Mover: No Node WWN: 500A09800000DE30 Port WWN: 510A09820000DE30 LUN: 0 SCSI Port: 3 SCSI Bus: 0 SCSI Target: 0 Device Type: DRIVE Vendor: IBM Product: ULTRIUM-TD4Serial Number: 77e846640f01a098045df0Device: Tape0 Data Mover: No Node WWN: 500A09800000DE30 Port WWN: 510A09820000DE30 LUN: 1 SCSI Port: 3 SCSI Bus: 0 SCSI Target: 0 Device Type: DRIVE Vendor: IBM Product: ULTRIUM-TD4Serial Number: 77e85f960f01a098045df0 Device: Tape1 Data Mover: No Node WWN: 500A09800000DE30 Port WWN: 510A09820000DE30 LUN: 2 SCSI Port: 3 SCSI Bus: 0 SCSI Target: 0 Device Type: DRIVE Vendor: IBM Product: ULTRIUM-TD4Serial Number: 77e86ec80f01a098045df0

Chapter 3. Tivoli Storage Manager enhancements provided since V5.5 availability 23

Device: Tape2 Data Mover: No Node WWN: 500A09800000DE30 Port WWN: 510A09820000DE30 LUN: 3 SCSI Port: 3 SCSI Bus: 0 SCSI Target: 0..lines deleted..

Use this information to check the SAN devices and map them to the corresponding element address. With this new functionality, it is also possible for virtual tape libraries to discover automatically the correct device address and update the path definitions.

3.2 RELABELSCRATCH parameter for Virtual Tape Libraries

The RELABELSCRATCH parameter allows you to automatically relabel volumes when they are returned to scratch. Support for this parameter is available in Fix Pack 5.5.1 and later levels.

Virtual Tape Libraries (VTLs) maintain volume space allocation after Tivoli Storage Manager has deleted a volume and returned it to a scratch state. The VTL has no knowledge that the volume was deleted and it keeps the full size of the volume allocate. This can be extremely large depending on the devices being emulated. As a result of multiple volumes that return to scratch, the VTL can maintain their allocation size and run out of storage space.

The only way for the VTL to realize that a volume has been deleted and its space can be reallocated is to write to the beginning of the newly returned scratch volume. The VTL will then see the volume as available. Tivoli Storage Manager can relabel volumes that have just been returned to scratch if the RELABELSCRATCH parameter is specified.

This optional parameter has been added to the DEFINE and UPDATE LIBRARY commands and is intended for use with VTLs. It specifies whether the server relabels volumes that have been deleted and returned to scratch. The syntax is:

RELABELSCRatch Yes I No

When this parameter is set to Yes, a LABEL LIBVOLUME operation is started and the existing volume label is overwritten.

Note: If you have both virtual and real volumes in your VTL, both types will be relabeled when this parameter is enabled. If the VTL includes real volumes, specifying this option could impact performance. This function is only available for SCSI Libraries.


Example 3-3 shows how virtual tapes will be relabeled when their status is changed to SCRATCH.

Example 3-3 RELABEL scratch example

ANR8468I LTO volume TSM0006 dismounted from drive TAPE_DEVICE_2 (mt0.3.0.3) in library TESTPC_VTL.ANR1141I Move data process ended for volume TSM0006.ANR0515I Process 4 closed volume TSM0008.ANR0515I Process 4 closed volume TSM0079.ANR0986I Process 4 for MOVE DATA running in the BACKGROUND processed 155287 items for a total of 50,948,409,476 bytes with a completion state of SUCCESS at 05:18:12.ANR0984I Process 5 for RELABEL started in the BACKGROUND at 05:18:17.ANR8799I RELABEL: Operation for library TESTPC_VTL started as process 5.ANR1341I Scratch volume TSM0006 has been deleted from storage pool BACKUP_VTL.ANR8810I Volume TSM0006 has been labeled in library TESTPC_VTL.ANR8801I LABEL LIBVOLUME process 5 for library TESTPC_VTL completed; 1 volume(s) labeled, 1 volume(s) checked-in.ANR0985I Process 5 for RELABEL running in the BACKGROUND completed with completion state SUCCESS at 05:18:19.

To determine if the RELABELSCRATCH parameter is set to Yes, you can issue the QUERY LIBRARY command, as shown in Example 3-4.

Example 3-4 QUERY LIBRARY command example

q libr f=d Library Name: TESTPC_VTL Library Type: SCSI ACS Id: Private Category: Scratch Category: WORM Scratch Category: External Manager: RSM Media Type: Shared: Yes LanFree: ObeyMountRetention: Primary Library Manager: WWN: Serial Number: 77e696d40f01a098045df0 AutoLabel: Yes Reset Drives: Yes Relabel Scratch: YesLast Update by (administrator): ADMIN Last Update Date/Time: 06/17/2009 07:45:36


3.3 RECLAIMDELAY and RECLAIMPERIOD server options

Two server options, which allow you to set the reclaim delay time and reclaim period time for SnapLock volumes are available.

RECLAIMDELAYThis option delays the reclamation of a SnapLock volume, allowing remaining data to expire, so that there is no need to reclaim the volume.

Specifies the number of days to delay the reclamation of a SnapLock volume. Before reclamation of a SnapLock volume begins, the Tivoli Storage Manager server allows the specified number of days to pass, so that any files remaining on the volume have a chance to expire. The default reclaim delay period is four days and can be set anywhere from 1 to 120 days. In Example 3-5 we specify that the number of days to delay reclamation is 30 days.

Example 3-5 SETOPT RECLAIMDELAY option

setopt reclaimdelay 30

ANR2119I The RECLAIMDELAY option has been changed in the options file. dsmserv.opt:

NDMPPREFDATAINTERFACE 192.168.111.81 SANDISCOVERY ON RECLAIMDELAY 30

RECLAIMPERIODThis option allows you to set the number of days for the reclamation period of a SnapLock volume.

It specifies the number of days allowed for the reclamation period of a SnapLock volume. After the retention of a SnapLock volume has expired, the Tivoli Storage Manager server will reclaim the volume within the specified number of days if there is still data remaining on the volume. The default reclaim period is 30 days and can be set anywhere from 7 to 365 days.

In Example 3-6 we specify 30 days as the reclamation period for our SnapLock volume:

Example 3-6

setopt reclaimperiod 30ANR2119I The RECLAIMPERIOD option has been changed in the options file.

dsmserv.opt:

NDMPPREFDATAINTERFACE 192.168.111.81 SANDISCOVERY ON RECLAIMDELAY 30 RECLAIMPERIOD 30

Note: The reclamation period does not begin until the RECLAIMDELAY period has expired.


3.4 Tivoli Storage Manager HP-UX passthru driver support

The Tivoli Storage Manager passthru device driver is supported on 64 bit HP-UX 11i v1, v2, and v3. This passthru driver replaces Tivoli Storage Manager's kernel device drivers (tsmscsi) and is packaged as part of Tivoli Storage Manager server Version 5.4.3.0, Version 5.5.1.0 and later.

The following changes have been implemented to the Tivoli Storage Manager server for HP-UX passthru device driver support:

� The Tivoli Storage Manager device driver package no longer includes the ddtrace utility, Tivoli Storage Manager kernel modules mod.o for HP 11i v1 or tsmtape, tsmchgr, tsmoptc for HP 11i v2. Two new device configuration tools, autoconf and tsmdlst, are included in the device driver package and are installed to the /opt/tivoli/tsm/devices/bin directory unless you specify another location.

� The Tivoli Storage Manager passthru device driver is packaged with the Tivoli Storage Manager server and storage agent packages.

� The sctl driver must be loaded into the kernel before devices are configured for the Tivoli Storage Manager passthru device driver. Issue the following command to verify that the sctl driver is installed.

>lsdev | grep sctl

If the driver has been loaded, you will see output similar to this:

lsdev | grep sctl203 -1 sctl ctl

� The HP-UX stape, sdisk, and schgr native drivers are required for device configuration for the Tivoli Storage Manager passthru device driver. To verify that these drivers are loaded in the kernel, issue the following commands from any directory. You should see output similar to what is listed with each command:

– stape:

>lsdev | grep stapelsdev | grep stape

205 -1 stape tape

– sdisk:

>lsdev | grep sdisklsdev | grep sdisk

188 31 sdisk disk

– schgr:

>lsdev | grep schgrlsdev | grep schgr

231 29 schgr autoch

Configuring devices for the Tivoli Storage Manager passthru device driver

Follow these steps to configure the devices:

1. Make sure that the Tivoli Storage Manager server is not running.

2. Delete the Tivoli Storage Manager device names that have previously been created by issuing the following command:

>rm /dev/rmt/tsm*


3. Run the ioscan command to make sure that all attached tape drives, auto-changers and optical disk devices have hardware paths associated with corresponding HBAs on the system.

4. Run the autoconf utility to configure devices for the Tivoli Storage Manager passthru device driver:

/opt/tivoli/tsm/devices/bin/autoconf

The autoconf utility uses the tsmddcfg script to configure devices and calls the tsmdlst utility to display all devices that have been configured by the passthru device driver. The device information is saved in lbinfo, mtinfo, and optinfo in the devices bin directory.

To prevent potential data integrity problems, verify that Tivoli Storage Manager devices can only be accessed through Tivoli Storage Manager passthru special files. If a device is controlled by the passthru driver and also one of the stape, schger, or sdisk drivers, you need to delete the corresponding device special files that are created by those drivers.

If there are no changes to the device hardware path on the system during the migration from the Tivoli Storage Manager kernel device driver to the passthru device driver, Tivoli Storage Manager device names should remain the same.

Note: You can also run autoconf with the -f option. Autoconf will issue ioscan to scan the system before configuring devices. This might take several minutes.


Part 3 Tivoli Storage Manager V6.1 Server enhancements

This part of the book covers the server enhancements provided in Tivoli Storage Manager V6.1.

Part 3


Chapter 4. Commands, utilities, and option changes

With the transition to DB2, new commands, utilities, and server options were introduced. Others either were updated or became obsolete and have been deleted. In this chapter we list new, changed, and deleted commands, utilities, and options. If they are discussed in the book, you will find references to the related section.

New commands, utilities, and options are available for the V6.1 server because of changes in database operations and new functions.

4


4.1 New server commands, utilities, and options

Table 4-1 describes the new server commands in Tivoli Storage Manager V6.1.

Table 4-1 New server commands

Table 4-2 lists the new server utilities in Tivoli Storage Manager V6.1.

Table 4-2 New server utilities

Command Function Comparable commands in previous versions

EXTEND DBSPACEsee Chapter 5.4.3, “Increase database space” on page 111.

Makes additional storage space available for the server to use for its database.

You can have multiple locations for the database storage space. After installation and initial use of DSMSERV FORMAT or DSMSERV LOADFORMAT, you can add more locations for the storage space for the database.

DEFINE DBVOLUMEfollowed by EXTEND DB

IDENTIFY DUPLICATES Starts or stops processes that identify duplicate data in a storage pool.

None

QUERY DBSPACEsee “Monitoring the database space” on page 54.

Displays the current locations for the database storage, along with total space, and used space.

QUERY DBVOLUME

SET DBRECOVERYsee “Configuring for manual database backups” on page 87.

Sets the device class to use for backup of the server's database.See Example 5-18 on page 87.

DEFINE DBBACKUPTRIGGER

SET DBREPORTMODEsee “DBREPORTMODE option” on page 114

Sets the amount of diagnostic information that is reported for the database.

None

SET DRMACTIVEDATASTGPOOL

Sets the active-data pools that are included in your recovery plans and procedures.

None

Utility Function Comparable commands in previous versions

DSMSERV DISPLAY DBSPACEsee Example 5-38 on page 105

Offline utility to view the current locations for database storage.

DSMSERV DISPLAY DBVOLUMES

DSMSERV DISPLAY LOGsee Example 5-40 on page 107

Offline utility to view information about the recovery logs (active log and archive logs).

DSMSERV DISPLAY LOGVOLUMES


DSMSERV INSERTDB Offline utility used only for inserting data that has been extracted from a V5 server database into an empty V6.1 database.

None

DSMSERV REMOVEDBFor an example see 6.3.3, “DR site recovery scenario” on page 129.

Use this command to remove a Tivoli Storage Manager server database. This command deletes all user data and log files, as well as any backup and restore history for the database. If the log files are needed for a roll-forward recovery after a restore operation, these files should be saved before you issue this command.

DSMUPGRD PREPAREDB Offline utility used only on a V5 server to prepare the database for extraction. After this utility is run, the data can be extracted from the database using the DSMUPGRD EXTRACTDB utility. This is one of the upgrade utilities.

DSMUPGRD EXTRACTDB Offline utility used only on a V5 server to extract the data from the database. The extracted data is inserted into a V6.1 database using the DSMSERV INSERTDB utility. This is one of the upgrade utilities.

DSMUPGRD EXTEND DB Offline utility used only on a V5 server to extend the database when database space is insufficient to successfully complete the upgrade process. This is one of the upgrade utilities.

DSMUPGRD EXTEND LOG Offline utility used only on a V5 server to extend the recovery log when recovery log space is insufficient to successfully complete the upgrade process. This is one of the upgrade utilities.

DSMUPGRD QUERYDB Offline utility used only on a V5 server to display information about the database and recovery log. This is one of the upgrade utilities.

Utility Function Comparable commands in previous versions

Chapter 4. Commands, utilities, and option changes 33

Figure 4-3 shows the new server options in Tivoli Storage Manager V6.1.

Table 4-3 New server options

Option Function Comparable commands or options in previous versions

ACTIVELOGDIRFor an example see 6.3.3, “DR site recovery scenario” on page 129.

The new directory for the location where the active log is stored. Use this option to change the location of the active log.

The location is originally specified during installation. There is only one location for the active log.

DEFINE LOGVOLUME

ACTIVELOGSIZEsee “LOG configuration” on page 55.

The maximum size of the active log.

EXTEND LOGREDUCE LOG

ARCHFAILOVERLOGDIRFor an example, see 6.3.3, “DR site recovery scenario” on page 129.

The directory in which the server stores archive log files if they cannot be stored in the archive log location.

None

ARCHLOGDIRFor an example, see 6.3.3, “DR site recovery scenario” on page 129.

The directory in which the server stores the archive log.

DBMEMPERCENTsee “Memory management” on page 46.

Sets a limit on the percentage of the system memory that is used for the database.

DEDUPREQUIRESBACKUP Control for backup operations for primary sequential-access storage pools that are set up for deduplication.

DISKSTGPOOLMEMSIZE The size of the cache that the server can use to manage operations for storage pools with the device type of DISK.

MIRRORLOGDIRFor an example, see “DR site recovery scenario” on page 129.

The directory where the log mirror for the active log is stored.

DEFINE LOGCOPY


4.2 Updated server commands, utilities, and options

Commands, utilities, and options are updated for Tivoli Storage Manager V6.1 because of changes in database operations and other new functions. Table 4-4 shows updated server commands.

Table 4-4 Updated server commands

Command Changes

BACKUP DBFor an example, see 6.3.3, “DR site recovery scenario” on page 129.

The SET DBRECOVERY command must be run first to set a device class for database backups.

An incremental database backup is now a backup of all changes since the last full backup. In earlier versions of the server, an incremental backup was a backup of all changes since either the last full backup or the last incremental backup.

BACKUP/RESTORE NODEQUERY NASBACKUP

The commands support creating SnapMirror to Tape images of file systems on NetApp file servers.

BACKUP/DELETE/QUERY/ UPDATE VOLHISTORYsee Chapter , “Restore prerequisites” on page 103.

Database dump operations are no longer available, therefore database dump volumes do not appear in the volume history. Query output is changed.

DEFINE/UPDATE DEVCLASS Device formats have been added for some operating systems.

DEFINE/DELETE/QUERY/UPDATE SPACETRIGGER

The space trigger commands now support space triggers only for storage pools. The database and log space triggers are no longer available.See “Triggered automatic backups” on page 98.

DEFINE/QUERY/UPDATE STGPOOL

The storage pool commands support the data deduplication functions.

DEFINE VOLUME The maximum capacity of a volume in a DISK storage pool is 8 TB.

EXPIRE INVENTORYsee Chapter 9, “Expiration enhancements” on page 161.

Expiration can be run for specific nodes and node groups, or for all nodes in a policy domain. The types of data to be examined for expiration can also be specified.

GRANT/REVOKE AUTHORITY

ANALYST privilege class is removed.

HALT The QUIESCE parameter is no longer needed.

MOVE/QUERY DRMEDIA Changes to disaster recovery manager commands allow you to include active-data pools in your recovery plans and procedures.

PREPAREFor an example, see 6.3.3, “DR site recovery scenario” on page 129.

QUERY DRMSTATUS

QUERY DBSee “Configuring for manual database backups” on page 87.

Output is changed.

QUERY LOGSee Example 5-33 on page 99.

QUERY OPTION Obsolete options are removed from the output.


Table 4-5 shows the updated server utilities.

Table 4-5 Updated server utilities

QUERY PROCESS Information about duplicate identification processes is available through this command.

QUERY SESSION A new field in the output indicates the actions that occurred during the session.

QUERY STATUS Output is changed. Obsolete options are removed, and the database backup trigger is removed.

SELECTsee “Changes to the SELECT command” on page 612.

Some parameters that were previously allowed might cause errors. SQL parameter usage must now conform to usage that is acceptable to the database manager.

SETOPT Obsolete options are removed.

UPDATE ADMIN ANALYST privilege class is removed.

Utility Changes

DSMSERV (starting the server) New options are available for specifying the owning user ID for the server instance on startup. The new options are also available for other DSMSERV utilities.

DSMSERV FORMATsee “Database configuration” on page 53 and “LOG configuration” on page 55.

Obsolete parameters are removed. New parameters are added to specify the directories for database space, and the maximum size and locations of the recovery log.

This utility is used to format a database for installation of a new server.

DSMSERV LOADFORMATsee “Database configuration” on page 53 and Chapter , “LOG configuration” on page 55

This utility is used only for formatting a new, completely empty database. An empty database is used only as part of the process of upgrading an earlier version of the server to V6.1. After you format an empty database, you use the DSMSERV INSERTDB utility to insert data that was extracted from the database of an earlier version of the server.

DSMSERV RESTORE DB� Restore a database to its

most current statesee Example 5-45 on page 109.

� Restore a database to a point in time

Volume history is now required for restoring the database.

All restore operations use roll-forward recovery.

The function for restoring individual database volumes was removed. The server no longer manages database volumes.

Command Changes


Table 4-6 shows the updated server options in Tivoli Storage Manager V6.1.

Table 4-6 Updated server options

For a detailed discussion of the new TXNGROUPMAX default, refer to Chapter 10, “Changes to the TXNGROUPMAX default” on page 177.

4.3 Deleted server commands, utilities, and options

Some commands, utilities, and options are deleted because their function is no longer needed. In some cases, new commands replace deleted commands. Table 4-7 shows deleted server commands in Tivoli Storage Manager V6.1.

Table 4-7 Deleted server commands

Option Changes

TXNGROUPMAX The default value is increased from 256 to 4096. Check whether the server options file has this option:

� If the server options file does not include this option, the server automatically uses the new default value.

� If the server options file includes a value for the option, the server uses that specified value. If the specified value is less than 4096, consider increasing this value, or removing the option so that the server uses the new default value. Increasing the value or using the new default value can improve the performance for data movement operations such as storage pool migration and storage pool backup.

Increasing the value for the TXNGROUPMAX option has no effect on data-movement performance for files that were stored on the server using a lower value for the option.

Command Changes

CONVERT ARCHIVE The operation that this command performed is no longer needed.

DEFINE/DELETE/QUERY/UPDATE DBBACKUPTRIGGER

Ensure that you schedule backups of the database to occur at least once per day.

DEFINE DBCOPY Database volumes are no longer used.

DEFINE/DELETE/QUERY DBVOLUME

Space allocation is done automatically in the directory locations specified for the database.

DEFINE LOGCOPY Instead of log volume copies, you can specify a log mirror to have the active log protected by a mirror copy.

DEFINE/DELETE/QUERY LOGVOLUME

The database manager automatically manages space in the recovery log directories.

For information about the directories that are used for the logs, use the QUERY LOG command.

ESTIMATE DBREORGSTATS Collecting and resetting database statistics occurs automatically.

Database-reorganization operations are done automatically by the database manager as needed.


Table 4-8 shows deleted server utilities in Tivoli Storage Manager V6.1.

Table 4-8 Deleted server utilities

EXTEND DB Space allocation is done automatically in the directory locations specified for the database. If the server needs additional space, you can add directory locations by using the EXTEND DBSPACE command.

EXTEND LOGsee “LOG configuration” on page 55

Server options are available for increasing the size of recovery logs.

QUERY SQLSESSION The information that this command supplied is no longer in the server database. SQL SELECT settings are replaced by syntax options that are available in a DB2 SELECT command.

REDUCE DB Space allocation is done automatically in the directory locations specified for the database. You cannot adjust the assigned capacity of the database.

REDUCE LOG The database manager automatically manages space in the recovery log directories.

RESET BUFPOOL The BUFPOOLSIZE option has been eliminated, therefore this command is not needed.

RESET DBMAXUTILIZATION Collecting and resetting database statistics occurs automatically.

RESET LOGCONSUMPTION

RESET LOGMAXUTILIZATION

SET LOGMODE Logging mode for the database is now always roll-forward mode.

SET SQLDATETIMEFORMAT The commands are replaced by options in the DB2 SELECT command syntax.

SET SQLDISPLAYMODE

SET SQLMATHMODE

UNDO ARCHCONVERSION The operation that this commands performed are no longer needed.

UPDATE ARCHIVE

Command Changes

DSMFMT Space allocation is done automatically in the directory locations specified for the database.

DSMSERV AUDITDB Offline database audits are no longer required.

As data is added to the server database, the database manager automatically checks data constraints and data types. The online integrity checks prevent problems for which offline audits had been needed in earlier releases.

DSMSERV DISPLAY DBBACKUPVOLUME

Information about volumes used for database backup is available from the volume history file. The volume history file is now required to restore the database.

Command Changes


Table 4-9 shows deleted server options in Tivoli Storage Manager V6.1.

Table 4-9 Deleted server options

New and changed server messagesIf you have scripts or other automation that use server messages, check the lists of new, changed, and deleted messages for items that you might need to change.

The list is available in the Information Center located at the following Web site:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6

The list is also available in the Tivoli Storage Manager Messages publication for V6.1.

DSMSERV DISPLAY DBVOLUMES

Use DSMSERV DISPLAY DBSPACE to view information about database space when the server is not running.

DSMSERV DISPLAY LOGVOLUMES

Use DSMSERV DISPLAY LOG to display information about recovery logs including the active log, the mirror for the active log, the failover directory for the archive log, and the overflow location for logs.

DSMSERV DUMPDB The operation that this utility performed is no longer needed.

DSMSERV EXTEND LOG This utility is replaced by the following server options:� ACTIVELOGSIZE� ACTIVELOGDIR� MIRRORLOGDIR

With these options, you can add recovery log space if the log is full when the server is down.

DSMSERV LOADDB The operation that this utility performed is no longer needed.

DSMSERV RESTORE DB� Restore a single database

volume to its most current state

� Restore a database to a point in time when a volume history file is unavailable

The server does not track individual database volumes in V6.1.

The volume history file is required to perform database restore operations.

DSMSERV UNLOADDB The operation that this utility performed is no longer needed.

Command Changes

BUFPOOLSIZE The server adjusts the value of buffer pool size dynamically.

DBPAGESHADOW The options are no longer needed.

DBPAGESHADOWFILE

LOGPOOLSIZE The server uses its own fixed-size recovery log buffer pool.

LOGWARNFULLPERCENT The option is no longer needed.

MIRRORREAD Mirroring of the active log is supported, but not of the database. Provide availability protection for the database by locating the database on devices that have high availability characteristics.MIRRORWRITE

SELFTUNEBUFPOOLSIZE The server adjusts the buffer pool size dynamically.

Command Changes



Chapter 5. IBM Tivoli Storage Manager database

Functionality and scalability are the key themes of the new Tivoli Storage Manager V6.1 announcement. For additional scalability, Tivoli Storage Manager's internal, proprietary database has been ported to IBM DB2.

In this chapter we provide a brief history of the proprietary database that comes with previous versions of IBM Tivoli Storage Manager server and introduces the new DB2 database used with Tivoli Storage Manager V6.1. We explain how to estimate the space requirements for the database and log, and we guide you through a complete backup and restore cycle for your database.

We give you a list of helpful DB2 commands and system utilities, and you learn how to configure the DB2 and the DB2 Control Center, a graphical administration tool, to connect to a Tivoli Storage Manager database.

At the end of the chapter, we introduce some tips to collect diagnostic information, in case this is required.

5


5.1 BackgroundThis section describes the Tivoli Storage Manager proprietary database, the limitations of that database, and the expectations of the advantages coming with the port to a DB2 database.

Tivoli Storage Manager proprietary databaseThe Tivoli Storage Manager database that comes with pre-6.1 servers uses a proprietary B+ Tree database that originated from IBM Almaden Research. This database utilizes state of the art ARIES/NT1 technology for the recovery log.

This proprietary database was chosen for two primary reasons at the time:

� The Tivoli Storage Manager proprietary database was portable across platforms.

The V1R1 of ADSM shipped for the MVS and VM platforms. In subsequent releases, this platform coverage expanded to OS/2, AIX, HP, SUN, Windows, and so on. This expanded platform coverage was possible because the proprietary DB package was imbedded in the product and the architecture was to be platform independent. At the time Tivoli Storage Manager was first being delivered, DB2 was not available on all of the platforms where Tivoli Storage Manager was expected to run, or on platforms that Tivoli Storage Manager was expected to be ported.

� The Tivoli Storage Manager proprietary database was chosen for performance.

The Tivoli Storage Manager proprietary database does not have locking or other common database serialization constructs built into it. It was optimized more for performance than what typical database products provided at the time.

The database has surpassed every expectation in terms of scalability and performance, supporting up to 530 GB databases. Over time, however, Tivoli Storage Manager development had to develop and maintain code that essentially keeps alternative indices for every table and can audit and correct referential integrity problems between tables. The database does not support secondary indexes, and a lot of code had to be written to implement and maintain alternate index information to speed searches. In addition, Tivoli Storage Manager development has written and maintained its own SQL engine for query processing and to load the data warehouse from the server database.

Here are some significant characteristics of the Tivoli Storage Manager proprietary database:

� Locking is done at an "advisory" level within the application itself.

The database does not implement locking at a record level and such, there are latch semantics at a page level that latch a page in “exclusive” mode when a given record on the page is being inserted, updated, or deleted.

� The database package does not provide or maintain indexes for tables.

The Tivoli Storage Manager application maintains the tables and any apparent index or alternate table view that is currently needed or supported by implementing these as separate tables. For example, if a given object on the server is represented by a record entry in tables A, B, and C, it is the application’s responsibility to insert all three of these records when the object is created, the application must make any necessary updates across these records if an object is updated, and it must delete all three of these records if a given object is deleted.

1 ARIES/NT: A Recovery Method Based on Write-Ahead Logging for Nested Transactions was described by IBM fellow C. Mohan and K. Rothermel. You can find the original paper at http://www.vldb.org/conf/1989/P337.PDF


http://www.vldb.org/conf/1989/P337.PDF

� Referential integrity checking is done by the application.

For Tivoli Storage Manager, this means that the application code has to manage and enforce any referential dependencies between rows in tables and such. Along these lines, the AUDITDB facility within Tivoli Storage Manager was implemented to evaluate and enforce many of the referential constraints that exist with Tivoli Storage Manager. Because referential integrity checking is done at the application levels, it allows for inconsistencies in how the checking is done. It also provides the opportunity to introduce errors in the database because of misunderstanding the relationships that exist.

� The upper limit of the database size is at 530 GB.

The database uses internal control structures to manage the available size of the database. Today customers are reaching the upper bound limit with their production databases. Similarly, the disaster recovery products (DR450) and other content manager type offerings have brought forward concerns over the maximum number of objects that could be stored in the server database.

As Tivoli Storage Manager has evolved over the years, enhancements to the database have generally been small. There has been investment in the database such as the following enhancements: DUMP/LOAD/AUDITDB, BACKUP/RESTORE, and SQL. However, the investment in the database has been primarily on an as-needed basis.

DB2 and other database productsWhen reviewing DB2 or other database products, note that they usually provide the following functions currently not available with the proprietary database:

� Constraints: Constraints are used to validate attributes/values of a column for a row. Constraints are typically easy to represent and can be defined when a table is created. Constraints can easily check and enforce specific values in a column, in a row, or ranges of values for a column, and so on.

� Triggers: Triggers cause other checks to be run, such as a fetch against another table to validate that some condition or relationship exists. Typically triggers are used to exercise more complex SQL statements then can be readily implemented or enforced by a constraint.

� Referential integrity (R/I): These are relationships defined between tables using “foreign keys” in one table to relate a given row to a row in another table. Similarly, it is also possible to implement referential integrity checking by stored procedures or even triggers. The main questions at this point are the complexity of the R/I check to be implemented, and what is the runtime (performance) impact to the check.

� Expanded database size: DB2 has much greater flexibility and potential capacity depending upon how it is configured. The limitations being dictated are based on the way DB2 is configured to manage its space (DMS verses SMS) and the page size to use. Where limitations do arise, they tend to be on a “per tablespace” basis, so there is at least still flexibility to evolve the tablespace scheme used by Tivoli Storage Manager to provide for further growth and expansion of the database.

Do not take this list for a complete reference or explanation of the actual capabilities, it is shown here only to illustrate advanced capabilities compared to the proprietary Tivoli Storage Manager database. These and additional functions are provided directly within DB2 or other database products. Compared to Tivoli Storage Manager Version 6, in older versions of the product, equivalents had to be implemented and maintained in the application code itself as opposed to the database.

Chapter 5. IBM Tivoli Storage Manager database 43

As with Tivoli Storage Manager, DB2 has evolved and has continued to be enhanced to remain competitive with other database products in the market. Today DB2 has platform coverage across all platforms that Tivoli Storage Manager supports and brings all the functions and features of a production enterprise-class database to an application using it.

Goals of the transition to DB2Through the years, while discussing with customers the transition to DB2 for the Tivoli Storage Manager database, the following major expectations or objectives were chosen:

� Tivoli Storage Manager administration should not become more complex than it is with the current database. You do not want additional DBA skills to be required for administration of Tivoli Storage Manager and to complete the tasks you do already today.

� Conversion from the proprietary database to the new database should be automated and should not require an unreasonable amount of time.

� Performance should be comparable to or better than that with the proprietary database.

� Existing and supported pre-6.1 storage agents must still be able to perform remote database operations.

Summarizing all the foregoing considerations, we identified these value propositions:

� Scalability: DB2 scales to much larger sizes and continues to be enhanced in this regard.

� Performance: There are many more tuning capabilities within DB2 than with the proprietary database.

� Recoverability: Many more tools and techniques are available for repairing or recovering DB2 databases than those that exist for the proprietary database.

� Monitoring and automation: A complete and robust implementation of SQL will now be available for customers to monitor and solicit information from Tivoli Storage Manager.

� Database license: There is no additional expense for a database license.

� Repair and recovery tools: Having a complete SQL implementation as well as the other features offered by DB2 eliminates the current techniques used to diagnose and repair the database, making the offline audit of the database obsolete.

5.2 Transition to DB2

While one of the target goals of the transition to the DB2 database was not to require any DB2 skills by a Tivoli Storage Manager administrator there are some aspects we want to discuss and explain to give you a better understanding on what happens under the cover.

Over the years, Tivoli Storage Manager administrators developed a good sense of how to use existing commands and utilities to configure for best performance. Most of these did become obsolete as the database itself now takes care of them

5.2.1 Database transition

The Tivoli Storage Manager server had to make a number of changes in order to utilize and exploit DB2 in place of the existing proprietary B+ tree database package that has been used since Tivoli Storage Manager was first released.


Here it is important to distinguish that Tivoli Storage Manager has code that is dedicated to managing the server database. Similarly, Tivoli Storage Manager has a large amount of code that provides the end-user (administrative and backup/archive/hsm client) capabilities. These end-user capabilities are the “application” code for purposes of this discussion. The existing Tivoli Storage Manager database management code is done using the database (DB) and recovery log (LOG) components. These components work in tandem doing transactional maintenance of the database for various database activities such as insert, update, delete, and fetch.

Figure 5-1 illustrates the various components involved when an operation is made to the integrated proprietary database.

Figure 5-1 Tivoli Storage Manager proprietary database and log components

The changes that were necessary to utilize and exploit DB2 as the Tivoli Storage Manager database were as follows:

� In order to use DB2 as the database, the existing DB component was eliminated. It was replaced with a component known as a remote data base (RDB). In this context, “remote” implies a database remote or separate from the Tivoli Storage Manager server itself. The RDB component is responsible for managing the Tivoli Storage Manager interaction with the available DB2 call level interface (CLI) APIs. This interface also provides the management of the available DB2 administrative APIs.

� The existing recovery log processing and component is superseded by DB2. The component is removed from the server initialization processing. DB2 owns and manages the recovery log functionality using its own recovery log capabilities and management.

� Transaction management now considers DB2 as a participant on a transaction.

The Tivoli Storage Manager DB component has always been a participant in a transaction and now the RDB component will also be a participant in any database related transaction. The RDB component is integrated in Tivoli Storage Manager so that it allows for the existing two-phase commit processing. Historically Tivoli Storage Manager has provided its own transaction manager and the DB2 semantics fit well in the existing model.

� The pre-Tivoli Storage Manager V6.1 locking scheme was implemented to “protect” sections of the database based on decisions being done by the application code. However, DB2 has its own locking and access control strategies. The Tivoli Storage Manager server code was updated to continue to provide the appropriate access control

Logical Volume Management (LVM) +Pseudo-Kernel/Device Interface

Database (DB) Log

Application Code(Admin & B/A/HSM &

Server Mgmt Processes)

DB

Operation

RecoveryLog

Database


and serialization to data in the database while utilizing capabilities that DB2 provides in this area. Primarily, Tivoli Storage Manager implemented its DB2 calls specifying “WITH UR,” which indicates “with uncommitted read.” The rational for this rule is that locking semantics and deadlock detection are already in place.

Uncommitted Read (UR) allows an application to access uncommitted changes of other transactions. The application also does not lock other applications out of the row that it is reading, unless the other application attempts to drop or alter the table.

� The pre-Tivoli Storage Manager V6.1 table schema is predicated upon the application level code owning and maintaining the relationships between rows in various tables as shown in Figure 5-2 on page 49. The new server exploits various capabilities that DB2 offers for the following purposes:

– Eliminating duplication across tables:

There were many cases where data was replicated across many tables. This was done because the proprietary database did not provide for multiple indices on the same table, thus allowing for search optimizations.

– Changing the key specifications for some tables:

Tivoli Storage Manager’s key and primary key selections historically have been limited by the fact that the only index/key available had to be unique and was governed by the B+ tree structure of the underlying tables. The new server takes advantage of various unique keys and primary keys to better suit optimization for DB2 and also to best meet performance objectives.

� There are additional capabilities within DB2 that are now used to validate or ensure integrity of the fields in the database and the tables themselves. A few of the DB2 capabilities used for this are views, triggers, stored procedures, and constraints. This explanation is drastically simplified and does not even try to explain these capabilities. For a complete understanding of these DB2 features, refer to the DB2 Information Center at:

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp

5.2.2 General DB2 configuration items

In this section we provide information about general DB2 configuration features.

Memory managementThe primary memory usage item for the server has historically been the server buffer pool specified by the BUFPOOLSIZE option. The buffer pool is the in-memory cache for the database pages used for pre-Tivoli Storage Manager V6.1 database management operations. With the transition to DB2, the buffer pool space shifts to the DB2 buffer pool where it is used for DB2's own database management operations on the Tivoli Storage Manager server’s behalf. There is also additional memory that DB2 will utilize for its own operating and management. You can consider the DBMEMPERCENT option being the replacement for the BUFPOOLSIZE option. However, it represents much more than the historic buffer pool because it represents the amount of RAM that DB2 can use for everything, such as the buffer pools (plural now) and the sort heap.

On UNIX systems, when you start the Tivoli Storage Manager server, the server attempts to change the ulimit values to unlimited. In general, this helps to ensure optimal performance and to assist in debugging. If you are a non-root user, when you start the server, attempts to change the ulimits might fail. To ensure proper server operation if you are running as a non-root user, make sure that you set the ulimits as high as possible, preferably to unlimited, before starting the server.


http://publib.boulder.ibm.com/infocenter/db2luw/v9//index.jsp

This includes setting DB2 user limits as high as possible. DB2 relies on private data memory for sort memory allocations during SQL processing. Insufficient shared heap memory can lead to Tivoli Storage Manager server failures when interacting with DB2. For more information about setting the appropriate platform values, see the following Technote:

http://www.ibm.com/support/docview.wss?uid=swg21212174

DB and log security in UNIXThe Tivoli Storage Manager server must be run by a member of the DB2 SYSADM_GROUP of the instance. This can be the instance user ID itself, or any member of that group. If you intend to run the server as the root user, you must add root to this group.

Even if you are running the server as root, all DB and log directories and files must be writable by the database instance user ID. The server no longer writes the DB and log files; DB2 does.

Required kernel parameter tuningHP-UX, Sun Solaris, and Linux systems require some kernel parameter tuning before you install. If you do not update these parameters, the installation of DB2 and Tivoli Storage Manager might fail. If these values are not set and the installation is successful, operational issues might still be encountered when using the server.

HP-UX and Sun Solaris systems recommendationsFor HP-UX and Sun Solaris systems, you can run the db2osconf utility to get recommended changes based on the size of your system. The db2osconf utility checks the current kernel configuration parameter settings, and suggests any updates that should be made. The db2osconf utility does not change the settings in the /etc/system file, but only suggests updates to help improve performance.

The suggested updates provided by the db2osconf utility are the minimum settings required to run DB2 on your system. To run both Tivoli Storage Manager and DB2, additional changes are required in addition to the suggestions made by the db2osconf utility (see Table 5-1 and Table 5-2).

Table 5-1 HP-UX recommended kernel parameter values

Parameter name Description Recommendedvalue

semume The process-wide maximum number of undo structures per process

8589934592

maxdsiz_64bit The maximum data segment size, in bytes for an executing process

8589934592

msgmnb The maximum number of bytes on a message queue

2097152

msgmni The maximum number of message queues 32767

msgtgl The maximum number of messages on all message queues

262144



Table 5-2 Sun Solaris recommended kernel parameter values

Details about the db2osconf utility are available at the IBM DB2 Database for Linux, UNIX, and Windows Information Center:

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?tab=search&searchWord=db2osconf&maxHits=500

Linux system recommendationsTo update the kernel parameters on Red Hat and SUSE Linux, you can run the ipcs - l command to list the parameter values and then analyze the output to determine whether any changes are required for your system.

Additional details on changing kernel parameters are available at the IBM DB2 Database for Linux, UNIX, and Windows Information Center:

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?tab=search&searchWord=kernel&parameters&maxHits=500

You can use the information in Table 5-3 to determine the minimum values that you should set to run Tivoli Storage Manager and DB2 together on your target operating system.

Table 5-3 Linux recommended kernel parameter values

Parameter name Description Recommendedvalue

set semsys:seminfo_semume The process-wide maximum number of undo structures per process

5120

set semsys:seminfo_semmni The number of semaphore identifiers 6144

set shmsys:shminfo_shmmax The maximum shared-memory segment size 46369367654

set shmsys:shminfo_shmmni The minimum shared-memory segment size 6144

set rlim_fd_max The process open-file descriptors limit 65536

set rlim_fd_cur The file descriptor limit 4096

Parameter name

Description Recommended value

SHMMNI The maximum number of segments 32768

SHMMAX The maximum size of a shared memory segment (kbytes)

x86 systems - 26843545664-bit systems - 1073741824

SHMALL The maximum allocation of shared memory pages (kbytes)

8388608

SEMMNI The maximum number of arrays 1024

SEMMSL The maximum semaphores per array 250

SEMMNS The maximum semaphores per system 256000

SEMOPM The maximum operations per semaphore call 35

MSGMNI The maximum number of system-wide message queues

1024

MSGMAX The maximum size of messages (bytes) 65536

MSGMNB The default maximum size of queue (bytes) 65536


http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?tab=search&searchWord=db2osconf&maxHits=500

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?tab=search&searchWord=kernel&parameters&maxHits=500

5.2.3 Database and log configuration items

Here we discuss the items to consider when configuring the DB2 database and log directories. Figure 5-2 shows the Tivoli Storage Manager V6.1 components involved: database, active log directory, mirror log directory, archive log directory, and the archive failover directory.

Figure 5-2 v V6.1 components

Estimating database space requirementsThe process to estimate how much space to configure differs between installing a new server or upgrading an existing server. Here we discuss both processes. If you plan to take advantage of the integrated deduplication function, you need to consider additional database and log space requirements. For additional information about deduplication, refer to Chapter 7, “Data deduplication in Tivoli Storage Manager V6.1” on page 145.

Estimate database space requirements for a new serverThe size of the database depends on the number of client files to be stored and the method by which the server manages them.

If you can estimate the maximum number of files that might be in server storage at any time, you can estimate the database size from the following information:

� Each stored version of a file requires about 600 to 1000 bytes of database space.

� Each cached file, copy storage pool file, and active-data pool file requires about 100 to 200 bytes of database space.

� Overhead can require up to 25% in additional space.

In the following examples, the computations are probable maximums. In addition, the numbers are not based on using file aggregation. In general, aggregation of small files reduces the required database space. Assume the following numbers for a Tivoli Storage Manager system:

� The size of the database depends on the number of client files to be stored and the method by which the server manages them.

TSM V6 Components

TSM Server

Active Log

Log Mirror (optional)

Archive Log

Failover Archive Log (optional)

TSM DB

TSM STGPools (disk, tape)

ActiveLogDir

MirrorLogDir

ArchiveLogDir

ArchFailoverLogDir


� If you can estimate the maximum number of files that might be in server storage at any time, you can estimate the database size from the following information:




Versions of filesThe following considerations apply:

� Backed up files:

Up to 500,000 client files might be backed up. Storage policies call for keeping up to three copies of backed up files:

500.000 files x 3 copies = 1.500.000 files

� Archived files:

Up to 100,000 files might be archived copies of client files.

� Space-managed files:

Up to 200,000 files migrated from client workstations might be in server storage.

File aggregation does not affect space-managed files.

At 600 bytes per file, the space required for these files is:

(1.500.000 + 100.000 + 200.000) x 600 = 1.0GB

Cached, copy storage pool, and active-data pool filesThe following considerations apply:

� Cached copies:

Caching is enabled in a 5 GB disk storage pool. The pool's high and low migration thresholds are 90% and 70% respectively. Thus, 20% of the disk pool, or 1 GB, is occupied by cached files.

If the average file size is about 10 KB, about 100,000 files are in cache at any one time.

100.000 files x 200 bytes = 19 MB

� Copy storage pool files:

All primary storage pools are backed up to the copy storage pool:

(1.500.000 + 100.000 + 200.000) x 200 bytes = 343 MB

� Active-data pool files:

All the active client-backup data in primary storage pools is copied to the active-data pool. Assume that 500,000 versions of the 1,500,000 backup files in the primary storage pool are active.

500.000 x 200 bytes = 95 MB

Therefore, cached files, copy storage pool files, and active-data pool files require about 0.5 GB of database space.

OverheadAbout 1.5 GB is required for file versions, cached copies, copy storage pool files, and active-data pool files. Allow up to 50% additional space (or 0.7 GB) for overhead.

The database should then be approximately 2.2 GB at a minimum.


If you cannot estimate the numbers of files, you can roughly estimate the database size as from 1% to 5% of the required server storage space. For example, if you need 100 GB of server storage, your database should be between 1 GB and 5 GB.

During SQL queries of the server, intermediate results are stored in temporary tables that require space in the free portion of the database. Therefore, using SQL queries requires additional database space. The more complicated the queries, the greater the space that is required.

For example, if you need 100 GB of server storage, your database should be between 1 GB and 5 GB. During SQL queries of the server, intermediate results are stored in temporary tables that require space in the free portion of the database. Therefore, using SQL queries requires additional database space. The more complicated the queries, the greater the space that is required. Notice: In the preceding examples, the results are estimates. The actual size of the database might differ from the estimate because of factors such as the number of directories and the length of the path and file names. As a best practice, periodically monitor your database and adjust its size as necessary.

You can use the worksheet in Table 5-4 to help you plan the amount and location of storage needed for the V6.1 server.

Table 5-4 Worksheet for planning space

Estimate database space requirements for a server upgradeThe amount of database space that is required depends on the size of the original V5 database, and on how much data the server will be managing.

The amount of storage space for the database is managed automatically. The database space can be spread across multiple directories. After you specify the directories for the database, the server uses the disk space available to those directories as required.

Note: In the preceding examples, the results are estimates. The actual size of the database might differ from the estimate because of factors such as the number of directories and the length of the path and file names. As a best practice, periodically monitor your database and adjust its size as necessary.

Adding a new database directory after initial load will cause a REORG of the database. Because this is expensive and disruptive, it should be avoided.

Item Space required Location

The instance directory for the server, which is a directory that contains files specifically for this server instance (the server options file and other server-specific files)

The database

Active log

Archive log

Optional: Log mirror for the active log

Optional: Secondary archive log (failover location for archive log)


Locate the database and recovery log directories on separate physical volumes or file systems. Ideally, use multiple directories for database space and locate them across as many physical devices or logical unit numbers (LUNs) as there are directories.

Plan for 33 - 50% more than the space that is used by the V5 database. (Do not include allocated but unused space for the V5 database in the estimate.) Some databases can grow temporarily during the upgrade process; consider providing up to 80% more than the space that is used by the V5 database.

Estimation stepsYou can estimate the amount of space that the database will require by completing the following steps:

1. Use the QUERY DB FORMAT=DETAILED command to determine the number of used database pages in your V5 database.

2. Multiply the number of used database pages by 4096 to get the number of used bytes.

3. Add 33 - 50% to the used bytes to estimate the database space requirements.

Consider testing the upgrade of the database to get a more accurate estimate. Not all databases will grow as much as the suggested 33 - 50% increase in space.

When the server is operating normally, after the upgrade process, some operations might cause occasional large, temporary increases in the amount of space used by the database. Continue to monitor the usage of database space to determine whether the server needs more database space.

For the best efficiency in database operations, anticipate future growth when you set up space for the database. If you underestimate the amount of space that is needed for the database and then must add directories later, the database manager might need to perform more database reorganization, which can consume resources on the system. Estimate requirements for additional database space based on 600 - 1000 bytes per additional object stored in the server.

Estimating log space requirementsIn this section we show how to estimate log space requirements.

Active log spaceEnsure that the recovery log has enough space.

The minimum size of the active log is 2048 MB (2 GB); the maximum is 131.072 MB (128 GB). The default is 2048 MB. You might want to begin with an active log size of 4 GB to 8 GB. Monitor the space usage and adjust the size of the active log as needed.

Active log mirror spaceThe active log mirror is a duplicate copy of the active log and should be the same size as the active log.

Creating a log mirror is optional. The additional space that the log mirror requires is another factor to consider when deciding whether to create a log mirror.

Note: You cannot use raw logical volumes for the database. If you want to reuse space on the disk where raw logical volumes were located for an earlier version of the server, you must create file systems on the disk first.


Archive log spaceThe size of the archive log depends on the number of objects stored by client nodes over the period of time between full backups of the database.

A full backup of the database causes obsolete archive log files to be pruned, to recover space. The archive log files that are included in a backup are automatically pruned after two more full database backups have been completed. Therefore, the archive log should be large enough to contain the logs generated since the previous two full backups.

If you perform a full backup of the database every day, the archive log must be large enough to hold the log files for client activity that occurs over two days. Typically 600 - 4000 bytes of log space are used when an object is stored in the server. Therefore you can estimate a starting size for the archive log using the following calculation:

objects stored per day x 3000 bytes per object x 2 days

For example:

5.000.000 objects/day x 3000 bytes/object x 2 days = 30.000.000.000 bytes, or 30 GB

It is important to maintain adequate space for the archive log directory. If the drive or file system where the archive log directory is located becomes full and there is no archive failover log directory, the data remains in the active log directory. This condition can cause the active log to fill up, which causes the server to stop.

Archive failover log spaceThe archive failover log is used by the server if the archive log directory runs out of space.

Specifying an archive failover log directory can prevent problems that occur if the archive log runs out of space. If the drive or file system where the archive failover log directory is located becomes full, the data remains in the active log directory. This condition can cause the active log to fill up, which causes the server to stop.

Database configurationWith the utilization of Database Managed Space (DMS) tablespace design, the database manager controls the storage space. Use the DBDIR/DBFILE parameter with the DSMSERV[LOAD]FORMAT command to specify up to 128 directories available to DB2, known as containers. This is DB2 terminology for what Tivoli Storage Manager calls database directories. The database volumes are managed by DB2; you are no longer asked to format them. In “DB and log security in UNIX” on page 47, we discuss this in more detail. You cannot place the containers on raw logical volumes, and you should make sure each container is in a separate file system or LUN.

Additional considerations when configuring the database are as follows:

� The database manager uses striping to ensure an even distribution of data across all containers. DB2 striping is recommended when writing data into multiple containers. If you choose to implement disk striping along with DB2 striping, the extent size of the tablespace and the strip size of the disk should be identical.

� The containers that make up a DMS tablespace do not need to be the same size; however, this is not normally recommended, because it results in uneven striping across the containers, and sub-optimal performance. If any container is full, DMS tablespaces use available free space from other containers.

� If the disk subsystem supports it, disable the read cache for the DB but enable the write cache for it. In addition, configure for random IO access.


� The database is used to contain committed Tivoli Storage Manager transactions.

� Page sizes used for the database are 8 K and 32 K depending on the tablespace. The largest tables, such as the big inventory tables, use a 32 KB page size. For any other table that we did not designate as large, we will use a page size of 8 KB. The maximum supported database size is 1 TB. No testing was done yet for performance, but from current feedback, page sizes used work fine with default disk subsystem segment sizes.

� Use fast disk. Using the slow internal disk included by default in most servers, or using consumer grade PATA/SATA disk, will slow everything down.

� If your disk storage is virtualized (such as when using a SAN Volume Controller), or is controlled by a RAID controller, you might be able to further improve I/O parallelism by setting the DB2 registry variable DB2_PARALLEL_IO. This is set using the DB2SET command, as in:

db2set DB2_PARALLEL_IO=value

The value is a comma-separated list of tablespace ids or '*', followed by a colon, followed by a number that indicates the number of physical disks backing your database container (directory). For Tivoli Storage Manager, we recommend to specify '*' for the tablespace IDs, and then whatever number of disks you have in your RAID configuration.

Example: For LUNs of 4+1 RAID5, you would use:

db2set DB2_PARALLEO_IO=*:4

This requires a restart of DB2.

� Separate the Tivoli Storage Manager components (DB LUNs, Log LUNs, Storage Pool LUNs).

The database defined for Tivoli Storage manager is taking advantage of the AUTOMATIC STORAGE parameter. Automatic storage is a storage management technique where storage for multiple tablespaces is automatically managed at the database level:

� Multiple tablespaces automatically draw increments of storage from a “database storage pool” on demand.

� This removes the need to watch for disk shortages in each individual tablespace.

� It also removes the need to manually enlarge containers or add stripe sets.

� It uses the DMS infrastructure internally, combining the performance benefits of the DMS infrastructure with manageability benefits of System Managed Space (SMS).

Automatic storage allows the server to:

� Create the database and associate a set of storage paths with it.

� Add storage paths to the database after creation.

� Create AUTOMATIC STORAGE tablespaces:

– No explicit container definitions are provided.– Containers are automatically created across the database storage paths.– Growth of existing containers and addition of new ones are managed by DB2.

� Redefine database storage paths during a database restore.

Monitoring the database spaceIf the server cannot automatically extend the database, it will try to prevent a server crash. We intentionally forced this by filling the database file system while a client ran a backup. Example 5-1 shows that the server aborts the transaction and closes the session with the client.


Example 5-1 ANR0131E, Server database space exhausted

ANR0131E dbieval.c(809): Server DB space exhausted.ANR0162W Supplemental database diagnostic information: -1:57011:-289([IBM][CLI Driver][DB2/NT] SQL0289N Unable to allocate new pages in tablespace "LARGESPACE1". SQLSTATE=57011).ANR0532W smnode.c(3361): Transaction 0:7594 was aborted for session 4 for nodeOLDSKOOL (WinNT).ANR0514I Session 4 closed volume D:\GALLIUM_SERVER1\FILECLASS\0000003F.BFS.ANR0403I Session 4 ended for node OLDSKOOL (WinNT).

You should monitor the file system for space being available to the database, use the QUERY DBSPACE command as shown in Example 5-2.

Example 5-2 QUERY DBSPACE: monitoring the database for available space

tsm: TIRAMISU>q dbspace

Location: g:\tsm\server1\databaseTotal Size of File System (MB): 59,388.70Space Used on File System (MB): 59,387.81 Free Space Available (MB): 0.00

The QUERY DBSPACE is a new command for the Tivoli Storage Manager V6.1 server, use the DSMSERV DISPLAY DBSPACE utility (see Example 5-38 on page 105) when the server is not running. Table 5-5 explains the fields being returned by the command.

Table 5-5 QUERY DBSPACE command explained

LOG configurationYou specify the logs used by the server with the ACTIVELOGDIR and the ARCHLOGDIR parameters to the DSMSERV [LOAD]FORMAT command. Both parameters are required. For the active log you can, in addition, specify the optional ACTIVELOGSIZE parameter. If you do not specify the active log size, it defaults to 2 GB. The active log directory specifies the directory in which the Tivoli Storage Manager server writes and stores active log files.

Field Description

Location Directory or path used for storing the database

Total Size of File System(MB)

Windows: Total space (in MB) on the drive where the directory is located

UNIX and Linux: Total space in the file system where the path is located

Space Used on File System(MB)

Windows: Total used space (in MB) on the drive where the directory is located

UNIX and Linux: Total used space in the file system where the path is located

Free Space Available (MB)

Windows: Space remaining on the drive where the directory is located

UNIX and Linux: Space remaining in the file system where the path is located

If two or more directories or paths are located on the same drive (Windows) or the same file system, then the total free space will be divided into that many directories or paths


There is only one active log location. The name must be a fully qualified directory name. The directory must already exist, it must be empty, and it must be accessible by the user ID of the database manager. The maximum number of characters is 175. In this context, active log is a Tivoli Storage Manager term, whereas DB2 uses logs and archive logs.

Optionally you can specify the ARCHFAILOVERLOGDIR and MIRRORLOGDIR with either of the format commands. ARCHFAILOVERLOGDIR specifies the directory to be used as an alternate storage location if the ARCHLOGDIR directory is full. MIRRORLOGDIR specifies the directory in which the server mirrors the active log (those files in the ACTIVELOGDIR directory). For both, the same restrictions apply as with the ARCHLOGDIR.

Active log directory The following considerations apply:

� It contains current in-flight transaction data.� I/O characteristic is sequential.� Usage is required.� Fixed-size non-circular log type is used.� Roll-forward mode is supported only.� Active log files are created in 512 MB sized files. The number of logs created is

determined by ACTIVELOGSIZE / 512. If you specified an odd number with the ACTIVELOGSIZE, the value is rounded up to the next even number.

� If a transaction is not committed and all active log files are filled, the server halts.� The default ActiveLogSize is 2 GB, maximum supported value is 128 GB.� The ACTIVELOGDIR value can be changed in the dsmserv.opt file (requires server

restart), and the initial value is taken from the format command.

Active log mirror directoryThe following considerations apply:

� It contains mirrored copies of active transaction data.� I/O characteristic is sequential.� Use is optional but recommended.� Mirror log files are created in 512 MB sized files.� If a mirror log directory becomes full, a message is issued, and the server continues.� The MIRRORLOGDIR value can be changed in the dsmserv.opt file (requires server

restart), and the initial value is taken from the format command if specified.

Archive log directoryThe following considerations apply:

� It contains committed transaction data.� I/O characteristic is sequential.� Usage is required.� It can have up to three full backups worth of space for archive logs.� It is required to roll forward transactions after a database restore� Log files older than two full backups ago are removed after DB backup.� The ARCHIVELOGDIR value can be changed in the dsmserv.opt file (requires server

restart), and the initial value is taken from the format command.

Archive failover log directoryThe following considerations apply:

� Used in case Archive Log Directory becomes full to hold archive logs.� I/O characteristic is sequential.� Use is optional.


� If in use, logs will be moved back to ACTIVELOGDIR location for a DB restore.� Log files are removed after DB backup.� The ARCHFAILOVERLOGDIR value can be changed in the dsmserv.opt file (requires

server restart), and the initial value is taken from the format command if specified.

The active log directory and the mirror log directory should be on high-speed reliable disk, the archive log directory can be configured to utilize slower disk. The failover archive log can be even slower, assumed it is used infrequently you can even use NFS.

The log file flow is illustrated in Figure 5-3. When they are full, the log files are closed by DB2 and get copied to the archive log directory, transactions might still be active when the file gets archived. The server continues to copy full log files to the archive log directory until the directory becomes full, then copies will go to the failover archive log directory if defined. If even the failover archive log directory fills up, for example, because of unexpected workload, the active logs will retain in the active log directory. This can result in an out of log space condition and a server halt if the active log directory fills up, too.

Figure 5-3 Log file flow, archive log directory full

Log file sizing recommendationsWith Tivoli Storage Manager V6.1, the recovery log is comprised of two primary storage locations. As explained previously, these locations are the active log and the archive log. (There are also some optional log storage locations in addition to these two, but for purposes of this discussion, the focus will be on these two primary or required storage locations).

The active log is used to store current in-flight transactions for the server. For example, if the server has 10 backup/archive client sessions performing backups, the transactions used by those sessions will be represented in the active log and used to track changes to the server database such as the insert, delete, or update to records for tables within the server database. The active log needs to be sized large enough to hold the largest concurrent workload that the server will encounter. Or put another way, it needs to be able to store the data representing in-flight transactions for the largest concurrent workload that the server can support.

Active Log / Archive Log / Failover Archive Log

S0000100.LOGS0000099.LOGS0000098.LOG

S0000097.LOG

Active Log Directory Archive Log Directory

Copy

S0000000.LOG

S0000095.LOG

Archive Log Directory

(Failover)

S0000096.LOG

S0000096.LOGS0000095.LOG


The archive log is used as a storage repository for log files that were previously active and no longer contain transaction references for in-flight transactions. So, when a given log file in the active log directory is no longer referenced by an in-flight transaction, that log file is eligible to be copied to the archive log directory where it will then be retained. The copy of log files from the active log directory to the archive log directory is done automatically by the DB2.

The active log will then continue at a steady state of the defined active log size. As new transactions are started in response to server activities, this will drive the head of the log forward as these new transaction records are prepended to the head of the active log. The tail of the active log is continually truncated as the oldest in-flight transactions complete, which allows active log volumes to become inactive and eligible to be archived (copied) to the archive log directory.

The archive log size is not maintained using a steady state or predefined size like the active log uses. The archive log will store all inactive log files based on retention policies that the Tivoli Storage Manager server manages. These policies are not configurable by you as an administrator, the archive log files will be pruned by DB2 following the pruning policy set up by Tivoli Storage Manager. This pruning is a function of full database backup cycles. To take a step back, we need to first understand how and why full database backups are considered in this processing. When any database backup is performed, the database backup will contain the actual database pages that are allocated and in use for the database and the active and archive log information necessary to represent transaction consistency for the database data stored within that database backup.

The Tivoli Storage Manager V6.1 server only operates in ROLLFORWARD recovery mode. In order to accommodate this, the archive log files are kept in order to represent all the transactional changes to the server database from the time of the last FULL database backup. So, a full database backup cycle in this discussion represents both the time between one full database backup and the next, and more importantly, it represents all the transactional changes that were recorded from the time the previous full database backup was performed until the time the next full database backup is done.

The Tivoli Storage Manager server requires that archive log space is retained representing two full database backup cycles. Because the server requires archive log space representing two full database backup cycles, you must also consider the active or current transaction load which is the files from the active log that become inactive and eligible to be moved to the archive log. his then increases the archive log space requirement from being two times the space needed to store the transactional data for a single database backup cycle to being up to a total of three times this total space requirement.

Given the framework of this discussion, next we provide recommendations on how to size the active and archive log space assigned to a Tivoli Storage Manager V6.1 server.

Active and archive log sizing upgrading to Tivoli Storage Manager V6.1Here we discuss the active and archive log sizing considerations when upgrading from a Tivoli Storage Manager V5.x server to Tivoli Storage Manager V6. As a starting point, the active log should be two times the size of the existing Tivoli Storage Manager V5.x recovery log. So if the V5.x recovery log was 10 GB, an active log size of 20 GB would be appropriate.

To estimate transaction activity on your V5.x server between full database backups, do this:

1. Prior to your next regularly scheduled FULL database backup, issue the command, SHOW LOGV. Make note of the log head LSN (HeadLsn), which will be in the form XXXXX.YYY.ZZZZ. Example 5-3 shows the output for one of our test servers, but let us assume for your production server that the value is 140312.105.1011.


Example 5-3 SHOW LOGV command

tsm: LEONARD>show logv

Log Global Variables:

SegTableSize=1000, ResizeLocked=False, EmptySegs=999, PagesReserved=131,MaxPagesUsed=378, PagesInUse=363, LastReportedFull=90

HeadLsn: 16354.231.1737 (segment 0, page 231) StableLsn: 16354.231.986 (segment 0, page 231) TruncLsn: 16354.223.16 (segment 0, page 223) ScanLsn: 16354.223.16 ScanEndLsn: 16354.223.16

Log Restart Record:

VersId=1, RecLen=88, InstallId=4A3D12ED, FmtCapacity=1000, Capacity=1000,NewCapacity=1000 FmtDate=1245516525, ResizeDate=0, MovePhase=0, SourceSeg=-1,TargetSeg=-1, consumedLsn=1.0.0, consumedReset=1245516525

TruncBaseLsn: 16354.0.0 (segment 0, page 0)

txnDelay: off=75%%, low=81%%, med=90%%, high=95%%, time=0ms

2. Let the full database backup run and then allow the server to operate normally.

3. At the next scheduled FULL database backup, issue the SHOW LOGV command. Again make note of the log head LSN (HeadLsn); this might now be a value like 158600.88.16.

4. To estimate the transaction activity for this server between full database backups, subtract the XXXXX values from the noted log head LSNs that were captured from the SHOW LOGV command. Using our example values, we would use 158600 - 140312. The result in this example is 18288. This value represents megabytes (MB) so the transaction load for a single database backup cycle for this example would be approximately 18 GB.

Using the estimated transaction workload for a single full database backup cycle, a conservative estimate of the space needed for the archive log would then be three times this value. Using the example values from the previous step, this would be 18 GB * 3 or approximately 54 GB.

Sizing consideration for active and archive log if deploying a new V6.1 serverWhen deploying a new Tivoli Storage Manager V6.1 server, an estimate is needed based on the expected load on the server in terms of the number of files to be stored nightly. The number of files stored for a given nightly schedule window is just one way to estimate this. This estimate needs to be done by the administrator or team implementing this server. This estimate should consider the total number of files to be backed up, archived, and space managed in a given night.

An example of this estimate is:

� Nightly client operations: 300 clients

� How many files will be stored in a single transaction: 4096

(This is derived as total files to be stored nightly per client times the server option setting for TXNGROUPMAX. For purposes of this example, the default value of 4096 is used.)

� Total concurrent workload represented by in-flight client transactions: 1,228,800.

(This is derived as number of clients times files stored in a single client transaction.)


� Total active log needed to support 1,228,800 files for 300 in-flight client session with TXNGROUPMAX = 4096: 3.5 GB.

Note that for this calculation, 3053 log bytes are needed per file in a given transaction. This represents the log bytes needed when backing up files from a Windows server where the file names vary in length from 12 to 120 bytes. This was done as a backup to a DISK storage pool because these pools have increased log overhead and use as compared to sequential media storage pools. You might need to consider a value larger than 3053 if the data being stored has file names that are longer than those referenced previously.

In this example, the recommended active log size would be 3.5 GB. There are a number of variations or other considerations which we discuss next.

Variation 1If the 300 clients use the client option RESOURCEUTILIZATION set greater than the default, such that each client session ran with up to a maximum of 3 sessions in parallel, this would then change the servers inflight concurrent load from 300 sessions to 900 (as a maximum). The calculation then becomes: (((900 * 4096) * 3053) / 1 GB) = 10.5 GB.

Variation 2If a workload of 1000 clients were used with the client option RESOURCEUTILIZATION set greater than the default, such that each client session ran with up to a maximum of 3 sessions in parallel, this would then result in a calculation of: (((3000 * 4096) * 3053) / 1GB) = 35 GB.

Variation 3If the backups were being done using simultaneous write, such that the data was being stored to two copy pools in addition to the primary storage pool, the log bytes estimate per file should be increased. If a value of 200 bytes for each copy storage pool is used, then this value is 3453. Using the original calculations, the result would be nearly 4 GB.

In the preceding examples and discussion, this assumes that the client store operations are done in isolation. For example, migration, deduplication (identify processing), reclamation, expiration, and even other administrative tasks such as administrative commands or SQL from administrative clients, are not being run concurrently with this client workload. Any of these operations included in the processing during the time for this client workload would increase the active log space required.

This also assumes that the client workloads are somewhat homogeneous. Of particular interest is the duration of transactions. If there are a large number of transactions that complete quickly (complete in a short amount of time), this can cause active log space issues if there are also long running transactions (meaning those that complete in a long amount of time) in this mix. If the mix of client workloads and the relative amount of time needed for specific transactions to complete is somewhat heterogeneous, then increasing the active log size might be necessary in order to compensate for these timing differences.

In this scenario, migration from the DISK storage pool to a sequential media pool (DEVTYPE=FILE) uses approximately 110 bytes per file migrated, which results in 10.5 MB of log space used for each 100,000 files migrated. Using our original example where the nightly client load in terms of number of files is 1,228,800, if these files then were migrated to the NEXT pool, then the log space needed for this migration operation (assuming all files were migrated) would be 129 MB.

Continuing on with the log size estimate for a Tivoli Storage Manager V6.1 server, if the active log is estimated to require 3.5 GB, then the archive log would require 10.5 GB.


Does deduplication for storage pools affect the active and archive log sizing?The affect of deduplication on the active and archive log needed for the server will vary depending upon the deduplication ratio of the data. In a scenario where there is a high percentage of data that can be deduplicated, the active log bytes per extent identified by the IDENTIFY process are approximately 1500 bytes. As an example, if the number of extents that can be identified during the execution of the IDENTIFY process is 250,000, then the active log space needed for this operation is estimated to be 358 MB.

Use the information from “Variation 2” on page 60 about sizing the active log for a new Tivoli Storage Manager V6.1 server installation, if the nightly backup load is 100,000 files for each of 300 clients (100,000 files is a change rate of 10% on a total number of files of 1,000,000 for each client). This represents 30,000,000 files for that nightly workload. If those 30,000,000 files represented 60,000,000 deduplicatable extents, the total archive log space required would be 84 GB.

In this scenario, the active log impact of 60,000,000 extents is based on the TXNGROUPMAX server options setting. The identify process will operate on aggregates (groups) of files based on how many files were stored in a given transaction. If the average number of extents per file is 2 (60,000,000 / 30,000,000) and the number of files in a transaction is 4096, then the extents per aggregate is 8192, which results in 12 MB of active log space used per 4096 files having 8192 extents.

The next consideration relative to the active log size needed for IDENTIFY processing is how many processes are being run. If there are 10 IDENTIFY processes running in parallel, then the concurrent load on the active log is 12 MB * 10 or 120 MB.

The final consideration for active log impacts from IDENTIFY processing is in regard to the impacts of really large files. For example, if a client backs up a single object, perhaps an image backup of a file system, that is 800 GB in size. This can represent a very high number of extents because of the nature of this data; for this discussion, assume that it is 1.2 million extents. This 1.2 million extents would represent a single transaction for an IDENTIFY process that requires an estimated 1.7 GB of active log space. This 1.7 GB of active log space might be easily attainable in isolation.

But if lots of other activity is happening in the active log, such as other IDENTIFY processes that are only having to process 8192 extents per transaction, the active log might become constrained for space because the small transactions are intermixing with the large transaction used to identify the extents for the 800 GB single object. If the deduplication enabled storage pool will have a mix of data with lots of uniform relatively small files while also having a small number of very large highly deduplicatable objects, then we recommend that you plan to increase the active log size by a factor of two. The issue is that it is not only the raw space that is needed, but also the timing and duration of the transactions requiring that space while other activities are concurrently processing. So, if the previous estimates recommend a 25 GB active log size, then with deduplication in the mix, the active log size becomes 50 GB and the archive log is then 150 GB.

In conclusion, there are a number of factors to consider when planning for the size of the Tivoli Storage Manager V6.1 server active and archive logs. The previous examples and discussion present some basic values that can be used for estimation purposes. Keep in mind that you might need to consider larger values in your actual environment.

Log file managementThe DB2 database manager uses a number scheme to name log files. This naming strategy has implications for log file reuse and log sequences. Also, a DB2 database that has no client application connection uses a new log file when the next client application connects to that


database server. These two aspects of DB2 Data Server database logging behavior affect the log file management choices that you make.

Consider the following factors when managing database logs:

� The numbering scheme for archived logs starts with S0000000.LOG, and continues through S9999999.LOG, accommodating a potential maximum of 10 million log files. The database manager resets to S0000000.LOG if:

– A database configuration file is changed to enable rollforward recovery – A database configuration file is changed to disable rollforward recovery – S9999999.LOG has been used.

� The DB2 database manager reuses log file names after restoring a database (with or without rollforward recovery). The database manager ensures that an incorrect log is not applied during rollforward recovery. If the DB2 database manager reuses a log file name after a restore operation, the new log files are archived to separate directories so that multiple log files with the same name can be archived. The location of the log files is recorded in the recovery history file so that they can be applied during rollforward recovery. You must ensure that the correct logs are available for rollforward recovery.

When a rollforward operation completes successfully, the last log that was used is truncated, and logging begins with the next sequential log. Any log in the log path directory with a sequence number greater than the last log used for rollforward recovery is re-used. Any entries in the truncated log following the truncation point are overwritten with zeros. Ensure that you make a copy of the logs before invoking the rollforward utility. You can invoke a user exit program to copy the logs to another location.

� If a database has not been activated (by way of the ACTIVATE DATABASE command), the DB2 database manager truncates the current log file when all applications have disconnected from the database. The next time an application connects to the database, the DB2 database manager starts logging to a new log file. If many small log files are being produced on your system, you might want to consider using the ACTIVATE DATABASE command. This not only saves the overhead of having to initialize the database when applications connect, it also saves the overhead of having to allocate a large log file, truncate it, and then allocate a new large log file.

� An archived log can be associated with two or more different log sequences for a database, because log file names are reused (see Figure 5-4). For example, if you want to recover Backup 2, there are two possible log sequences that could be used. If, during full database recovery, you roll forward to a point in time and stop before reaching the end of the logs, you have created a new log sequence. The two log sequences cannot be combined. If you have an online backup image that spans the first log sequence, you must use this log sequence to complete rollforward recovery.

If you have created a new log sequence after recovery, any tablespace backup images on the old log sequence are invalid. This is usually recognized at restore time, but the restore utility fails to recognize a tablespace backup image on an old log sequence if a database restore operation is immediately followed by the tablespace restore operation. Until the database is actually rolled forward, the log sequence that is to be used is unknown. If the tablespace is on an old log sequence, it must be “caught” by the tablespace rollforward operation. A restore operation using an invalid backup image might complete successfully, but the tablespace rollforward operation for that tablespace will fail, and the tablespace will be left in restore pending state.

For example, suppose that a tablespace-level backup operation, Backup 3, completes between S0000013.LOG and S0000014.LOG in the top log sequence. If you want to restore and roll forward using the database-level backup image, Backup 2, you will need to roll forward through S0000012.LOG. After this, you could continue to roll forward through either the top log sequence or the (newer) bottom log sequence. If you roll forward


through the bottom log sequence, you will not be able to use the tablespace-level backup image, Backup 3, to perform tablespace restore and rollforward recovery.

To complete a tablespace rollforward operation to the end of the logs using the tablespace-level backup image, Backup 3, you will have to restore the database-level backup image, Backup 2, and then roll forward using the top log sequence. After the tablespace-level backup image, Backup 3, has been restored, you can initiate a rollforward operation to the end of the logs. See Figure 5-4.

Figure 5-4 DB2: re-use of log file names

5.3 Database administration tools

A question raised often in the DB2 transition context is about the amount of DB2 skills necessary to administer the Tivoli Storage Manager database. Should you as a Tivoli Storage Manager administrator go to DB2 school?

The answer is, that the product is designed to require very little DB2 knowledge on the part of the administrator. And you should not be directly changing anything within the DB2 subsystem unless directed to do so by IBM support, or as part of a procedure that is documented in the Tivoli Storage Manager product manuals.

In this database administration section, we provide a brief description of the administrative interfaces provided by DB2, the command processor, and the DB2 Control Center. A deep discussion of the administration tools or even DB2 commands is far beyond the scope of this book. If you are interested and want to have more information on this topic, review the DB2 Information Center at:


5.3.1 DB2 commands

We found the following list of commands helpful with the DB2 database exploitation by the Tivoli Storage Manager server.

0000010.LOG

Backup 1 Backup 2 Backup 3

0000011.LOG 0000012.LOG 0000013.LOG 0000014.LOG

0000013.LOG 0000014.LOG

Restore Backup 2and Roll Forward to

end of log 12.

Note: For the Tivoli Storage Manager server to work correctly and the integrated DB2 database being able to manage itself appropriately, use of the administration tools is not required.



DB2 command line processor On a Windows system you can open a DB2 command window, click Start → All Programs → IBM DB2 → <DB2 Instance> → Command Line Tools → Command Window. This will open a window in the DB2 install directory with the environment set; from here, you can submit the DB2 commands. On a UNIX system you can issue DB2 commands and SQL statements from the command line using either the DB2 Administration Server user ID or the DB2 instance user ID.

The DB2 command line processor can be used in a variety of modes:

� Interactive input mode:

By entering the db2 command, the DB2 command line processor can be started in interactive input mode. In this mode, the operating system command processor or shell is configured and initialized specifically for the direct processing of DB2 commands and SQL statements and for returning the output of the processing.

� Command mode:

The DB2 command line processor command mode maintains the operating system command processor or shell environment. To use this mode, simply prefix DB2 commands and SQL statements with db2. This indicates to the operating system that the command or SQL statement that follows is to be handled by the DB2 command line processor. In the command mode, because there is no explicit initialization done to the processor or shell environment, operating system commands can be issued as before.

� Batch mode:

Batch mode is an extension of command mode. Batch mode enables you to specify a file containing a set of DB2 commands or SQL statements to be processed by the DB2 command line processor.

Regardless of the mode used, the DB2 command line processor provides maximal support for working with DB2 instances and DB2 databases. Example 5-4 shows the invocation of the command line processor and the result of submitting a command for the list of active databases.

Example 5-4 Activating the command line processor and submitting a command

C:\Program Files\Tivoli\TSM\db2\BIN>db2(c) Copyright IBM Corporation 1993,2007Command Line Processor for DB2 Client 9.5.2

You can issue database manager commands and SQL statements from the commandprompt. For example: db2 => connect to sample db2 => bind sample.bnd

For general help, type: ?.For command help, type: ? command, where command can bethe first few keywords of a database manager command. For example: ? CATALOG DATABASE for help on the CATALOG DATABASE command ? CATALOG for help on all of the CATALOG commands.

To exit db2 interactive mode, type QUIT at the command prompt. Outsideinteractive mode, all commands must be prefixed with 'db2'.To list the current command option settings, type LIST COMMAND OPTIONS.

For more detailed help, refer to the Online Reference Manual.


db2 => list active databases

Active Databases

Database name = TSMDB1Applications connected currently = 5Database path = G:\SERVER1\NODE0000\SQL00001\

Before you can submit commands against a Tivoli Storage Manager database, you need to tell the command line processor to establish a connection with the database by issuing the db2 connect command; see Example 5-5. After completing your task, submit the db2 connect reset command to free up resources.

Note that for the db2 select command to work, the fully qualified name in the form schema.table-name, in this case tsmdb1.nodes, must be used. An alias for the table cannot be used in place of the actual table. The schema is the user name under which the table or view was created.

Example 5-5 DB2: connect to database command

db2 => select nodename, platform from tsmdb1.nodesSQL1024N A database connection does not exist. SQLSTATE=08003

db2 => connect to tsmdb1

Database Connection Information

Database server = DB2/NT 9.5.2 SQL authorization ID = ADMINIST... Local database alias = TSMDB1

db2 => select nodename, platform from tsmdb1.nodes

NODENAME PLATFORM

-------------------------------------------------------------- -----------------OLDSKOOL WinNT

db2 => connect resetDB20000I The SQL command completed successfully.

You can use the command line processor to get detailed explanations of the reported SQLCODE or SQLSTATE. We use the SQL1024N and SQLSTATE=08003 from the previous example with Example 5-6. The user response reported confirms that we had to connect to the database.

Example 5-6 DB2: SQLCODE and SQLSTATE explained

db2 => ? SQL1024N

SQL1024N A database connection does not exist.

Explanation:

There is no connection to a database. Other SQL statements cannot beprocessed unless an SQL CONNECT was previously executed.


The command cannot be processed.

User response:

If the error occurred when disconnecting from the database, continueprocessing. If the error occurred on another SQL statement, issue an SQLCONNECT statement and resubmit the command or statement.

sqlcode: -1024

sqlstate: 08003

db2 => ? 08003

SQLSTATE 08003: The connection does not exist.

To verify the current database configuration, the db2 get db cfg command becomes helpful. You can familiarize with the result returned by reviewing Example 5-7. We highlighted some of the configurables that you should already know about.

Example 5-7 DB2: get db cfg command

db2 => get db cfg

Database Configuration for Database

Database configuration release level = 0x0c00 Database release level = 0x0c00

Database territory = C Database code page = 819 Database code set = ISO8859-1 Database country/region code = 1 Database collating sequence = IDENTITY Alternate collating sequence (ALT_COLLATE) = Number compatibility = OFF Varchar2 compatibility = OFF Database page size = 16384

Dynamic SQL Query management (DYN_QUERY_MGMT) = DISABLE

Discovery support for this database (DISCOVER_DB) = ENABLE

Restrict access = YES Default query optimization class (DFT_QUERYOPT) = 5 Degree of parallelism (DFT_DEGREE) = 1 Continue upon arithmetic exceptions (DFT_SQLMATHWARN) = NO Default refresh age (DFT_REFRESH_AGE) = 0 Default maintained table types for opt (DFT_MTTB_TYPES) = SYSTEM Number of frequent values retained (NUM_FREQVALUES) = 10 Number of quantiles retained (NUM_QUANTILES) = 20

Decimal floating point rounding mode (DECFLT_ROUNDING) = ROUND_HALF_EVEN

Backup pending = NO

Database is consistent = NO


Rollforward pending = NO Restore pending = NO

Multi-page file allocation enabled = YES

Log retain for recovery status = NO User exit for logging status = YES

Self tuning memory (SELF_TUNING_MEM) = ON Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC Database memory threshold (DB_MEM_THRESH) = 10 Max storage for lock list (4KB) (LOCKLIST) = AUTOMATIC Percent. of lock lists per application (MAXLOCKS) = AUTOMATIC Package cache size (4KB) (PCKCACHESZ) = AUTOMATIC Sort heap thres for shared sorts (4KB) (SHEAPTHRES_SHR) = AUTOMATIC Sort list heap (4KB) (SORTHEAP) = AUTOMATIC

Database heap (4KB) (DBHEAP) = AUTOMATIC Catalog cache size (4KB) (CATALOGCACHE_SZ) = 260 Log buffer size (4KB) (LOGBUFSZ) = 98 Utilities heap size (4KB) (UTIL_HEAP_SZ) = 48371 Buffer pool size (pages) (BUFFPAGE) = 250 SQL statement heap (4KB) (STMTHEAP) = AUTOMATIC Default application heap (4KB) (APPLHEAPSZ) = AUTOMATIC Application Memory Size (4KB) (APPL_MEMORY) = AUTOMATIC Statistics heap size (4KB) (STAT_HEAP_SZ) = AUTOMATIC

Interval for checking deadlock (ms) (DLCHKTIME) = 10000 Lock timeout (sec) (LOCKTIMEOUT) = -1

Changed pages threshold (CHNGPGS_THRESH) = 80 Number of asynchronous page cleaners (NUM_IOCLEANERS) = AUTOMATIC Number of I/O servers (NUM_IOSERVERS) = AUTOMATIC Index sort flag (INDEXSORT) = YES Sequential detect flag (SEQDETECT) = YES Default prefetch size (pages) (DFT_PREFETCH_SZ) = AUTOMATIC

Track modified pages (TRACKMOD) = ON

Default number of containers = 10 Default tablespace extentsize (pages) (DFT_EXTENT_SZ) = 32

Max number of active applications (MAXAPPLS) = AUTOMATIC Average number of active applications (AVG_APPLS) = AUTOMATIC Max DB files open per application (MAXFILOP) = 32768

Log file size (4KB) (LOGFILSIZ) = 131072 Number of primary log files (LOGPRIMARY) = 4 Number of secondary log files (LOGSECOND) = 0 Changed path to log files (NEWLOGPATH) = Path to log files = g:\tsm\server1\activelog\ Overflow log path (OVERFLOWLOGPATH) = s:\tsm\server1\archivelog\RstDbLog\ Mirror log path (MIRRORLOGPATH) = First active log file = S0000032.LOG Block log on disk full (BLK_LOG_DSK_FUL) = NO Percent max primary log space by transaction (MAX_LOG) = 90 Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 3


Group commit count (MINCOMMIT) = 1 Percent log file reclaimed before soft chckpt (SOFTMAX) = 100 Log retain for recovery enabled (LOGRETAIN) = OFF User exit for logging enabled (USEREXIT) = OFF

HADR database role = STANDARD HADR local host name (HADR_LOCAL_HOST) = HADR local service name (HADR_LOCAL_SVC) = HADR remote host name (HADR_REMOTE_HOST) = HADR remote service name (HADR_REMOTE_SVC) = HADR instance name of remote server (HADR_REMOTE_INST) = HADR timeout value (HADR_TIMEOUT) = 120 HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 0

First log archive method (LOGARCHMETH1) = DISK:g:\tsm\server1\archivelog\archmeth1\ Options for logarchmeth1 (LOGARCHOPT1) = Second log archive method (LOGARCHMETH2) = OFF Options for logarchmeth2 (LOGARCHOPT2) = Failover log archive path (FAILARCHPATH) = t:\tsm\server1\archivelog\failarch\ Number of log archive retries on error (NUMARCHRETRY) = 5 Log archive retry Delay (secs) (ARCHRETRYDELAY) = 300 Vendor options (VENDOROPT) =

Auto restart enabled (AUTORESTART) = ON Index re-creation time and redo index build (INDEXREC) = SYSTEM (RESTART) Log pages during index build (LOGINDEXBUILD) = OFF Default number of loadrec sessions (DFT_LOADREC_SES) = 1 Number of database backups to retain (NUM_DB_BACKUPS) = 2 Recovery history retention (days) (REC_HIS_RETENTN) = 0 Auto deletion of recovery objects (AUTO_DEL_REC_OBJ) = ON

TSM management class (TSM_MGMTCLASS) = TSM node name (TSM_NODENAME) = TSM owner (TSM_OWNER) = TSM password (TSM_PASSWORD) =

Automatic maintenance (AUTO_MAINT) = ON Automatic database backup (AUTO_DB_BACKUP) = OFF Automatic table maintenance (AUTO_TBL_MAINT) = ON Automatic runstats (AUTO_RUNSTATS) = OFF Automatic statement statistics (AUTO_STMT_STATS) = OFF Automatic statistics profiling (AUTO_STATS_PROF) = OFF Automatic profile updates (AUTO_PROF_UPD) = OFF Automatic reorganization (AUTO_REORG) = ON

Enable XML Character operations (ENABLE_XMLCHAR) = YES WLM Collection Interval (minutes) (WLM_COLLECT_INT) = 0

Use the db2 list db directory command to list the contents of the system database directory. If you specify an optional path, the contents of the local database directory are listed.

Example 5-8 DB2: list db directory command

db2 => list db directory

System Database Directory


Number of entries in the directory = 1

Database 1 entry:

Database alias = TSMDB1 Database name = TSMDB1 Local database directory = G: Database release level = c.00 Comment = Directory entry type = Indirect Catalog database partition number = 0 Alternate server hostname = Alternate server port number =

As shown in Example 5-9, you can use the db2 get instance command to verify the current instance. If you need a list of available instances, see “db2ilist: List instances command” on page 604.

Example 5-9 db2: get instance command

db2 => get instance

The current database manager instance is: SERVER1

Use the db2 describe table command to list details on a specific table. As shown in Example 5-10, the command lists the following information about each column:

� Column name� Type schema� Type name� Length� ScaleNulls (yes/no)

Example 5-10 DB2: describe table command

db2 => describe table tsmdb1.activity_log

Data type ColumnColumn name schema Data type name Length Scale Nulls------------------------------- --------- ------------------- ---------- ----- ------DATETIME SYSIBM TIMESTAMP 10 0 NoUNIQUE SYSIBM INTEGER 4 0 NoMESSAGENUM SYSIBM INTEGER 4 0 NoMESSAGE SYSIBM VARCHAR 2001 0 NoORIGINATOR SYSIBM INTEGER 4 0 NoSESSIONID SYSIBM INTEGER 4 0 YesSEVERITY SYSIBM SMALLINT 2 0 YesNODENAME SYSIBM VARCHAR 65 0 YesOWNERNAME SYSIBM VARCHAR 65 0 YesSCHEDNAME SYSIBM VARCHAR 31 0 YesDOMAINNAME SYSIBM VARCHAR 31 0 YesSERVERNAME SYSIBM VARCHAR 65 0 YesSESSIONTOKEN SYSIBM INTEGER 4 0 YesPROCESSTOKEN SYSIBM INTEGER 4 0 Yes

14 record(s) selected.


DB2 system commandsOn Linux and UNIX operating systems, the DB2 system commands are located in the DB2DIR/instance directory, where DB2DIR is the instance directory where the DB2 copy is installed. On Windows operating systems, the DB2 system commands are located under the DB2PATH\bin directory, where DB2PATH represents the installation location where the current version of the DB2 database system is installed.

You can use DB2 profile registry command, db2set, to display, set, or remove DB2 profile variables. db2set is an external environment registry command that supports local and remote administration, by the DB2 Administration Server, of DB2's environment variables stored in the DB2 profile registry.

In Example 5-11 you can see how to use the command to query the current settings.

Example 5-11 DB2: db2set system command

C:\Program Files\Tivoli\TSM\db2\BIN>db2set -all[e] DB2PATH=C:\Program Files\Tivoli\TSM\db2[i] DB2_SKIPINSERTED=ON[i] DB2_KEEPTABLELOCK=ON[i] DB2_EVALUNCOMMITTED=ON[i] DB2_VENDOR_INI=g:\progra~1\tivoli\tsm\server1\tsmdbmgr.env[i] DB2_SKIPDELETED=ON[i] DB2INSTPROF=C:\Documents and Settings\All Users\Application Data\IBM\DB2\DB2TSM1[i] DB2_PARALLEL_IO=*[g] DB2_EXTSECURITY=YES[g] DB2SYSTEM=GALLIUM[g] DB2PATH=C:\Program Files\Tivoli\TSM\db2[g] DB2INSTDEF=SERVER1

To query DB2 for the current code release level, use the db2level command (Example 5-12).

Example 5-12 DB2: db2level system command

C:\Program Files\Tivoli\TSM\db2\BIN>db2levelDB21085I Instance "SERVER1" uses "32" bits and DB2 code release "SQL09052"with level identifier "03030107".Informational tokens are "DB2 v9.5.201.3237", "special_21101", "WR21421_21101", and Fix Pack "2a".Product is installed at "C:\PROGRA~1\Tivoli\TSM\db2" with DB2 Copy Name "DB2TSM1".

To query DB2 for the current code release level, use the db2level command as shown in Example 5-13.

Example 5-13 DB2: db2level system command

C:\Program Files\Tivoli\TSM\db2\BIN>db2licm -lProduct name: "DB2 Enterprise Server Edition"License type: "Restricted"Expiry date: "Permanent"Product identifier: "db2ese"Version information: "9.5"

You can use the db2start and db2stop commands to start and stop the DB2 database manager, however, the preferred method to stop is a halt command submitted by either the Tivoli Storage Manager command line or by an administrative user. Use these commands only if directed so by IBM; if you try to stop or start DB2 while the Tivoli Storage Manager server is up and running an error will be reported.


Messages SQL1025N and SQL1026N, as shown in Example 5-14, remind you not to submit the commands while the Tivoli Storage Manager server is up.

Example 5-14 DB2: dbstart and dbstop commands

C:\Program Files\Tivoli\TSM\db2\BIN>db2stopSQL1025N The database manager was not stopped because databases are still active.

C:\Program Files\Tivoli\TSM\db2\BIN>db2startSQL1026N The database manager is already active.

Appendix B, “DB2 and SQL commands” on page 597 lists additional DB2 and DB2 system commands that you will find to be useful.

If you are interested in more information about the CLP, refer to DB2 Basics: Getting to know the DB2 UDB command line processor, at:

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0503melnyk/

5.3.2 DB2 Control Center

You can use the DB2 Control Center as a graphical interface to manage DB2 instances and database objects.

To open the DB2 Control Center:

� In Windows, click Start → Programs → IBM DB2 → General Administration Tools → Control Center.

� In Linux, open the IBM DB2 folder on the desktop and click Control Center.

By default, the Tivoli Storage Manager instance is not configured for access by the DB2 Control Center. In the following figures we explain how to set up the DB2 Control Center so you can act on the database.

Figure 5-5 shows the initialization panel presented to you with the invocation of the DB2 Control Center.

Figure 5-5 DB2 Control Center: Initializing


http://www.ibm.com/developerworks/db2/library/techarticle/dm-0503melnyk/

Next you are asked to specify the DB2 Control Center view type. Select the Advanced view type, and click OK (Figure 5-6).

Figure 5-6 DB2 Control Center: Control Center View

The DB2 Control Center opens in the object view. You can use the object tree to display and work with system and database objects.

The object tree displays the relation between objects in a hierarchy. You expand the object tree down from a particular object, the objects that reside, or are contained, in that object are displayed underneath.

To invoke actions on an object in the object tree, right-click to open a pop-up menu of available actions. Then select a menu choice. A window or notebook opens to guide you through the steps required to complete the action (Figure 5-7). You will see examples later.

Figure 5-7 DB2 Control Center: expand All Databases


If, from a fresh installation, you try to expand All Databases, as shown in Figure 5-7, the expansion selector (+) disappears. No database is configured to be accessible by the DB2 Control Center so far.

Next you press the expansion selector (+) to expand All Systems, see Figure 5-8.

Figure 5-8 DB2 Control Center: expand All Systems

At this point, the local system Idaho is the only system known to the DB2 Control Center. You press the expansion selector (+) to expand the IDAHO system branch (Figure 5-9).


Figure 5-9 DB2 Control Center: system IDAHO

Next you press the expansion selector (+) to expand the IDAHO system → Instances branch (Figure 5-10).

Figure 5-10 DB2 Control Center: IDAHO instances


The DB2 Control Center expands the instances branch, the default DB2TSM is shown. The DB2TSM instance is a dummy instance created during the installation of the Tivoli Storage manager product. DB2 makes it the default instance, then. If you open a command window, or start up the DB2 Control Center, this is the instance that is going to be acted on. What makes it the default instance is the fact that the DB2INSTANCE environment variable is set in your user profile, and it points to this, the DB2TSM instance (Figure 5-11).

Figure 5-11 DB2 Control Center: IDAHO DB2TSM instance

Note: Future versions of the product might no longer create the dummy DB2TSM instance.


If you try to expand the DB2TSM databases, as shown in Figure 5-12 and Figure 5-13, the expansion selector (+) just disappears. No database is configured for the dummy instance.

Figure 5-12 DB2 Control Center: expand DB2TSM Databases

Figure 5-13 DB2 Control Center: DB2TSM expansion selector disappears


Now you start adding the Tivoli Storage Manager server instance to the DB2 Control Center. Select the IDAHO Instances branch as shown in Figure 5-14.

Figure 5-14 DB2 Control Center: IDAHO Instances branch selected


Right-click the Instances branch, then select Add from the action options as shown in Figure 5-15.

Figure 5-15 DB2 Control Center: IDAHO Instances branch action options

The Add Instance window allows you to make the Tivoli Storage Manager server instance available to the DB2 Control center. As shown in Figure 5-16, just press Discover.

Figure 5-16 DB2 Control Center: IDAHO add instance


The Discovery Search window allows you to select from detected instances. You select the SERVER1 instance and click OK (Figure 5-17).

Figure 5-17 DB2 Control Center: instance discovery search result

Figure 5-18 shows that next you are prompted for an Instance Node Name. A unique nickname is required.

Figure 5-18 DB2 Control Center: Instance Node Name infopop


In Figure 5-19, specify IDAHO_S1 as the instance node name, and click Apply to continue.

Figure 5-19 DB2 Control Center: specify Instance Node Name

Next click the new IDAHO_S1 (SERVER1) instance you just created as shown in Figure 5-20.

Figure 5-20 DB2 Control Center: IDAHO_S1 instance


The Databases branch for IDAHO_S1 (SERVER1) is displayed (see Figure 5-21). If you try to expand that, again the expansion selector (+) disappears.

Figure 5-21 DB2 Control Center: IDAHO_S1 Databases branch


Right-click the Databases branch for action options, then select Add as shown in Figure 5-22.

Figure 5-22 DB2 Control Center: IDAHO_S1 add databases

Again you can click Discover, this time to search for available databases as shown in Figure 5-23.

Figure 5-23 DB2 Control Center: discover databases


From the database discovery search window, select the Tivoli Storage Manager database, TSMDB1, and click OK to continue (see Figure 5-24).

Figure 5-24 DB2 Control Center: TSMDB1 database

On the Add Database window, you can specify an Alias and an additional Comment. In our example you accept the details and click Apply (see Figure 5-25).

Figure 5-25 DB2 Control Center: add TSMDB1 database


By default, the DB2 Control Center tries to search additional databases. Click Cancel to return the DB2 Control Center object view (see Figure 5-26).

Figure 5-26 DB2 Control Center: cancel search for additional databases

At this point you have completed the task. Instance IDAHO_S1 and the database TSMDB1 are accessible through the DB2 Control Center (see Figure 5-27).

Figure 5-27 DB2 Control Center: TSMDB1 configured for instance IDAHO_S1

You can also manually make the database and the instance available to the DB2 ControlCenter. What the DB2 Control Center actually does, when you add the server instance as just described, is to define it as a remote node/instance in the local, default instance using a command as shown here:

CATALOG LOCAL NODE node-name INSTANCE tsm-instance-name


When you add the database in the DB2 Control Center, it catalogs it as a remote database on that remote node/instance, using a command similar to this:

CATALOG DATABASE TSMDB1 AS alias-name ON node-name

The effect of both of these commands is that the new Tivoli Storage Manager instance and the new database are both cataloged in the local, default instance. For an example of this approach being documented, see “Client ODBC configuration” on page 583.

Alternatively, you can set the db2instance environment variable and then invoke the DB2 Control Center with the db2cc command as shown in Example 5-15.

Example 5-15 Setting the db2instance environment variable

C:\Program Files\Tivoli\TSM\db2\BIN>set db2instance=SERVER1

C:\Program Files\Tivoli\TSM\db2\BIN>db2cc

5.4 Database maintenance

Now that you have configured your database, we want to review the database maintenance processes. The backup command still is BACKUP DB, but under the covers, everything has changed. In this section we discuss the details on the backup API configuration for use by the BACKUP DB and RESTORE DB commands.

5.4.1 Backing up your database

Tivoli Storage Manager client API now is used by the server backup and restore database commands. BACKUP DB or RESTORE DB tells DB2 to back up or restore the Tivoli Storage Manager database to the server over the client API as illustrated in Figure 5-28. While DB2 already knows how to back itself up to the server, the advantage of this design is that you can use disk or tape devices already controlled by the Tivoli Storage Manager server. There is no need to reserve devices dedicated only to database backup.

The key benefits achieved are:

� Use of existing server capabilities for volume management.

� Transparency to volume history, devconfig, DELETE VOLHIST, and so on.

� Use of existing server capabilities for offsite media management such as MOVE DRMEDIA, PREPARE and so on.


Figure 5-28 V6.1 database backup process flow

The first time you will observe a server database backup being performed is right after installation. You will see the messages reported in Example 5-16.

Example 5-16 ANR2976I and ANR2974I

ANR4726I The ICC support module has been loaded.ANR0152I Database manager successfully started.ANR0152I Database manager successfully started.ANR1380I The buffer pool monitor switch is enabled.ANR1004I Server formatting complete, database ready for loading.ANR0369I Stopping the database manager because of a server shutdown.ANR2976I Offline DB backup for database TSMDB1 started.ANR2974I Offline DB backup for database TSMDB1 completed successfully.

Manual database backupWhile the ANR2974I message reported in Example 5-16 might imply to you that everything is already set up for a successful database backup, at this point the offline backup is required by DB2 to switch from circular logging to archive logging. The offline backup performed on each dsmserv [load]format command uses the archive log directory to hold the backup data.

This initial backup is required by DB2 in order for Tivoli Storage Manager to set the recovery log processing mode to ROLLFORWARD. At this point, this database backup only contains the server schema (DDL). This database backup is subsequently deleted because it only contains the server schema definitions that can be recreated by Tivoli Storage Manager anyway.

V6 DB Backup Process Flow

Volhist

TSMDB2

Database

TSMServer

Sequential Data Stream(Disk Devc or Tape)

1

2

3

4

1

2

3

4

Initiate database backup

Intercept inbound session from DB2

Stream backup to seq. datastream

Add volume to volume history

TSM API, node$$_TSMDBMGR_$$


After completing the installation and configuration of the server, we recommend that a FULL database backup be performed. This database backup and any subsequent database backups will be tracked in the server volume history, as expected, and used as part of the server disaster recovery manager (DRM) processing.

Configuring for manual database backupsNow we still need to complete the configuration for a successful database backup. Example 5-17 shows the error message reported without any configuration being done if you submit the backup command, assumed that you have a file device class already configured.

Example 5-17 ANR2590E reported

tsm: TIRAMISU>backup db devc=fileANR2590E BACKUP DB failed - SET DBRECOVERY command has not been issued.

So we submit the SET DBRECOVERY command. See Example 5-18 for the results.

Example 5-18 SET DBRECOVERY command.

tsm: TIRAMISU>set dbrecovery fileANR2782I SET DBRECOVERY completed successfully and device class for automaticDB backup is set to FILE.

You use the SET DBRECOVERY command to specify the device class to be used for full automatic backups. You can verify the current setting with the QUERY DB FORMAT=DETAIL command as shown in Example 5-19.

Example 5-19 Query the database and verify DBRECOVERY setting

TSM:TIRAMISU>q db f=dANR2017I Administrator SERVER_CONSOLE issued command: QUERY DB f=d

Database Name: TSMDB1Total Size of File System (MB): 59,389 Space Used by Database(MB): 448 Free Space Available (MB): 27,231 Page Size(Bytes): Total Pages: 32,772 Usable Pages: 32,636 Used Pages: 23,740 Free Pages: 8,896 Buffer Pool Hit Ratio: 97.4 Total Buffer Requests: 53,137 Sort Overflows: 0 Lock Escalation: 0 Package Cache Hit Ratio: 68.5 Last Database Reorganization: Full Device Class Name: FILE Incrementals Since Last Full: 1Last Complete Backup Date/Time: 06/03/2009 09:19:32

As you can see in Example 5-19, the output returned by the QUERY DATABASE command has changed, Table 5-6 gives you the details.


Table 5-6 QUERY DATABASE description

Field Description

Database Name The name of the database.

Total Size of File System (MB) Total space in MB in the current storage location.

Windows: Total space on the drive where the directory is located.

UNIX and Linux: Total space in the file system where the path is located.

Space Used by Database(MB) Space in MB currently allocated and in use in the current storage location.

Free Space Available (MB) Space in MB not in use but available in the database.

Windows: Space remaining on the drive where the directory is located.

UNIX and Linux: Space remaining in the file system where the path is located.

Page Size(Bytes) The database page size (in bytes).

Total Pages Total number of pages in tablespace.

Usable Pages The number of usable pages in tablespace.

Used Pages The number of used pages in tablespace

Free Pages Number of pages not in use in tablespace.

Buffer Pool Hit Ratio The total hit ratio percent.The ratio of physical reads to logical reads gives the hit ratio for the buffer pool. The lower the hit ratio, the more the data is being read from disk rather than the cached buffer pool which can be a more costly operation.

Total Buffer Requests The total number of buffer pool data logical reads and index logical reads since the last time the database was started or since the database monitor was reset.

Sort Overflows The total number of sorts that ran out of the sort heap and might have required disk space for temporary storage.

Lock Escalation The number of times that locks have been escalated from several row locks to a table lock.

Package Cache Hit Ratio A percentage indicating how well the package cache is helping to avoid reloading packages and sections for static SQL from the system catalogs. It also indicates how well the package cache is helping to avoid recompiling dynamic SQL statements. A high ratio indicates it is successful in avoiding these activities.

Last Database Reorganization The last time that the database manager performed an automatic reorganization activity.

Full Device Class Name The name of the device class this is used for full database backups.

Incrementals Since Last Full The number of incremental backups that were performed since the last full backup.

Last Complete Backup Date/Time

The date and time of the last full backup.


Completing the SET DBRECOVERY was easy, now we can start the database backup again (see Example 5-20).

Example 5-20 Backup DB still terminates

TSM:TIRAMISU>backup db devc=fileANR2017I Administrator SERVER_CONSOLE issued command: BACKUP DB devc=fileANR4559I Backup DB is in progress.ANR0984I Process 3 for DATABASE BACKUP started in the BACKGROUND at 12:23:14.ANR2281I Incremental database backup started as process 3.TSM:TIRAMISU>ANR2968E Database backup terminated. DB2 sqlcode: -2033. DB2 sqlerrmc: 406.ANR0985I Process 3 for DATABASE BACKUP running in the BACKGROUND completed withcompletion state FAILURE at 12:23:15.

Example 5-20 documents how the backup still fails. When a BACKUP DB or RESTORE DB command fails with a message indicating the DB2 SQLCODE or the SQLERRMC with return codes, you can get a description of the DB2 SQLCODE by completing the following procedures:

1. On a Windows operating system, click Start → All Programs → IBM DB2 → <DB2 Instance> → Command Line Tools → Command Line Processor to open a DB2 command-line interface. For all other supported platforms, log on to the DB2 instance ID and open a shell window, then issue the command DB2.

2. Enter the SQLCODE. For example, if the DB2 SQLCODE is -2033, issue the command as documented in Example 5-21.

Example 5-21 Retrieve DB2 SQLCODE descriptions

db2 => ? sql2033

SQL2033N An error occurred while accessing TSM during the processing of a database utility. TSM reason code: "<reason-code>".

Explanation:

Some common TSM reason codes are:

106 The specified file is being used by another process. You tried to read from or write to a file that is currently being used by another process.

137 TSM authentication failure.

168 Password file is needed, but user is not root. This message is often generated when the DSMI_DIR environment variable points to a directory that contains a 32-bit version of the dsmtca program, yet the DB2 instance is 64-bit, or vice-versa.

400 An invalid option was specified on the OPTIONS parameter passed to TSM.

406 TSM Cannot find or read its options file.

The utility stops processing.


User response:

Responses for common TSM problems are:

106 Ensure that you specified the correct file or directory name, correct the permissions, or specify a new location.

137 If the TSM parameter PASSWORDACCESS is set to GENERATE, ensure that the system administrator has used the dsmapipw utility to set the password. If PASSWORDACCESS is set to PROMPT, ensure that the TSM_NODENAME and TSM_PASSWORD database configuration parameters have been set correctly.

168 Ensure that DSMI_DIR points to a directory containing the correct version of db2tca, restart the instance, and execute the command again.

400 Ensure that the OPTIONS parameter specified on the BACKUP or RESTORE command is correct.

406 Ensure that the DSMI_CONFIG environment variable points to a valid TSM options file. Ensure that the instance owner has read access to the dsm.opt file. Ensure that the DSMI_CONFIG environment variable is set in the db2profile.

In general, the sqlcode -2033 errors are all setup-related errors. As we did not do any configuration for the database backup to work through the API, we have to do that now. If you use the Tivoli Storage Manager Server Instance Configuration wizard to create a server instance, configuration is done automatically. If you are configuring an instance manually, for the back up to work, you must meet the following requirements:

� Tivoli Storage Manager API is installed on server machine (done by COI install).

� Tivoli Storage Manager API has the correct client option settings.

� DSMI_DIR, DSMI_CONFIG, DSMI_LOG environment variables are set in DB2 instance process.

� DSMI_DIR, DSMI_CONFIG, DSMI_LOG point to the correct places:

– Api executables– Api configuration files– Api log file directory

� The correct password is set.

Here we guide you through a manual configuration, so first we need to resolve the DB2 SQLCODE -2033 SQLERRMC 406. SQL error message code 406 requires that the following issues be resolved:

� The DSMI_CONFIG environment variable points to a valid Tivoli Storage Manager options file.

� The instance owner has read access to the dsm.opt file.

� The DSMI_CONFIG environment variable is set in the db2profile.


The steps required to complete the task are as follows:

1. We create a file that we name tsmdbmgr.env in the instance directory with the content documented in Example 5-22.

Example 5-22 Content of tsmdbmgr.env

DSMI_CONFIG=g:\progra~1\tivoli\tsm\server1\tsmdbmgr.optDSMI_LOG=g:\progra~1\tivoli\tsm\server1

2. We set the DSMI_ api environment-variable configuration for the database instance. Open a DB2 command window, and on the Windows operating system, click Start → All Programs → IBM DB2 → <DB2 Instance> → Command Line Tools → Command Window. This will open a window in the DB2 install directory. From here you can submit the db2set command, as shown in Example 5-23.

Example 5-23 DB2 CLP: db2set command

C:\Program Files\Tivoli\TSM\db2\BIN>db2set -i server1 DB2_VENDOR_INI=g:\progra~1\tivoli\tsm\server1

To verify the current setting of the DB2_VENDOR_INI variable, you can submit the command as shown in Example 5-24.

Example 5-24 Verify DB2_VENDOR_INI setting

C:\Program Files\Tivoli\TSM\db2\BIN>db2set -i server1 DB2_VENDOR_INIg:\progra~1\tivoli\tsm\server1\tsmdbmgr.env

3. Now we create the tsmdbmgr.opt file in the \program files\tivoli\tsm\server1 directory with the contents shown in Example 5-25.

Example 5-25 tsmdbmgr.opt file

nodename $$_TSMDBMGR_$$ commmethod tcpip tcpserveraddr localhosttcpport 1500passwordaccess generateerrorlogname “g:\progra~1\tivoli\tsm\server1\tsmdbmgr_server1.log”

The $$_TSMDBMGR_$$ node is a special hidden node for the purpose of the database backup. You cannot query the node on the server using the QUERY NODE command.

4. Next we make the changes active to DB2. We use the command window as shown before and submit the following commands as shown in Example 5-26.

Example 5-26 Activating the DB2 changes

C:\Program Files\Tivoli\TSM\db2\BIN>SET DB2INSTANCE=server1

C:\Program Files\Tivoli\TSM\db2\BIN>db2stopSQL1064N DB2STOP processing was successful.

C:\Program Files\Tivoli\TSM\db2\BIN>db2startSQL1063N DB2START processing was successful.

It is important to stop and restart DB2 to activate the changes. Failing to do so will result in the backup not working later.


5. We set the correct password as shown in Example 5-27. If you are use to the dsmcutil command, note the slight difference: This is the dsmsutil command you find in the server installation directory.

The password, TSMDBMGR, is preset at the server and cannot be changed as the special node, $$_TSMDBMGR_$$. The password for this node does not expire!

Example 5-27 Update password for $$_TSMDBMGR_$$

C:\Documents and Settings\Administrator>set DSMI_CONFIG=g:\progra~1\tivoli\tsm\server1\tsmdbmgr.opt

C:\Documents and Settings\Administrator>"C:\Program Files\Tivoli\TSM\server\dsmsutil" UPDATEPW /NODE:$$_TSMDBMGR_$$ /PASSWORD:TSMDBMGR /VALIDATE:NO

TSM Windows NT Client Service Configuration UtilityCommand Line Interface - Version 6, Release 1, Level 0.0 1027FB(C) Copyright IBM Corporation, 1990, 2008, All Rights Reserved.Last Updated Oct 28 2008TSM Api Version 6.1.0

Command: Update Registry PasswordMachine: GALLIUM(Local Machine)

The Registry password for node $$_TSMDBMGR_$$ has been updated .

You can also use the dsmapipw command to propagate the password to the Tivoli Storage Manager Server as shown in Example 5-28. Change the directory to the servers db2\adsm directory, for example, to C:\Program Files\tivoli\TSM\db2\adsm, and then submit the command.

Example 5-28 Use dsmapipw to propagate the password to the server

C:\Program Files\tivoli\TSM\db2\adsm>set DSMI_CONFIG=g:\progra~1\tivoli\tsm\server1\tsmdbmgr.opt

C:\Program Files\tivoli\TSM\db2\adsm>dsmapipw

************************************************************** Tivoli Storage Manager ** API Version = 6.1.0 **************************************************************Enter your current password:TSMDBMGR

Enter your new password:TSMDBMGR

Enter your new password again:TSMDBMGR

Your new password has been accepted and updated.

6. Finally, we can submit the database backup, so let us try the backup database command again. Example 5-29 documents the results and shows that we have completed the task.


Example 5-29 The first manual backup

TSM:TIRAMISU>backup db devc=file type=fullANR2017I Administrator SERVER_CONSOLE issued command: BACKUP DB devc=filetype=fullANR4559I Backup DB is in progress.ANR0984I Process 10 for DATABASE BACKUP started in the BACKGROUND at 09:29:37.ANR2280I Full database backup started as process 10.TSM:TIRAMISU>ANR0406I Session 17 started for node $$_TSMDBMGR_$$ (DB2/NT) (Tcp/Ipgallium(4668)).ANR8340I FILE volume G:\TSM\SERVER1\FILECLASS\44132980.DBV mounted.ANR0511I Session 17 opened output volume G:\TSM\SERVER1\FILECLASS\44132980.DBV.ANR1360I Output volume G:\TSM\SERVER1\FILECLASS\44132980.DBV opened (sequencenumber 1).ANR1361I Output volume G:\TSM\SERVER1\FILECLASS\44132980.DBV closed.ANR0514I Session 17 closed volume G:\TSM\SERVER1\FILECLASS\44132980.DBV.ANR0403I Session 17 ended for node $$_TSMDBMGR_$$ (DB2/NT).ANR0406I Session 18 started for node $$_TSMDBMGR_$$ (DB2/NT) (Tcp/Ipgallium(4673)).ANR8340I FILE volume G:\TSM\SERVER1\FILECLASS\44133021.DBV mounted.ANR0511I Session 18 opened output volume G:\TSM\SERVER1\FILECLASS\44133021.DBV.ANR1360I Output volume G:\TSM\SERVER1\FILECLASS\44133021.DBV opened (sequencenumber 1).ANR1361I Output volume G:\TSM\SERVER1\FILECLASS\44133021.DBV closed.ANR0514I Session 18 closed volume G:\TSM\SERVER1\FILECLASS\44133021.DBV.ANR0403I Session 18 ended for node $$_TSMDBMGR_$$ (DB2/NT).ANR4550I Full database backup (process 10) completed.ANR0985I Process 10 for DATABASE BACKUP running in the BACKGROUND completedwith completion state SUCCESS at 09:30:23.

Note that the configuration for a UNIX server database backup through the API differs slightly from the example for the Windows platform that we went through here. If you want to configure for a different environment, refer to the chapter, Preparing the database manager for backup, available from the Information Center at:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.srv.install.doc/t_srv_prep_dbmgr.html

Remember the SET DBRECOVERY command that we submitted with Example 5-18 on page 87. If you submit the BACKUP DB command with a different device class, a warning message ANR4976W will be reported, reminding you about the DBRECOVERY default device class as shown in Example 5-30.

Example 5-30 ANR4976W, database backup to different device class

TSM:TIRAMISU>backup db type=full devc=testANR2017I Administrator SERVER_CONSOLE issued command: BACKUP DB type=fulldevc=testANR4976W The device class TEST is not the same as device class FILE defined forthe serverbackup node $$_TSMDBMGR_$$.ANR2280I Full database backup started as process 14.ANR4559I Backup DB is in progress.ANR0984I Process 13 for DATABASE BACKUP started in the BACKGROUND at 10:39:47.the serverbackup node $$_TSMDBMGR_$$.ANR2280I Full database backup started as process 13.



As we mentioned earlier, if you use the Tivoli Storage Manager Server Instance Configuration wizard to create a server instance, configuration is done automatically. By using the wizard, you can avoid some configuration steps that are complex when done manually. Start the wizard on the system where you installed the Tivoli Storage Manager Version 6.1 server. On a UNIX system, you can find the dsmifgx program in the Tivoli Storage Manager server’s bin directory; on a Windows system, you can double-click the dsmicfgx.exe program in the C:\Program Files\Tivoli\TSM\server directory.

SummaryYou do not need to submit DB2 commands to back up a Tivoli Storage Manager V6.1 database. You can still use the known backup commands for manual database backups, as you did with earlier versions. However, you need to configure the server to be able to back up through the API used by DB2 to complete the task.

Configuring the server for automatic database backupsNow that we completed the first backup, you might like to know how to restore the database. However, we skip this task for right now and will discuss it later. First we want to look at the configuration for automatic backups of the server database.

Backup methodologiesIf the Tivoli Storage Manager server database or the recovery log is unusable, the entire server is unavailable. If a database is lost and cannot be recovered, all of the data managed by that server is lost. If a storage pool volume is lost and cannot be recovered, the data on the volume is also lost.

To back up the database and storage pools regularly, you define administrative schedules. If you lose your database or storage pool volumes, you can use offline utilities provided by IBM Tivoli Storage Manager to restore your server and data.

With the proprietary database, it has been a widely used practice to configure for regular full backups followed by a sequence of incremental backups (Figure 5-25). The maximum number of incremental backups you can run between full backups is 32. Assuming that you scheduled for weekly full backups, the scenario would look like the one shown in Figure 5-29.

Figure 5-29 V5 style database backup schedule

Note: We recommend that you use the GUI post-install configuration, dsmicfgx, or dsmicfgx.exe, to configure the server for database backup. You can thus avoid some configuration steps that are complex when done manually.

V5 database backup

Sun

Full

Mon

Incr

Tue

Incr

Wed

Incr

Thu

Incr

Fri

Incr

Sat

Incr

Sun

Full


With the Tivoli Storage Manager V6.1 backup command, it might seem that nothing much has changed, because the following database backup methodologies are supported:

� Full backup:

– It specifies that you want to run a full backup of the Tivoli Storage Manager database.

– For devclass tape, at least one tape volume is used.

It contains the database backup and also active/archive logs since the last full backup.

– For devclass file, at least two volumes are used.

The first contains the database backup, the second contains active/archive logs since the last full backup.

– It clears the archive logs.

� Incremental backup:

– It specifies that you want to run an incremental backup of the Tivoli Storage Manager database. An incremental (or cumulative) backup image contains a copy of all database data that has changed since the last successful full backup operation was performed.

– For devclass tape, at least one volume is used.

It contains changed pages, plus initial database metadata.

– For devclass file, at least two volumes are used.

They contain changed pages, plus initial database metadata.

� Tivoli Storage Manager database snapshot:

– It specifies that you want to run a full snapshot database backup. The entire contents of a database are copied and a new snapshot database backup is created without interrupting the existing full and incremental backup series for the database.

– Snapshot database backups should be used in addition to full and incremental backups.

– For devclass tape, at least one tape volume is used.

It contains the DB backup and also active/archive logs since the last full backup.

– At least two volumes are used

The first contains the DB backup, the second contains active/archive logs since the last full backup.

� The following file device class volume naming conventions apply:

– DBV: Normal backup file device class volume.

– DSS: Snapshot backup file device class volume.

Now let us compare the V5 style database backup schedule with the same approach adapted to a Tivoli Storage Manager V6.1 server. Figure 5-30 shows how the space requirements rise with each incremental backup.


Figure 5-30 V6.1 style database backup schedule

In DB2 terms, the backup methodology introduced for the Tivoli Storage Manager server is an incremental cumulative backup. The incremental database now represents all database data that has changed since the most recent, successful, full backup operation. If you plan to restore to Wednesday’s backup, you only need Sunday’s full backup, plus the last incremental backup for Wednesday. If you want to complete the same task in V5, you need Sunday’s full backup and the incremental backup volumes from Monday, Tuesday and Wednesday.

If you are used to the methodology of weekly full database backups and in between incremental backups, however, you should notice the difference when staying with this approach:

� Only full backups allow for the deletion of archive log volumes.

� The incremental backups will not free archive log space, requiring more space in the archive log directories.

� The incremental database backups result in increased volume utilization to include the additional archive log information.

Scheduled automatic backupsImplementing a database backup methodology that would address all requirements out in the field is beyond the scope of this book. So here we describe how to configure regular database backups and combine those with triggered backups. It then is up to you as an administrator to monitor the activity log and adjust the scheduled backups to best meet your requirements.

You define the scheduled database backup as an administrative schedule as you are used to doing; see Example 5-31 for the exact command.

Example 5-31 Define a schedule for full database backup

TSM:TIRAMISU>define schedule db_daily_backup type=administrative cmd="backup db deviceclass=file type=full" starttime=10:00ANR2017I Administrator SERVER_CONSOLE issued command: DEFINE SCHEDULE db_daily_backup type=administrative cmd='backup db deviceclass=file type=full'starttime=10:00

Sun

Full

Mon

Incr

Tue

Incr

Wed

Incr

Thu

Incr

Fri

Incr

Sat

Incr

Sun

Full

V6 database backup


ANR2577I Schedule DB_DAILY_BACKUP defined.TSM:TIRAMISU>q sched db_daily_backup type=admin f=dANR2017I Administrator SERVER_CONSOLE issued command: QUERY SCHEDULEdb_daily_backup type=admin f=d

Schedule Name: DB_DAILY_BACKUP Description: Command: backup db deviceclass=file type=full Priority: 5 Start Date/Time: 06/12/2009 10:00:00 Duration: 1 Hour(s) Schedule Style: Classic Period: 1 Day(s) Day of Week: Any Month: Day of Month: Week of Month: Expiration: Active?: NoLast Update by (administrator): SERVER_CONSOLE Last Update Date/Time: 06/12/2009 18:55:45 Managing profile:

With the foregoing setup, we protect the server by running database backups at least once per day. Even more frequent backups might be needed if the server handles high numbers of client transactions. You need to monitor the activity log for triggered database backups starting and messages indicating that a database backup is required; for this, see Table 5-9 on page 100. The observation will allow for proper scheduling. A best practice is to schedule regular backups of the server database, and verify that they occur as scheduled. We do this in Example 5-32.

Example 5-32 Verification that scheduled database backups are working

ANR2750I Starting scheduled command db_daily_backup ( backup db deviceclass=file type=full ).ANR2017I Administrator SERVER_CONSOLE issued command: BACKUP DB type=fulldevc=fileANR0984I Process 2 for DATABASE BACKUP started in the BACKGROUND at 14:51:29.ANR2280I Full database backup started as process 2.TSM:TIRAMISU>ANR0406I Session 1 started for node $$_TSMDBMGR_$$ (DB2/NT) (Tcp/Ip gallium(32-23)).ANR8340I FILE volume G:\TSM\SERVER1\FILECLASS\44843491.DBV mounted.ANR0511I Session 1 opened output volume G:\TSM\SERVER1\FILECLASS\44843491.DBV.ANR1360I Output volume G:\TSM\SERVER1\FILECLASS\44843491.DBV opened (sequencenumber 1).ANR1361I Output volume G:\TSM\SERVER1\FILECLASS\44843491.DBV closed.ANR0514I Session 1 closed volume G:\TSM\SERVER1\FILECLASS\44843491.DBV.ANR0403I Session 1 ended for node $$_TSMDBMGR_$$ (DB2/NT).ANR0406I Session 2 started for node $$_TSMDBMGR_$$ (DB2/NT) (Tcp/Ip gallium(32-49)).ANR8340I FILE volume G:\TSM\SERVER1\FILECLASS\44843516.DBV mounted.ANR0511I Session 2 opened output volume G:\TSM\SERVER1\FILECLASS\44843516.DBV.ANR1360I Output volume G:\TSM\SERVER1\FILECLASS\44843516.DBV opened (sequencenumber 1).


ANR1361I Output volume G:\TSM\SERVER1\FILECLASS\44843516.DBV closed.ANR0514I Session 2 closed volume G:\TSM\SERVER1\FILECLASS\44843516.DBV.ANR0403I Session 2 ended for node $$_TSMDBMGR_$$ (DB2/NT).ANR4550I Full database backup (process 2) completed.ANR0985I Process 2 for DATABASE BACKUP running in the BACKGROUND completed withcompletion state SUCCESS at 14:51:57.

Triggered automatic backupsWith the combination of automatic and triggered backups, you can develop a good idea of the schedule definitions that you need to implement.

With DB2 automatic backup enabled, DB2 can decide to perform database backups based on a number of different criteria or thresholds, including these:

� Has the minimum required number of full backups been performed?� Has the time interval between database backups been exceeded?� How much log space has been consumed since the last database backup?

After evaluating the DB2 automatic database backup capabilities, it was determined that the database backup processing is not consistent with the typical server administration model used by Tivoli Storage Manager.

Administrators used the DBBACKUPTRIGGER command to specify when Tivoli Storage Manager backs up the database. A backup occurred when the specified percentage of the assigned capacity of the recovery log was reached. Configuring the DBBACKUPTRIGGER is no longer required. There is a new approach to trigger database backups; the frequency and timing of the database backup are explicitly controlled by the Tivoli Storage Manager server itself.

Tivoli Storage Manager triggers full and incremental database backup as a result of the following criteria:

� Log space consumed since the last backup:

The DB2 API db2GetSnapshot() function is used to get the first (firstActiveLogFileNum) and the las active logfile number (lastActiveLogFileNum).

The logSpaceUsedSinceLastBackup is calculated by counting the number of log files used since the last backup (lastActiveLogFileNum - (firstActiveLogFileNum + 1)) and multiplying by the log file size (512).

If this value is greater than the maximum log size, the ACTIVELOGSIZE parameter configured with the [load]format command, a full database backup will be started. This represents the same trigger that would be used by automatic DB2 backup trigger: “How much log space has been consumed since the last database backup?”

The following message is reported when this condition is met:

ANR4531I: An automatic full database backup will be started. The last log number used is last log used and the first log number used is first log used. The log file size is log file size megabytes. The maximum log file size is maximum log file size megabytes.

� Log utilization ratio:

The DB2 API db2GetSnapshot() function is used to get totalActiveLogSpaceUsed and totalActiveLogSpaceAvailable.

The log utilization ratio is calculated with the following formula:

logUsedRatio = totalActiveLogSpaceUsed / ( totalActiveLogSpaceUsed + totalActiveLogSpaceAvailable )


If the logUsedRatio exceeds the predefined threshold of 80%, an automatic incremental backup will be triggered.

ANR4529I: An automatic full or incremental database backup will be started. The active log space used is active log space used megabytes, and the active log space available is active log space available megabytes. The ratio, ratio, exceeds the threshold 0.80.

Use the QUERY LOG F=D command to monitor the log usage, the output changed from earlier versions. For details, see Example 5-33. If the server is not running, you can use the DSMSERV DISPLAY LOG utility. Refer to Example 5-40 on page 107 for details.

Example 5-33 QUERY LOG command

TSM:TIRAMISU>q log f=dANR2017I Administrator SERVER_CONSOLE issued command: QUERY LOG f=d

Total Space(MB): 2,048 Used Space(MB): 0.28 Free Space(MB): 2,039.72 Active Log Directory: d:\tsm\server1\activelog Mirror Log Directory:Archive Failover Log Directory: Archive Log Directory: d:\tsm\server1\archivelog

Note that the above configuration is not recommended; the active log and the archive log, as well as the database directories, should not be configured to a single disk. Table 5-7 explains the new fields for the QUERY LOG F=D command.

Table 5-7 QUERY LOG command

For triggered backups, if you are used to the DBBACKUPTRIGGER option, be aware that this configurable is no longer available. Table 5-8 compares the Tivoli Storage Manager V5 database backup trigger options with the new database trigger functionality.

Field Description

Total Space(MB) Specifies the maximum size in megabytes of the active log.

Used Space(MB) Specifies the total amount of active log space that is used in the database in megabytes.

Free Space(MB) Specifies the amount of active log space in the database that is not being used by uncommitted transactions in megabytes.

Active Log Directory Specifies the location where active log files are stored. When you change the active log directory, the server moves all archived logs to the archive log directory and all active logs to a new active log directory.

Mirror Log Directory Specifies the location where the mirror for the active log is maintained.

Archive Failover Log Directory Specifies the location into which the server saves archive logs if the logs cannot be archived to the archive log directory.

Archive Log Directory Specifies the location into which the server can archive a log file after all the transactions that are represented in that log file are completed.


Table 5-8 Comparison of trigger attributes

Messages indicating that a database backup is requiredIn addition to the triggered backup related activity log messages, watch the server activity log for occurrences of the messages shown in Table 5-9. If you see any of these messages, you need to monitor the available space in the active log and archive log storage paths. You might need to run an additional database and adjust your database backup schedules.

Table 5-9 Database related messages requiring administrator attention

DBBACKUP trigger attribute

Attribute description V6.1 equivalent Comments

DEVCLASS Device class used for FULL database backups

Device class configured with the SET DBRECOVERY command.

V6.1 triggered backups use the device class specified with the SET DBRECOVERY command. This is essentially equivalent behavior to what was previously available in V5.x.

LOGFULLPct When log utilization reaches this percentage, an automatic database backup starts.

None If the log space used since the last backup exceeds the configured ACTIVELOGSIZE, a full database backup is triggered.

An incremental backup is triggered when the log utilization ratio exceeds 80%.

See Chapter , “Triggered automatic backups” on page 98 for details.

INCRDEVCLASS Device class used for triggered incremental backups.

None V6.1 triggered backups use the device class specified with the SET DBRECOVERY command.

NUMINCremental The number of incremental backups to perform before the next FULL must be performed.

None

MININTERVAL The minimum time to elapse between allowing triggered backups.

None V6.1 server checks every 10 minutes if a triggered backup is required.

MINLOGFREEpct Minimum percentage of log space that must be freed by the automatic backup before it will be performed.

None While the database backups with V6.1 do impact log utilization and the DB2 archival log operations, the differences in log management and overall log capacity mitigate this difference.

Message Reason for the message being issued

ANR0293I The server is performing an online reorganization for the table referenced in the message.

ANR0294I The online reorganization for the table referenced in the message has ended.

ANR0295I The active log space used exceeds the log utilization threshold.


Online table reorganization consumes log space. As a result of the log use because of database reorganization, a database backup might become necessary to manage the available active log space. Example 5-34 shows the messages being issued for the BF.Aggregated.Bitfiles and the Backup.Objects table.

Example 5-34 ANR0293I, ANR0294I:Indicators for database backup requirement

ANR0293I Reorganization for table BF.Aggregated.Bitfiles started...ANR0294I Reorganization for table BF.Aggregated.Bitfiles ended...ANR0293I Reorganization for table Backup.Objects started...ANR0294I Reorganization for table Backup.Objects ended.

Additional backup considerationsIt is essential to save your volume history file. Without it, you cannot restore your database later. To ensure the availability of volume history information, it is extremely important to take at least one of the following steps:

� Store at least one copy of the volume history file offsite or on a disk separate from the database.

� Store a printout of the file offsite.

� Store a copy of the file offsite with your database backups and device configuration file.

� Store a remote copy of the file, for example, on an NFS-mounted file system.

� Note: DRM saves a copy of the volume history file in its disaster recovery plan file.For DRM restore scenarios, see Chapter 6, “IBM Tivoli Storage Manager Disaster Recovery Manager” on page 121

The VOLUMEHISTORY server option lets you specify backup volume history files. Then, whenever the server updates volume information in the database, it also updates the same information in the backup files. If you try to back up a database without a valid VOLUMEHISTORY option configured to the dsmserv.opt file, the backup will fail with message ANR2639E as shown in Example 5-35.

Example 5-35 ANR2639E; VOLUMEHISTORY option not configured

TSM:TIRAMISU>backup db type=full devc=fileANR2017I Administrator SERVER_CONSOLE issued command: BACKUP DB type=full devc=fileANR2639E BACKUP DB failed - no files have been defined for storing sequential volume history information.

ANR0296Ia The space used in the log file system exceeds the threshold for log file system utilization.

ANR0297I The log space used since the last database backup exceeds the maximum log file size.

a. For some configurations, this message can be ignored. See the following Technote for details:http://www.ibm.com/support/docview.wss?uid=swg21380107

Message Reason for the message being issued



SummaryIn Tivoli Storage Manager V5.x, the log was circular. As such, the notion of how much log would be freed up by a database backup had significance because it implied that the log was healthy and the tail of the log could be moved up to free some amount of space based on the database backup.

With Tivoli Storage Manager V6, the log is no longer circular, so the need to free a specific amount of log space during a database backup is no longer significant. Database backup with Tivoli Storage Manager V6.1 is oriented more toward protecting the database than was previously the case.

While the V5 database backup triggers are no longer supported, Tivoli Storage Manager still triggers automatic backups. Depending on which trigger is met, a full or an incremental backup is executed.

5.4.2 Restoring the database

If a database is damaged or destroyed and a database backup and other files are available, the database can be restored. In addition to just preparing for a disaster, you can also use the restore process to distribute your database and or log volumes to different file systems available to your Tivoli Storage Manager server.

Figure 5-31 explains the new process flow for a restore of the Tivoli Storage Manager server database.

Figure 5-31 V6.1 database restore process flow

V6 DB Restore Process Flow

VolhistTSMDB2Database

TSMServer

Sequential Data Stream(Disk Devc or Tape)

2

3

4

1

2

3

4

Initiate DB2 restore

Intercept inbound session from DB2

1 Retrieve volume history information

TSM API, node$$_TSMDBMGR_$$

Initiate database restore


Three types of database restore operations are supported:

� Restoring the database to its most current state� Restoring the database to a point in time� Restoring the database from a snapshot

In this section we provide an example of a restore scenario and show which requirements to meet for a successful restore.

Restore prerequisitesTo restore your database, the following information is required:

� You must have copies of the volume history file and the device configuration file.

� You must have copies of, or you must be able to create, the server options file and the database and recovery log setup information (the output from detailed queries of your database and recovery log).

The server needs information from the volume history file. Volume history information is stored in the database, but during a database restore, it is not available from there. It is critical that you make a copy of your volume history file and save it. The file cannot be recreated.

The database volumes we created with the database backup from Example 5-29 on page 93 are listed by the volume history file as shown in Example 5-36.

Example 5-36 Volume history file content

********************************************************************************** * Sequential Volume Usage History* Updated 06/04/2009 09:30:23* *********************************************************************************Operation Date/Time: 2009/06/12 14:51:29 Volume Type: BACKUPFULL* Location for volume G:\TSM\SERVER1\FILECLASS\44843491.DBV is: '' Database Backup LLA: FULL_BACKUP.20090612145129.1 Database Backup HLA: \NODE0000\ Volume Name: "G:\TSM\SERVER1\FILECLASS\44843491.DBV" Backup Series: 5 Backup Op: 0 Volume Seq: 1 Device Class Name: FILE Database Backup ID: 0 , 3073 Database Backup Home Position: 0 Database Backup Total Data Bytes : 0 , 381800459 Database Backup Total Log Bytes: 0 , 13656075 Database Backup Log Block Number: -1 , -1 ************************************************** Operation Date/Time: 2009/06/12 14:51:29 Volume Type: BACKUPFULL* Location for volume G:\TSM\SERVER1\FILECLASS\44843516.DBV is: '' Database Backup LLA: FULL_BACKUP.20090612145129.2 Database Backup HLA: \NODE0000\ Volume Name: "G:\TSM\SERVER1\FILECLASS\44843516.DBV" Backup Series: 5


Backup Op: 0 Volume Seq: 2 Device Class Name: FILE Database Backup ID: 0 , 3074 Database Backup Home Position: 0 Database Backup Total Data Bytes : 0 , 381800459 Database Backup Total Log Bytes: 0 , 13656075 Database Backup Log Block Number: -1 , -1 **************************************************

There is new information in the volume history file, which is now needed for a restore of the database:

� Database Backup LLA:

This is provided by DB2 and used by the restore process to determine the DB2 backup time stamp.

� Database Backup Home Position:

This is the home position for the tape used by the restore processing to know where the database data starts. This is only valid for tape volumes. For file device class, it is 0.

� Database Backup Total Data Bytes:

This is the total number of DB data bytes in this database backup.

� Database Backup Total Log Bytes:

This is the total number of bytes for recovery log in this database backup.

� Database Backup Log Block Number:

This is the starting block number where the backup recovery log starts. This is only valid for tape volumes. For file device class, this is -1. Tivoli Storage Manager needs this information because the database backup and restore are done in two sessions. One session is for the database data and the other is for the recovery logs.

To ensure the availability of volume history information, it is extremely important to take one of the following steps:

� Store at least one copy of the volume history file offsite or on a disk separate from the database

� Store a printout of the file offsite.

� Store a copy of the file offsite with your database backups and device configuration file.

� Store a remote copy of the file, for example, on an NFS-mounted file system.

The VOLUMEHISTORY server option lets you specify a backup of volume history files. Then, whenever the server updates volume information in the database, it also updates the same information in the backup files.

You can also back up the volume history information at any time, by entering the backup volhistory command.

If you do not specify file names, the server backs up the volume history information to all files specified with the VOLUMEHISTORY server option.

Important: It is essential to save your volume history file. Without it, you cannot restore your database.


In order to ensure that updates are complete before the server is halted, we recommend the following steps:

1. Do not halt the server for a few minutes after issuing the BACKUP VOLHISTORY command.

2. Specify multiple VOLUMEHISTORY options in the server options file.

3. Examine the volume history file to see if the file is updated.

Restoring the databaseLife has been good so far, but what happens now? Our test setup is not optimal; it allows the file space used by the archive log to fill up and the server comes to a halt. Example 5-37 shows the ANR0130E message reported upon an attempt to start the server in the foreground.

Example 5-37 ANR0130E, log space exhausted

Tivoli Storage Manager for WindowsVersion 6, Release 1, Level 2.0

Licensed Materials - Property of IBM

(C) Copyright IBM Corporation 1990, 2009.All rights reserved.U.S. Government Users Restricted Rights - Use, duplication or disclosurerestricted by GSA ADP Schedule Contract with IBM Corporation.

ANR4726I The ICC support module has been loaded.ANR0152I Database manager successfully started.ANR0130E rdbdb.c(1306): Server LOG space exhausted.

To increase the amount of log space available to the server, evaluate the directories and file system assigned to the ACTIVELOGDIR, ARCHIVELOGDIR, and ARCHFAILOVERLOGDIR. An out of log space condition might occur because the ACTIVELOGDIR location is full. Or, an out of log condition might occur if the log files in the ACTIVELOGDIR that are no longer active cannot be archived to the ARCHIVELOGDIR and ARCHFAILOVERLOGDIR locations. If necessary, a larger ARCHIVELOGDIR or ARCHFAILOVERLOGDIR can be specified by updating this option in the dsmserv.opt file and then restarting the server.

We take the ANR0130E as a hint for a reorganization of our server database and log setup. Our plan is to extend the log space to allow the server to start again. Then we take a database backup, add new file systems to the box, and finally restore the database to the new file systems.

First we free up some space on the G: drive by deleting unused files we were able to identify. Next we create the new archive log directory under the new target, d:\tsm\server1\archivelog. We change the dsmserv.opt file to reflect the new location of the archivelogdir temporarily to the ARCHLOGDirectory located at d:\tsm\server1\archivelog and start the server to activate that change as shown in Example 5-38. We use the DSMSERV DISPLAY DBSPACE parameter to the dsmserv command to verify the current database setup.

Example 5-38 Server utility: display dbspace command

G:\Program Files\tivoli\tsm\server1>"c:\Program Files\tivoli\tsm\server\dsmserv.exe" display dbspaceANR0900I Processing options file G:\Program Files\tivoli\tsm\server1\dsmserv.opt.ANR7800I DSMSERV generated at 14:46:49 on May 19 2009.





ANR4726I The ICC support module has been loaded.ANR0153I Database manager already running.ANR1380I The buffer pool monitor switch is enabled.ANR0153I Database manager already running.

Location: d:\gallium_server1\dbTotal Size of File System (MB): 102,398.65Space Used on File System (MB): 35,141.96 Free Space Available (MB): 67,256.69

Location: g:\tsm\server1\databaseTotal Size of File System (MB): 59,388.70Space Used on File System (MB): 31,426.66 Free Space Available (MB): 27,898.03

This start activated our change to the archive log, and an archivelog structure was created under the new location. Now we copy all the old logfiles to this new location, and when this is completed, we delete the old archivelog directory (see Example 5-39).

Example 5-39 Copying archivelog data while the server is down

D:\TSM\server1\archivelog>xcopy /E G:\TSM\server1\archivelog\* .G:\TSM\server1\archivelog\archmeth1\SERVER1\TSMDB1\NODE0000\C0000000\S0000025.LOG..lines deleted..G:\TSM\server1\archivelog\archmeth1\SERVER1\TSMDB1\NODE0000\C0000000\S0000047.LOGG:\TSM\server1\archivelog\RstDbLog\SQLLPATH.TAG23 File(s) copied

D:\TSM\server1\archivelog>del /s /q G:\TSM\server1\archivelog\*Deleted file - G:\TSM\server1\archivelog\archmeth1\SERVER1\TSMDB1\NODE0000\C0000000\S0000025.LOG..lines deleted..Deleted file - G:\TSM\server1\archivelog\archmeth1\SERVER1\TSMDB1\NODE0000\C0000000\S0000047.LOGDeleted file - G:\TSM\server1\archivelog\RstDbLog\SQLLPATH.TAG

In addition, Example 5-40 documents the log layout that we collect with the DSMSERV DISPLAY LOG command.


Example 5-40 Server utility: display log

G:\Program Files\tivoli\tsm\server1>"c:\Program Files\tivoli\tsm\server\dsmserv.exe" display logANR0900I Processing options file G:\Program Files\tivoli\tsm\server1\dsmserv.opt.ANR7800I DSMSERV generated at 14:46:49 on May 19 2009.

Tivoli Storage Manager for WindowsVersion 6, Release 1, Level 2.0´Licensed Materials - Property of IBM


ANR4726I The ICC support module has been loaded.ANR0152I Database manager successfully started.ANR1380I The buffer pool monitor switch is enabled.

Total Space(MB): 2,048 Used Space(MB): 0.00 Free Space(MB): 2,040.00 Active Log Directory: g:\tsm\server1\activelog Mirror Log Directory:Archive Failover Log Directory: Archive Log Directory: d:\tsm\server1\archivelog

We will use the d: drive for the archivelog temporarily only, later we separate the log again from the d: drive which we use for file device class volumes. Example 5-41 documents the backup process that we initiate next.

Example 5-41 Create a database backup, type backup

TSM:TIRAMISU>backup db type=dbsnapshot devc=fileANR2017I Administrator SERVER_CONSOLE issued command: BACKUP DB type=dbsnapshotdevc=fileANR4559I Backup DB is in progress.ANR0984I Process 3 for DATABASE BACKUP started in the BACKGROUND at 15:09:40.ANR2287I Snapshot database backup started as process 3.TSM:TIRAMISU>ANR0406I Session 3 started for node $$_TSMDBMGR_$$ (DB2/NT) (Tcp/Ip gallium(43-31)).ANR8340I FILE volume G:\TSM\SERVER1\FILECLASS\44844582.DSS mounted.ANR0511I Session 3 opened output volume G:\TSM\SERVER1\FILECLASS\44844582.DSS.ANR1360I Output volume G:\TSM\SERVER1\FILECLASS\44844582.DSS opened (sequencenumber 1).ANR1361I Output volume G:\TSM\SERVER1\FILECLASS\44844582.DSS closed.ANR0514I Session 3 closed volume G:\TSM\SERVER1\FILECLASS\44844582.DSS.ANR0403I Session 3 ended for node $$_TSMDBMGR_$$ (DB2/NT).ANR0406I Session 4 started for node $$_TSMDBMGR_$$ (DB2/NT) (Tcp/Ip gallium(43-63)).ANR8340I FILE volume G:\TSM\SERVER1\FILECLASS\44844610.DSS mounted.ANR0511I Session 4 opened output volume G:\TSM\SERVER1\FILECLASS\44844610.DSS.ANR1360I Output volume G:\TSM\SERVER1\FILECLASS\44844610.DSS opened (sequence


number 1).ANR1361I Output volume G:\TSM\SERVER1\FILECLASS\44844610.DSS closed.ANR0514I Session 4 closed volume G:\TSM\SERVER1\FILECLASS\44844610.DSS.ANR0403I Session 4 ended for node $$_TSMDBMGR_$$ (DB2/NT).ANR4558I Snapshot database backup (process 3) completed.ANR0985I Process 3 for DATABASE BACKUP running in the BACKGROUND completed withcompletion state SUCCESS at 15:10:11.

We create the directories for the database, active log, and archivelog using the commands documented in Example 5-42.

Example 5-42 Create DBDIR, ACTIVELOGDIR and ARCHIVELOGDIR directories

D:\>md i:\tsm\dbdir1

D:\>md j:\tsm\dbdir2

D:\>md k:\tsm\activelog

D:\>md l:\tsm\archivelog

Again we apply a change to the dsmserv.opt file to now reflect the final target directory for the archive logs:

ARCHLOGDirectory l:\tsm\archivelog

Before we can start the restore, we create a file for the database directory locations to be used with the restore command. We enter each location on a separate line. In our scenario the dbdir.txt file looks as documented in Example 5-43.

Example 5-43 dbdir.txt file

i:\tsm\dbdir1j:\tsm\dbdir2

The DSMSERV REMOVEDB command we use in Example 5-44 removes the information about table TSMDB1 from the DB2 database. This command deletes all user data and log files, as well as any backup/restore history for the database. If the log files are needed for a roll-forward recovery after a restore operation, or the backup history required to restore the database, these files should be saved prior to issuing this command. The REMOVEDB command uses the DB2 API sqledrpd command, the DB2 equivalent is the command:

db2 drop db <db_alias>

At the time you submit the command, the database must not be in use.

Example 5-44 DSMSERV REMOVEDB command

G:\Program Files\tivoli\tsm\server1>"c:\Program Files\tivoli\tsm\server\dsmserv.exe" removedb tsmdb1ANR0900I Processing options file G:\Program Files\tivoli\tsm\server1\dsmserv.opt.ANR7800I DSMSERV generated at 09:55:28 on Jun 11 2009.





ANR4726I The ICC support module has been loaded.ANR2638W This command will delete all user data and log files, as well as anybackup/restore history for the TSM server database. Are you sure you want yourdatabase and all of its references removed (y or n)?yANR0152I Database manager successfully started.ANR0366I Database TSMDB1 was removed successfully.

Example 5-45 documents the restore process. Notice that we had to fully qualify the On parameter to the restore command for this to work successfully. This parameter specifies a file listing the directories to which the database will be restored; see Example 5-43 on page 108 for our definitions.

Example 5-45 Database restore to a new database and log structure

G:\Program Files\tivoli\tsm\server1>"c:\Program Files\tivoli\tsm\server\dsmserv.exe" restore db todate=today totime=now source=dbsnapshot on=g:\progra~1\tivoli\tsm\server1\dbdir.txt activelogd=k:\tsm\activelog recoveryd=m:\recoverydANR0900I Processing options file G:\Program Files\tivoli\tsm\server1\dsmserv.o-pt.ANR7800I DSMSERV generated at 09:55:28 on Jun 11 2009.




ANR4726I The ICC support module has been loaded.ANR1636W The server machine GUID changed: old value (), new value (10.81.67.e1-.6a.5a.11.dd.aa.6e.00.02.55.c6.b9.40).ANR7808W Sun Microsystems Library Attach module libacs.dll is not available from the system.ANR8200I TCP/IP Version 4 driver ready for connection with clients on port 1500.ANR0152I Database manager successfully started.ANR4916I Starting point-in-time database restore snapshot to date 06/12/2009 16:50:55.ANR4620I Database backup series 2 operation 0 device class FILE.ANR8340I FILE volume G:\TSM\SERVER1\FILECLASS\44844582.DSS mounted.ANR1363I Input volume G:\TSM\SERVER1\FILECLASS\44844582.DSS opened (sequence number 1).ANR1364I Input volume G:\TSM\SERVER1\FILECLASS\44844582.DSS closed.ANR8340I FILE volume G:\TSM\SERVER1\FILECLASS\44844610.DSS mounted.ANR1363I Input volume G:\TSM\SERVER1\FILECLASS\44844610.DSS opened (sequence number 1).ANR1364I Input volume G:\TSM\SERVER1\FILECLASS\44844610.DSS closed.


ANR4638I Restore of backup series 2 operation 0 in progress.ANR0406I Session 1 started for node $$_TSMDBMGR_$$ (DB2/NT) (Tcp/Ip gallium(2688)).ANR8340I FILE volume G:\TSM\SERVER1\FILECLASS\44844582.DSS mounted.ANR0510I Session 1 opened input volume G:\TSM\SERVER1\FILECLASS\44844582.DSS.ANR1363I Input volume G:\TSM\SERVER1\FILECLASS\44844582.DSS opened (sequence number 1).ANR4912I Database full restore in progress and DB Data bytes transferred 67,371,008.ANR4912I Database full restore in progress and DB Data bytes transferred 134,742,016.ANR4912I Database full restore in progress and DB Data bytes transferred 202,113,024.ANR4912I Database full restore in progress and DB Data bytes transferred 269,484,032.ANR4912I Database full restore in progress and DB Data bytes transferred 336,855,040.ANR1365I Volume G:\TSM\SERVER1\FILECLASS\44844582.DSS closed (end reached).ANR4912I Database full restore in progress and DB Data bytes transferred 381,800,459.ANR1364I Input volume G:\TSM\SERVER1\FILECLASS\44844582.DSS closed.ANR0514I Session 1 closed volume G:\TSM\SERVER1\FILECLASS\44844582.DSS.ANR0403I Session 1 ended for node $$_TSMDBMGR_$$ (DB2/NT).ANR0406I Session 2 started for node $$_TSMDBMGR_$$ (DB2/NT) (Tcp/Ip gallium(2710)).ANR8340I FILE volume G:\TSM\SERVER1\FILECLASS\44844610.DSS mounted.ANR0510I Session 2 opened input volume G:\TSM\SERVER1\FILECLASS\44844610.DSS.ANR1363I Input volume G:\TSM\SERVER1\FILECLASS\44844610.DSS opened (sequence number 1).ANR1365I Volume G:\TSM\SERVER1\FILECLASS\44844610.DSS closed (end reached).ANR4912I Database full restore in progress and DB transaction log bytes transferred 27,291,659.ANR1364I Input volume G:\TSM\SERVER1\FILECLASS\44844610.DSS closed.ANR0514I Session 2 closed volume G:\TSM\SERVER1\FILECLASS\44844610.DSS.ANR0403I Session 2 ended for node $$_TSMDBMGR_$$ (DB2/NT).ANR0406I Session 3 started for node $$_TSMDBMGR_$$ (DB2/NT) (Tcp/Ip gallium(2712)).ANR0403I Session 3 ended for node $$_TSMDBMGR_$$ (DB2/NT).ANR0153I Database manager already running.ANR1380I The buffer pool monitor switch is enabled.ANR0153I Database manager already running.ANR4917I Point-in-time database restore with snapshot complete, restore date 06/12/2009 15:09:40.ANR0369I Stopping the database manager because of a server shutdown.

Now our restore is complete, but did we reach our goal, the relocation of the database and log volumes? We start the server and use the QUERY DBSPACE and the QUERY LOG command again to verify this. The result is documented in Example 5-46. The database is spread over drives J: and K:. The active log is on drive K: and the archive log was relocated to the L: drive.

Example 5-46 Relocation verification

TSM:TIRAMISU>q dbspaceANR2017I Administrator SERVER_CONSOLE issued command: QUERY DBSPACE


Location: j:\tsm\dbdir2Total Size of File System (MB): 5,114.41Space Used on File System (MB): 709.00 Free Space Available (MB): 4,405.41

Location: i:\tsm\dbdir1Total Size of File System (MB): 5,114.41Space Used on File System (MB): 708.98 Free Space Available (MB): 4,405.43

TSM:TIRAMISU>q log f=dANR2017I Administrator SERVER_CONSOLE issued command: QUERY LOG f=d

Total Space(MB): 2,048 Used Space(MB): 2.80 Free Space(MB): 2,037.20 Active Log Directory: k:\tsm\activelog Mirror Log Directory:Archive Failover Log Directory: Archive Log Directory: L:\tsm\archivelog

SummaryIn this chapter we discussed an example of a database restore scenario. You should now know how to prepare and complete a database restore. In addition, you now understand that the V5 approach of adding and deleting databases volumes for Tivoli Storage Manager database relocation no longer works. Relocating server volumes requires a database restore and results in server downtime. This makes planning in the beginning more important.

Remaining tasks at this point include the configuration of a mirror for the active log or the definition of an archive log failover directory. However, at this point you should be able to complete those steps with the information from the administrator’s reference guide and the manual.

If you are interested in a review of other restore scenarios, refer to 6.3, “Recovery of a V6.1 Tivoli Storage Manager server” on page 128, where we discuss a DRM restore to a new hardware box.

5.4.3 Increase database space

In case your database grows, you can use the EXTEND DBSPACE command to add additional space to an existing installation. This requires a restart of the server for the change to become active. See Example 5-47.

Example 5-47 Extend dbspace command

TSM:TIRAMISU>extend dbspace m:\tsmdb\dbdir3ANR2017I Administrator SERVER_CONSOLE issued command: EXTEND DBSPACEm:\tsmdb\dbdir3ANR2592I Directory(ies) 'm:\tsmdb\dbdir3' has been defined in the database space.TSM:TIRAMISU>q dbspaceANR2017I Administrator SERVER_CONSOLE issued command: QUERY DBSPACE

Location: j:\tsm\dbdir2Total Size of File System (MB): 5,114.41


Space Used on File System (MB): 709.00 Free Space Available (MB): 4,405.41

Location: i:\tsm\dbdir1Total Size of File System (MB): 5,114.41Space Used on File System (MB): 708.98 Free Space Available (MB): 4,405.43

Location: m:\tsmdb\dbdir3Total Size of File System (MB): 5,114.41Space Used on File System (MB): 28.22 Free Space Available (MB): 5,086.19

TSM:TIRAMISU>q db f=dANR2017I Administrator SERVER_CONSOLE issued command: QUERY DB f=d

Database Name: TSMDB1Total Size of File System (MB): 15,343 Space Used by Database(MB): 454 Free Space Available (MB): 13,897 Page Size(Bytes): Total Pages: 33,048 Usable Pages: 32,776 Used Pages: 23,744 Free Pages: 9,032 Buffer Pool Hit Ratio: 97.5 Total Buffer Requests: 53,178 Sort Overflows: 0 Lock Escalation: 0 Package Cache Hit Ratio: 66.3 Last Database Reorganization: Full Device Class Name: FILE Incrementals Since Last Full: 0Last Complete Backup Date/Time: 06/12/2009 14:51:29

Example 5-47 on page 111 documents how we submitted the EXTEND DBSPACE command and subsequent QUERY DBSPACE and QUERY DB commands to show the directory assigned to the database. However, in Example 5-48, you can see that the directory is just empty.

Example 5-48 Database directory stays empty

G:\Program Files\tivoli\tsm\server1>dir m:\tsmdb\dbdir3 Volume in drive M is tsmdb3 Volume Serial Number is 1C55-D0C5

Directory of m:\tsmdb\dbdir3

06/12/2009 08:49 PM <DIR> .06/12/2009 08:49 PM <DIR> .. 0 File(s) 0 bytes 2 Dir(s) 5,333,258,240 bytes free


When we restart the server, the new database directory gets populated by DB2 and is available for the our server.

To further explain this scenario, assume that DB2 manages your database consisting of four LUNs, 50 GB each, as shown in Figure 5-32. Each LUN is assigned its own volume group on the host and each volume group has one file system.

With this configuration, DB2 uses separate I/O threads for each directory/file system.

Figure 5-32 DB2 managed database

Now if you are running out of database space, you can use the EXTEND DBSPACE command to add space to the database. In this example, you create two new 50 GB LUNs, assign them to the volume group, and create a separate file system for each LUN. After you add the space to your Tivoli Storage Manager server, with the next restart, DB2 runs through a reorganization of the database as shown in Figure 5-33.

Figure 5-33 Database reorganization with EXTEND DBSPACE

To prevent this from happening, we recommend that you carefully configure your DBSPACE and, if possible, just extend the file spaces, because this is transparent to your Tivoli Storage Manager server and the underlying database.

Note: Adding a new database directory after initial load will cause a REORG of the database. Because this is expensive and disruptive, it should be avoided.

LUN 1VG1/db150GB

LUN 2VG2/db250GB

LUN 3VG3/db350GB

LUN 4VG4/db450GB

LUN 1VG1/db150GB

LUN 2VG2/db250GB

LUN 3VG3/db350GB

LUN 4VG4/db450GB

LUN 5VG5/db550GB

LUN 6 VG6/db650GB

Caution! – DB2 performs online reorganization:

LUN 1VG1/db150GB

LUN 2VG2/db250GB

LUN 3VG3/db350GB

LUN 4VG4/db450GB

LUN 5VG5/db550GB

LUN 6 VG6/db650GB


As shown in Figure 5-34, you create four new 25 GB LUNs and extend each of your database file systems by those 25 GB LUNs. It is not necessary to submit the EXTEND DBSPACE command, and a database RORG is not performed.

Figure 5-34 Avoid database REORG to be required

5.4.4 Diagnostic information

In this section we discuss additional options available to collect diagnostic information related to communication with the DB2 database or executing DB2 commands.

DBREPORTMODE optionYou use the SET DBREPORTMODE for the V6.1 Tivoli Storage Manager server to set the database error reporting level. Possible values are:

� None:

No database diagnostic reporting is to be done.

Purpose: If some pervasive symptom is encountered that is flooding the activity log with messages, disable reporting by setting to NONE can eliminate the “noise”.

� Partial (Default):

Report exception cases or items that are likely issues that need to be considered.

Purpose: Report the exception cases, those cases where something unexpected occurs.

� Full:

Report all available information when an exception case is encountered.

Purpose: This can be enabled to pursue additional information if a given exception case does not report enough information initially; lighter weight, then full trace enablement.

As an example, if a database deadlock might be encountered, with DBREPORTMODE set to FULL, additional server transaction and lock information will be reported.

Additional database related information is available by the QUERY STATUS command. You can verify the current DBREPORTMODE setting as shown in Example 5-49.

Example 5-49 QUERY STAUS: additional information

TSM:TIRAMISU>q staANR2017I Administrator SERVER_CONSOLE issued command: QUERY STATUSStorage Management Server for Windows - Version 6, Release 1, Level 2.0

LUN 1LUN 5VG1/db175GB





Server Name: TIRAMISU Server host name or IP address: Server TCP/IP port number: 1500 Crossdefine: Off Server Password Set: No Server Installation Date/Time: 06/01/2009 21:55:51 Server Restart Date/Time: 06/12/2009 17:29:52 Authentication: On Password Expiration Period: 90 Day(s) Invalid Sign-on Attempt Limit: 0 Minimum Password Length: 0 Registration: Closed Subfile Backup: No Availability: Enabled Accounting: Off Activity Log Retention: 1 Day(s) Activity Log Number of Records: 185 Activity Log Size: <1 M Activity Summary Retention Period: 30 Day(s) License Audit Period: 30 Day(s) Last License Audit: 06/02/2009 09:43:06 Server License Compliance: Valid Central Scheduler: Active Maximum Sessions: 25 Maximum Scheduled Sessions: 12 Event Record Retention Period: 10 Day(s) Client Action Duration: 5 Day(s) Schedule Randomization Percentage: 25 Query Schedule Period: Client Maximum Command Retries: Client Retry Period: Client Scheduling Modes: Any Active Receivers: CONSOLE ACTLOG NTEVENTLOG Configuration manager?: Off Refresh interval: 60 Last refresh date/time: Context Messaging: OffTable of Contents (TOC) Load Retention: 120 Minute(s) Machine Globally Unique ID: 10.81.67.e1.6a.5a.11.dd.aa.6e.00.02.55- .c6.b9.40 Archive Retention Protection: Off Database Reporting Mode: Partial Database Directories: j:\tsm\dbdir2,i:\tsm\dbdir1 Total Size of File System (MB): 10,228.82 Space Used on File System (MB): 1,417.98 Free Space Available (MB): 8,810.84 Encryption Strength: AES

DB2 diagnostic informationYou can configure your DB2 to collect information to aid in troubleshooting. Here we discuss in brief the DB2 notification files, the DB2 diagnostic log file, and the diagnostic directory path. For a detailed description, review the available DB2 documentation. You can find the DB2 V9.5 Information Center at:

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp



The information that DB2 records in the notification files and the diagnostic log is determined by the configuration settings. To check the current setting, issue the get database manager configuration command. Example 5-50 shows some of the output returned. We omitted information not required for this discussion.

Example 5-50 DB” command: get database manager configuration

C:\Program Files\Tivoli\TSM\db2\BIN>db2 get database manager configuration

Database Manager Configuration

Node type = Enterprise Server Edition with local and remote clients

Database manager configuration release level = 0x0c00

Maximum total of files open (MAXTOTFILOP) = 16000 CPU speed (millisec/instruction) (CPUSPEED) = 6.140475e-007 Communications bandwidth (MB/sec) (COMM_BANDWIDTH) = 1.000000e+002

Max number of concurrently active databases (NUMDB) = 8 Federated Database System Support (FEDERATED) = NO Transaction processor monitor name (TP_MON_NAME) =

Default charge-back account (DFT_ACCOUNT_STR) =

Java Development Kit installation path (JDK_PATH) = C:\PROGRA~1\Tivoli\TSM\db2\java\jdk

Diagnostic error capture level (DIAGLEVEL) = 3 Notify Level (NOTIFYLEVEL) = 3 Diagnostic data directory path (DIAGPATH) =

The level parameters specify the type of errors that will be recorded.

Valid values are:

0 - No diagnostic data captured

1 - Severe errors only

2 - All errors

3 - All errors and warnings (Default)

4 - All errors, warnings and informational messages

Use the UPDATE DBM CFG command to update either of the values:

db2 attach to <instance-name>

db2 update dbm cfg using <parameter-name> <value>

db2 detach

For example:

DB2 UPDATE DBM CFG USING DIAGLEVEL X

Where X is the desired notification level.


On platforms supporting the Korn shell, the DB2 team provides a script to archive and maintain DB2 message logs and diagnostic data. For a complete description, go to the following URL:

http://www.ibm.com/developerworks/data/library/techarticle/dm-0904db2messagelogs/index.html?S_TACT=105AGX11

Administration notification log The primary log file intended for use by database and system administrators is the Administration Notification log. When significant events occur, the DB2 database manager writes information to the administration notification log. For example, it records the status of DB2 utilities (REORG, BACKUP, RECOVERY, ROLL-FORWARD), high-level application issues, licensing activity, log file paths and storage problems, monitoring and indexing activities, tablespace problems, and so on. This information is intended for use by database and system administrators.

Diagnostic information about errors is recorded in the administration notification file. This information is used for problem determination and is intended for DB2 technical support.

The administration notification file contains text information logged by DB2 as well as DB2 Spatial Extender. It is located in the directory specified by the DIAGPATH database manager configuration parameter. On Windows NT®, Windows 2000, and Windows XP systems, the DB2 administration notification file is found in the event log and can be reviewed through the Windows Event Viewer.

The information that DB2 records in the administration log is determined by the DIAGLEVEL and NOTIFYLEVEL settings. Use a text editor to view the file on the machine where you suspect a problem to have occurred. For Windows operating systems, you can use the Event Viewer to view the administration notification log.

The most recent events recorded are the furthest down the file. Generally, each entry contains the following parts:

� A timestamp.

� The location reporting the error. Application identifiers allow you to match up entries pertaining to an application on the logs of servers and clients.

� A diagnostic message (usually beginning with “DIA” or “ADM”) explaining the error.

� Any available supporting data, such as SQLCA data structures and pointers to the location of any extra dump or trap files.

If the database is behaving normally, this type of information is not important and can be ignored.

db2diag.logThe db2diag.log file is intended for use by DB2 support for troubleshooting purposes, it is available on all platforms supported by DB2. By default, it is found in the directory identified by the diagpath database manager configuration parameter and is created automatically when the instance is created.

Note: The administration notification file and the db2diag.log file grow continuously. When either one gets too large, back it up and then erase the file. A new file is generated automatically the next time it is required by the system.


http://www.ibm.com/developerworks/data/library/techarticle/dm-0904db2messagelogs/index.html?S_TACT=105AGX11

The db2diag.log file contains diagnostic information about error and warnings encountered by the instance. This information is used for problem determination and is intended for IBM software support. The type of message recorded in this file is determined by the diaglevel database manager configuration parameter.

You can format the db2diag.log using the db2diag utility. When the utility is run without any option, as we do in Example 5-51, it reminds you to submit the command db2diag -h to review available formatting and filter options.

Example 5-51 dbdiag command

C:\Program Files\tivoli\TSM\db2\BIN>db2diag > db2diag.txtdb2diag invoked with the default set of filtering/formatting optionson file "C:\DOCUME~1\ALLUSE~1\APPLIC~1\IBM\DB2\DB2TSM1\DB2TSM\db2diag.log".Enter "db2diag -h" to get a short description of all available options.

The returned db2diag output always starts with DB2 installation specific information and gives you additional details about the running system, see Example 5-52.

Example 5-52 db2diag header output.

2009-06-11-18.35.02.843000-420 I1H962 LEVEL: EventPID : 1084 TID : 3668 PROC : db2bp.exeINSTANCE: DB2TSM NODE : 000EDUID : 3668FUNCTION: DB2 UDB, RAS/PD component, pdLogInternal, probe:120START : New Diagnostic Log fileDATA #1 : Build Level, 128 bytesInstance "DB2TSM" uses "32" bits and DB2 code release "SQL09052"with level identifier "03030107".Informational tokens are "DB2 v9.5.201.3237", "special_21101", "WR21421_21101", Fix Pack "2a".DATA #2 : System Info, 1564 bytesSystem: WIN32_NT GALLIUM Service Pack 2 5.2 x86 Family 6, model 11, stepping 1CPU: total:2 online:2 Cores per socket:1 Threading degree per core:1Physical Memory(MB): total:3776 free:2577 available:1989Virtual Memory(MB): total:5669 free:4681Swap Memory(MB): total:1893 free:2104Information in this record is only valid at the time when this file wascreated (see this record's time stamp)


Example 5-53 shows an event with message ADM7514W being generated upon a database stop by the db2stop command. For details how to interpret the fields, review the available DB2 documentation and search for db2diag.log.

Example 5-53 DB2 stop event as reported in the db2diag.log

2009-06-12-14.28.54.375000-420 E72150H327 LEVEL: Event

PID : 2304 TID : 1520 PROC : db2syscs.exe

INSTANCE: DB2TSM NODE : 000

EDUID : 1520

FUNCTION: DB2 UDB, base sys utilities, DB2StopMain, probe:911

MESSAGE : ADM7514W Database manager has stopped.

STOP : DB2 DBM

Diagnostic data directory pathThe diagpath configuration parameter is used to specify the directory that will contain the error file, alert log file, and any dump files that might be generated, based on the value of the diaglevel parameter. If the diagpath parameter is null, the diagnostic information will be written to files in one of the following directories or folders:

� For supported Windows environments:

– If the DB2INSTPROF environment variable or keyword is not set, information will be written to x:\SQLLIB\DB2INSTANCE, where x:\SQLLIB is the drive reference and directory specified in the DB2PATH registry variable or environment variable, and DB2INSTANCE is the name of the instance owner. (The directory does not have to be named SQLLIB.)

– If the DB2INSTPROF environment variable or keyword is set, information will be written to x:\DB2INSTPROF\DB2INSTANCE, where DB2INSTPROF is the name of the instance profile directory and DB2INSTANCE is the name of the instance.

� For UNIX-based environments:

– INSTHOME/sqllib/db2dump, where INSTHOME is the home directory of the instance.

SummaryWith the transition to DB2, there are some additional log files that need to be reviewed in case you are investigating an unwanted symptom or have to do some troubleshooting. You now know how to adjust reporting levels and diagnostic file path information for your server.


Chapter 6. IBM Tivoli Storage Manager Disaster Recovery Manager

Protection and recovery of your Tivoli Storage Manager servers and their data is essential to your business resiliency plans. In this chapter we provide a review of the changes implemented in Tivoli Storage Manager V6.1 with respect to your Disaster Recovery Manager configurations.

As in previous releases, the Disaster Recovery Manager feature (license) is included with Tivoli Storage Manager Extended Edition only.

6


6.1 Introduction to disaster recoveryProviding a secure disaster recovery environment encompasses the complete data protection spectrum. Although disaster recovery of your data is a small portion of the overall Business Continuity Plan (BCP), this data protection is critical to your business survival in times of disaster.

There are a few enhancements in Tivoli Storage Manager V6.1 that affect your disaster recovery planning:

� Active data storage pools� Deduplication storage pools� DB2 database and recovery log enhancements

The Disaster Recovery Manager (DRM) will play a role in the management of your copy pool volumes, building your recovery plans efficiently, and providing a central point of packaging recovery information. In this chapter we discuss strategies designed around using Tivoli Storage Manager’s Disaster Recovery Manager as part of the building blocks in providing secure disaster recovery capabilities within your company.

When deploying the data deduplication feature, there are additional considerations, which we present in 6.4, “Data deduplication considerations” on page 137. This section discusses copy pool protection, and how its best deployed for both performance and recovery.

Within the scope of disaster recovery, there are multiple ‘tiers of disaster”, which we discuss further in 6.5, “Seven tiers of disaster recovery solutions” on page 140. More specifically, we also discuss a concept of data protection for “local” system disasters. These would include the Tivoli Storage Manager server, library manager, or the connected media, and data related to these components.

If disaster strikes, specifically related to a local data protection system, understanding the recovery processes is a critical success factor. Understanding, documenting, and testing are essential to sound disaster recovery preparedness.

6.2 Disaster Recovery Manager changes in V6.1

This section describes the Tivoli Storage Manager DRM enhancements, and references changes to Tivoli Storage Manager V6.1, from a point of disaster recovery.

Because Tivoli Storage Manager is now utilizing an external database product, a multi-phase recovery will be required. At the time of writing this chapter, there have been no changes to the DRM plan to adapt to the recovery of the DB2 database.

6.2.1 New system requirements for V6.1

When planning for your disaster recovery site, or deciding how this upgrade might impact your recovery site, you need to understand the changes in the Tivoli Storage Manager server requirements for V6.1. The updated system requirements can be found at the URL:

http://www-01.ibm.com/software/tivoli/products/storage-mgr/platforms.html?S_CMP=rnav




6.2.2 Recovery plan limitations

The Disaster Recovery Manager does not:

� Create DB2 instance groups or user IDs� Create log directories� Configure the Tivoli Storage Manager client API for use by backup and restore databases

At the recovery site, use the Tivoli Storage Manager Instance Configuration Wizard or manual steps that you have recorded in RECOVERY.INSTRUCTIONS.*

6.2.3 DRM enhancements for V6.1

An enhancement was added to support active data storage pools (ADPs) within the current DRM framework. The design objectives were to ensure that:

� ADPs can be utilized in DRM recovery plans, and procedures, to ensure that some, if not all, client machines can be restored more quickly and efficiently.

� All current DRM capabilities will be available to an ADP for management of on site/off site resources in preparation for a potential disaster.

� ADPs will emulate current DRM implementation of copy storage pools so existing methodologies and procedures can be easily expanded.

Considerations for using ADP in a DRM scenarioAn ADP will typically not be used for restoring the primary storage pools because this might cause some, or all, inactive files to be deleted from the database if the server determines that an inactive file needs to be replaced but cannot find it in the ADP.

A typical scenario would be for ADP volumes to be made available as soon as possible at the disaster site for high priority clients to begin immediate restore followed by availability of copy pool volumes.

Clients restoring directly from ADP volumes can run concurrently with clients restoring from lower priority copy pools because ADPs have a higher priority. This means that clients restoring from ADPs will not access their data that exists in copy pools, preventing potential thrashing and mount point conflicts.

New SET DRMACTIVEDATASTGPOOL commandThe new command for Disaster Recovery Manager is SET DRMACTIVEDATASTGPOOL, which is used to specify the active data pools to be managed by DRM. Previously, there was no awareness of the active data volumes in DRM. Using this command to specify names of the active data pools to be recovered (or destroyed) after a disaster will also create defaults if the PREPARE, MOVE DRMEDIA, or QUERY DRMEDIA commands do not include the ACTIVEDATASTGPOOL parameter.

� A new command modeled after the existing SET DRMCOPYSTGPOOL command� Multiple ADP names can be entered by a comma delimited list� Entering a NULL (“”) value will remove ALL ADPs from DRM� System authority is required to issue the command� SET action can be verified with Query Drmstatus.

The parameters included are the active data pool names. The usage is separate multiple names with commas and no intervening spaces. You can use wildcard characters. The specified names will overwrite any previous settings.

Chapter 6. IBM Tivoli Storage Manager Disaster Recovery Manager 123

If you enter a null string (""), all current names are removed, and no active data pool volumes in MOUNTABLE state are processed if they were not explicitly entered as MOVE DRMEDIA, QUERY DRMEDIA, or PREPARE command parameters.

Example 6-1 demonstrates the syntax to add multiple activedata storagepool entries.

DRM updates for active data poolsA new DRM SET command has been added to provide the ability to specify ADP names to be managed by DRM.

MOVE DRMEDIAThe MOVE DRDEMDIA command has been updated so that Active Data Pool (ADP) media can be cycled off site/on site per underlying server policies and processes. The command has been updated with the ACTIVEDATASTGPOOL parameter, which allows for override of the previously enabled SET ACTIVEDATASTGPOOL, or one-time movement of volumes from the mountable state.

If the ACTIVEDATASTGPOOL parameter not used, only those ADPs enabled by the SET command are processed. Multiple ADP names can be entered by a comma delimited list, as shown in Example 6-1.

Example 6-1 DRM move data command using the ACTIVEDATAStgpool parameter

MOVE DRMedia * WHEREstate=Mountable ACTIVEDATAStgpool= fileactivepoolANR0609I MOVE DRMEDIA started as process 13024.ANR6682I MOVE DRMEDIA command ended: 13024 volumes processed.

Query DRMedia * WHEREstate=Mountable ACTIVEDATAStgpool= fileactivepool

QUERY DRMEDIAThe SQL Engine and QUERY DRMEDIA have been updated so that ADP media can be tracked and managed appropriately.

PREPAREThe PREPARE command will be updated to provide the ability to include ADP volumes in the scripts, macros and documentation included in the recovery plan file. The existing command has been updated with the ACTIVEDATASTGPOOL parameter. This new parameter allows for the override of previously enabled SET DRM ADPs or one-time processing of eligible ADP volumes.

If the ACTIVEDATASTGPOOL parameter is not used, only those ADPs enabled by the SET command are processed. If no ADPs have been set, only the ADP volumes marked on site at the time the prepare ran will be processed. These volumes are marked unavailable. Multiple ADP names can be entered through a comma delimited list, as shown in Example 6-2.

Example 6-2 Disaster Recovery Manager command to set up active data storage pools

set drmactivedatapool activedatastgpool1,activedatastgpool2,activedatastgpool3

After setting the drmactivedatapool values, then run the PREPARE command, as shown in Example 6-3 to review the differences in the recovery plan.

Example 6-3 DRM prepare command using the ACTIVEDATAStgpool parameter

PREPare ACTIVEDATAStgpool=activepool24,activepool35


Updates to existing commands and parametersIn this section we discuss various updates since V5.5.

DRM updates to accommodate DB2The primary objective of the DRM development team was to preserve the move drmedia function and command externals, while making changes to the prepare recovery plan file for DB2. The changes to the stanza content and add and delete stanzas where required.

The externals of DRM are the same as V5.5 for DB and copy storage pool volumes. For the internals, copy storage pool volume tracking was untouched, and with regards to DB volume tracking the following is true:

� Tivoli Storage Manager is still responsible for tracking DB backup volumes, not DB2!� Tivoli Storage Manager Volume History is still used to track DB backup volumes.� DB backup volume expiration is the same as V5.5.� AUTO_DEL_REC processing is used for DB2 hygiene, so DB2 keeps minimal records,

ideally just latest backup series.

The design objective was keeping DB2 backup volume records to a minimum, as DB2 has its own “Volume History” called recovery history. However, Tivoli Storage Manager does not use it for tracking DB backup volumes, and maintains use of its own volume history file.

DB2 will continue to manage its volumes, using these features:

� DB2 AUTO_DEL_REC process deletes its own backup volume records:

– NUM_DB_OBJ 1– EXPIRE_DB_DAYS 0

� DB2 AUTO_DEL_REC runs as the final step of a successful FULL backup:

– Also it cleans up accumulated DB2 archive logs.– Current DB2 bug:

• DB2 deletes too many archive logs when ideal PARMs above are set.• So until DB2 fix is delivered and integrated into a Tivoli Storage Manager PTF,

NUM_DB_OBJ is set to 2.• This creates the problem, “you have to do at least two fulls to prime archive

log expiration” experienced in the initial releases of Tivoli Storage Manager V6.1.

There have been some changes to the volume history file to accommodate DB2 information, which are required by the dsmserv restore DB command, as shown in Example 6-4.

Example 6-4 Volume history file demonstrating the field differences to accommodate DB2

Volume Type: DBSNAPSHOT* Location for volume G:\TSM\SERVER1\FILECLASS\44844610.DSS is: '' Database Backup LLA: FULL_BACKUP.20090612150940.2 Database Backup HLA: \NODE0000\ Volume Name: "G:\TSM\SERVER1\FILECLASS\44844610.DSS" Backup Series: 2 Backup Op: 0 Volume Seq: 2 Device Class Name: FILE Database Backup ID: 0 , 3076 Database Backup Home Position: 0 Database Backup Total Data Bytes : 0 , 381800459 Database Backup Total Log Bytes: 0 , 27291659 Database Backup Log Block Number: -1 , -1


Disaster recovery plan changesThe disaster recovery plan has been changed to accommodate the difference between the DB and Log directory uses, because Tivoli Storage Manager no longer formats the DB and Log volumes. This difference also required a change to the dsmserv restore db command.

Recovery plan file stanza changes or deletions are shown in bold type in the following list:

� SERVER.REQUIREMENTS (changed)� RECOVERY.INSTRUCTIONS.GENERAL� RECOVERY.INSTRUCTIONS.off site� RECOVERY.INSTRUCTIONS.INSTALL� RECOVERY.VOLUMES.REQUIRED� RECOVERY.SCRIPT.DISASTER.RECOVERY.MODE script (changed)� RECOVERY.SCRIPT.NORMAL.MODE script� LOG.VOLUMES (removed)� DB.VOLUMES (removed)� DB.STORAGEPATHS (added)� LOGANDDB.VOLUMES.INSTALL (removed)� LICENSE.REGISTRATION macro� COPYSTGPOOL.VOLUMES.AVAILABLE macro� COPYSTGPOOL.VOLUMES.DESTROYED macro� PRIMARY.VOLUMES.DESTROYED macro� PRIMARY.VOLUMES.REPLACEMENT.CREATE macro� PRIMARY.VOLUMES.REPLACEMENT macro� STGPOOLS.RESTORE macro� VOLUME.HISTORY.FILE� DEVICE.CONFIGURATION.FILE� DSMSERV.OPT.FILE� LICENSE.INFORMATION

SERVER.REQUIREMENTS changesThis stanza now reflects the same information as output of the query db and query log admin commands. The changes hold the appropriate DB2 information instead of V5.5 Tivoli Storage Manager db and log volume information. This is still a useful reference point at the recovery site for determining the amount of disk space required on a replacement machine and db and log directory names for pre-creation.

RECOVERY.SCRIPT.DISASTER.RECOVERY.MODEFor this stanza, the LOGANDDB.VOLUMES.INSTALL.CMD invocation was removed, and the invocation of the altered dsmserv restore db command was added, however, it is “remarked out” in the script. It demonstrates how to restore DB to a new location, not using paths recorded in the DB2 backup image.

RECOVERY.SCRIPT.DISASTER.RECOVERY.MODEThe DB.STORAGEPATHS stanza is populated as a result of a DB2 query.

ACTIVEDATASTGPOOL.VOLUMES.AVAILABLEThis stanza has been added to the recovery plan to support active data storage pools, and is implemented to mark active data storage pool volumes as available for use in recovery, as shown in Example 6-5.

Note: Unlike previous versions of Tivoli Storage Manager, you must have the volume history and devconfig files to recover a V6.1 DB.


Example 6-5 DRM Activedatastgpool.volumes.available stanza

/* Recovery Administrator: Remove any volumes that have not been obtained *//* from the vault or are not available for any reason. *//* Note: It is possible to use the mass update capability of the *//* UPDATE command instead of issuing an update for each volume. However, *//* the 'update by volume' technique used here allows you to select *//* a subset of volumes to be processed. */ upd vol /tsm1/activepool/srv/0000169D.BFS acc=READO wherestg=FILEACTIVEPOOL upd vol /tsm1/activepool/srv/00001700.BFS acc=READO wherestg= FILEACTIVEPOOL upd vol /tsm1/activepool/srv/00001701.BFS acc=READO wherestg= FILEACTIVEPOOL upd vol /tsm1/activepool/srv/00001702.BFS acc=READO wherestg= FILEACTIVEPOOL

ACTIVEDATASTGPOOL.VOLUMES.DESTROYEDThis stanza has been added to the recovery plan to support active data storagepools, and is implemented to mark destroyed active data storage pool volumes as unavailable, as shown in Example 6-6.

Example 6-6 DRM activedatastgpool.volumes.destroyed stanza

/* Volumes in this macro were not marked as 'off site' at the time the *//* PREPARE ran. They were likely destroyed in the disaster. *//* Recovery Administrator: Remove any volumes that were not destroyed. */

upd vol /tsm1/activepool/srv/00001703.BFS acc=UNAVAIL wherestg=TSMACTIVEDIRS/* del vol /tsm1/activepool/srv/00001703.BFS */upd vol /tsm1/activepool/srv/00001703.BFS acc=UNAVAIL wherestg=TSMACTIVEDIRS/* del vol /tsm1/activepool/srv/00001703.BFS */

RECOVERY.VOLUMES.REQUREDThis stanza has been updated to provide information about activedata storage pool volumes to include the recovery process, and is shown in Example 6-7.

Example 6-7 activedata storage pool stanza

Volumes required for client restore(s) using active data Location = Safe Vault Inc. Active Storage Pool = FILEACTIVEPOOL Device Class = FILECLASS Volume Name = /tsm1/activepool/srv/0000169D.BFS

RECOVERY.SCRIPT.DISASTER.RECOVERY.MODEThis stanza has been updated to include the ADP stanza for exploding into macros.

Recovery plan limitationsKeep in mind the following limitations of the recovery plan:

� It does not install Tivoli Storage Manager, DB2.� It does not create DB2 instance groups or user IDs.� It does not create log directories.� It does not configure the Tivoli Storage Manager client API for use by backup/restore DB.� At the recovery site, use the Tivoli Storage Manager Instance Configuration Wizard or

manual steps that you have recorded in RECOVERY.INSTRUCTIONS.*


When running a Tivoli Storage Manager server with multiple instances, we recommend that each instance be protected with Disaster Recovery Manager. Some basic setup commands are shown in Example 6-8 to establish your plan and instructions for your new server instance.

Example 6-8 An example for naming convention and command syntax for DRM instances

set drmplanprefix /home/<instance>/DRM/plans/<hostname>-<instance>set DRMINSTRP /home/<instance>/DRM/instructions/<hostname>-<instance>

6.2.4 Disaster Recovery Manager exclusions in V6.1

There is a very large exclusion from the V6.1 DRM package for UNIX, which is the exclusion of the LOG and DB information, and all scripting related to these two components. Example 6-9 shows the stanzas not included in V6.1. They are shown here from a V5.5 AIX recovery plan.

Example 6-9 UNIX DRM stanza exclusions from the V6.1 recovery plan

LOGANDDB.VOLUMES.CREATE scriptLOG.VOLUMESDB.VOLUMESLOGANDDB.VOLUMES.INSTALL script

The exclusions for the Windows platform V5.5 recovery plan file is shown in Example 6-10.

Example 6-10 Windows DRM stanza exclusions from the V6.1 recovery plan

LOG.VOLUMESDB.VOLUMESLOGANDDB.VOLUMES.INSTALL script

These exclusions are an important phase in the rebuilding of the Tivoli Storage Manager server, which must now be performed manually, prior to invoking the recovery scripts.

6.3 Recovery of a V6.1 Tivoli Storage Manager server

As mentioned earlier in the “Introduction to disaster recovery” on page 122, there are multiple levels of disaster recovery. In this section we discuss two recovery options, one is a local database recovery, and the second is a remote Tivoli Storage Manager V6.1 server recovery.

6.3.1 Local disaster recovery of the Tivoli Storage Manager database

Local disaster recovery techniques for the Tivoli Storage Manager V6.1 DB2 database and recovery logs are discussed in detail in 5.4.2, “Restoring the database” on page 102. Understanding the changes implemented with the new database and recovery log environment is essential for Tivoli Storage Manager server management.


6.3.2 DR site recovery of the Tivoli Storage Manager server

Using the Disaster Recovery Manager feature as a portion of your overall recovery guide for your DR site, we will recover a V6.1 Tivoli Storage Manager server on UNIX and Windows. We use the following high level task flow:

1. Find the recovery plan and backup volumes at the vault and get to the recovery site.

2. Find the replacement machine at the recovery site.

3. Install OS and Tivoli Storage Manager server software (if this is from “scratch” and not from a system backup such as sysback or a previously built “warm” machine).

4. Break out the recovery plan so you have the dsmserv.opt, devconfig, and volhist files.

5. Create the db2 instance user IDs and group the same as the original.

6. Create the dbdir, activedir, and archive dirs the same as the original.

7. Run dsmicfgx to configure the replacement instance.

8. Specify the instance user ID and password to DB2.

9. Specify the dbdir, activedir, and archive dirs to DB2.

10.Drop the DB2 database tsmdb1 that was created by dsmicfgx.

11.Restore original dsmserv.opt, volhist, and devconf files to the instance directory (as done by the DR recovery script in the plan file). You must use these volhist and devconf files.

12.Run dsmserv restore db (as done by the DR recovery script in the plan file).

13.Restore high priority clients.

14.Run or manually perform the steps in the recovery.normal.mode.script to restore primary storage pools.

Steps 5-10 here are the new steps that are required for a V6.1 DRM based server recovery. We provide details for the new steps that are platform independent.

6.3.3 DR site recovery scenario

A common recovery site scenario might be a Tivoli Storage Manager production server at two physically separated sites. Each server holds a production “instance” and a disaster recovery “instance” for the other site.

The Tivoli Storage Manager disaster recovery instance, which is our UTAH-TSM1 instance, will be recovered to our Vermont server, as the instance name utah-tsm1. The task details in the following sections highlight the steps to accomplish this.

Ensure that the database backup is set on UTAH-TSM1For the purpose of this example, we perform the full database backup to a disk location, transfer the disk file over to Vermont, then use the file as input on Vermont.

On UTAH-TSM2We follow these steps:

1. def devc dbb_file devt=file maxcap=20G DIR=/tsmstg/dbb

2. set dbrecovery dbb_file

Note: The UNIX command line (no graphic console) cannot run dsmicfgx, therefore the options are X11 redirection or command line using the ‘-i console’ parameter.


3. backup db type=full devc=dbb_file scratch=yes.

4. prepare

5. Transport the recovery plan, with the copy pools tapes and database backup to Vermont.

On Vermont, the disaster recovery serverOn our remote server Vermont, we have an instance for disaster recovery which uses the same naming convention for paths and instance naming.

1. We create the disks to accommodate the Utah-TSM2 instance. However, because this is a DR instance (short term production run), our configuration might even be reduced to a subset of production, depending on our requirements. We configured Vermont as shown in Example 6-11.

Example 6-11 AIX custom logical volume and JFS2 file systems for TSM2 on the DR system Vermont

Filesystem 1024-blocks Free %Used Iused %Iused Mounted on/dev/dbdir5lv 2097152 2096504 1% 4 1% /tsm2/dbdir001/dev/dbdir6lv 2097152 2096504 1% 4 1% /tsm2/dbdir002/dev/dbdir7lv 2097152 2096504 1% 4 1% /tsm2/dbdir003/dev/dbdir8lv 2097152 2096504 1% 4 1% /tsm2/dbdir004/dev/actlog1lv 9371648 9369888 1% 4 1% /tsm2/actlog/dev/actlog1mlv 9371648 9369888 1% 4 1% /tsm2/activelogm/dev/archlog1lv 18808832 18805632 1% 4 1% /tsm2/archlog

2. For this setup purpose, we are configuring the instance ‘tsm2’ as the name of our DR instance (utah-TSM2). The tasks involved the creation of the group, user ID and home directory for our Tivoli Storage Manager instance, as shown in Example 6-12.

Example 6-12 Tivoli Storage Manager instance user ID creation in AIX

# mkuser -a id=1003 pgrp=tsmsrvrs home=/home/tsm2 tsm2# passwd tsm2Changing password for "tsm2"tsm1's New password:Enter the new password again:

3. Next, log in using the user ID and password, and you will be prompted to change the password for user ID, as shown in Example 6-13.

Example 6-13 Logging into AIX and changing the password for TSM1 new instance creation

You must change your password now and login again!Changing password for "tsm2"tsm1's Old password:tsm1's New password:

4. Next, we edit the .profile file as seen in the existing TSM2 instance, or copy the file. This is to maintain environment consistency with the instances. Performing this step, ensure any specific path details are altered for the new instance.

5. Change the ownership of the newly created file system mount points. Changing the ownership of the “tsm2” mounts and directories can be accomplished by issuing the commands shown in Example 6-14.


Example 6-14 AIX chown command and review of owner and group settings

$ suroot's Password:

# cd /

# chown -R tsm2.tsmsrvrs /tsm2/*# ls -l /tsm2total 0drwxr-xr-x 3 tsm2 tsmsrvrs 256 Jun 21 10:39 activelogmdrwxr-xr-x 3 tsm2 tsmsrvrs 256 Jun 21 10:15 actlogdrwxr-xr-x 3 tsm2 tsmsrvrs 256 Jun 21 10:43 archlogdrwxr-xr-x 3 tsm2 tsmsrvrs 256 Jun 21 12:13 dbdir001drwxr-xr-x 3 tsm2 tsmsrvrs 256 Jun 21 12:14 dbdir002drwxr-xr-x 3 tsm2 tsmsrvrs 256 Jun 21 12:14 dbdir003drwxr-xr-x 3 tsm2 tsmsrvrs 256 Jun 21 12:14 dbdir004

6. Create a new server options file (dsmserv.opt) by either referencing the recovery plan file, or copy the existing instance TSM1 server option file, and edit any details required. Refer to the IBM Tivoli Storage Manager for AIX Installation Guide V6.1, GC23-9781 for more information regarding dsmserv.opt parameters and settings.

7. Increase the size of the instance directory for TSM2, which in this case is the /home file system. Each instance requires approximately 420 MB of additional space.

8. The next step is to log out of AIX as the root user, and log in as the instance user ID (tsm2). Upon completing this step, you will find that an environment for DB2 has been established, as discussed in the previous steps.

9. Next update the default directory for the database to reflect the instance directory, by running the db2 update command as shown in Example 6-15.

Example 6-15 Setting the default directory for the database to be the same as the instance directory

$ pwd/home/tsm2$ db2 update dbm cfg using dftdbpath /tsm2DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completedsuccessfully.

10.Preparing the DB2 database and recovery logs is our next step. The db2icrt command will update the instance details within DB2. The command is run as shown in Example 6-16.

Example 6-16 Command to configure a Tivoli Storage Manager V6.1 server instance

# /opt/tivoli/tsm/db2/instance/db2icrt -a SERVER -u tsm2 tsm2DBI1070I Program db2icrt completed successfully.

11.Following the successful formatting, the next step will be to start the Tivoli Storage Manager V6.1 server in the foreground. To perform this, we will use the new parameters provided in the dsmserv command, as shown in Example 6-17.

Example 6-17 Starting the Tivoli Storage Manager V6.1 server instance in the foreground

$ /opt/tivoli/tsm/server/bin/dsmserv -u tsm2 -i /home/tsm2


DB2 configuration for database backupWe now must configure the API to allow for a DB2 database backup. If you use the Tivoli Storage Manager Server Instance Configuration wizard to create a server instance, configuration is done automatically. If you are configuring an instance manually, for the backup to work, the following requirements must be met:

� The Tivoli Storage Manager API is installed on the server machine (done by COI install).

� The Tivoli Storage Manager API has the correct client option settings.

� The DSMI_DIR, DSMI_CONFIG, DSMI_LOG environment variables are set in the DB2 instance process.

� The DSMI_DIR, DSMI_CONFIG, DSMI_LOG point to the correct places.

– API executables– API configuration files– API log file directory


The following steps are required to complete this task:

1. We set the DSMI_ api environment variables in the <instance>/sqllib/db2profile file, as shown in Example 6-18.

Example 6-18 The line items added to the sqllib/db2profile file

export DSMI_CONFIG=/home/tsm1/tsmdbmgr.optexport DSMI_DIR=/usr/tivoli/tsm/client/api/bin64export DSMI_LOG=/home/tsm1

2. Then log out, and back into the instance, or issue the command as shown in the ~/.profile to re-read the profile.

3. Next, create a file called tsmdbmgr.opt in the /home/tsm1 directory and add the following line as shown in example Example 6-19.

Example 6-19 Content of the /home/tsm2/tsmdbmgr.opt file

servername tsmdbmgr_tsm2

4. Next, edit the /usr/tivoli/tsm/client/api/bin64/dsm.sys. Avoid placing the server name, TSMDBMGR_TSM2, first in dsm.sys because it should not be the system-wide default. In this example, the added lines are after the stanza for server_a, as shown in Example 6-20 on page 132.

Example 6-20 /usr/tivoli/tsm/client/api/bin64/dsm.sys

Servername server_aCOMMMethod TCPipTCPPort 1500TCPServeraddress node.domain.company.COM

servername TSMDBMGR_TSM2 commmethod tcpip tcpserveraddr localhost tcpport 1500 passwordaccess generate passworddir /home/tsm2 errorlogname /home/tsm2/tsmdbmgr.lognodename $$_TSMDBMGR_$$


5. Next, set the API password for the instance TSM1, using the password (current and new) as TSMDBMGR, as root user, as shown in Example 6-21.

Example 6-21 Setting the API password for DB2.

# cd /home/tsm1/sqllib/adsm# ./dsmapipw

************************************************************** Tivoli Storage Manager ** API Version = 6.1.0 **************************************************************Enter your current password:Enter your new password:Enter your new password again:

This db2 upd command establishes the db2 configuration for the tsmdb1 database, and can be reviewed for the TSM2 instance by running an AIX command line db2 get snapshot for database on TSMDB1, as shown in Example 6-22, to query the TSMDB1 database for the TSM2 server instance.

Example 6-22 db2 get snapshot for database on TSMDB1 DB2 command

$ db2 get snapshot for database on TSMDB1 |grep tsm2Database path = /home/tsm2/tsm2/NODE0000/SQL00001/Automatic storage path = /tsm2/dbdir001Automatic storage path = /tsm2/dbdir002Automatic storage path = /tsm2/dbdir003Automatic storage path = /tsm2/dbdir004

6. Next, stop the running Tivoli Storage Manager TSM2 instance using the dsmcadmc command or ISC and Administration Center.

7. Drop the DB2 database tsmdb1 created by the configuration process we just followed. Use the command DSMSERV REMOVEDB to drop the TSM1DB database from DB2, as shown in Example 6-23.

Example 6-23 Dropping the DB2 database created for the DR instance.

$ dsmserv removedb TSMDB1

Tivoli Storage Manager for AIXVersion 6, Release 1, Level 2.0



ANR7801I Subsystem process ID is 438424.ANR0900I Processing options file /home/tsm2/dsmserv.opt.ANR7811I Using instance directory /home/tsm2.ANR4726I The ICC support module has been loaded.ANR2638W This command will delete all user data and log files, as well as anybackup/restore history for the TSM server database. Are you sure you want yourdatabase and all of its references removed (y or n)? y


ANR0152I Database manager successfully started.ANR0366I Database TSMDB1 was removed successfully.

8. Next, ensure that the active log path and recovery directory are empty prior to the restore, as shown in Example 6-24.

Example 6-24 Ensure the active log path and recovery directory are empty

$ rm -r /tsmstg/recoveryd/*$ rm -r /tsm2/actlog/*$ rm -r /tsm2/dirdb001/*

9. Run the DSMSERV RESTOREDB command, referencing the exploded DB.STORAGEPATHS file, as shown in Example 6-25.

Example 6-25 dsmserv restoredb command

dsmserv restore db todate=today source=dbb on=/tsmstg/dbb/DB.STORAGEPATHS activelogd=/tsm2/actlog recoveryd=/tsmstg/recoveryd

10.Now, review the output of the restore results as shown in Example 6-26.

Example 6-26 Output of the dsmserv restore db command on AIX




ANR7801I Subsystem process ID is 356514.ANR0900I Processing options file /home/tsm2/dsmserv.opt.ANR0921I Tracing is now active to file trace.txt.ANR7811I Using instance directory /home/tsm2.ANR4726I The ICC support module has been loaded.ANR1636W The server machine GUID changed: old value (), new value (00.00.00.00.4f.96.11.de.82.b2.08.63.09.0c.05.7f).ANR8200I TCP/IP Version 4 driver ready for connection with clients on port 1502.ANR0153I Database manager already running.ANR4634I Starting point-in-time database restore to date 06/24/09 23:59:59.ANR4620I Database backup series 4 operation 0 device class DBB_FILE.ANR8340I FILE volume /tsmstg/dbb/45798964.DBV mounted.ANR1363I Input volume /tsmstg/dbb/45798964.DBV opened (sequence number 1).ANR1364I Input volume /tsmstg/dbb/45798964.DBV closed.ANR8340I FILE volume /tsmstg/dbb/45800956.DBV mounted.ANR1363I Input volume /tsmstg/dbb/45800956.DBV opened (sequence number 1).ANR1364I Input volume /tsmstg/dbb/45800956.DBV closed.ANR4638I Restore of backup series 4 operation 0 in progress.ANR0406I Session 1 started for node $$_TSMDBMGR_$$ (DB2/AIX64) (Tcp/Ip loopback(32915)).ANR8340I FILE volume /tsmstg/dbb/45798964.DBV mounted.


ANR0510I Session 1 opened input volume /tsmstg/dbb/45798964.DBV.ANR1363I Input volume /tsmstg/dbb/45798964.DBV opened (sequence number 1).ANR4912I Database full restore in progress and DB Data bytes transferred 67,371,008.ANR4912I Database full restore in progress and DB Data bytes transferred 134,742,016.ANR4912I Database full restore in progress and DB Data bytes transferred 202,113,024.ANR4912I Database full restore in progress and DB Data bytes transferred 269,484,032.ANR4912I Database full restore in progress and DB Data bytes transferred 336,855,040.ANR4912I Database full restore in progress and DB Data bytes transferred 404,226,048.ANR4912I Database full restore in progress and DB Data bytes transferred 471,597,056.ANR4912I Database full restore in progress and DB Data bytes transferred 538,968,064.ANR4912I Database full restore in progress and DB Data bytes transferred 606,339,072.ANR4912I Database full restore in progress and DB Data bytes transferred 673,710,080.ANR4912I Database full restore in progress and DB Data bytes transferred 741,081,088.ANR1365I Volume /tsmstg/dbb/45798964.DBV closed (end reached).ANR4912I Database full restore in progress and DB Data bytes transferred 807,632,907.ANR1364I Input volume /tsmstg/dbb/45798964.DBV closed.ANR0514I Session 1 closed volume /tsmstg/dbb/45798964.DBV.ANR0403I Session 1 ended for node $$_TSMDBMGR_$$ (DB2/AIX64).ANR0406I Session 2 started for node $$_TSMDBMGR_$$ (DB2/AIX64) (Tcp/Ip loopback(32916)).ANR8340I FILE volume /tsmstg/dbb/45800956.DBV mounted.ANR0510I Session 2 opened input volume /tsmstg/dbb/45800956.DBV.ANR1363I Input volume /tsmstg/dbb/45800956.DBV opened (sequence number 1).ANR4912I Database full restore in progress and DB transaction log bytes transferred 67,371,008.ANR1365I Volume /tsmstg/dbb/45800956.DBV closed (end reached).ANR4912I Database full restore in progress and DB transaction log bytes transferred 73,441,291.ANR1364I Input volume /tsmstg/dbb/45800956.DBV closed.ANR0514I Session 2 closed volume /tsmstg/dbb/45800956.DBV.ANR0403I Session 2 ended for node $$_TSMDBMGR_$$ (DB2/AIX64).ANR0406I Session 3 started for node $$_TSMDBMGR_$$ (DB2/AIX64) (Tcp/Ip loopback(32917)).ANR0403I Session 3 ended for node $$_TSMDBMGR_$$ (DB2/AIX64).ANR0153I Database manager already running.ANR1380I The buffer pool monitor switch is enabled.ANR4645I The restore date reflects the most recent backup available up to the specified TODATE.ANR4635I Point-in-time database restore complete, restore date 06/23/09 19:16:01.ANR0369I Stopping the database manager because of a server shutdown.$


11.Next, and the last step prior to restore testing, is to start the recovered Tivoli Storage Manager server from Utah-tsm1, and now on Vermont as TSM2, in the foreground, as shown in Example 6-27.

Example 6-27 Output of a recovered AIX Tivoli Storage Manager V6.1 server on a DR instance




ANR7801I Subsystem process ID is 356514.ANR0900I Processing options file /home/tsm2/dsmserv.opt.ANR0921I Tracing is now active to file trace.txt.ANR7811I Using instance directory /home/tsm2.ANR4726I The ICC support module has been loaded.ANR1636W The server machine GUID changed: old value (), new value (00.00.00.00.4f.96.11.de.82.b2.08.63.09.0c.05.7f).ANR8200I TCP/IP Version 4 driver ready for connection with clients on port 1502.ANR0153I Database manager already running.ANR1311E Vary-on failed for disk volume /tsmstg/backuppool02F - unable to access disk device.ANR7807W Unable to get information for file xxxxxxlines removed to save output space......

ANR2103I Activity log pruning completed: 1299 records removed.ANR0984I Process 1 for IDENTIFY PROCESS started in the BACKGROUND at 08:18:12.ANR1018I Volume deduplication process 1 started for storage pool DD, identify processes=3.ANR0984I Process 2 for IDENTIFY PROCESS started in the BACKGROUND at 08:18:12.ANR1018I Volume deduplication process 2 started for storage pool DD, identify processes=3.ANR0984I Process 3 for IDENTIFY PROCESS started in the BACKGROUND at 08:18:12.ANR1018I Volume deduplication process 3 started for storage pool DD, identify processes=3.ANR2803I License manager started.ANR8200I TCP/IP Version 4 driver ready for connection with clients on port 1502.ANR2718W Schedule manager disabled.ANR2828I Server is licensed to support Tivoli Storage Manager Basic Edition.ANR2828I Server is licensed to support Tivoli Storage Manager Extended Edition.TSM:UTAH-TSM1>ANR0993I Server initialization complete.ANR0916I TIVOLI STORAGE MANAGER distributed by Tivoli is now ready for use.

TSM:UTAH-TSM1>

As we have highlighted in the output from Example 6-27, three processes are started which are for the server dedup function which has been recovered at the DR site.


12.Restore high priority clients.

13.Run or perform the steps in recovery.normal.mode.script to restore primary storage pools.

SummaryIn this section we have shown a disaster recovery scenario of a V6.1.2 Tivoli Storage Manager server instance running on Utah as TSM1, which is the deduplication instance in our test lab. The recovery instance was on the DR server Vermont, into a newly created instance called TSM2. An existing TSM1 was already in place, and the intent of this exercise was to demonstrate that the DR target could be any system, with any path structure.

6.4 Data deduplication considerations

The intent of the following section is to generate some detailed thought, planning, and requirement considerations when reviewing how you design the copypool protection within your data protection infrastructure. Although deduplication is the primary focus here, your legal and business requirements must be understood and applied, and ultimately leveraged when building a business case to appropriately configure your environment to include deduplication and disaster recovery protection (local and remote).

How does deduplication affect the use of copy storage pools and disaster recovery (DRM) planning and management? Tivoli Storage Manager V6 introduced data deduplication that might have planning or functional considerations relating to how a given server is managed and, in particular, how it performs disaster recovery management (DRM). Our discussion examines this in two primary ways. The first is to discuss typical DRM considerations without data deduplication in the mix. And then, with the DRM foundation set, we discuss the implications of data deduplication to those DRM activities.

6.4.1 Data life cycle for a Tivoli Storage Manager server and DRM

In the following topics, we describe a general view of the data life cycle within a Tivoli Storage Manager server after it has been stored (either archived or backed up).

Data stored to primary storage poolMigration is from higher levels in the storage hierarchy to lower levels in the storage hierarchy. Most typically, this is a migration from a disk staging pool that might be of DEVTYPE=DISK or DEVTYPE=FILE, to a lower cost sequential media pool such as DEVTYPE=FILE or DEVTYPE=X, where X represents an actual tape device such as LTO.

Storage pool backup is performed to one or more copy storage pools. This is done to provide for on site and off site copies of the data depending upon how an administrator chooses to manage the server. There are two primary possibilities here.

In the first case, there is a single copy storage pool being used. If this is the case, it provides a single duplicate copy of the data, and if it is being used for offset protection/safety purposes, then it is also being rotated or transition offset to support that.

In the second case, there are multiple copy storage pools being used for a given set of data. The general model in this case is that a copy storage pool copy of the data is being used to keep an on site (local) duplicate copy of the data to protect from media/device failure for the primary storage pool. And the second or other copy storage pools are then used for offset protection by rotating those volumes to an off site location in order to protect from a major disaster that results in the loss of the primary data center or server hardware and devices.


Database backupDatabase backup for the server needs to happen as the last step in this sequence because the pointers and other meta-data characteristics that are recorded in the database are influenced or impacted by the migration and storage pool backup steps listed previously.

Finally, movement of volumes for off site storage can now be performed. If using the Tivoli Storage Managers DRM feature, this would be the MOVE DRMEDIA command and related processing. The idea here is to take the current database backup along with matching storage pool backup volumes and remove them from the primary location for the purpose of transporting them to the off site data protection location.

Note that the sequence listed above is not an absolute. For example, if simultaneous write is used when the data is stored, a copy storage pool copy of the data will be created in parallel or concurrent with the store of the data into the primary storage pool. Alternatively, the use of migration might not be used in your configured environment; you might simply be storing to a primary location and then creating copy storage pool copies from that without any actual storage hierarchy in place.

What we have accomplished so farCopy storage pool and database backup volumes are at an off site location and available for the recovery of the server if a major disaster occurred.

If two copy storage pools are being used, one for on site and one for off site, then we also have populated and managed an on site pool that protects against media/device failure by having on site and available duplicate copies of the data.

Then as data is expired based on policy retention values, reclaimable space is created on those copy storage pool volumes (on site and off site). This reclaimable space can then be reclaimed in one of two ways:

1. If the copy storage pool volumes are on site, meaning that they have not been moved to an off site location and the server knows that these volumes are locally available, the volumes will be reclaimed as a normal part of reclamation processing. The volumes will be reclaimed by moving the available, still referenced, data to other volumes in the same storage pool based on the percentage reclaimable space setting for that storage pool.

2. If the copy storage pool volumes are off site, meaning that they have been moved to an off site location and the server knows that these volumes are not locally available, the volumes will be reclaimed using the server's off site reclamation processing. This processing will create new representations of these volumes to take off site while all references to the data on the off site volume will be removed. This off site reclamation processing avoids data movement or copying of data from an off site location by relying upon copying data from locally resident primary storage pool locations.

6.4.2 Data life cycle for a Tivoli Storage Manager server and DRM including deduplicated storage pools

There are a number of operational considerations when using deduplicated primary or copy storage pools. One key consideration, though, is that deduplication is only allowed for storage pools using a device class of DEVTYPE=FILE. As such, deduplicated copy storage pools do not lend themselves to use by DRM for the off site protection of the Tivoli Storage Manager server.


The following scenarios discuss some typical or expected implementations:

� PRIMARY POOL DEDUPLICATED, SINGLE COPY STORAGE POOL NOT DEDUPLICATED

– This is probably the typical situation that is expected. In this case, the time to back up the primary storage pool to a non-deduplicated copy storage pool might take longer. The issue is that as data is copied to the copy storage pool, the deduplicated chunks representing a given file need to be read and the file “recomposed” or “undeduplicated” and stored in its entirety in the copy storage pool. However, this allows for the use of the Tivoli Storage Manager DRM feature and the use of off site copy storage pool volumes to recovery data at a disaster recovery site.

� PRIMARY POOL DEDUPLICATED, MULTIPLE COPY STORAGE POOLS NOT DEDUPLICATED

– This is also expected to be a typical situation or configuration. In this case, the time to back up the primary storage pool might also take longer because of the reads necessary to get the various chunks representing a given object being written to one of these copy storage pools. This is similar to the case above but also provides an on site copy storage pool copy of the data in addition to the off site support.

� PRIMARY POOL DEDUPLICATED, SINGLE COPY STORAGE POOL DEDUPLICATED

– In this case, the primary goal is space savings at the primary server location. However, this does not provide for DRM exploitation and off site rotation of copy storage pool volumes because the deduplicated copy storage pool can only be achieved using DEVTYPE=FILE volumes. This approach can have inherent risk associated with it, that risk being that there is no off site copy of the data that can be used in the event that the primary server location, hardware, or data center is damaged or destroyed.

� PRIMARY POOL DEDUPLICATED, SINGLE COPY STORAGE POOL NOT DEDUPLICATED, SINGLE COPY STORAGE POOL DEDUPLICATED

– In this case, the deduplicated copy storage pool is providing space savings for the primary server location as well as duplication of the data that resides in the primary storage pool. Keep in mind that Tivoli Storage Manager server deduplication is done at the level of a single storage pool so a deduplicated primary pool and a deduplicated copy storage pool will be referencing different chunks and maintaining different database references in order to track and manage the data chunks that represent a given file. On the other hand, the non-deduplicated copy storage pool in this case, is likely real tape (something other then DEVTYPE=FILE) and is being used along with DRM for the purpose of having an off site data protection site. The off site copy storage pool volumes in conjunction with an appropriate database backup can then be used to restore the server and restore/retrieve data from the copy storage pool volumes.

Why you would use a deduplicated copy storage poolThe advantages to a deduplicated copy storage pool are as follows.

� Storage pool backup when going from a deduplicated primary pool to a deduplicated copy storage pool is more efficient because it can copy just the data chunks and it does not have to recompose (undeduplicate) the underlying data.

� A deduplicated copy storage pool reduces the space needed to an on site copy of the primary storage pool data. This space savings can allow server installations that were not previously able to keep on site copy storage pool copies of data.

Note: This approach does not provide for an off site copy of the data or the use of Tivoli Storage Manager's DRM feature. If the primary product server or data center were damaged or destroyed, this might result in the loss of data or inability to recover that data.


6.5 Seven tiers of disaster recovery solutions

The goal of any disaster protection planning is to protect the most business-critical processes and minimize unplanned downtime. Keep in mind that all planning for any type of a disaster-tolerant solution is always subject to balancing the solution versus the downtime versus the cost.

The recovery time of any of the Seven Tiers of Disaster Recovery solutions is very much dependent on the following considerations:

� Recovery of the IT infrastructure� Recovery time for the data availability � Restoring the operational processes � Restoring the business processes

Figure 6-1 Seven Tiers of Disaster Recovery

6.5.1 A breakdown of the seven tiers

In 1992, the SHARE user group in the United States, in combination with IBM, defined a set of Disaster Recovery tier levels. This was done to address the need to properly describe and quantify various different methodologies for successful mission-critical computer systems' Disaster Recovery implementations. Accordingly, within the IT Business Continuance industry, the tier concept continues to be used, and it is very useful for describing today's Disaster Recovery capabilities. They need only to be updated for today's specific Disaster Recovery technologies and associated RTO/RPO.

These Seven Tiers of Disaster Recovery solutions offer a simple methodology of how to define your current service level, and to identify the target service level and the required environment to meet your recovery requirements.

BC Tier 0: No off site dataBusinesses with a Business Continuity (BC) Tier 0 Disaster Recovery solution have no Disaster Recovery Plan. There is no saved information, no documentation, no backup hardware, and no contingency plan.

Recovery Time Objective 15 Min. 1-4 Hr.. 4 -8 Hr.. 8-12 Hr.. 12-16 Hr.. 24 Hr.. Days

Valu

e (C

ost)

BC Tier 4 Point in Time disk copy, Tivoli Storage Manager-

BC Tier 3 Electronic Vaulting, Tivoli Storage Mgr

BC Tier 2 Hot Site, Restore from Tape

BC Tier 7 Site Mirroring with automated recovery

BC Tier 6 Storage mirroring (with or without automation)

BC Tier 5 Software mirroring (transaction integrity)

BC Tier 1 Restore from Tape

Recovery from a disk image Recovery from tape copy


Typical recovery time: The length of recovery time in this instance is unpredictable. In fact, it might not be possible to recover at all. Your business longevity if any disaster where to occur is at risk.

BC Tier 1: Data backup using a cold siteBusinesses that use BC Tier 1 Disaster Recovery solutions will physically ship their Tivoli Storage Manager copypool and database backup tapes for storage at this facility. Depending on how often backups are transported, these companies are prepared to accept several days to weeks of data loss, but their backups are secure off site. However, this tier lacks the system infrastructure on which to restore data.

Disaster Recovery solutionsPickup Truck Access Method (PTAM), Tivoli Storage Manager, Disaster Recovery module would be used for recovery.

BC Tier 2: Data backup with a hot site or warm siteBusinesses using BC Tier 2 Disaster Recovery solutions make regular backups on tape (daily). This is combined with an off site facility and infrastructure (known as a hot site or warm site), in which you would restore systems from those tapes in the event of a disaster. This tier solution will still result in the need to recreate several hours to days worth of data, but it is more predictable in recovery time. Part of the supporting infrastructure often includes high speed network connectivity.

Disaster Recovery solutionsPTAM with Hot Site available, Tivoli Storage Manager virtual volume transmitting (secure IP network), or Tivoli Storage Manager electronic vaulting (secure SCSI over IP network). If a Fibre Channel network exists, there is also the possibility of Tivoli Storage Manager electronic vaulting. Tivoli Storage Manager, Disaster Recovery module would be used for recovery.

BC Tier 3: Electronic vaultingThe BC Tier 3 solutions utilize components of BC Tier 2. Additionally, all Tivoli Storage Manager copypool data is electronically vaulted. There should be a Tivoli Storage manager server (same platform as your production site) connected to the off site library.

As a result there is less data loss when a disaster is declared. The transition from the state of idle off site storage to becoming the primary recovery source is much faster than Tier 1 and Tier 2, because the data is physically loaded and ready. This methodology is reliable and very predictable for recovery times. Automation can be built in, and there is significantly less manpower required for annual or semi-annual testing.

Disaster Recovery solutionsElectronic vaulting of data (Fibre Channel network, or ISCSI if a secure IP network exists), Tivoli Storage Manager - Disaster Recovery Manager would be used for recovery.

BC Tier 4: Point-in-time copiesBusiness Continuity (BC) Tier 4 solutions are used by businesses that require both greater data currency and faster recovery than companies who use the lower tiers. Rather than relying largely on tape recovery, as is common in the lower tiers, Tier 4 solutions begin to incorporate more disk-based solutions. Several hours of data loss is still possible, but it is easier to make such point-in-time (PIT) copies with greater frequency than data that can be replicated through tape-based solutions.


Disaster Recovery solutionsBatch/Online Database Shadowing and Journaling, Metro/Global Copy, FlashCopy, FlashCopy Manager, Peer-to-Peer Virtual Tape Server, TotalStorage Productivity Center for Replication, Tivoli Storage Manager - Disaster Recovery Manager, N series Snapshot

BC Tier 5: Transaction integrityBC Tier 5 solutions are used by businesses with a requirement for consistency of data between production and recovery data centers. There is little to no data loss in such solutions; however, the presence of this functionality is entirely dependent on the application in use.

Disaster Recovery solutionsSoftware, two-phase commit, such as DB2 remote replication, MQSeries®, Oracle DataGuard

BC Tier 6: Zero or little data lossBC Tier 6 Disaster Recovery solutions maintain the highest levels of data currency. They are used by businesses with little or no tolerance for data loss and who need to restore data to applications rapidly. These solutions have no dependence on the applications to provide data consistency.

Disaster Recovery solutionsMetro Mirror, Global Mirror, z/OS Global Mirror, GDPS® HyperSwap® Manager, Peer-to-Peer VTS with synchronous write, PPRC Migration Manager, TotalStorage Productivity Center for Replication, AIX HACMP/XD with Logical Volume Mirroring

BC Tier 7: Highly automated, business-integrated solutionBC Tier 7 solutions include all the major components being used for a Tier 6 solution with the additional integration of automation. This allows a Tier 7 solution to ensure consistency of data above that of which is granted by Tier 6 solutions. Additionally, recovery of the applications is automated, allowing for restoration of systems and applications much faster and more reliably than would be possible through manual Disaster Recovery procedures.

Disaster Recovery solutionsGDPS/PPRC with or without HyperSwap, GDPS/XRC, GDPS/GM, PPRC with HyperSwap, HACMP/XD, AIX HACMP/XD with Metro MIrror, System i® High Availability Business Partner Software, System i Copy Services Toolkit

6.5.2 Selecting the optimum Disaster Recovery solution

It is important to understand that the cost of a solution must be in reasonable proportion to the business value of IT. Most of your business requirements should be determined during your Business Continuity Planning, however that said, ideally you should not spend more money on a Disaster Recovery solution than the financial loss you would suffer from a disaster.


Based on the following objectives, it becomes relatively simple to decide, as a business, which solution to select according to how much you can afford to spend and the speed at which you need your data recovered; the quicker the recovery required, the higher the cost:

� Recovery Time Objective (RTO):

– How long can you afford to be without your systems?

� Recovery Point Objective (RPO):

– When it is recovered, how much data can you afford to recreate?

� Degraded Operations Objective (DOO):

– What will be the impact on operations with fewer data centers?

� Network Recovery Objective (NRO):

– How long will it take to switch over the network?

Normally all the components that make up continuous availability are situated in the same computer room. The building, therefore, becomes the single point-of-failure. While you must be prepared to react to a disaster, the solution you select might be more of a recovery solution than a continuous-availability solution. A recovery solution must then be defined by making a trade-off among implementation costs, maintenance costs, and the financial impact of a disaster. These will all be reviewed as a result of performing a business impact analysis of your business as part of a larger Business Continuity Plan.

For more information about Business Continuity planning, see IBM System Storage Business Continuity: Part 1 Planning Guide, SG24-6547, and IBM System Storage Business Continuity: Part 2 Solutions Guide, SG24-6548.

6.6 Best practices for offsite data vaulting and security

Here we list some best practices for offsite data vaulting and security:

1. Always test your restore processes:

– Primary volume recovery

– Tivoli Storage Manager database recovery

– Recovery from a server failure due to insufficient space in the archive recovery log

– Tivoli Storage Manager server recovery (using the Disaster Recovery Manager), simulating local server recovery from bare metal condition

– Tivoli Storage Manager server recovery (using the Disaster Recovery Manager), simulating local server recovery from bare metal condition

2. Only remove Tivoli Storage Manager database backup and copypool tapes from your library. These are tracked by the Disaster Recovery Manager module:

– Maintain backup sets within the production or off site library only, and remove for immediate client recovery, then return the tape after the recovery is complete.

– If removal of backup sets must happen due to library space, or a desire to store them in a vault, a separate tracking document must be maintained for audit purposes.

3. Categorize your data based on levels of business (or legal) importance

– Only use off site for your business critical and business important data.

– Structure your storage pools based on importance.


4. Create copypool data for low priority data which is stored locally at the production site:

– Use media disaster coverage only (no site coverage).

5. Use multiple copypools for your business critical/important copypool data:

– This will reduce the tape contention, and during a site disaster recovery it will reduce the number of copypool tapes required within the library during restore operations (100 critical client tapes, instead of 500 tapes if only one large copypool is required).

– Create a separate copypool structure for deduplicated storage pool protection.

– Create a separate copypool structure for activedata storage pool protection.

6. Application encryption at AES128 bit (Tivoli Storage Manager client or API encryption) should be used for all business critical or business important data.

7. System Managed Encryption or Library Managed Encryption (or equivalent functionality provided by other vendors) is used for any Tivoli Storage Manager full (or snapshot) database backup cartridges which are removed from the library:

– When there is no SME or LME possible, transport and store the Tivoli Storage Manager database backup separately from the copypool data.

8. All electronic vaulting is transferred over:

– An encrypted IP network segment, using VPN, IPSec or SSL based encryption

– OSI layer 1 - Fibre Channel network

9. All copypool data held off site should consist of active data, inactive data, and possibly deduplicated data.


Chapter 7. Data deduplication in Tivoli Storage Manager V6.1

Tivoli Storage Manager V6.1 provides a new built-in data deduplication feature that can help make better use of storage space by elimination of redundant data. In this chapter we discuss deduplication strategies, algorithms, and then the specific implementation of deduplication in Tivoli Storage Manager V6.1.

7


7.1 Introduction to deduplication

This section provides a basic understanding of the difference between deduplication and compression, and explains the basics of how deduplication works. The information provided is Tivoli Storage Manager independent and applies to filers as well as backup systems.

Deduplication is a technique that allows more data to be stored on a given amount of media than would otherwise be possible. It works by removing duplicates in the stored version of your data. In order to do that, the deduplication system has to process the data into a slightly different form. When you need the data back, it can be reprocessed into in the same form as it was originally submitted.

Deduplication and compression are closely related, and the two often work in similar ways, but the size of the working set of data for each is different. Deduplication works against large data sets, compared to compression (for example, real-world LZW compression often only has a working data set under 1 MB, compared to deduplication, which is often implemented to work in the range of 1 TB to 1 PB). With deduplication, the larger the quantity being deduplicated, the more opportunity exists to find similar patterns in the data, and the better the deduplication ratio can theoretically be, so a single store of 40 TB would be better than five separate data stores of 8 TB each.

Deduplication is effective with many, but not all workloads. It requires that there are similarities in the data being deduplicated: For example if a single file exists more than once in the same store, this could be reduced down to one copy plus a pointer for each deduplicated version (this is often referred to as a “Single Instance Store”). Some other workloads such as uncompressible and non-repeated media (JPEGs, MPEGs, MP3, or specialist data such as geo-survey data sets) will not produce significant savings in space consumed. This is because the data is not compressible, has no repeating segments, and has no similar segments.

In many situations, deduplication works better than compression against large data sets, because even with data that is otherwise uncompressible, deduplication offers the potential to efficiently store duplicates of the same compressed file.

To sum up, deduplication typically allows for more unique data to be stored on a given amount of media, at the cost of the additional processing on the way into the media (during writes) and the way out (during reads).

7.1.1 Deduplication approaches

There are a large number of approaches to the deduplication of data. A simple way of deduplicating would be to simply look for files of the same name and content, and remove duplicates on that level, however, this would overlook the possibility to deduplicate similar pieces of data within different files. For that sort of processing, we need to deal with data at a level below the files themselves, at the block or bit level. We also need a way of referring to the parts of files we consider are worth deduplicating. Some implementations use a fixed size of sub-file called a block, while others use variable sized pieces of file, which we will call chunks for the purposes of this book.

In order to process data quickly, many storage techniques use hash functions. A hash function is a process that reads some input data (also referred to as a chunk), and returns a value that can then be used as a way to refer to that data. An example of this is demonstrated using the AIX csum command. We are able to return hash values for a given file with more than one algorithm. The real-world application for csum is to check that a file has been downloaded properly from a given Internet site, provided that the site in question has the MD5


listed with the file. Example 7-1 shows a pair of example hashes for a given file: The two hash functions are MD5 and SHA-1 in this case. MD5 produces a 128-bit digest (hash value), where SHA1 produces a 160-bit value. This is shown by the different digest lengths (notice that the 05e4.. is shorter than the 0d14.. value).

Example 7-1 Hash values of two commonly used functions against the same file

# csum -h MD5 tivoli.tsm.devices.6.1.2.0.bff05e43d5f73dbb5beb1bf8d370143c2a6 tivoli.tsm.devices.6.1.2.0.bff

# csum -h SHA1 tivoli.tsm.devices.6.1.2.0.bff0d14d884e9bf81dd536a9bea71276f1a9800a90f tivoli.tsm.devices.6.1.2.0.bff

A typical method of deduplication is to logically separate the data in a store into manageable chunks, then produce a hash value for each chunk, and store those hash values in a table. When new data is taken in (ingested) into the store, the table is then compared with the hash value of each new chunk coming in, and where there’s a match, only a small pointer to the first copy of the chunk is truly stored as opposed to the new data itself.

Typical chunk sizes could be anywhere in the range of 2 KB to 4 MB, although theoretically any chunk size could be used. There is a trade-off to be made with chunk size: a smaller chunk size means a larger hash table, so if we use a chunk which is too small, the size of the table of hash pointers will be large, and could outweigh the space saved by deduplication. A larger chunk size means that in order to gain savings, the data must have larger sections of repeating patterns, so while the hash-pointer table will be small, the deduplication will find fewer matches.

The hashes used in deduplication are similar to those used for security products; MD5 and SHA-1 are both commonly used cryptographic hash algorithms, and both are used in deduplication products, along with other more specialist customized algorithms.

With any hash, there is a possibility of a collision, which is the situation when two chunks with different data happen to have the same hash value. This possibility is extremely remote: in fact the chance of this happening is less likely than the undetected, unrecovered hardware error rate.

Other methods exist in the deduplication technology area which are not hash based, so do not have any logical possibility of collisions. One such method is called hyperfactor; this is implemented in the IBM ProtecTIER® storage system.

7.1.2 Deduplication ratios

Vendors often quote “average” deduplication ratios as a guide to the space savings available. In common with compression, deduplication engines are only as good as the type of data fed into them—so your mileage might vary.

The classic example of a deduplication engine’s prowess is with data like that contained in an e-mail system. If we send an uncompressed 1 MB attachment to 100 people, the copies would take up 100 MB on the e-mail server, plus the 1 MB “sent” copy in our sent folder. The e-mail server would need 101 MB of free space for us to send that e-mail. When we come to back up the e-mail server, we would separately back up all 101 copies as though unrelated, using 101 MB of space.

If we were doing this with a deduplicating data store as the target, we would probably consume less than 1 MB on deduplicated storage, depending on how deduplicatable the original 1 MB attachment was. If we assume that it had 50% repeating patterns inside, the

Chapter 7. Data deduplication in Tivoli Storage Manager V6.1 147

deduplication ratio might be as high as 202:1. This ignores a lot of factors but gives an idea of a best-case scenario. Alternatively, a compressed file (such as MPEG video) will not usually further compress or deduplicate at all, but the savings could still be 100:1 in the example above because the same data is repeated 101 times. Similar savings are also quite common on certain types of databases.

Taking a very simple, traditional approach to backup (taking full backups daily) results in a high proportion of redundancy in the data stored, which traditionally meant lots of tapes. On tape we might be looking at 20 or more copies of the same files, each containing the same redundancies. In the example above, we could multiply the 200:1 ratio by nearly 20 in such a case. Deduplicating that sort of system is a very good idea indeed, from a space-savings point of view: the ratios achieved would be high, the space savings large.

With Tivoli Storage Manager, IBM has always endeavoured to use storage more intelligently. The progressive incremental backup method reduces the duplication inherent in backups, so when we look at equivalent ratios for Tivoli Storage Manager backup data, they do not flatter the deduplication equipment so much. What we are really seeing here is how much more efficient Tivoli Storage Manager is at avoiding duplicates in the first place, than the traditional approach. We have tried to avoid un-necessary duplication, and in some ways Tivoli Storage Manager is still more efficient: for example, doing full backups every day still requires the processor, disk and network resources to move all the data to the deduplication system. With Tivoli Storage Manager and progressive incremental backups, we avoid reading a lot of that data, so we avoid using the resources. Add subfile backups to the solution, and we only move the parts of the files that have changed, further reducing the redundancy, before the data ever gets to the Tivoli Storage Manager Server.

7.1.3 Tivoli Storage Manager V6.1 deduplication overview

In this section we introduce the Tivoli Storage Manager V6.1 specifics of deduplication in the context of the features already present, which reduce deduplication at the source.

Tivoli Storage Manager has contained a duplication avoidance strategy since its inception as WDSF in 1990—the progressive incremental backup methodology. This reduces the amount of duplicates for backup data coming into the server, although in a fairly simple fashion. It only backs up files that have changed—for example, one can simply change the modification data of a file and Tivoli Storage Manager will need to back it up again. In terms of effect on stored data, this is similar to data deduplication at the file level—we are reducing the redundant data at source by not backing up the same file content twice.

Since Tivoli Storage Manager 4.1, there has been a feature called adaptive subfile backup. This allows for the blocks of data changed within a file to be sent over the network to the Tivoli Storage Manager Server, as opposed to all the blocks: essentially like a block-level incremental backup. As such, it forms another type of duplication avoidance. It has some limitations—it currently only works with files up to 2 GB, and the reconstruction of the data during restore causes additional workload on the Tivoli Storage Manager Server over regular incremental workloads. It is most useful for backups where the client has very limited network access to the Tivoli Storage Manager Server, such as a branch office or a mobile device.

Tivoli Storage Manager V6.1 is capable of deduplicating data at the server. It performs deduplication out of band, in Tivoli Storage Manager server storage pools. Deduplication is only performed on data in FILE (sequential disk) devtype storage pools—it does not deduplicate DISK (random disk) storage pools, or tape storage pools. In addition, data deduplication has to be enabled by the Tivoli Storage Manager administrator on each pool individually, so it is possible to deduplicate those types of data which will benefit most, as opposed to everything. There is no requirement for it to be enabled for all pools.


Data is deduplicated after ingestion, in order to allow the Tivoli Storage Manager server to accept data without the possibility of having to slow down in order to deduplicate inline. When migrating or copying from the FILE devtype pools to tape, Tivoli Storage Manager V6.1 does not store the deduplicated version of the data on tape devclass devices, instead it reconstructs the data so that full copies are stored on tape. This is to aid processing for recoveries, which could otherwise become difficult to manage.

If Tivoli Storage Manager V6.1 had implemented deduplication with a fixed chunk size, the statistical probability of a collision would be to the order of 50% at 280 hashes. Because Tivoli Storage Manager varies its chunk size and uses that as part of the comparison, the possibility is made even more remote (something less remote than 50% probability at 2100 hashes) whereas a single Tivoli Storage Manager server is currently architecturally capable of storing 263 bitfile objects, itself impossible because of limitations in other places (for example, storage pool space to store the data from so many objects). The probability of a collision is very remote indeed. The average chunk size is typically about 250 KB, although Tivoli Storage Manager V6.1 varies this as needed between 2 KB and 4 MB.

Before Tivoli Storage Manager chunks the data at a bit file object level, it calculates an MD5 of all the objects in question, which are then sliced up into chunks. Each chunk has an SHA1 hash associated with it, which is used for the deduplication. The MD5s are there to verify that objects submitted to the deduplication system are reformed correctly, because the MD5 is recalculated and compared with the saved one to ensure that returned data is correct.

Table 7-1 shows an overview of data deduplication in Tivoli Storage Manager V6.1.

Figure 7-1 Data deduplication summary


7.1.4 Should we use Tivoli Storage Manager, or VTL/Filer deduplication?

The deduplication feature built into the Tivoli Storage Manager V6.1 server gives rise to a common question when designing new backup implementations: “Should we use Tivoli Storage Manager for deduplication, or should we use a deduplicating VTL or filer?”.

The answer depends on the size of the Tivoli Storage Manager solution being designed, and the availability (or cost) of alternative deduplication products. Tivoli Storage Manager V6.1’s deduplication system is implemented in the server code, and is included as a regular, base feature of Tivoli Storage Manager Enterprise Edition so there is no additional license cost for it. As with any software, there is a requirement to supply the correct hardware resources to make it perform as required. When sizing a system such as this, we have to remember to allocate processor resources, and also database space to the deduplication effort.

Experienced administrators already know that Tivoli Storage Manager database expiration was one of the more processor-intensive activities on a Tivoli Storage Manager Server. Expiration is still processor intensive, albeit less so in Tivoli Storage Manager V6.1, but this is now second to deduplication in terms of consumption of processor cycles. Calculating the MD5 hash for each object and the SHA1 hash for each chunk is a processor intensive activity. In order to store the hash table that allows deduplication to work, one must also consider extra Tivoli Storage Manager database and log space because this is where the hashes are stored after they are calculated. Depending on the amount of data being deduplicated, this could in some cases double the required space in the database, so it is something that really requires consideration.

Sizing deduplicationSizing the deduplication in Tivoli Storage Manager versus externally in a VTL or similar method is a judgement related to the system performance required.

These are some reasons to consider Tivoli Storage Manager deduplication:

� If you have a large preexisting disk storage pool and want to leverage this feature� If you have CPU cycles available that are not already in use� With Tivoli Storage Manager’s new expiration algorithm, your Tivoli Storage Manager

server might now have CPU/bandwidth available over Tivoli Storage Manager V5.� If you cannot consider alternatives for cost, support, power, or other reasons� If your installation is too small to effectively use an alternative deduplication method

Here are some reasons to consider ProtecTIER or a similar deduplication device:

� If your Tivoli Storage Manager server is already CPU, memory, or disk IO constrained� If deduplication across Tivoli Storage Manager servers is desired� If replication between sites of the deduplicated store is required

For environments with many Tivoli Storage Manager Servers, or with larger amounts of data, we recommend looking at platforms such as the IBM ProtecTIER product as best practice. Apart from scaling to very large sizes (at the time of writing, a single ProtecTIER cluster handles 1PB of real (non-deduplicated) storage at access rates over 900 MB/sec), it also opens the door to deduplication between separate Tivoli Storage Manager Servers, something Tivoli Storage Manager’s internal deduplication does not currently allow, as well as other benefits like inline deduplication, IP-based replication of stores and so on.

An additional recommendation is to use storage media with fast access characteristics for Tivoli Storage Manager deduplication. We recommend SSD or SAS/FC over SATA disks, if deduplication performance is an issue. Random read I/O is most of the profile seen during deduplication processing, so concentrating on that has the best effect for deduplication.


7.2 Implementing deduplication

A Tivoli Storage Manager V6.1 server can deduplicate data from any currently supported Tivoli Storage Manager V5.x client, as well as data from the Tivoli Storage Manager V6.1 client. If possible, you should use the Tivoli Storage Manager V6.1 (or later) client because it contains some changes specifically designed to make the deduplication process more efficient. Some of the underlying communication protocols have been revised so that they send metadata first, and data later, allowing the Tivoli Storage Manager V6.1 server to process the data sections for deduplication slightly more effectively than the older clients. Because the Tivoli Storage Manager server performs the deduplication, and performs it at a storage pool level, it is also possible to deduplicate data already backed up (potentially under older versions of Tivoli Storage Manager).

In order to allow deduplication, it is important that the Tivoli Storage Manager client does not encrypt the data before it comes to the Tivoli Storage Manager server. Should this happen, deduplication would not achieve any useful results: on the contrary, it would simply waste processor resources, IO resources, and database space. For this reason, Tivoli Storage Manager has been improved so that encrypted files are marked as such in the Tivoli Storage Manager database, and not processed for deduplication.

Customers who have Tivoli Storage Manager clients that are required to encrypt data (for example, branch offices in an organization) are recommended to continue to store that data in the current manner for the moment, using a storage pool without deduplication enabled. Data can still be encrypted on tape drives supporting those features as they currently are, unaffected by deduplication.

For customers who use client-side compression (for example, due to limited network bandwidth), deduplication on the server will not be as effective as though the data was not compressed, but it still works surprisingly well with most compressed files. The Tivoli Storage Manager Client implements compression using an LZW-based algorithm with a 32 KB working window, so where the changes are outside this window, there are good possibilities for the Tivoli Storage Manager Server to be able to deduplicate chunks of similar compressed files.

There are new server options and commands available to control deduplication on Tivoli Storage Manager V6.1 servers. There is an option available to ensure that only data which is already backed up into a Tivoli Storage Manager copy storage pool can be deduplicated. If this is set to “yes” (which is the default), then data will only be processed for deduplication if it has been safeguarded previously by a storage pool backup.

Note: In terms of sizing Tivoli Storage Manager V6.1 deduplication, we currently recommend using Tivoli Storage Manager to deduplicate up to 6 TB total of storage pool space for the deduplicated pools. This is a rule of thumb only and exists solely to give an indication of where to start investigating VTL or filer deduplication. The reason that a particular figure is mentioned is for guidance in typical scenarios on commodity hardware. If more than 6 TB of real diskspace is to be duplicated, you can either use Tivoli Storage Manager or a hardware deduplication device. The 6 TB is in addition to whatever disk is required by non-deduplicated storage pools. This rule of thumb will change as processor and disk technologies advance, because the recommendation is not an architectural, support, or testing limit.


In order to expedite an example of this, the first thing that we do here is disable the feature as shown in Example 7-2.

Example 7-2 Disabling the default “deduprequiresbackup” feature

tsm: UTAH-TSM1>setopt deduprequiresbackup no

Do you wish to proceed? (Yes (Y)/No (N)) yANR2119I The DEDUPREQUIRESBACKUP option has been changed in the options file.

tsm: UTAH-TSM1>

Now we must set up a file-type device class. In the example, this is called “dedupe,” although we could have named it any way we wanted as with any other device class. We then create a new primary sequential storage pool called “dd”, on our new device class. Note that during the creation of this, we specify the deduplicate=yes parameter, and the number of identify processes along with the usual storage pool creation parameters (see Example 7-3).

Example 7-3 Setting up a declass and deduplicated storage pool

tsm: UTAH-TSM1>define devclass dedupe devtype=file mountl=20 maxcap=100m dir=/tsmstgANR2203I Device class DEDUPE defined.

tsm: UTAH-TSM1>define stgpool dd dedupe maxscr=100 deduplicate=yes identifyprocess=3ANR2200I Storage pool DD defined (device class DEDUPE).

We have set up an example with a regular random disk storage pool with 10 GB of space available, under the default “backuppool” storage pool. We put 3.7 GB of backup data into it, as shown in Example 7-4.

Example 7-4 Our random diskpool containing 3.7 GB of data

tsm: UTAH-TSM1>q stg

Storage Device Estimated Pct Pct High Low Next Stora-Pool Name Class Name Capacity Util Migr Mig Mig ge Pool Pct Pct----------- ---------- ---------- ----- ----- ---- --- -----------ARCHIVEPOOL DISK 0.0 M 0.0 0.0 90 70BACKUPPOOL DISK 10 G 37.0 37.0 90 70 DDDD DEDUPE 10 G 0.0 0.0 90 70SPACEMGPOOL DISK 0.0 M 0.0 0.0 90 70

tsm: UTAH-TSM1>

Now we migrate from “backuppool” to “dd” using the “nextstg” parameter on the backuppool pointing to our new “dd” pool.

Example 7-5 Migrate STGPOOL

tsm: UTAH-TSM1>migrate stg backuppool lo=0ANR2110I MIGRATE STGPOOL started as process 5.ANR1000I Migration process 5 started for storage pool BACKUPPOOL manually, highMig=90, lowMig=0, duration=No.ANS8003I Process number 5started.

tsm: UTAH-TSM1>


At this point, Tivoli Storage Manager starts processing the data for deduplication. We then run reclamation on the dd storage pool so volumes principally emptied out by the deduplication can be reclaimed.

In terms of how deduplication processing works on the Tivoli Storage Manager Server, it looks slightly different if compared with other processes. Running the query process command on a server where a storage pool has deduplication enabled will always return some identify processes. From Tivoli Storage Manager V6.1.2 onward, these are called Identify Duplicates processes.

These processes look for chunks of duplicated data, and there can be from one to twenty of them per storage pool. If there is no deduplication backlog, the deduplication processes will show up as idle. The deduplication processes are different because they stay resident—they do not terminate when they finish work, instead, they go to an “idle” mode until they are needed again, as shown in Example 7-6.

Example 7-6 Deduplication “Identify” Processes in idle mode, Tivoli Storage Manager V6.1.0

tsm: UTAH-TSM1>q pro

Process Process Description Status Number-------- -------------------- ------------------------------------------------- 2 Identify Process Storage pool: DD. Volume: NONE. State: idle. State Date/Time: 06/10/09 14:32:14. Current Physical File(bytes): 0. Total Files Processed: 0. Total Duplicate Extents Found: 0. Total Duplicate Bytes Found: 0. 3 Identify Process Storage pool: DD. Volume: NONE. State: idle. State Date/Time: 06/10/09 14:32:14. Current Physical File(bytes): 0. Total Files Processed: 0. Total Duplicate Extents Found: 0. Total Duplicate Bytes Found: 0. 4 Identify Process Storage pool: DD. Volume: NONE. State: idle. State Date/Time: 06/10/09 14:32:14. Current Physical File(bytes): 0. Total Files Processed: 0. Total Duplicate Extents Found: 0. Total Duplicate Bytes Found: 0.

tsm: UTAH-TSM1>

In addition to these new processes, deduplication has some effects on already existing processes. When Tivoli Storage Manager deduplication runs, it dereferences objects no longer required by Tivoli Storage Manager in a similar way as expiration does, and in common with expired objects on sequential media, we must run reclamation in order to recover the space on those volumes. As part of an administrative schedule or maintenance plan, we would usually run reclamation after deduplication.


Another command affected by deduplication is the query stgpool command, which now shows three extra pieces of information (see Example 7-7).

Example 7-7 Query STGPool including new deduplication information

tsm: UTAH-TSM1>q stg dd f=d

Storage Pool Name: DD Storage Pool Type: Primary Device Class Name: DEDUPE Reclamation Type: Threshold Overwrite Data when Deleted:... Deduplicate Data?: YesProcesses For Identifying Duplicates: 3 Duplicate Data Not Stored: 1,526 M (38%)

tsm: UTAH-TSM1>

Before enabling Tivoli Storage Manager deduplication on a previously existing server, we must understand the consequences. During initial deduplication processing, the Tivoli Storage Manager log file and database will grow. The log grows because the database will be processing lots of transactions, and the database grows to accommodate the table for hashes of objects and hashes for the chunks which enables deduplication to function.

The size of this table is proportional to the number of chunks and objects that Tivoli Storage Manager is processing. If we have a Tivoli Storage Manager server with a 30 GB DB, and we deduplicate every object in storage (because all of our objects are on a file-based storage pool), we might end up with a 70 GB Tivoli Storage Manager database, so it is important to have available database and log space when turning on deduplication in a live system.

Disabling deduplication does not delete the hash information for objects already chunked, so there is no way of simply going back to the 30 GB version of our database. In order to do that, we would have to remove the existing backup data either by expiring it, or by backing up the data to new nodes and then deleting the relevant file spaces. Even if we delete file spaces (thus de-referencing the objects in storage), Tivoli Storage Manager will still spend some time resolving the deduplication hashes in the background. This takes time—for example, it might take up to a day for changes to filter through on a very busy system.


Chapter 8. No-query restore changes

In this chapter we discuss the changes made to the server side of the no-query restore process (NQR).

8


8.1 Introduction

Tivoli Storage Manager restore processing is done in one of two models, Classic or No Query Restore (NQR).

The NQR reduces the memory requirement on Tivoli Storage Manager clients during restore and is optimized for large file systems. In installations with clients backing up very large client file systems or backup data spread over many volumes, performance issues were reported when the NQR technique is used and only very few files qualify as restore candidates.

The changes made to the NQR restore process, by exploiting the DB2 database, address these issues.

8.1.1 Proprietary NQR algorithm

The proprietary NQR algorithm, which is found to be extremely database intensive, is split into two phases:

1. Scan phase:

a. Scan backup objects table according to the restore file specification.

b. Store sequential volumes to process for later process in Restore.Objects.

c. Save disk objects for later processing in Restore.Objects.

2. Restore phase:

a. Use Restore. Objects to obtain volumes for restore (multiple sessions).

b. Restore objects from disk directly.

c. For sequential volumes.

i. Start a scan using file specification, looking for files on the volume that match file specification.

ii. For aggregates found on the volume, start a subscan of entries within the aggregate.

d. When a batch of files has accumulated, restore the batch.

Phase 1 and phase 2, with the proprietary NQR implementation, might run simultaneously.

8.1.2 Objectives of the new NQR process

The changes made to the proprietary NQR algorithm were implemented with the following objectives:

� Improve the prior algorithm:

– Provide consistent performance through Classic restore and NQR– Prevent multiple restores of the same file– Prevent failure to restore certain directories

� Exploit the DB2 environment; simplify the NQR process.

� Maintain compatibility with Tivoli Storage Manager Version 5 storage agents.

� Maintain retrieval by position on tape volumes.

� Make no changes to restore externals.

� Have no new messages.


8.1.3 New NQR process

The new NQR process still is split into two phases, but phase one must be completed before phase two can be started.

1. Search phase:

a. Scan backups table using file specification;Make extensive use of custom SQL in retrievals from backups table.

b. Save sequential volume information for phase 2 in Restore.Srvobj.

c. Save disk objects in Restore.Srvobj.

d. Save sequential objects in Restore.Srvobj.

2. Restore phase:

a. Use Restore.Srvobj to obtain volumes from which to restore (multiple sessions).

b. Restore disk entries directly.

c. Use SQL to retrieve objects from Restore.Srvobj which are on the volume from which this session is restoring.

d. When a batch of files has accumulated, restore the batch.

If a restore originates from a pre-Tivoli Storage Manager V6.1 storage agent, the data base queries are translated to access Restore.Srvobj. The new NQR process still supports restartable restores, but information is stored so that restarts occur only at a volume boundary.

Next we provide examples from a synthetic test restoring 178 objects out from 16-node backups of 86.655 million 1 KB files, across 230 file storage volumes. The numbers were collected under lab conditions; numbers for production servers will differ of course.

Tivoli Storage ManagerV5.5 NQR restore exampleExample 8-1 shows the restore statistics for a long running NQR type of restore. This represents the problematic restore: It takes about 2.5 hours to restore 204 KB worth of data. For this restore scenario, a Tivoli Storage Manager CPU load of about 4% was observed.

Note: During data base migration from Tivoli Storage Manager Version 5 to Version 6, restartable restores are not migrated.

Chapter 8. No-query restore changes 157

Example 8-1 V5.5 NQR restore example

Session established with server MERLOT1: Solaris SPARC Server Version 5, Release 5, Level 0.0 Server date/time: 06/24/2009 18:56:00 Last access: 06/24/2009 15:36:15

Total number of objects inspected: 178Total number of objects restored: 178Total number of objects updated: 0Total number of journal objects: 0Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 0Total number of objects failed: 0Total number of bytes transferred: 204.92 KBLanFree data bytes: 0 BData transfer time: 8,519.75 secNetwork data transfer rate: 0.02 KB/secAggregate data transfer rate: 0.02 KB/secTotal number of bytes pre-compress: 0Total number of bytes post-compress: 0Objects compressed by: 0%Elapsed processing time: 02:28:12Average file size: 0 B

Tivoli Storage ManagerV5.5 Classic restore exampleThe same restore scenario forced to Classic restore by DISABLENQR YES option completed in about 25 seconds. But this requires us in advance to distinguish between NQR or Classic restore methodology. Example 8-2 shows the numbers for the Classic restore. For this restore scenario, a Tivoli Storage Manager CPU load of about 2% was observed.

Example 8-2 Tivoli Storage Manager V5.5 Classic restore example


Total number of objects inspected: 178Total number of objects restored: 178Total number of objects updated: 0Total number of journal objects: 0Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 0Total number of objects failed: 0Total number of bytes transferred: 204.92 KBLanFree data bytes: 0 BData transfer time: 1.02 secNetwork data transfer rate: 199.34 KB/secAggregate data transfer rate: 49.01 KB/secTotal number of bytes pre-compress: 0Total number of bytes post-compress: 0Objects compressed by: 0%Elapsed processing time: 00:00:04Average file size: 0 B


Tivoli Storage Manager V6.1 enhanced NQR restore exampleExample 8-3 shows the restore statistics using NQR restore with a V6.1 client, we get about the same restore numbers without having to configure for this scenario. For this restore scenario, a Tivoli Storage Manager CPU load of about 5% was observed.

Example 8-3 V6.1 enhanced NQR restore


Total number of objects inspected: 178Total number of objects restored: 178Total number of objects updated: 0Total number of journal objects: 0Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 0Total number of objects failed: 0Total number of bytes transferred: 204.92 KBLanFree data bytes: 0 BData transfer time: 0.01 secNetwork data transfer rate: 13,661.91 KB/secAggregate data transfer rate: 33.00 KB/secTotal number of bytes pre-compress: 0Total number of bytes post-compress: 0Objects compressed by: 0%Elapsed processing time: 00:00:06Average file size: 0 B

Again, note that these numbers were collected for a synthetic test. Values for a production environment will vary depending on server load, object distribution, and other effects that might impact performance.

8.2 Summary

With the transition to DB2 and the changes made to the NQR process, you get comparable restore performance without having to configure anything.

Chapter 8. No-query restore changes 159

Chapter 9. Expiration enhancements

In this chapter we discuss the enhancements to the Tivoli Storage Manager V6.1 server EXPIRATION process and the externals that are introduced with the changed process.

9


9.1 Introduction

The Tivoli Storage Manager expiration process deletes server objects from the database that no longer conform to the rules in associated management classes.

9.1.1 Proprietary expiration algorithm

The Tivoli Storage Manager expiration processing, as available with previous versions of the product, historically suffers from two issues, efficiency and flexibility:

� Efficiency:

Over the years that the Tivoli Storage Manager is available, the amount of data managed by a single server instance grew significantly. This data growth can be the number of clients supported by a server, the number of objects belonging to a given client, or both. Until today, expiration is a single process that is only able to use a pair of threads. The two threads used performed two different tasks:

a. The first thread scans the Expiring.Objects table trying to identify candidates that could be deleted.

b. The second thread deletes batches of files that the first thread identified as eligible for deletion.

Figure 9-1 explains the proprietary expiration algorithm available with Tivoli Storage Manager versions earlier than V6.

Figure 9-1 Proprietary expiration algorithm

Search thread

{ scan Expiring.Objects table { oldest entry forward apply policies to each entry if entry eligible for deletion { add entry to batch. if batch full { dispatch to Deletion thread. } } }}

Deletion thread

{ wait for dispatch while item in batch { delete object }}

Algorithm only used two threads.

Search algorithm could scan a lot of objects that were not actually eligible for expiration.


� Flexibility:

Many administrators expressed the desire to be able to run expiration on specific nodes. This would allow them to clean up from some sort of policy error or change or to simply expire out old data for a client node that was consuming a large amount of space in the storage hierarchy.

This flexibility is partly available in the proprietary expiration processor. For instance, you are allowed to specify a sequential range of node IDs by undocumented options (begin node ID/end node ID). There is no ability to specify multiple nodes that are not sequentially aligned within the expiration table. This also requires that you have knowledge of node IDs. Because there is no documented procedure how to retrieve the node IDs, most of the time a service call was necessary to exploit the function.

9.1.2 Objectives of the new expiration process

With Tivoli Storage Manager V6.1 and the transition to the DB2 database, extensive changes were needed. In particular, changes to the server schema were done to exploit the DB2 capabilities and to eliminate redundancy in the base tables and the meta-data representation that the Tivoli Storage Manager server uses.

One significant change for Tivoli Storage Manager V6.1 and the inventory tables is the elimination of the Expiring.Objects database table. This table was used to represent objects that could be expired (deleted) by the expiration process. This table duplicated information from the base Archive.Objects and Backup.Objects tables. Similarly, the existing expiration algorithm and processing was tightly coupled to the layout of this table and the organization of the data within this table.

As an example, the expiration processing relied upon the ordering of records in order to skip (exclude) records that could not be expired based on current policy settings. The algorithm and processing of the expiration code itself was coded to exploit this data ordering and some existing (proprietary) database capability to exclude objects on a fetch records request.

The Tivoli Storage Manager V6.1 expiration algorithm:

� Exploits DB2 SQL capabilities:

– Reduces processing overhead by only looking at candidates relative to a given policy– Accommodates new table schemes for inventory tables– Eliminates Expiring.Objects table

� Delivers long-standing enhancement requests:

– Expire by node or list of nodes– Expire by domain– Expire by type of data (backup, archive, other)– Increased throughput– Better visibility into what is happening:

• What node/fs/datatype is being processed• When is a given node/fs/datatype finished• How much was examined and deleted for each

� Preserves:

– Restart ability– Command initiated (command or administrative schedule)– Server initiated (based on EXPINTERVAL)

Chapter 9. Expiration enhancements 163

9.1.3 Enhanced Tivoli Storage Manager V6.1 expiration algorithm

The new expiration algorithm provides the efficiency and flexibility that Tivoli Storage administrators have requested for a long time. Figure 9-2 explains the new algorithm. Compare this against Figure 9-1 on page 162.

Figure 9-2 New expiration algorithm

Not only has the dispatch thread logic changed to take advantage of the new server database schema, you now can also define how many threads you want to allow for expiration by the RESOURCE parameter.

9.2 Externals of the enhanced expiration

Here we describe new command line options, integration into the Administration Center and new messages that became available with the enhance expiration processing.

9.2.1 Command line changes

The Tivoli Storage Manager V6.1 expiration introduces additional parameters to the EXPIRE INVENTORY command, NODE, DOMAIN, RESOURCE, and TYPE. Example 9-1 documents the old and the new options, and we discuss the new parameters after that.

New expiration algorithmDispatch thread{ setup expiration resolve command parameters { generate list of candidate NODES to process determine type of objects to process if restart records exist { retrieve restart records } } start expiration thread up to N nodes}

Expiration thread(s){ if there is a restart record available { load it and process } else { acquire NEXT Node from to-do list } for each filespace { for each management class { for each object type { find eligible file { call imDeleteObject } } } }}

Multiple threads are being run under a single expiration process.


Example 9-1 EXPIRE INVENTORY processing options

.-Quiet--=--No------.

>>-EXPIre Inventory--+-------------------+----------------------> '-Quiet--=--+-No--+-' '-Yes-' .-Wait--=--No------. .-SKipdirs--=--No------. >--+------------------+--+----------------------+---------------> '-Wait--=--+-No--+-' '-SKipdirs--=--+-No--+-' '-Yes-' '-Yes-' .-Node--=--*------------------. >--+-----------------------------+------------------------------> '-Node--=---node1,node2,...---' >--+-------------------------------------+----------------------> '-DOmain--=----domainName-------------'

.-REsource--=--4--------. >--+-----------------------+------------------------------------> '-REsource--=--value--+-'

.-Type--=--ALl---------. >--+----------------------+-------------------------------------> '-Type--=--+-ALl-----+-' |-ARchive-| |-Backup--| '-Other---'

>--+-----------------------+-----------------------------------? '-DUration--=--minutes-'

Table 9-1 documents different combinations for the new parameters to the expiration command, valid and invalid ones, and the expected results. Use the examples as a starting point to review your current expiration schedules.

Table 9-1 Sample expiration process NODE and DOMAIN parameter combinations

Node value Domain value Result

None None All nodes for all domains will be processed.This is the default behavior.

* * Invalid – domain cannot be wild carded.

* None All nodes for all domains will be processed.

None DOMAIN=xxx All nodes assigned to the specified domain will be processed.

None DOMAIN=xxx* Invalid – domain cannot be wild carded.

NODE=DEPT_A* DOMAIN=xxx All nodes matching the pattern DEPT_A* that are assigned to domain XXX will be processed.

NODE=A,B,C,D* None Nodes A, B, C and any matching the pattern D* will be processed.


� The expiration process TYPE parameter allows you to define which specific data types to expire. You can specify one of the four following values, with ALL being the default:

– ARCHIVE: Process only archive data for the candidate nodes.

– BACKUP: Process only backup data for the candidate nodes.

– OTHER: Process remote DRM recovery plan files and database backups from the volume history.

– ALL: Process all eligible data (Archive, Backup, and Other)

� The expiration process RESOURCE parameter specifies the number of threads that can run in parallel. Specify a number from 1 to 10.

The resources represent parallel work by the server within the single expiration process (expiration still runs as a single process).

For example, if you specify:

– NODE=X,Y,Z and RESOURCE=3 (or greater), then expiration processing for the three client nodes X, Y, and Z runs in parallel.

– NODE=X,Y,Z and RESOURCE=5, then expiration processing for the three client nodes runs in parallel, and the extra two resources are ignored.

9.2.2 Administration Center integration: Expiration

The enhanced expiration processing options are available with the Administration Center.

From the Administration Center’s Tivoli Storage Manager view (see Figure 9-3), you want to invoke expiration for server UTAH_TSM1. Select the target server from the Tivoli Storage Manager view and click Server Maintenance.

Figure 9-3 Administration Center: Server maintenance


Open the Select Action drop-down list and click Expire Inventory as shown in Figure 9-4.

Figure 9-4 Administration Center: Select action


From the Expire Inventory window for server UTAH_TSM1, as shown in Figure 9-5, you can specify all the options to fit your needs. This window supports all new parameters, the number of threads to be utilized, which data to process, domain, and node selection. For the domain parameter, you can select the domain from a list of available domains configured to your system.

Figure 9-5 Administration Center: Expiration options

9.2.3 Administration Center integration: maintenance script

Here we describe the task to generate a maintenance script using the Administration Center and explain the enhanced expiration integration. We do not document all the panels that you have to go through, but show the basic steps. From the Maintenance Script panel, first select the server—in our case UTAH_TSM1—as shown in Figure 9-6. From the Select Action drop-down menu, click Create Maintenance Script.


Figure 9-6 Administration Center: Create a maintenance script

The maintenance script wizard includes the following tasks:

� Back up primary storage pools� Copy active data from a primary pool to an active-data pool� Back up the server database� Identify the copy storage pool and database backup volumes to be moved� Create a disaster recovery plan file� Migrate stored data from primary storage pools to secondary storage pools� Remove expired data from server storage� Reclaim fragmented tapes by consolidating active data

Here you are looking at the expiration task only, so after the wizard’s Welcome panel, you are guided through the definitions for database backup and storage pool migration before you are presented with the Expire Stored Data window (see Figure 9-7). In this scenario we specify the expiration process to run for 20 minutes with 8 threads. After this has completed, click Next to continue.

Figure 9-7 Administration Center: Maintenance wizard expiration settings


Again, the wizard prompts you, now with the definitions for reclamation and maintenance scheduling. Finally, before you click Finish, you are asked to review the settings specified in the wizard as shown in Figure 9-8. The settings that you made in the expiration wizard are listed under the Expire Stored Data section.

Figure 9-8 Administration Center: maintenance wizard review window

9.2.4 New server messages

With the expiration process enhancements, there are new server messages (Example 9-2).

Example 9-2 Expiration completion messages

ANR2017I Administrator ADMIN issued command: EXPIRE INVENTORYANR0984I Process 2 for EXPIRE INVENTORY started in the BACKGROUND at 09:24:56.ANR0811I Inventory client file expiration started as process 2...lines deleted..ANR0165I Inventory file expiration started processing for node OLDSKOOL,filespace \\gallium\g$, copygroup BACKUP and object type FILE.ANR2017I Administrator ADMIN issued command: QUERY PROCESSANR0166I Inventory file expiration finished processing for node OLDSKOOL,filespace \\gallium\g$, copygroup BACKUP and object type FILE with processingstatistics: examined 9649, deleted 9649, retrying 0, and failed 0.ANR2369I Database backup volume and recovery plan file expiration startingunder process 2...lines deleted..ANR0167I Inventory file expiration process 2 processed for 13 minutes.ANR0812I Inventory file expiration process 2 completed: processed 8 nodes,examined 239685 objects, deleting 239685 backup objects, 0 archive objects, 0DB backup volumes, and 0 recovery plan files. 0 objects were retried and 0errors were encountered.ANR0987I Process 2 for EXPIRE INVENTORY running in the BACKGROUND processed239685 items with a completion state of SUCCESS at 09:38:23.


Have a look at the statistics here: While the expiration methodology did not change much, the exploitation of DB2 allows the algorithm to be much more efficient, in most cases the expiration process inspects only what is eligible for expiration. However, you might see more objects inspected related to the number of objects expired when processing expiration for example on backup set objects, DRM plan files or a retention enabled server.

For each node, file space, data type, and object type processed, the ANR0165I and ANR0166I messages are reported as with Example 9-3.

Example 9-3 Expiration messages ANR0165I and ANR0166I

ANR2017I Administrator SERVER_CONSOLE issued command: EXPIRE INVENTORY node=capitola,monterey,pleasanton reso=3 type=backupANR0984I Process 1 for EXPIRE INVENTORY started in the BACKGROUND at 10:48:59.

(PROCESS: 1)ANR0811I Inventory client file expiration started as process 1. (PROCESS: 1)ANR0165I Inventory file expiration started processing for node PLEASANTON,

filespace \1000000KB_of_10KB, copygroup BACKUP and object type FILE. (PROCESS: 1)

ANR0166I Inventory file expiration finished processing for node PLEASANTON,filespace \1000000KB_of_10KB, copygroup BACKUP and object type FILE withprocessing statistics: examined 10004, deleted 10004, retrying 0, and failed 0.(PROCESS: 1)

ANR0165I Inventory file expiration started processing for node MONTEREY, filespace\1000000KB_of_10KB, copygroup BACKUP and object type FILE. (PROCESS: 1)

ANR0166I Inventory file expiration finished processing for node MONTEREY,filespace \1000000KB_of_10KB, copygroup

BACKUP and object type FILE with processing statistics: examined 90006, deleted90006, retrying 0, and failed 0. (PROCESS: 1)

ANR0167I Inventory file expiration process 1 processed for 7 minutes. (PROCESS: 1)ANR0812I Inventory file expiration process 1 completed: processed 3 nodes,

examined 100010 objects, deleting 100010 backup objects, 0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 0 objects were retried and 0errors were encountered. (PROCESS: 1)

ANR0987I Process 1 for EXPIRE INVENTORY running in the BACKGROUND processed 100010items with a completion state of SUCCESS at 10:56:24. (PROCESS: 1)

When expiration processes backup sets, as with Example 9-4, a different set of messages is reported, ANR0190I and ANR0191I. The summary records are cut each time an ANR0166I message is issued.

Example 9-4 Expiration messages ANR0190I and ANR0191I

ANR0190I Inventory file expiration started processing node ALMADEN for backup sets...lines deleted..ANR0191I Inventory file expiration finished processing node ALMADEN for backup

sets with processing statistics: examined 2, deleted 0, retrying 0, and failed 0.

The output returned by the QUERY PROCESS command has changed; see Example 9-5. Remember that the number of nodes reported includes in-flight nodes.


Example 9-5 QUERY PROCES command expiration record

Expiration Processed 8 nodes, examined 134746 objects, deleting 134746 backup objects, 0 archive objects, 0 DB backup volumes, 0 recovery plan files; 0 objects have been retried and 0 errors encountered.

9.2.5 Expiration restart

If an expiration process is cancelled prior to completion, a subsequent expiration process will pick up from the same place that the last one left off.

The key difference between Tivoli Storage Manager V6.1 and earlier versions of the product is that the expiration command allows for many variations that did not previously exists—and as such, the restart tracking model is extended to track restart position information using the command itself as the identifier for that information. The restart position is only honored if the expiration commands are exactly the same.

This gives you the ability to have an expiration model that much better fits your requirements. For example, you can do expiration of archives weekly while performing expiration of backup data daily. In the event that the expiration of the archive data does not complete in a single session, the next weekly run picks up where it left off without the intervening expiration of backup data processes interfering.

As an example, you might have three different expiration commands scheduled throughout the week. Each of the three commands would have its own restart position, if it was cancelled prior to completion:

� If a command is re-issued and there is a matching restart position, expiration finishes processing those in-flight nodes and then any other nodes that had not been processed and that were candidates to be processed for that expiration run.

� If restart data exists for a given expiration and the command has not been re-executed for two weeks (14 days), the “stale” restart data is deleted such that the next time this expiration command is run, it will start from the beginning.

� The deletion of the stale expiration restart information happens as a part of expiration processing itself—at the end of the process while cleaning up the existing process and information it checks for and deletes any stale restart information.

� After all candidate nodes for that expiration have been processed, across however many restarts that might be, the expiration process will complete and the restart tracking will be cleaned up because there is no longer a restart position to track.

Example 9-6 shows the ANR4896I message issued in case of an expiration restart. We use the domain parameter with the expire command to process only nodes for domain OTHERDOMAIN.

Example 9-6 ANR4896I: expiration restart message

ANR2017I Administrator SERVER_CONSOLE issued command: EXPIRE INVENTORY reso=2dom=otherdomainANR0984I Process 1 for EXPIRE INVENTORY started in the BACKGROUND at 08:57:04.ANR0811I Inventory client file expiration started as process 1...lines deleted..


ANR2017I Administrator SERVER_CONSOLE issued command: CANCEL PROCESS 1ANR0940I Cancel request accepted for process 1...lines deleted..ANR0167I Inventory file expiration process 1 processed for 1 minutes.ANR0813I Inventory file expiration process 1 canceled prior to completion:processed 4 nodes, examined 11 objects, deleting 10 backup objects, 0 archiveobjects, 0 DB backup volumes, and 0 recovery plan files. 0 objects were retriedand 0 errors were encountered.ANR0987I Process 1 for EXPIRE INVENTORY running in the BACKGROUND processed 11items with a completion state of SUCCESS at 08:58:05...lines deleted..ANR2017I Administrator SERVER_CONSOLE issued command: EXPIRE INVENTORY reso=2dom=otherdomainANR0984I Process 2 for EXPIRE INVENTORY started in the BACKGROUND at 08:59:38.ANR0811I Inventory client file expiration started as process 2.ANR4896I Inventory client file expiration is restarting process 1 from06/19/2009...lines deleted..ANR2017I Administrator SERVER_CONSOLE issued command: CANCEL PROCESS 2ANR0940I Cancel request accepted for process 2...lines deleted..ANR0987I Process 2 for EXPIRE INVENTORY running in the BACKGROUND processed5893 items with a completion state of SUCCESS at 09:00:23.ANR2017I Administrator SERVER_CONSOLE issued command: QUERY PROCESSANR2017I Administrator SERVER_CONSOLE issued command: EXPIRE INVENTORY reso=2dom=otherdomainANR0984I Process 3 for EXPIRE INVENTORY started in the BACKGROUND at 09:00:48.ANR0811I Inventory client file expiration started as process 3.ANR4896I Inventory client file expiration is restarting process 2 from06/19/2009.ANR2369I Database backup volume and recovery plan file expiration startingunder process 3...lines deleted..ANR0167I Inventory file expiration process 3 processed for 2 minutes.ANR0812I Inventory file expiration process 3 completed: processed 1 nodes,examined 35003 objects, deleting 35003 backup objects, 0 archive objects, 0 DBbackup volumes, and 0 recovery plan files. 0 objects were retried and 0 errorswere encountered.ANR0987I Process 3 for EXPIRE INVENTORY running in the BACKGROUND processed35003 items with a completion state of SUCCESS at 09:02:57.


Consider the following scenario:

1. Expiration starts and determines that nodes A, B, C, D, E, F, G, H, I and J need to be processed.

2. Expiration completes processing nodes A and B; nodes C and D are in-flight at the time expiration is cancelled.

3. Expiration is invoked again and begins by processing C and D based on the restart information of what was previously done.

4. As C and D complete, expiration progresses to the remaining candidate nodes, which in this case would be E, F, G, H, and I.

5. Expiration then progresses in this manner across cancellations and restarts until all nodes from the original candidate list were completed.

6. After expiration completes processing all nodes from the original candidate list, a new EXPIRATION invocation resolves a new candidate node list and begins processing as just described.

Figure 9-9 explains the scenario we just described. For easier understanding, it assumes that the expiration payload is the same for all nodes.

Figure 9-9 Expiration restart processing

Now with all the new expiration parameters, you might wonder what happens if expiration is trying to expire a single node from multiple processes in parallel. We tried to expire the same node with two separate expiration commands and different parameters to make the commands distinct. Example 9-7 shows that the condition is detected and only one process expires the node’s data.

Example 9-7 Parallel expiration attempt for the same node

ANR2017I Administrator SERVER_CONSOLE issued command: EXPIRE INVENTORYnode=oldskool reso=1ANR0984I Process 1 for EXPIRE INVENTORY started in the BACKGROUND at 10:26:02.ANR0811I Inventory client file expiration started as process 1.ANR2017I Administrator SERVER_CONSOLE issued command: EXPIRE INVENTORY

EXPIRE INVENTORY NODES=A,B,C,D,E,F,GH,I,J RES=´4

NODE A NODE B NODE C NODE D NODE E NODE FWAIT WAIT

NODE G NODE HWAIT WAIT

NODE I NODE JWAIT WAIT

NODE C NODE D NODE E NODE F NODE G NODE H

NODE I NODE JWAIT WAIT

EXPIRATION RESTART

Cancel exp

EXPIRE INVENTORY NODES=A,B,C,D,E,F,GH,I,J RES=4

EXPIRE INVENTORY NODES=A,B,C,D,E,F,GH,I,J RES=4

Cancel exp

NODE G NODE H NODE I NODE J


node=oldskool reso=2ANR4298I Expiration thread already processing - unable to begin anotherexpiration process.

Then we tried the same procedure by defining a node group and we added the same node plan to expire to that group. Example 9-8 shows that the condition is detected again, in addition you see that you can invoke expiration on NODEGROUPS defined to the server.

Example 9-8 Parallel expiration attempt, node, and node group

TSM:TIRAMISU>def nodegroup expiregroupANR2017I Administrator SERVER_CONSOLE issued command: DEFINE NODEGROUPexpiregroupANR4780I Node group EXPIREGROUP defined.TSM:TIRAMISU>define nodegroupmember expiregroup oldskoolANR2017I Administrator SERVER_CONSOLE issued command: DEFINE NODEGROUPMEMBERexpiregroup oldskoolANR4789I Node OLDSKOOL associated to node group EXPIREGROUP.ANR4787I DEFINE NODEGROUPMEMBER: 1 members defined in the node groupEXPIREGROUP.TSM:TIRAMISU>expire inventory node=oldskoolANR2017I Administrator SERVER_CONSOLE issued command: EXPIRE INVENTORYnode=oldskoolANR0984I Process 1 for EXPIRE INVENTORY started in the BACKGROUND at 11:32:40.ANR0811I Inventory client file expiration started as process 1.TSM:TIRAMISU>..lines deleted..TSM:TIRAMISU>expire inventory node=EXPIREGROUPANR2017I Administrator SERVER_CONSOLE issued command: EXPIRE INVENTORYnode=EXPIREGROUPANR4298I Expiration thread already processing - unable to begin anotherexpiration process...lines deleted..ANR0167I Inventory file expiration process 1 processed for 1 minutes.ANR0812I Inventory file expiration process 1 completed: processed 1 nodes,examined 47 objects, deleting 47 backup objects, 0 archive objects, 0 DB backupvolumes, and 0 recovery plan files. 0 objects were retried and 0 errors wereencountered.ANR0985I Process 1 for EXPIRE INVENTORY running in the BACKGROUND completedwith completion state SUCCESS at 11:32:55.

If you see the ANR4298I message reported in your activity log, this might be caused by the fact that you configured the same node and type to different expiration jobs.


9.2.6 Expiration retries

During expiration, for example, because of lock contention, it might not be possible to delete an object to process. In this case expiration will retry the deletion of a file that has encountered a lock conflict. The fixed maximum number of retries is 5. If expiration cannot acquire the lock within the maximum number of retries, this deletion batch is flagged in error and the expiration process moves onto the next node.

For instance, if expiration retries a batch of files (such as 400), the expiration status message looks like Example 9-9.

Example 9-9 Expiration deletion retries

ANR0166I Inventory file expiration finished processing for node NODE1, filespace \\ibm-164391ac47a\c$, copygroup ARCHIVE and object type FILE with processing statistics: examined 400, deleted 400, retrying 400, and failed 0.

If the expiration process retries the same batch five times and still cannot acquire the necessary locks, the expiration status message reflects this as shown in Example 9-10. When this situation is encountered, expiration attempts to throttle back the number of files contained within the deletion transaction batch in an attempt to delete as much as possible and minimize risk of lock conflicts.

Example 9-10 Expiration retry number exceeded

ANR0166I Inventory file expiration finished processing for node NODE1, filespace \\ibm-164391ac47a\c$, copygroup ARCHIVE and object type FILE with processing statistics: examined 400, deleted 0, retrying 0, and failed 400.

The expiration process is robust against any locking problems that it might encounter and will retry the operation if a locking condition is met.

9.3 Summary

The Tivoli Storage Manager V6.1 enhancements to the server expiration process integrate the new database schema and provide:

� Improved efficiency, by abandoning the producer/consumer thread model. Each thread involved examines and deletes its own candidate list independent of the other threads that might be running. The workload is split up across the available number of threads designated by the RESOURCE value on the command.

� Improved flexibility, by giving you the ability to control for whom expiration is done and what is expired.


Chapter 10. Changes to the TXNGROUPMAX default

The changed TXNGROUPMAX default requires some more explanation. In this chapter we discuss how this option affects your backup and archive performance, server internal data movement operations, and log requirements.

10


10.1 Transaction handling

When client files are backed up or archived, the server can group them into an aggregate of files. By controlling the size of aggregates, you can control the performance of client operations.

The size of the aggregate depends on the sizes of the client files being stored, and the number of bytes and files allowed for a single transaction. Two options affect the number of files and bytes allowed for a single transaction. TXNGROUPMAX, located in the server options file, affects the number of files allowed. TXNBYTELIMIT, located in the client options file, affects the number of bytes allowed in the aggregate.

A transaction is the unit of work exchanged between the client and server. The client program can move multiple files or directories between the client and server before it commits the data to server storage.

A transaction can contain multiple files or directories. This is called a transaction group. Using the TXNGROUPMAX server option, you can specify the number of files or directories that are contained within a transaction group. A larger value for the TXNGROUPMAX option can affect the performance of client backup, archive, restore, and retrieve operations. You can use the TXNGROUPMAX option to increase performance when Tivoli Storage Manager writes to tape. This performance increase can be considerable when a user transfers multiple small files.

If you increase the value of TXNGROUPMAX by a large amount, you need to monitor the effects on the recovery log. A larger value can increase utilization of the recovery log, as well as increase the length of time for a transaction to commit. Also consider the number of concurrent sessions to be run. It might be possible to run with a higher TXNGROUPMAX value with a few clients running. However, if there are hundreds of clients running concurrently, you might need to reduce the TXNGROUPMAX to help manage the recovery log usage and support this number of concurrent clients. If the performance effects are severe, they might affect server operations. See “Monitoring the database space” on page 54 for more information.

10.1.1 TXNGROUPMAX option examples

The following examples show how the TXNGROUPMAX option can affect performance throughput for operations to tape and the recovery log:

� The TXNGROUPMAX option is set to 20. The MAXSESSIONS option, which specifies the maximum number of concurrent client/server sessions, is set to 5. Five concurrent sessions are processing, and each file in the transaction requires 10 logged database operations. This would be a concurrent load of:

20*10*5=1000

This represents 1000 log records in the recovery log. Each time a transaction commits the data, the server can free 200 log records. Over time and as transactions end, the recovery log can release the space that is used by the oldest transactions. These transactions complete, and the log space usage increases.

� The TXNGROUPMAX option is set to 2000. The MAXSESSIONS option is set to 5. Five concurrent sessions are processing, and each file in the transaction requires 10 logged database operations. This is a concurrent load of:

2000*10*5=100,000


This represents 100,000 log records in the recovery log. Each time a transaction commits the data, the server can free 20,000 log records. Over time and as transactions end, the recovery log can release the space that is used by the oldest transactions. These transactions complete, and the log space usage increases.

Based on the previous two examples, five concurrent transactions with a TXNGROUPMAX setting of 2000 consume significantly more space in the recovery log. This increase in log space usage also increases the risk of running out of recovery log space.

Table 10-1 shows a comparison of the examples of the preceding TXNGROUPMAX settings. This example becomes more significant if a given log record takes 100 bytes.

Table 10-1 Example of log bytes that are consumed by five concurrent sessions

10.1.2 Server options

You can use several server options to tune server performance and reduce the risk of running out of recovery log space:

� Use the THROUGHPUTTIMETHRESHOLD and THROUGHPUTDATATHRESHOLD options in conjunction with the TXNGROUPMAX option to prevent a slower performing node from holding a transaction open for extended periods.

� Increase the size of the recovery log when you increase the TXNGROUPMAX setting.

You should evaluate the performance and characteristics of each node before increasing the TXNGROUPMAX setting. Nodes that have only a few larger objects to transfer do not benefit as much as nodes that have multiple, smaller objects to transfer. For example, a file server benefits more from a higher TXNGROUPMAX setting than does a database server that has one or two large objects. Other node operations can consume the recovery log at a faster rate. Be careful when increasing the TXNGROUPMAX settings for nodes that often perform high log-usage operations. The raw or physical performance of the disk drives that are holding the database and recovery log can become an issue with an increased TXNGROUPMAX setting. The drives must handle higher transfer rates to handle the increased load on the recovery log and database.

You can set the TXNGROUPMAX option as a global server option value, or you can set it for a single node. Refer to the REGISTER NODE command and the server options in the Administrator’s Reference. For optimal performance, specify a lower TXNGROUPMAX value (between 4 and 512). Select higher values for individual nodes that can benefit from the increased transaction size.

10.2 Implementation example

To verify if your transaction boundaries are honored, you can use the undocumented SHOW TRANSFERSTATS <storage pool> command. You can use the command to verify storage pool migration and backup throughputs. The average logical files per physical file represent the aggregation and should be close to TXNGROUPMAX. The average physical file size should be close the TXNBYTELIMIT value. If you back up or archive a mix of large and small files, you need to take this into consideration when looking at the numbers.

TXNGROUPMAX setting Number of log bytes consumed

TXNGROUPMAX=20 100.000

TXNGROUPMAX=2000 10.000.000

Chapter 10. Changes to the TXNGROUPMAX default 179

Take a look at the following numbers collected in our lab. We make sure that we back up the data to a clean file system, 25000 files of 10 KB each. With the new TXNGROUPMAX default of 4096, we see the numbers reported in Example 10-1.

Example 10-1 Storage pool migration statistics, TXNGROUPMAX 4096

tsm: UTAH-TSM1>show transferstats backuppoolStatistics for last migration from pool BACKUPPOOL Start date/time: 06/12/09 01:07:03 Elapsed time: 10 seconds Total wait time: 0 seconds Number of participating processes: 1 Total duration of all processes: 10 seconds Total physical files: 7 Total logical files: 25000 Total bytes: 261603328 Average logical files per physical file: 3571.4 Average physical file size: 36496.0 KB Number of batch/file transactions ended: 1 Number of batch transactions aborted: 0 Number of file transactions started: 0 Number of file transactions aborted: 0

No storage pool backup information available for BACKUPPOOL.

Do not expect the average logical files per physical file to be exactly the number specified with the TXNGROUPMAX option. There are more factors involved, but at least the numbers should be close enough. The 3571 files from this example are fine.

We now delete the client’s file system on the server and do exactly the same backup, followed by a migration. The numbers are reported in Example 10-2.

Example 10-2 Storage pool migration statistics, TXNGROUPMAX 256

tsm: UTAH-TSM1>show transferstats backuppoolStatistics for last migration from pool BACKUPPOOL Start date/time: 06/12/09 01:19:12 Elapsed time: 15 seconds Total wait time: 1 seconds Number of participating processes: 1 Total duration of all processes: 15 seconds Total physical files: 98 Total logical files: 25000 Total bytes: 261603328 Average logical files per physical file: 255.1 Average physical file size: 2606.9 KB Number of batch/file transactions ended: 1 Number of batch transactions aborted: 0 Number of file transactions started: 0 Number of file transactions aborted: 0

No storage pool backup information available for BACKUPPOOL.

Even with this simple example, the migration already took much longer than with the new default.


10.3 Summary

The new TXNGROUPMAX default better fits today’s environments, especially when it comes to transfer to tape. At this point, you know how to ensure that the settings are honored by using the SHOW TRANSFERSTATS command.

Chapter 10. Changes to the TXNGROUPMAX default 181

Part 4 Tivoli Storage Manager V6.1 Client enhancements

This part of the book covers the client enhancements provided in Tivoli Storage Manager V6.1.

Part 4


Chapter 11. HSM for Windows

In this chapter we discuss the enhancements to the Tivoli Storage Manager V6.1 hierarchical storage management (HSM) client for Windows.

11


11.1 Introduction

IBM Tivoli Storage Manager for HSM for Windows client provides hierarchical storage management (HSM) for Windows NTFS file systems.

HSM is a data storage system that automatically moves data between high-cost and low-cost storage media. HSM exists because high-speed storage devices, such as hard disk drives, are more expensive per byte stored than slower devices, such as optical discs and magnetic tape drives. While it would be ideal to have all data available on high-speed devices all the time, this is prohibitively expensive for many organizations. Instead, you can use HSM to store the bulk of your enterprise's data on slower devices, and then copy data to faster disk drives only when needed.

With the previous versions of the code, migration jobs are used to control which data is to be migrated. These jobs contain the information, which files are to be migrated and which file space on the Tivoli Storage Manager server is used. All files that match the criteria of a job are migrated, and it does not matter, whether this job will migrate only few files or nearly all files. One migration job can span over multiple volumes, if nested volumes are present. A migration job can also span multiple volumes, if nested volumes are not present. For example, you can add D:\dir1 and E:\Dir2 to one single migration job. In that case, this single job will migrate files from two different volumes.

Migration jobs can be executed manually in the HSM for Windows GUI or on the command line by running the dsmclc tool. It is not possible to schedule two jobs at the same time, because every HSM for Windows executable can be started only once at a time. Alternatively any scheduler can be used to start the dsmclc tool for migration. This provides some kind of “automated” migration for HSM for Windows, but does not guarantee a certain amount of free space in the volume, nor does it generally avoid out of space situations. The typical space usage with this implementation is shown in Figure 11-1.


Figure 11-1 Space usage with version 5 HSM for Windows

11.2 Automatic threshold migration

The version 6 client adds the capability to HSM for Windows to automatically maintain a certain amount of free space in the file system by what is known as threshold migration.

Threshold migration allows you to:

� Configure threshold migration for a volume in the HSM for Windows GUI or on the command line

� Monitor the utilization (threshold) of one or more file systems

� Collect and provide suitable migration candidates

� Migrate candidates to the Tivoli Storage Manager server when a certain high threshold is reached, until the configured low threshold is reached.

With automatic threshold migration, the typical space usage is shown in Figure 11-2. Compare this against Figure 11-1. No scheduled or manual job must be run to achieve this.

Chapter 11. HSM for Windows 187

Figure 11-2 Space usage with version 6.1 HSM for Windows threshold migration

The capability to automatically maintain a certain amount of free space in the file system is similar to the Tivoli Storage Manager for Space Management threshold migration available on UNIX platforms. If you are used to the UNIX methodology of threshold migration, the HSM for Windows threshold migration differs from the one on UNIX platforms.

Threshold migration monitors space usage; there is not an out-of-space event as on UNIX. And, because the monitoring is done in configurable intervals, such as every 5 minutes, it might happen that the file system runs out of space in the meantime and applications get I/O errors.

11.2.1 Installation

Threshold migration is supported on all environments on which HSM for Windows is supported.

In general, these are the requirements:

� Windows Server 2008 (Standard and Enterprise)

� Only 64 bit with minimum 1 GB memory for HSM and minimum 100 MB free disk space

� Single Node or MSCS Cluster

� Requires Tivoli Storage Manager Backup Archive client of the same version and PTF (6.1.X) being installed

� Requires the Tivoli Storage Manager Server to be at least 5.5

Note: The HSM for Windows 6.1 client does not support on demand migration or premigration.


For MSCS cluster installations, the client must be installed on every node, where files should be migrated or recalled (for example, on any node to which a volume with stubs can fail over).

Figure 11-3 shows the IBM Tivoli Storage Manager HSM Client InstallShield Wizard Custom Setup. Select the IBM Tivoli Storage Manager Monitor Service and click Next to continue.

Figure 11-3 Monitor service installation

The installation itself does not require any planning, you just invoke the setup.exe to start installation. In order to configure HSM for Windows, you need to contact your Tivoli Storage Manager server administrator to register the HSM client node and, if installed on a cluster, to grant proxy for the individual nodes. This is not part of the setup, but the setup displays the required commands.

The IBM Tivoli Storage Manager Monitor Service will be installed by default. Upon a successful installation, you can check by the Windows task manager if the monitor service is running. Search for hsmmonitor.exe as shown in Figure 11-4.

Figure 11-4 Windows Task Manager: hsmmonitor.exe


You can also click Start → Administrative Tools → Services and search for the IBM Tivoli Storage Manager Monitor Service as shown in Figure 11-5.

Figure 11-5 IBM Tivoli Storage Manager HSM Monitor Service

You can also use the HSM command line client, dsmhsmclc.exe to verify that the service is running. Example 11-1 shows the output of a dsmhsmclc check command.

Example 11-1 dsmhsmclc check output

C:\Program Files\Tivoli\TSM\hsmclient>dsmhsmclc.exe checkCommand Line HSM Reconcile and Threshold Migration Interface - Version 6, Release 1, Level 0.0(c) Copyright by IBM Corporation and other(s) 2005, 2009. All Rights ReservedHSM Service is running: YESMonitor Service is running: YESDLL state: N/A (single node)HSMResTypDLL.dll version: N/A (single node)HSMResTypDLLEx.dll version: N/A (single node)Configuration check for volume 'D:\': success

Highest return code was 0


11.2.2 Configuration

Example 11-1 shows that the configuration check for volume D:\ was successful. We configured the volume for threshold migration using the HSM GUI. Click Tools → Threshold Migration as shown in Figure 11-6.

Figure 11-6 HSM GUI: Tools menu

On the Threshold Migration Settings panel, select the drive that you want to be monitored for threshold migration and click Configure. In Figure 11-7 you can see that we specified the L:\ path.

Figure 11-7 Threshold Migration Settings: Configure


You can now enter the Threshold Migration settings. We complete the configuration as shown in Figure 11-8.

Figure 11-8 Threshold Migration Settings: completed

Table 11-1 explains the configurable options that you have to set up threshold migration, the volume mount path, and the server file space definition is required, all other options come with a default.

Table 11-1 Threshold migration options

Option Range Default Explanation

Volume mount path - - Name of the volume (like D:)- required

FILESpace - - Target filespace on the Tivoli Storage Manager server- required

HIGHthreshold 1-100% 90 Disk usage that triggers the start of threshold migration

LOWthreshold 0-99% 80 Disk usage that triggers the stop of threshold migration

MONitorinterval 0-9999 min 5 min Monitoring frequency


You can use the command line client to configure the parameters:

dsmhsmclc -CONFIGUREThresholdmig D: -FILESPace HSMOldskool

All migration methods can run in parallel: threshold migration, job migration or file list migration can run in parallel. Any combination of the following is possible:

� Job migration: HSM GUI or dsmclc migrate <parameters>

Run migration based on file value (job migration)

� File list migration: dsmclc migratelist <parameters>

Run migration based on external input (file list migration)

� Threshold migration: hsmmonitor service

Run migration based on capacity (threshold migration)

Figure 11-9 Computer Management: Disk Management

SCANinterval 1-9999 h 24 h Interval for scanning for new candidates

CHECKCANdidatesinterval 0-9999 min 180 min Interval for validation of candidates

MINMIGFILESIZE 4KB - 2TB 4KB Minimal size for a migration candidate

MINMIGFILEAGE 0-9999 d 360 d Minimal age for a migration candidate

MINAGETYPE CreateModifyAccess

Access Timestamp to be used to calculate the age of a file

AGEWEIGHT 0-100% 50 Importance of file age relative to filesize

BACKUPBEforemigrate yesno

no Backup files before migration

Option Range Default Explanation


11.2.3 Operation

There are four major tasks to threshold migration, which run in parallel in different threads of the HSM monitor service:

1. Monitoring for file system threshold (MONitorinterval):

Check the file system usage for High threshold.

2. Scanning for new candidates:

The scan searches for new candidates in the volume and stores them in the candidates list, which is a binary file in the volume root, named dsmthreshmig.bin. This file is hidden and excluded from the backup with the B/A client.

You can query the candidates list with the following command:

dsmhsmclc -dumpthreshold -FILESYSTEM d: -CANDidateslist full

There are three different types of scans:

– Regular scan (SCANinterval): Regularly searches in the volume for new good candidates and adds them to the candidates list (dsmthreshmig.bin)

– Demand scan: Fills up the candidates list, if not enough candidates are available to migrate from HT to LT

– Emergency scan: Finds candidates during threshold migration, if no more candidates are available

3. Validation (CHECKCANDidatesinterval):

Verifies that the files in the candidates list are still valid candidates and removes invalid candidates

4. Threshold migration:

The actual migration itself, gets candidates from the candidates list and migrates them

11.3 Summary

Threshold migration is easy to understand and to configure and integrates seamlessly into the existing HSM for Windows client. The threshold migration starts when a high threshold (HT) is reached and continues to run until a low threshold (LT) is reached or until all migratable files are migrated.

After threshold migration is configured for your system, for example, your file server will almost always have free space. You can, however, use threshold migration in combination with additional migration jobs, schedules, or manually.


Chapter 12. Active Directory Object Item Restore

In this chapter we provide an overview of what an Active Directory is and the features that come with Tivoli Storage Client V6.1.

12


12.1 Active Directory overview

Active Directory is the Microsoft technology that provides critical network services, including:

� LDAP directory services � Kerberos based authentication � DNS based naming and other network information

With a central database at its core, Active Directory enables administrators to assign policies, as well as helping them with software deployment and applying critical updates.

The Active Directory directory service stores network resource meta data for an entire domain and centralized network (see Figure 12-1).

Figure 12-1 The Active Directory Components

An active directory is a directory structure used on Microsoft Windows based computers and servers to store information and data about networks and domains (see Figure 12-2). It is primarily used for online information and was originally created in 1996 and first used with Windows 2000.

An active directory (sometimes referred to as an AD) does a variety of functions, including the ability to provide information about objects, helps organize these objects for easy retrieval and access, allows access by end users and administrators, and allows the administrator to set security up for the directory. An active directory can be defined as a hierarchical structure. This structure is usually broken up into three main categories: the resources, which might include hardware such as printers; services for end users, such as Web e-mail servers; and objects, which are the main functions of the domain and network.


Figure 12-2 The Active Directory Structure

What we have in Tivoli Storage Client 5.5Backup and restore of Active Directory on MS 2003 Domain Controller server is supported, and Active Directory restores require the Domain Controller to be booted into Active Directory Restore mode. Active Directory can only be restored with all bootable components (the entire system state).

What we have in Tivoli Storage Client 6.1Let us now move on to the new function available in Windows Active Directory. In 12.2, “Version 6.1 Client Update”, we present the new features in Tivoli Storage Client V6.1.

12.2 Version 6.1 Client Update

One of the Active Directory enhancements in V6.1 is Individual Object Restore from Backup. Here we discuss the objectives of Individual Object Restore:

� We do not need to reboot the Domain Controller during the restore process.

� A Windows Server Administrator can restore individual Active Directory objects as needed.

� The backup client V6.1 provides an easy to use graphical interface “tombstone” reanimation support.

� Active Directory objects can be restored from a Tivoli Storage Manager server.

� No additional configuration or setup is required for this feature.

Note: When you delete an object in Active Directory, that object does not disappear completely. Instead, the object becomes a deleted object, also known as a tombstone.

Chapter 12. Active Directory Object Item Restore 197

Restoring the linksSome Active Directory objects require a recreation of so-called “links” after restore. For example, a restored user needs to be reinserted into one or more groups, a restored organizational unit needs to have one or more group policy objects (GPO) restored and assigned, and so on.

There are certain commonly used and standard Active Directory object types, as well as less commonly used, or user defined types of objects. We are going to support “link recreation” only for the following most common and built-in types of Active Directory objects:

� User� Group� Organizational Unit� Computer� Printer� GPO

All other object types will be restored as is, without any additional processing.

12.2.1 Design limitations for restore

In this section we discuss the restore limitations:

� Windows 2008 Server is the only platform supported for restoring AD objects from a Tivoli Storage Manager system state backup.

� The entire Active Directory database (ntds.dit) must be restored (this will require additional disk space).

� Tivoli Storage Manager will not interpret Active Directory schema or attempt to recreate the schema during restore:

– If the schema was modified after backup, the restored object might no longer be compatible.

– Restore will attempt as many attributes as possible and issue a warning message if some could not be restored.

� a-When an object is restored from Tivoli Storage Manager backup and its tombstone does not exist, it is re-inserted into Active Directory database:

– The new object will have a different GUID from the original.

– If the tombstone exists, it will be reanimated first before attributes restore from the backup, therefore the restored object will have the original GUID.

� Tivoli Storage Manager will not be able to restore all attributes for all types of objects:

– For user passwords, a warning message will be issued to the user.

� When a tombstone is recreated, it will contain only basic attributes needed to identify the object.

– Tivoli Storage Manager will reanimate the tombstone “as is.”

– It will not attempt to recreate stripped attributes based on any other information in the Active Directory.


12.2.2 New client commands and parameters

There are new commands and parameters in support of the Active Directory function in Tivoli Storage Manager V6.1:

� Query ADOBJects

� Restore ADOBJects

� Query SYSTEMSTate NTDS (“Q Systemstate” is not new)

� Query ADOBJect sourcepathspec [options]

– Displays local Active Directories:

• Deleted objects and corresponding attributes• Attributes from a System State backup, located on a Tivoli Storage Manager server

(2008 server only)

– Supported clients:

• Windows Server 2003 • Windows Server 2008

– Query ADOBJect options

Table 12-1 shows these options and explains how to use them.

Table 12-1 Active Directory options

� Restore ADOBJect Sourcepathspec:

– This specifies the Active Directory object or container to restore.

– When a container is specified, all contents will also be restored. See:

http://msdn2.microsoft.com/en-us/library/aa746384.aspx

– Specification:

• Full distinguished name of an object or a container• Just the name attribute ('cn' or 'ou')• Wildcards can be used• Wildcards are not supported in distinguished name specification

� Restore ADOBJect Options

Table 12-2 shows the ADOBJect options.

Option Where to use

ADLOCation (2008 only) command line only

dateformat dsm.opt or command line

detail command line only

pitdate (2008 only) command line only

pittime (2008 only) command line only

scrolllines dsmopt or command line

scrollprompt dsmopt or command line

timeformat dsmopt or command line


http://msdn2.microsoft.com/en-us/library/aa746384.aspx

Table 12-2 ADOBJect options

� Query SystemState ntds:

– This specifies that you want to display a list of Active Directory backups.

– This is an existing command with a new argument. It is only valid for the 2008 Windows Server (see Example 12-1).

Example 12-1 Query SystemState ntds command

>>-Query SYSTEMSTate--+-----------------+---------------------->< +- BOOTABLE-------+ +- BITS-----------+ +- EVENTLOG-------+ +- RSM------------+ +- RSS------------+ +- CLUSTERDB------+ +- TLS------------+ +- WMI------------+ +- IIS------------+ +- DHCP-----------+ +- WINSDB---------+ +- component_name-+ +- NTDS-----------+ +- REGISTRY-------+ +- COMPDB---------+ '- SYSFILES-------'

12.2.3 New client options

You can define the location where the client can keep data generated to restore the ntds DB:

� Adlocation (2008 server only):

– Specifies the location of the AD to query– Parameters:

• Local queries the local deleted objects (default value)• Server queries the objects from a System State backup

� Stagingdir path:

– Defines the location where the client can restore the ntds DB– Data deleted by the client upon exit– Used by Active Directory objects restore operation– Can be used in dsm.opt or command line

Option Where to use

ADLOCation (2008 only) command line only

dateformat dsm.opt or command line

pick command line only

pitdate (2008 only) command line only

pittime (2008 only) command line only

replace dsmopt or command line

timeformat dsmopt or command line


Display organizational unitHere we see a graphic of an AD object restore. In this case, organizational units (OUs) are Active Directory containers into which you can place users, groups, computers, and other organizational units. As you can see, the object is listed under “Local deleted objects” and to the right are its attributes and values (see Figure 12-3).

Figure 12-3 Tivoli Storage Manager Client V6.1 - AD restore


Restoring a user object from a tombstoneHere we show how a tombstone is presented in a Restore window (see Figure 12-4).

Figure 12-4 Tivoli Storage Manager Client V6.1 - Tombstone restore

Restoring from a system state backupHere we see a restore from a system state backup (see Figure 12-5).

Figure 12-5 Tivoli Storage Manager Client V6.1 - system state backup


Confirmation of restore After you actually click the Restore button, you will see the information in Figure 12-6.

Figure 12-6 Tivoli Storage Manager Client V6.1 - Active Directory database directory restore

Displaying organizational unitsFigure 12-7 shows the organizational units restore.

Figure 12-7 Tivoli Storage Manager Client V6.1 - organizational unit restore


Chapter 13. Client restore statistics

In this chapter we explain how the QUERYSUMMARY option extends the backup command line client query backup and archive commands to provide a restore and retrieve preview capability.

13


13.1 QUERYSUMMARY option

Tivoli Storage Manager clients with version 6.1 introduce the QUERYSUMMARY option to the existing client QUERY BACKUP and QUERY ARCHIVE commands to gather and display statistics relating to restore and retrieve commands.

You can use this query options prior to a restore or retrieve operation to obtain information about the number of files matching the pattern, number of distinct sequential access volumes on which the data is stored, total number of bytes to be restored or retrieved, and memory that would be consumed for a classic restore or retrieve.

As an example, we set up the file space in the test lab as shown in Example 13-1.

Example 13-1 File space setup

TSM:TIRAMISU>q occ oldskoolANR2017I Administrator SERVER_CONSOLE issued command: QUERY OCCUPANCY oldskoolNode Name Type Filespace FSID Storage Number of Physical Logical Name Pool Name Files Space Space Occupied Occupied (MB) (MB)---------- ---- ---------- ----- ---------- --------- --------- ---------OLDSKOOL Bkup \\gallium- 3 FILEPOOL 50,539 816.33 816.33 \g$

Example 13-2 shows the QUERYSUMMARY output for a sample restore from that file system.

Example 13-2 QUERYSUMMARY output from sample restore

tsm> query ba \\gallium\g$\*\Eric* -su=yes -querysummary

Size Backup Date Mgmt Class A/I File ---- ----------- ---------- --- ---- 0 B 06/25/2009 19:52:58 STANDARD A \\gallium\g$\mmw\load\750m\0058\0754\STOPDBG\Erica

..<lines deleted>..

1,024 B 06/25/2009 20:16:51 DEFAULT A \\gallium\g$\mmw\load\97656m1k\alt_sources\0272\0285\BDGXCC32\0744\0590\cascade\Eric

Summary Statistics

Total Files Total Dirs Avg. File Size Total Data Memory Est.----------- ---------- -------------- ---------- ---------- 68 2 18.07 KB 1.20 MB 26.62 KB

Estimated Number of Volumes: 2


13.2 QUERYSUMMARY output

The QUERYSUMMARY output allows you to better plan your restore and retrieve activities. Before you even start the restore, you can verify that the target destination does not run out of storage space, or that the client has enough memory available to complete the operation. The estimated number of volumes could indicate to do a server MOVE NODEDATA before starting the restore attempt.

Chapter 13. Client restore statistics 207

Part 5 Complimentary products and NDMP

This part of the book covers the Tivoli Storage Manager V6.1 update information for Data Protection for Mail - Exchange and NDMP.

Part 5


Chapter 14. N Series support

Tivoli Storage Manager uses Network Data Management Protocol (NDMP) to perform high-performance, scalable backups and restores. In this chapter we explain how the backups and restores minimize network traffic and transfer data outboard of the Tivoli Storage Manager client and server.

14


14.1 Overview

Tivoli Storage Manager V6 provides enhancements to address the “really big filer” challenge. Customers who are using very large file systems on their systems often come to the point where it is not possible to do either the standard incremental backup or to use the NDMP backup implementation with Table of Content created during backup. But there is the need of single file restore for several versions and often many retention days. A solution is needed that can put together several kinds of backup methods, such as Snapshot backup, incremental backup, and block based image dump. Tivoli Storage Manager V6 provides enhancements designed to improve performance with IBM System Storage N series and NetApp Network Attached Storage (NAS) devices.

14.1.1 Large file system backup

There are two new functions using the Tivoli Storage Manager 5.5.2 Server together with the V6.1 Client addressing the requirement for large file system backup:

� With Tivoli Storage Manager V5.5.2 and V6.1, performance of a full image backup of the IBM N series and NetApp file systems is improved, through integration with the Network Data Management Protocol (NDMP) and the NetApp SnapMirror to Tape function to move a disaster recovery image copied from the NAS device to storage managed by Tivoli Storage Manager. The SnapMirror to Tape function is not intended as a replacement for conventional backup operations, but does allow disaster recovery protection for large file systems for which conventional backup methods are impractical.

– SnapMirror to tape dumps all current file data an all Snapshot file data from the filer to local tape or filer-to-Tivoli Storage Manager Server.

– It enables the restore of all Snapshot copies back to the destination system.

– It is not intended as a backup mechanism, but is used to provide fast creation of a Disaster Recovery image for N series / NetApp filers.

– Tivoli Storage Manager will integrate to issue the NDMP commands to leverage NDMP filer-to Tivoli Storage Manager Server and back-end data movement management features for managing the SnapMirror to tape.

� The ability of Tivoli Storage Manager V6.1 to back up large NAS devices is improved, while providing file level recovery.Tivoli Storage Manager V6.1 takes advantage of a NetApp Snapshot Differencing interface for IBM N series and NetApp NAS file systems to help identify new, changed, and deleted files, eliminating the need for Tivoli Storage Manager V6.1 to scan the NAS file system prior to an incremental backup. For example:

– Integration with N series / NetApp greatly speeds up the backup of these large filers.

– Windows and AIX backup/archive client with NFS and CIFS attached filers is provided.

– Tivoli Storage Manager can use NetApp API to identify new, changed, or deleted files.

– Tivoli Storage Manager Backup-Archive client does not need to scan the filer prior to incremental backup.

– Progressive incremental backup with file level recovery is provided.

Note: It is not necessary to upgrade to IBM Tivoli Storage Manager Version 6.1 Server in order to use this new function.


14.1.2 IP address of server interface to receive NDMP backup data

If your server has multiple network interfaces installed or if you are using a dedicated network for your NDMP backups transferring data over the network, it might be necessary to define the dedicated network address to the server. Use the NDMPPREFDATAINTERFACE server option.

This option specifies the IP address associated with the interface in which you want the server to receive all NDMP backup data.

This option affects all subsequent NDMP filer-to-server operations, but does not affect NDMP control connections, which use the system’s default network interface. The value for this option is a host name or IPV4 address that is associated with one of the active network interfaces of the system on which the Tivoli Storage Manager server is running. This interface must be IPV4 enabled.

SETOPT commandYou can update this server option without stopping and restarting the server by using the SETOPT command. The syntax in the Tivoli Storage Manager server options file is:

NDMPPREFDATAINTERFACE ip_address

Parametersip_address

Specify an address in either dotted decimal or host name format. If you specify a dotted decimal address, it is not verified with a domain name server. If the address is not correct, it can cause failures when the server attempts to open a socket at the start of an NDMP filer-to-server backup. Host name format addresses are verified with a domain name server.

There is no default value. If a value is not set, all NDMP operations will use the Tivoli Storage Manager server’s network interface for receiving backup data during NDMP filer-to-server backup operations. To clear the option value, specify the SETOPT command with a null value, ““. For more information, refer to the IBM Tivoli Storage Manager Administrator’s Guide for your platform, found at the Web site:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.nav.doc/r_pdfs.html

If you get the error message ANR4794E (see Example 14-1) during NAS backup or your NDMP backup seems to be very slow, you can verify it with an NDMP trace on your Filer and a Tivoli Storage Manager trace on your Tivoli Storage Manager-Server.

Example 14-1 Error message ANR4794E

ANR4794E The NAS file server 192.168.111.190 failed to open an NDMP data connection to the TSM tape server. Please verify that the file server is capable of outbound data connections.

Set up the NDMP Trace on the Filer and a Tivoli Storage Manager Trace on your Tivoli Storage Manager Server to find out what is going wrong (see Example 14-2).

Example 14-2 set up the NDMP trace on the Filer

NAS1> ndmpd debug 70ndmpd debug verbose: 70ndmpd debug stack trace: falsendmpd debug screen trace: true

Chapter 14. N Series support 213

ndmpd debug file trace: true

output after the test in /etc/log/ndmp.nnn looks similar to this:

Jun 05 02:51:33 GMT+02:00 [ndmpd:32]: Data connection type: 1Jun 05 02:51:33 GMT+02:00 [ndmpd:32]: TCP Addr: 0.0.0.0Jun 05 02:51:33 GMT+02:00 [ndmpd:32]: TCP Port: 0Jun 05 02:51:33 GMT+02:00 [ndmpd:32]: Error code: NDMP_CONNECT_ERRJun 05 02:51:33 GMT+02:00 [ndmpd:32]: IOException: Connection timed outJun 05 02:51:34 GMT+02:00 [ndmpd:32]: NDMP message type: NDMP_DATA_ABORT

You have discovered that the TCP Address in the trace is 0.0.0.0 and the TCP Port is 0. Set up the Tivoli Storage Manager trace on the server as shown in Example 14-3.

Example 14-3 Set up the Tivoli Storage Manager trace on the Server

trace disable * trace enable spi spid sessremote addmsg trace begin <pathandfilenamehere>

In this case it is necessary to define the dedicated network address to the server using the NDMPPREFDATAINTERFACE server option. After you have set that option, the backup starts without an error, as you can see in the trace (Example 14-4).

Example 14-4 Results after setting the NDMPPREFDATAINTERFACE option

setopt ndmpprefdatainterface 192.168.111.81

output after the test in /etc/log/ndmp.nnn looks similar to this:

Jun 05 03:02:34 GMT+02:00 [ndmpd:34]: Data connection type: 1Jun 05 03:02:34 GMT+02:00 [ndmpd:34]: TCP Addr: 192.168.111.81Jun 05 03:02:34 GMT+02:00 [ndmpd:34]: TCP Port: 2077Jun 05 03:02:34 GMT+02:00 [ndmpd:34]: Error code: NDMP_NO_ERRJun 05 03:02:34 GMT+02:00 [ndmpd:34]: NDMP message type: NDMP_DATA_START_BACKUP_V4

Do not forget to disable the trace as shown in Example 14-5.

Example 14-5 Stop and disable the trace on Tivoli Storage Manager and Filer

on TSM:trace flushtrace endtrace disable

on the Filer:

ndmpd debug 0ndmpd debug verbose: 0ndmpd debug stack trace: falsendmpd debug screen trace: truendmpd debug file trace: true


To check the correct network interface, use the SYSSTAT function on the Filer to verify the Network speed (see Example 14-6).

Example 14-6 Sysstat shows data flow during full and differential backup of the NAS device

NAS1> sysstat -x 1CPU NFS CIFS HTTP Net kB/s Disk kB/s Tape kB/s Cache in out read write read write age 64% 0 0 0 47 1658 1668 20 0 0 >60 47% 0 0 0 67 2763 2476 8 0 0 >60 47% 0 0 0 64 2763 2656 0 0 0 >60 20% 0 0 0 50 2202 2124 0 0 0 >60 33% 0 0 0 37 1667 1564 0 0 0 >60 20% 0 0 0 59 2960 2785 0 0 0 >60 17% 0 0 0 42 1939 1940 8 0 0 >60 6% 0 0 0 26 1149 807 0 0 0 >60 8% 0 0 0 11 553 1008 0 0 0 >60 27% 0 0 0 56 2741 2627 0 0 0 >60 56% 0 0 0 56 2760 1982 104 0 0 >60 32% 0 0 0 32 1928 2084 64 0 0 >60 28% 0 0 0 59 3046 2732 4 0 0 >60 17% 0 0 0 29 1658 1900 8 0 0 >60 40% 0 0 0 61 3315 2940 0 0 0 >60 25% 0 0 0 19 1106 1076 0 0 0 >60 36% 0 0 0 36 2208 2046 8 0 0 >60 15% 0 0 0 0 156 167 0 0 0 >60 15% 0 0 0 11 393 254 0 0 0 >60 10% 0 0 0 0 0 207 0 0 0 >60

14.2 SnapMirror to Tape

For performance reasons, IBM agreed with NetApp to use their built-in SnapMirror to Tape function available in NetApp FAS Systems and IBM N-Series to do block-level backup for disaster protection for large filers.

Tivoli Storage Manager integrates to issue the NDMP commands to move the SnapMirror image from the NetApp filer to a Tivoli Storage Manager server managed storage target for fast creation of a DR image. An overview of this function is shown in Figure 14-1.


Figure 14-1 SnapMirror to tape support with Filer-to-Server and Filer-to-Tape

SnapMirror to Tape provides an alternative method for backing up very large NetApp file systems. Because this backup method has limitations, use this method when copying very large NetApp file systems to secondary storage for disaster recovery purposes. You can back up very large NetAppfile systems using the NetAppSnapMirror to Tape feature. Using a block-level copy of data for backup, the SnapMirror to Tape method is faster than a traditional Network Data Management Protocol (NDMP) full backup and can be used when NDMP full backups are impractical.

You would use the NDMP SnapMirror to Tape feature as a disaster recovery option for copying very large NetAppfile systems to secondary storage. However, for most NetApp file systems, use the standard NDMP full or differential backup method, the new SnapDiff-API incremental backup, the Snapshot functions of the filer, or a combination of these.

Using a parameter option on the BACKUP and RESTORE NODE commands, you can back up and restore file systems using SnapMirror to Tape. There are several limitations and restrictions on how SnapMirror images can be used. Consider the following guidelines before you use it as a backup method:

� You cannot initiate a SnapMirror to Tape backup or restore operation from the Tivoli Storage Manager Web client, command-line client, or the Administration Center.

� You cannot perform differential backups of SnapMirror images.

� You cannot perform a directory-level backup using SnapMirror-to-Tape, because Tivoli Storage Manager does not permit a SnapMirror to Tape backup operation on a server virtual file space.

Storage Manager 6

Nseries

Nseries

SM2T image data transferto local tape

Tape

SM2T image data transferto TSM Server on LAN

TSM Server


� You cannot perform an NDMP file-level restore operation from SnapMirror to Tape images. Therefore, a table of contents is never created during SnapMirror to Tape image backups.

� At the start of a SnapMirror to Tape copy operation, the file server generates a Snapshot of the file system. NetApp provides an NDMP environment variable to control whether this Snapshot should be removed at the end of the SnapMirror to Tape operation. Tivoli Storage Manager always sets this variable to remove the Snapshot.

� After a SnapMirror to Tape image is retrieved and copied to a NetAppfile system, the target file system is left configured as a SnapMirror partner. NetApp provides an NDMP environment variable to control whether this SnapMirror relationship should be broken. Tivoli Storage Manager always breaks the SnapMirror relationship during the retrieval. After the restore operation is complete, the target file system is in the same state as that of the original file system at the point-in-time of backup.

14.2.1 How to set up, use, and control SnapMirror to Tape for backup

The only difference between a normal NDMP backup and a SnapMirror to Tape backup is to specify the additional option, type=snapm, in the backup node and restore node administrative server command. Next we describe the syntax for this option.

TYPEThis specifies the backup method used to perform the NDMP backup operation.

The default value for this parameter is BACKUPIMAGE, and it should be used to perform a standard NDMP base or differential backup. Other image types represent backup methods that might be specific to a particular file server.

BACKUPImageThis specifies that the file system should be backed up using an NDMP dump operation. This is the default method for performing an NDMP backup.

The BACKUPIMAGE type operation supports full and differential backups, file-level restore processing, and directory-level backup.

SNAPMirrorThis specifies that the file system should be copied to a Tivoli Storage Manager storage pool using the Network Appliance™ SnapMirror to Tape function.

SnapMirror images are block level full backup images of a file system.

Typically, a SnapMirror backup takes significantly less time to perform than a traditional NDMP full file system backup. However there are limitations and restrictions on how SnapMirror images can be used. The SnapMirror to Tape function is intended to be used as a disaster-recovery option for copying very large Network Appliance file systems to secondary storage.

For most Network Appliance file systems, use the standard NDMP full or differential backup method. See the IBM Tivoli Storage Manager Administrator’s Guide for your platform for limitations on using SnapMirror images as a backup method. The Tivoli publications can be found at the Web site:





Refer to the documentation that came with your Network Appliance file server for more information. When setting the TYPE parameter to SNAPMirror, note the following restrictions:

� You cannot specify TOC=YES or TOC=PREFERRED.

� The file_system_name cannot be a virtual file space name.

� The snapshot that is created automatically by the file server during the SnapMirror copy operation will be deleted at the end of the operation.

� This parameter is valid for Network Appliance and IBM N-Series fileservers only.

An example of the TYPE option to start the SnapMirror to tape backup is shown in Example 14-7.

Example 14-7 How to start a SnapMirror to tape backup

dsmadmc:backup node SIM1 /vol/mixedvol01 type=snapmANR2685I SnapMirror backup of NAS node SIM1, file system /vol/mixedvol01, started as process 16 by administrator TSMADMIN

ANR0986I Process 16 for NAS SNAPMIRROR BACKUP running in the BACKGROUND processed 1 items for a total of 6,344,704 bytes with a completion state of SUCCESS.

You will find the result of this task in several logs, queries and tables. An example of the Tivoli Storage Manager-Server NAS-Backup query is shown in Example 14-8.

Example 14-8 query nasbackup to display the SnapMirror to tape backups

tsm: TESTPC-81>query nasbackup sim1 * type=snapm

Node Name Filespace Object Type Object Creation Mgmt Class Image Name Size (MB) Date Name Storage Pool Name------------ ----------- ----------- --------- ---------- ---------- ----------SIM1 /vol/vol0 SnapMirror 189.5 06/05/2009 STANDARD NASPOOL 18:45:00SIM1 /vol/winvo- SnapMirror 5.5 06/03/2009 STANDARD NASPOOL l01 19:04:53SIM1 /vol/winvo- SnapMirror 5.5 06/03/2009 STANDARD NASPOOL l01 20:21:36SIM1 /vol/winvo- SnapMirror 5.5 06/03/2009 STANDARD NASPOOL l01 20:28:26SIM1 /vol/winvo- SnapMirror 5.5 06/03/2009 STANDARD NASPOOL l01 20:45:13SIM1 /vol/winvo- SnapMirror 5.5 06/03/2009 STANDARD NASPOOL l01 20:59:28SIM1 /vol/winvo- SnapMirror 5.5 06/03/2009 STANDARD NASPOOL l01 21:06:49SIM1 /vol/winvo- SnapMirror 6.1 06/04/2009 STANDARD NASPOOL l01 19:59:45SIM1 /vol/winvo- SnapMirror 6.1 06/04/2009 STANDARD NASPOOL l01 20:02:31more... (<ENTER> to continue, 'C' to cancel)

SIM1 /vol/mixed- SnapMirror 6.1 06/06/2009 STANDARD NASPOOL


The Summary-Table in the Tivoli Storage Manager-Server is shown in Example 14-9.

Example 14-9 Result form the select of the summary table

>select start_time,end_time,activity,number,entity,examined,affected,failed,bytes,idle,mediaw,processes,successful from summary where activity like '%Snap%'

START_TIME: 2009-06-06 00:35:36.000000 END_TIME: 2009-06-06 00:36:05.000000 ACTIVITY: NAS SnapMirror Backup NUMBER: 16 ENTITY: SIM1 EXAMINED: 1 AFFECTED: 1 FAILED: 0 BYTES: 6344704 IDLE: 0 MEDIAW: 1 PROCESSES: 1SUCCESSFUL: YES

Included in the Filer logs is the snapmirror log (see Example 14-10), which is always created during normal NDMP backup and SnapMirror to tape backup.

Example 14-10 Output of the /etc/logs/snapmirror

slk Sat Jun 6 02:00:10 CES state.softlock.mixedvol01.000003da.155.snapmirror_tape_6_6_09_02:00:09 Softlock_add (Transfer)src Sat Jun 6 02:00:11 CES sim1:mixedvol01 sim1:NDMP_REMOTE41 Request (Store)src Sat Jun 6 02:00:11 CES sim1:mixedvol01 sim1:NDMP_REMOTE41 Startsrc Sat Jun 6 02:00:30 CES sim1:mixedvol01 sim1:NDMP_REMOTE41 End (5160 KB, Compression 0.0 : 1)slk Sat Jun 6 02:00:30 CES state.softlock.mixedvol01.000003da.155.snapmirror_tape_6_6_09_02:00:09 Softlock_delete (Release)

14.2.2 How to restore a NAS Volume from SnapMirror to Tape backup

There are several items to consider if you want to restore NAS-Volumes, backed up with SnapMirror to Tape.

� SnapMirror images are block-level full-backup images of a Network Appliance file system. A SnapMirror image can only be restored to a file system that has been prepared as a SnapMirror target volume. Refer to the documentation that came with your Network Appliance file server for details.

� On restore, the destination must be available and prepared with the following commands:

NetApp command: “vol create ... ”NetApp command: “vol restrict ... ”

� After a SnapMirror image is retrieved and copied to a target file system, Tivoli Storage Manager breaks the SnapMirror relationship that was created by the file server during the operation. After the restore is complete, the target file system returns to the same state as that of the original file system at the point-in-time of the backup.

� You cannot specify the FILELIST parameter.


� Neither the source_file_system_name nor the destination_file_system_name can be a virtual file space name.

� Restoration of traditional volume to unlike geometry can be very slow.

� The destination of the retrieval must use the same or later version of Data ONTAP®.

� The traditional volume file system format is different from the FlexVol® volume file system format:

– A FlexVol volume cannot be restored to a traditional volume.– A traditional volume cannot be restored to a FlexVol volume.

� This parameter is valid for Network Appliance and IBM N-Series file servers only.

14.3 The snapdiff option for NFS data stored on NetApp filers

To back up your file systems on your NAS-Filer, you have several choices. One of them is to use the traditional way of incremental backups. Therefore, you have to mount the NFS or CIFS share to a Windows or UNIX system, where the Backup/Archive Client is running.

The problem of doing backups in this way is that it takes too long due to the compare of the objects to find what has changed and what needs to be backed up. For mounted file systems you cannot use journal based backup.

14.3.1 Overview of SnapDiff

Incremental backup process leverages the NetApp Snapshot Difference API, which uses Snapshots to determine what files have changed since the last backup. It is an alternative to the traditional incremental backup file scan process and identifies file changes since the last backup in seocnds.The performance is independent of the number of files on volume.

There is the ability to restore files on a file level basis and use the traditional Tivoli Storage Manager storage hierarchy. This function is only available for N-Series or NetApp filers with ONTAP 7.3.

File level restore is limited to 7 bit ASCII characters in file and directory names. Global character set support requires an update to ONTAP and Tivoli Storage Manager client. It is available with Tivoli Storage Manager Client 6.1 for Windows and AIX running against Tivoli Storage Manager Server Version 5.x or 6.1 (see Figure 14-2).

Figure 14-2 Overview of snapdiff option

The snapdiff option is for backing up NAS/N-Series file server volumes that are NFS or CIFS attached.


When used with the incremental command, snapdiff streamlines the incremental process by performing an incremental backup of the files that were reported as changed by NetApp, instead of scanning the volume looking for files that have changed.

Use this option with an incremental backup of a NAS filer volume instead of a simple incremental or incremental with snapshotroot whenever the NAS filer is running ONTAP V7.3 or later, for performance reasons. Do not use the snapdiff and snapshotroot options together.

The first time that you perform an incremental backup with this option, a snapshot is created (the base snapshot) and a traditional incremental backup is performed using this snapshot as the source. The name of the snapshot that is created is recorded in the Tivoli Storage Manager database.

The second time an incremental backup is run with this option, a newer snapshot is either created or an existing one is used to find the differences between these two snapshots. This second snapshot is called the diffsnapshot. Tivoli Storage Manager then incrementally backs up the files reported as changed by snapdiff to the Tivoli Storage Manager server. The file space selected for snapdiff processing must be mapped or mounted to the root of the volume. You cannot use the snapdiff option for any file space that is not mounted or mapped to the root of the volume. After backing up data using the snapdiff option, the snapshot that was used as the base snapshot is deleted from the .snapshot directory. Tivoli Storage Manager does not delete the snapshot if it was not created by Tivoli Storage Manager. You can also perform a snapdiff incremental backup with the -DiffSnapShot=Latest option.

For NAS and N-Series filers running ONTAP 7.3 or later, you can use the snapdiff option when performing a full volume incremental backup. Using this option reduces memory usage and speeds up the processing. However, similar to using the incremental-by-date method, the following considerations and situations apply:

� A file is excluded due to an exclude rule in the include-exclude file. Tivoli Storage Manager performs a backup of the current Snapshot with that exclude rule in effect. This happens when you have not made changes to the file, but you have removed the rule that excluded the file. NetApp will not detect this include-exclude change because it only detects file changes between two Snapshots.

� If you have added an include statement to the option file, that include option will not take effect unless NetApp detects that the file has changed. This is because Tivoli Storage Manager does not inspect each file on the volume during backup.

� You have used the dsmc delete backup command to explicitly delete a file from the Tivoli Storage Manager inventory. NetApp will not detect that a file has been manually deleted from Tivoli Storage Manager. Therefore, the file remains unprotected in Tivoli Storage Manager storage until it is changed on the volume and the change is detected by NetApp signalling Tivoli Storage Manager to back it up again.

� Policy changes such as changing the policy from mode=modified to mode=absolute are not detected.

� The entire file space is deleted from the Tivoli Storage Manager inventory. This causes the snapdiff option to create a new Snapshot to use as the source, and a full incremental backup will be performed.

� Tivoli Storage Manager will not control what constitutes a changed object, that is controlled by NetApp.

For more information, see IBM Tivoli Storage Manager for Windows Backup-Archive Clients Version 6.1, SC23-9792 and IBM Tivoli Storage Manager for UNIX and Linux Backup-Archive Clients 6.1, SC23-9791.


14.3.2 How the Backup Archive Client interacts with the SnapDiff-API

Here we describe the initial incremental backup with snapdiff option process:

1. Tivoli Storage Manager client creates a Snapshot version. You can use the diffsnapshot option to use the most recent externally created Snapshot.

2. Tivoli Storage Manager backs up all files from Snapshot.

3. The Snapshot name is stored in the Tivoli Storage Manager server.

Subsequent incrementals with the snapdiff option process follow the following steps:

1. The name of the previous Snapshot is retrieved from Tivoli Storage Manager server.

2. Tivoli Storage Manager client creates a new Snapshot version. You can use the diffsnapshot option to use the most recent externally created Snapshot.

3. The Snapshot Differencing API compares previous and new Snapshot versions and reports file and directory differences to the Tivoli Storage Manager client.

4. The Tivoli Storage Manager client backs up files identified in the report.

5. The new Snapshot name is stored in the Tivoli Storage Manager server for use in the next incremental backup.

6. The Tivoli Storage Manager client deletes the previous Snapshot version, if you have not used the difsnapshot option to use the most recent externally created Snapshot.

Figure 14-3 shows how the Tivoli Storage Manager Client interacts with the Snapshot Differencing API.

Figure 14-3 How Tivoli Storage Manager Client interacts with Snapshot Differencing API

14.3.3 Preparation for using SnapDiff API

In preparation for using the SnapDiff API, the first step is to create and store a password for the administrator on the filer to create the Snapshot.

To enable Snapshot Difference processing, set up a user ID and password on the Tivoli Storage Manager client. First use the dsmc set password command to establish a user ID and password. The user ID and password must have administrative authority, such as administrator, or equivalent. Use the administrator authority level when you map or mount the file server volume. See Example 14-11, which shows how to set up a password.

Example 14-11 How to set up a password with dsmc with UNC name

tsm> set password -type=filer sim1 administratorPlease enter password for user id "administrator@sim1": *****Re-enter the password for verification:*****ANS0302I Successfully done.


If you have mounted the file server volume with IP address, you should create the password with the appropriate IP address (see Example 14-12).

Example 14-12 Specify set password with IP address

tsm> set password -type=filer 192.168.111.190 administratorPlease enter password for user id "[email protected]": *****Re-enter the password for verification:*****ANS0302I Successfully done.

The result will be stored in the Windows Registry (see Figure 14-4).

Figure 14-4 Windows Registry with stored passwords

For AIX, you will use the same command, but the name resolution of the IP address should be possible, so you have to check the /etc/hosts. Example 14-13 shows how to set up the password for the AIX Backup/Archive client.

Example 14-13 set up password for AIX Backup/Archive client

dsmc set password -type=filer sim1 administrator

tsm> set password -type=filer sim1 administratorPlease enter password for user id "administrator@sim1": Re-enter the password for verification:ANS0302I Successfully done.

The result is placed in /etc/security/adsm/TSM.PWD in encrypted form (see Example 14-14).

Example 14-14 stored password in /etc/security/adsm

# more TSM.PWDThis file contains an encrypted TSM password, do not change or delete.^Cï^C^D^D^M^M^ENULLSIM1administratorM-^MM-^Pd¨Ðûº¼^VJ0M-^EM-^QJ÷ð±õ


If the password is not created correctly or if the name resolution did not work properly, you will get the error messages shown in Example 14-15.

Example 14-15 Error messages when password is set incorrect

Incremental by snapshot difference of volume '/unix01'ANS2837E Failed to perform incremental backup operation using snapshot difference as the user id and password for NAS Filer 'sim1' have not been configured correctly.ANS2832E Incremental by snapshot difference failed for /unix01. Please see error log for details.ANS5283E The operation was unsuccessful.

You can find the reason of the error, using a TSM Client trace. To do this put the trace options in the dsm.opt client option file as shown in Example 14-16.

Example 14-16 AIX BA-Client Option File dsm.opt

Tracefile \tmp\tracefile.outTracemax 2048Tracesegsize 256Traceflags enter exit general snapshot hci hci_detail diskmap diskmap_detail hdw hdw_detail

The output in the trace file as a result of entering the failed incremental command is shown in Example 14-17.

Example 14-17 Trace-File output

06/04/09 18:53:21.764 : snapcommon.cpp ( 281): Entering nsGetNasVolumeInfo(): with: inputPath: </unix01>.06/04/09 18:53:21.765 : PsDiskMapper.cpp (3531): dmMapNasVolume: statvfs() for </unix01>. vfs_num <19>. type<nfs3>. fsid<7>06/04/09 18:53:21.765 : PsDiskMapper.cpp (3312): psCollectMountTableInfo: DevId:<19> NFS Mount point:</unix01>NFS Volume:</vol/unixvol01> NFS Host Name:<192.168.111.190> NFS Mount Options: <>:06/04/09 18:53:21.769 : PsDiskMapper.cpp (3795): psGetHostName(): gethostbyaddr() failed. hostname: <192.168.111.190>. Error: <1>.06/04/09 18:53:21.769 : PsDiskMapper.cpp (3626): dmMapNasVolume(): psGetHostName() failed. hostname: <192.168.111.190>. Error: <6201>.

06/04/09 18:57:01.139 : PsDiskMapper.cpp (3531): dmMapNasVolume: statvfs() for </unix01>. vfs_num <19>. type<nfs3>. fsid<7> 06/04/09 18:57:01.139 : PsDiskMapper.cpp (3312): psCollectMountTableInfo: DevId:<19> NFS Mount point:</unix01> NFS Volume:</vol/unixvol01> NFS Host Name:<192.168.111.190> NFS Mount Options: <>:06/04/09 18:57:01.143 : PsDiskMapper.cpp (3795): psGetHostName(): gethostbyaddr() failed. hostname: <192.168.111.190>. Error: <1>.06/04/09 18:57:01.143 : PsDiskMapper.cpp (3626): dmMapNasVolume(): psGetHostName() failed. hostname: <192.168.111.190>. Error: <6201>.06/04/09 18:57:01.144 : snapcommon.cpp ( 347): nsGetNasVolumeInfo(): dmMapNfsVolume() failed to map remote volume for path: </unix01>.


14.3.4 Using snapdiff option to do Incremental Backup for NAS file systems

To start an incremental backup with snapdiff option, you can ether use the Command-Line Interface (dsmc) or the Graphical User Interface (dsm or dsmj) with the Backup Archive Client for Windows and AIX. This option is valid for all Windows clients, except IA 64-bit and AIX 64-bit clients.

For the related options to the incremental command, see Tivoli Storage Manager for Windows Backup-Archive Clients Version 6.1, SC23-9792 and Tivoli Storage Manager for UNIX and Linux Backup-Archive Clients 6.1, SC23-9791.

Using command line interface dsmcExample 14-18 shows how to do an incremental backup with the new snapdiff option.

Example 14-18 Incremental Backup with snapdiff option using the Command Line Interface (dsmc)

tsm> inc -snapdiff=yes /unix01

Incremental by snapshot difference of volume '/unix01'Performing a full incremental of volume '/unix01' to establish a base snapshot

Successful incremental backup of '/unix01'

Total number of objects inspected: 10,111Total number of objects backed up: 10,111Total number of objects updated: 0Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 0Total number of objects failed: 0Total number of bytes transferred: 10.46 MBData transfer time: 0.21 secNetwork data transfer rate: 48,860.41 KB/secAggregate data transfer rate: 33.87 KB/secObjects compressed by: 0%Elapsed processing time: 00:05:16tsm>

The first time, a full incremental backup has to be taken, to establish a base Snapshot. To verify the Snapshots on your filer, enter the snap list command on your filer interface as shown in Example 14-19.

Example 14-19 Snap list command on Filer

snap list winvol01Volume winvol01working...

%/used %/total date name---------- ---------- ------------ -------- 1% ( 1%) 0% ( 0%) Jun 04 20:00 hourly.0 2% ( 1%) 0% ( 0%) Jun 04 16:00 hourly.1 3% ( 1%) 0% ( 0%) Jun 04 12:00 hourly.2 5% ( 1%) 0% ( 0%) Jun 04 08:00 hourly.3 10% ( 6%) 0% ( 0%) Jun 04 00:00 nightly.0


12% ( 2%) 0% ( 0%) Jun 03 20:00 hourly.4 13% ( 2%) 0% ( 0%) Jun 03 16:00 hourly.5 14% ( 1%) 0% ( 0%) May 25 00:00 nightly.1

snap list unixvol01Volume unixvol01working...

%/used %/total date name---------- ---------- ------------ -------- 0% ( 0%) 0% ( 0%) Jun 04 20:00 hourly.0 0% ( 0%) 0% ( 0%) Jun 04 16:00 hourly.1 0% ( 0%) 0% ( 0%) Jun 04 12:00 hourly.2 1% ( 0%) 0% ( 0%) Jun 04 08:00 hourly.3 1% ( 0%) 0% ( 0%) Jun 04 00:00 nightly.0 1% ( 0%) 0% ( 0%) Jun 03 20:00 hourly.4 1% ( 0%) 0% ( 0%) Jun 03 16:00 hourly.5 1% ( 0%) 0% ( 0%) May 25 00:00 nightly.1

snap list mixedvol01Volume mixedvol01working...

%/used %/total date name---------- ---------- ------------ -------- 1% ( 1%) 0% ( 0%) Jun 04 20:00 hourly.0 6% ( 5%) 0% ( 0%) Jun 04 16:00 hourly.1 7% ( 1%) 0% ( 0%) Jun 04 12:00 hourly.2 8% ( 1%) 0% ( 0%) Jun 04 08:00 hourly.3 13% ( 5%) 0% ( 0%) Jun 04 00:00 nightly.0 14% ( 1%) 0% ( 0%) Jun 03 20:00 hourly.4 15% ( 1%) 0% ( 0%) Jun 03 16:00 hourly.5 16% ( 1%) 0% ( 0%) May 25 00:00 nightly.1

The second time an incremental backup is run with this option, a newer Snapshot is either created or an existing one is used to find the differences between these two Snapshots. This second Snapshot is called the diffsnapshot. Tivoli Storage Manager then incrementally backs up the files reported as changed by NetApp by the Tivoli Storage Manager server. The file space selected for snapdiff processing must be mapped or mounted to the root of the volume.

You cannot use the snapdiff option for any file space that is not mounted or mapped to the root of the volume. After backing up data using the snapdiff option, the Snapshot that was used as the base Snapshot is deleted from the .snapshot directory. Tivoli Storage Manager does not delete the Snapshot if it was not created by Tivoli Storage Manager. You can also perform a snapdiff incremental backup with the -DiffSnapShot=Latest option. This will be documented in the statistics at the end of the backup, that no objects were inspected (see Example 14-20).


Example 14-20 Second incremental backup with NetApp Snapshot Difference

tsm> inc -snapdiff=yes /unix01

Incremental by snapshot difference of volume '/unix01'Successful incremental backup of '/unix01'

Total number of objects inspected: 0Total number of objects backed up: 0Total number of objects updated: 0Total number of objects rebound: 0Total number of objects deleted: 0Total number of objects expired: 0Total number of objects failed: 0Total number of bytes transferred: 0 BData transfer time: 0.00 secNetwork data transfer rate: 0.00 KB/secAggregate data transfer rate: 0.00 KB/secObjects compressed by: 0%Elapsed processing time: 00:00:04

If you are monitoring this backup on your filer, you will find that a Snapshot will be created and after successful completion, the previous one will be deleted.

Now, when we are looking for existing Snapshots after we did the backup with NetApp Snapshot Difference, we will see the Snapshot created and referenced by Tivoli Storage Manager as shown in Example 14-21.

Example 14-21 list snapshots after backup with NetApp Snapshot Difference

sim1*> snap list winvol01Volume winvol01working...

%/used %/total date name---------- ---------- ------------ -------- 1% ( 1%) 0% ( 0%) Jun 09 19:21 TSM_TEST4A2E9A320_WINVOL01 2% ( 1%) 0% ( 0%) Jun 09 19:15 newsnap02 3% ( 1%) 0% ( 0%) Jun 09 18:55 newsnap01 4% ( 1%) 0% ( 0%) Jun 06 00:00 nightly.0 5% ( 1%) 0% ( 0%) Jun 05 20:00 hourly.0 6% ( 1%) 0% ( 0%) Jun 05 16:00 hourly.1 7% ( 1%) 0% ( 0%) Jun 05 12:00 hourly.2 8% ( 1%) 0% ( 0%) Jun 05 08:00 hourly.3 9% ( 1%) 0% ( 0%) Jun 05 00:00 nightly.1 10% ( 1%) 0% ( 0%) Jun 04 21:16 TSM_RS604A280EA537B71_WINVOL01 11% ( 1%) 0% ( 0%) Jun 04 20:00 hourly.4 12% ( 1%) 0% ( 0%) Jun 04 16:00 hourly.5


Using the Graphical User InterfaceYou can do the same procedure using the Graphical User Interface. Start your dsm or dsmj session from your backup archive client (see Figure 14-5).

Figure 14-5 select the mounted file system for incremental backup


The file system must be mounted either with IP Address or by network name. The password you have set must be stored with same IP Address or network name.

The next step is to select the backup method, use the new function incremental (snapshot difference) instead of traditional incremental (see Figure 14-6).

Figure 14-6 select incremental (snapshot difference) for backup

When you click the Backup button, you will get another window that asks you, if you want to create a new snapshot or if you want to use an existing one that you have created before manually on the filer. In our case we select Create (see Figure 14-7).


Figure 14-7 select create for snapshot usage

After a successful backup, you get the statistics showing that 11 new files are backed up, but no files were inspected. This is because we are using NetApp (see Figure 14-8).

Figure 14-8 Detailed statistics report from backup with NetApp Snapshot Difference


14.3.5 Hints and tips for troubleshooting

Here we provide some additional information that we found during our test.

Qtree security style dependenciesYou have to consider that, with a Windows client, you can back up file systems residing on volumes created on the filer with a qtree security style of NTFS or MIXED. On an AIX client, you can back up file systems residing on volumes created on the filer with qtree security style of UNIX or MIXED.

Example 14-22 shows how you enter the command on your filer and what result you will get:

Example 14-22 qtree status

sim1> qtreeqtree: This command is deprecated; using qtree status.Volume Tree Style Oplocks Status-------- -------- ----- -------- ---------vol0 unix enabled normalwinvol01 ntfs enabled normalunixvol01 unix enabled normalmixedvol01 mixed enabled normal

We highly recommended avoiding mixed style volumes:

� If mixed is necessary, avoid offering or using write-access from CIFS and NFS-world on volume-level. Back up only from that world, where writes are allowed.

� If mixed, avoid at least write-access from CIFS and NFS-world on directory-level. Backup only from that world, where writes are allowed on directory level.

� If you do mixed mode and write from different worlds (for example, NFS and CIFS) to the directory, you will lose some write-attributes over time (at least, when you have to restore from backups).

Problems with authentication against the filerIf you get the error message ANS2837E, you have to check if the password is set correctly. For this, you can use regedit in Windows or look in /etc/security/adsm to find out what is wrong. An overview of this situation is shown in Figure 14-9.

Note: Backup of mixed style volumes is not supported with Tivoli Storage Manager backup archive client, even if it works.


Figure 14-9 Error message ANS2837E, wrong password or wrong mount

In this case, the password was set to the name and we are trying to do the backup against the IP address of the filer. So this is a dependency you must consider. This might not appear on AIX systems, when the IP Address can be resolved.

14.3.6 Performance issues and test results

NetApp Snapshot Difference was implemented for customers with so-called “Big Fat Filers” housing millions of files, with unacceptable backup windows. Using incremental backup by NetApp, the Tivoli Storage Manager Client does not need to crawl the file space looking for changed files, but instead queries the ONTAP 7.3 OS on a filer for what files have changed since the last -snapdiff or -diffsnapshot backup.

Note: We could not use the Tivoli Storage Manager Web Client GUI, because mapped drives are not visible under the Network node in the Backup Tree Window of the Tivoli Storage Manager Web client GUI when connecting to Tivoli Storage Manager clients on Windows XP and Windows 2003. For more information, refer to the Technote, Unable to view/back up network drives using Tivoli Storage Manager Web client on Windows:


Note: The performance data contained in this document was measured in a controlled environment. Results obtained in other operating environments can vary significantly depending on factors such as system workload and configuration. Accordingly, this data does not constitute a performance guarantee or warranty.



This method specifically speeds up incremental backups of filers with many files, and with a small percentage of changed files. In a classic incremental backup, the Tivoli Storage Manager Client will spend hours on a large file system, searching for changed files. In both extremes, NetApp Snapshot Difference performs better than classic incremental, but especially so when relatively few files have been changed. Testing was also performed on a small file system to ensure that there was no performance degradation when using NetApp on such a system.

Test environmentOur test environment consisted of the following components:

� Filer: N5300 with Data ONTAP Release 7.3� Tivoli Storage Manager Server: 5.5.1.0 on a 2-way 3.4 GHz, 4 GB Windows Server 2003� Tivoli Storage Manager Client: 6.1.0.0 connected to local Tivoli Storage Manager Server� Storage Pool: File pool on fibre-attached DS8K� Small Workload: 8 thousand 100 KB files� Large Workload: 1.2 million 10 KB files� Huge Workload: 12 million 10 KB files

Test results with small workloadThese were our test results with a small workload:

� In the Small Workload test, when 10% data changed, using NetApp Snapshot Difference improved throughput from 1538 KB/sec to 2758 KB/sec (80% improvement).



Test results with large workloadThese were our test results with a large workload:

� In the Large Workload test, when 10% data changed, using NetApp Snapshot Difference improved throughput from 228 KB/sec to 676 KB/sec (196% improvement) (about 3x as fast).

� In the Large Workload test, when 20% data changed, using NetApp Snapshot Difference improved throughput from 433 KB/sec to 756 KB/sec (75% improvement).

� In the Large Workload test, when 80% data changed, using NetApp Snapshot Difference improved throughput from 472 KB/sec to 913 KB/sec (93% improvement).

Test conclusionsHere we discuss our test conclusions:

� In the Huge Workload test, when 10% data changed, using NetApp Snapshot Difference improved throughput from 199 KB/sec to 537 KB/sec (170% improvement).

� As an example of a reduced backup window, NetApp reduced the backup window of this test from almost 17 hours to about 6.25 hours (37% of the time).

The improvement is quite significant when only a small percentage of the data changes. Specific results will vary depending on the hardware configuration. If the percentage of changed data is lower than 10%, an even greater improvement will be expected. Refer to:





Chapter 15. IBM Tivoli Storage Manager Data Protection for Mail: Exchange 6.1

The Tivoli Storage Manager for Mail 6.1 product updated the Data Protection for MS Exchange component. This product has been updated to include Individual Mailbox Restore (IMR), using the GUI.

In this chapter we explain how you can use this Mailbox Restore feature to perform individual mailbox and item-level recovery operations in Microsoft Exchange Server 2003 or Microsoft Exchange Server 2007 environments using Data Protection for Exchange backups.

15


15.1 System requirements

In the following topics, we highlight the hardware and software requirements for Data Protection for Microsoft Exchange V6.1.

15.1.1 Data Protection for Microsoft Exchange V6.1 on Windows for x86

Data Protection for Microsoft Exchange on Windows for x86 requires the following hardware and software:

� Intel® Pentium® 166, or later processor (or equivalent) with at least 20 MB of available disk space and 96 MB of RAM is required.

� One of the following operating system options is required:

– Windows Server 2003 with SP2, or later: Standard, Enterprise, or Data Center editions – Windows Server 2003 R2 with SP2, or later: Standard, Enterprise, or Data Center

editions – Windows Server 2008 Standard, Enterprise, or Data Center without Hyper-V editions

15.1.2 Microsoft Exchange Server 2003 SP2 or later

The requirements for Microsoft Exchange Server 2003 SP2 or later, for Standard or Enterprise Editions are listed here:

� Tivoli Storage Manager Server Version 5.5.0 or later is required.

� Tivoli Storage Manager API Version 5.5.1 or later is required.

Tivoli Storage Manager API Version 5.5.1 is included and is automatically installed with Data Protection for Exchange 6.1.

� An IBM Tivoli Storage Manager backup-archive client V5.5.1, or later, if IBM Tivoli Storage Manager central scheduling is used.

� An IBM Tivoli Storage Manager backup-archive client V5.5.1, or later, if VSS operations are used, is required.

� Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1 version 6.5.8067.0, or later, if mailbox restore operations are used, is required.

When backing up Exchange Server 2003, Microsoft .NET Framework V2.0, or later, is required.

15.1.3 Data Protection for Microsoft Exchange V6.1 on Windows for x64

Data Protection for Microsoft Exchange on Windows for x64 requires the following hardware and software:

� Intel EMT64, or AMD Opteron, or equivalent x64 processor with at least 20 MB of available disk space and 96 MB of RAM.

Note: Microsoft Cluster Server (MSCS) and Veritas Cluster Server (VCS) are supported. Refer to the User's Guide for details on MSCS and VCS configuration. Running in a Microsoft Virtual Server 2005 R2 SP1 or later x86 guest is supported.


� One of the following operating system options:

– Windows Server 2003 with SP2 or later: Standard x64, Enterprise x64, or Data Center x64 editions.

– Windows Server 2008 Standard x64, Enterprise x64, or Data Center x64, without Hyper-V editions

– Microsoft Exchange Server 2007: Standard or Enterprise Editions.

– Tivoli Storage Manager Server Version 5.5.0 or later.

– Tivoli Storage Manager API Version 5.5.1 or later.

– Tivoli Storage Manager API Version 5.5.1 is included and automatically installed with Data Protection for Exchange 6.1.

– An IBM Tivoli Storage Manager backup-archive client V5.5.1, or later, if IBM Tivoli Storage Manager central scheduling is used.

– An IBM Tivoli Storage Manager backup-archive client V5.5.1, or later, if VSS operations are used.

– Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1 version 6.5.8067.0, or later, if mailbox restore operations are used.

15.1.4 Compatibility issues with earlier versions

Data Protection for Microsoft Exchange Server 6.1 is compatible with the previous versions:

� 2.2.0� 2.2.1� 5.1.5� 5.2.1� 5.3.3� 5.5.0� 5.5.1

You cannot restore Data Protection for Exchange Version 1 backups with later versions of Data Protection for Exchange (including 6.1). You must retain Data Protection for Exchange Version 1 for as long as you maintain Version 1 backups.

15.1.5 Backup methods supported

Data Protection for Microsoft Exchange Server 6.1 supports the following backup methods.

� Full Backup (Proprietary and VSS):

A Full backup backs up the specified storage group, as well as associated transaction logs.

� Incremental Backup (Proprietary only):

An incremental backup backs up only transaction logs, and clears the logs after the backup completes.

� Differential Backup (Proprietary only):

A differential backup only backs up transaction logs, but does not delete them after the backup is completed.

Note: Microsoft Cluster Server (MSCS) and Veritas Cluster Server (VCS) are supported. Refer to the User's Guide for details on MSCS and VCS configurations.

Chapter 15. IBM Tivoli Storage Manager Data Protection for Mail: Exchange 6.1 237

� Copy Backup (Proprietary only):

A copy backup is similar to a full backup except that transaction log files are not deleted after backup, and does not affect the full/incremental backup sequencing.

� Database Copy Backup (Proprietary only):

A database copy backup only backs up the specified database as well as its associated transaction logs.

15.2 Individual Mailbox Restore feature

With the Individual Mailbox Restore feature, you can perform individual mailbox and item-level recovery operations in Exchange Server 2003 or Exchange Server 2007 environments using Data Protection for Exchange backups. This feature:

� Supports mainstream platforms:

– Exchange Server 2003 and Exchange Server 2007– Windows Server 2003, Windows Server 2008– 32-bit x86 and 64-bit x64

� Uses strictly Microsoft recommended techniques and interfaces:

– Recovery Storage Groups– Messaging API (MAPI)– CDOExm– Exchange Management Shell

� Has a single user interface for:

– Storage group, database, mailbox or message restore– Proprietary or VSS restores– Full, differential, incremental, and copy restores

� Supports existing backup procedures – no changes required:

– Does not require separate, costly “brick” backups– Mailboxes can be restored from backups made with previous versions of Tivoli Storage

Manager for Mail

� Offers full Tivoli Storage Manager integration:

– Full automation and handling of Exchange recovery– Simple command-line interface – ‘tdpexcc restoremailbox <mailbox>’– Simple GUI - GUI panel allows for easy user selection– Globalization and localization

� Can recover deleted or relocated users

� Can run recovery from original server or alternate server

� Maintains mailbox history (which backups contain which mailboxes)

� Provides Active Directory-based security

� Supports multiple restore destinations:

– Original location– Alternate mailbox and folder– Outlook data (.PST) file


� Restores multiple object types:

– Messages– Calendar entries– Contacts– Notes, tasks– User folders

� Has user-selectable restore granularity:

– Multiple mailboxes– Single mailbox– Multiple messages or contacts– Individual message or contact

� Offers advanced filtering capability based on:

– Subject– Sender– Message date/time– Attachments– Other text, such as message body or folder name

15.2.1 Individual Mailbox Restore limitations

These items are considered restrictions when using the Individual Mailbox Restore feature:

� PST files are limited to non-Unicode and 2 GB in size.� There is no support for public folders.� Manual intervention is required to set up Recovery Storage Groups on Exchange 2003;

direct Exchange server administrative action is required.� A full storage group (database object) restore is required in order to restore individual

mailboxes or other content.

15.2.2 Tivoli Storage Manager 6.1 Mailbox Restore features

Tivoli Storage Manager 6.1 Mailbox Restore offers the following features:

� Supports mainstream platforms:

– Exchange Server 2003 and Exchange Server 2007– Windows Server 2003, Windows Server 2008– 32-bit x86 and 64-bit x64

� Uses strictly Microsoft recommended techniques and interfaces:

– Recovery Storage Groups– Messaging API (MAPI)– CDOExm– Exchange Management Shell

� Has a single user interface for:

– Storage group, database, mailbox or message restore– Proprietary or VSS restores– Full, differential, incremental, and copy restores

� Supports existing backup procedures – no changes required:

– Does not require separate, costly “brick” backups– Mailboxes can be restored from backups made with previous versions of Tivoli Storage

Manager for Mail


� Offers full Tivoli Storage Manager integration:

– Full automation and handling of Exchange recovery– Simple command-line interface – tdpexcc restoremailbox <mailbox>– Simple GUI - GUI panel allows for easy user selection– Globalization and localization

� Can recover deleted or relocated users

� Can run recovery from original server or alternate server

� Maintains mailbox history (which backups contain which mailboxes)

� Provides Active Directory-based security

� Supports multiple restore destinations:

– Original location– Alternate mailbox and folder– Outlook data (.PST) file

� Restores multiple object types:

– Messages– Calendar entries– Contacts– Notes, tasks– User folders

� Has user-selectable restore granularity:

– Multiple mailboxes– Single mailbox– Multiple messages or contacts– Individual message or contact

� Offers advanced filtering capability based on:

– Subject– Sender– Message date/time– Attachments– Other text, such as message body or folder name

15.2.3 Exchange Server: Mailbox Restore

Here we take a look how to restore a specific user’s entire mailbox or individual items.

We launch the Mailbox Restore window from the DP interface as shown in Figure 15-1. In this scenario, we need to restore two mailboxes; “Elton John” and “The First Storage Group”.

We use the listbox element named Mailbox and the Add button to the right to place the restore requests into the list on the right.

On the Mailbox Restore window, you can set filters and also change the destination location for the Restore. After setting all parameters, click Restore.

� Examples of Mailbox restore are as follows:

– Restore a user’s mailbox that was accidentally deleted.– Restore a user’s mailbox as it existed on December 31, 2007.– Restore Andy Pettite’s “HGH” mailbox folder as it existed on 12/31/2007.– Restore all messages received from “Roger Clemens” on 1/18/2008.


Figure 15-1 Mailbox Restore launch and filter specification

Next, the Restore Progress window is presented, as shown in Figure 15-2.

Figure 15-2 Mailbox Restore Recovery Progress window


15.2.4 Tivoli Storage Manager Mailbox Restore limitations

The following restrictions apply to the Mailbox Restore function:

� PST files must be non-Unicode and limited to 2 GB.

� There is no support for public folders.

� Manual intervention is required to set up Recovery Storage Groups on Exchange 2003.

� A full restore to a temporary location is done, in order to restore individual mailboxes.

15.2.5 The restoremailbox command line parameter

The following new command-line-only parameter has been added to the tdpexcc command to allow for the individual mailbox recovery:

restoremailbox

Use the command-line interface when you must use the mailboxoriglocation optional parameter to specify the server, the storage group, and the database where the mailbox was located at the time of backup. The following additional command line parameters are required for this recovery:

� server-name: Name of Exchange Server where the mailbox resided at the time of backup� sg-name: Name of storage group where the mailbox resided at the time of backup� dbname: Name of database where the mailbox resided at the time of backup

Note: Microsoft is de-emphasizing public folders in favor of Sharepoint.


Part 6 Tivoli Storage Manager V6.1 planning considerations

This part of the book covers the planning considerations for the installation of Tivoli Storage Manager V6.1 and upgrade to Tivoli Storage Manager V6.1.

Part 6


Chapter 16. Installation and upgrade planning for Tivoli Storage Manager V6.1

In this chapter we discuss details related to planning your Tivoli Storage Manager V6.1 installation or upgrade. It is our intention to provide you with insight on multiple upgrade methods, because the upgrade process has changed from previous releases.

To further understand the changes in the upgrade process, refer to the Tivoli Storage Manager Server Upgrade Guide, SC23-9554.

For the changes in the installation process, refer to the Tivoli Storage Manager Installation Guide for your particular platform as listed in “Related publications” on page 627.

16


16.1 Overview

Next we discuss what is delivered this release of Tivoli Storage Manager, as well as what is not included. Further, we go through the steps in preparation, those things that you need to think about when to do the upgrade.

Our intent here is to give you an understanding of what the requirements are, to put into perspective the resources, time, and effort that are required to install or upgrade to Tivoli Storage Manager V6.1 using the DB2 database.

We begin our discussion about strategy and what the upgrade is, in terms of the resource time and effort to get there. The basic things to consider include the upgrade process itself, which is a resource intensive process, as well as a number of considerations in planning for the upgrade. In certain ways, this upgrade process is similar to previous upgrades, but because of the time and resources required, it can become complicated, and planning is really the solution.

16.2 Upgrade strategy

Investing some of your valuable time in the planning phase for the installation or upgrade for Tivoli Storage Manager V6.1 is a wise investment, and critical for success. New requirements and new processes make the planning phase more important than ever when working with your Tivoli Storage Manager server.

Some considerations would be the moving of data from an original V5 server database to the V6.1 database. This process will use a large percentage of a system’s processor and requires a high amount of I/O activity. You have options for how to perform this task, whether this is across a network connection or utilizing storage media.

In your planning, consider testing the upgrade on non-production systems. Testing gives you information about how long the upgrade of the server database will take, which will help you to plan for the time that the server will be unavailable. Some databases might take much longer than others to upgrade.

Testing also gives you more information about the size of the new database compared to the original, giving you more precise information about database storage needs.

If you have multiple servers, consider upgrading one server first, to get experience with how the upgrade process will work for your data. Use the results of the first upgrade to plan for upgrading the remaining servers.

16.2.1 What you can and cannot do with Tivoli Storage Manager V6.1

Next we list some examples of what you can and cannot do in Tivoli Storage Manager V6.1. This list is subject to change and we suggest that you go to the Tivoli Storage Manager Wiki for the latest updates:

http://www.ibm.com/developerworks/wikis/display/tivolistoragemanager/Home



What you can doIn Tivoli Storage Manager V6.1:

� You can run multiple Tivoli Storage Manager database instances on the same operating systems image.

� You can forget about having to do database audits and off-line reorganizations. The reorganizations will happen when DB2 has less activity and when there is a need for it. You will see messages in the activity log when that happens.

� The database and log volumes must be on a file system. You cannot use Raw Logical Volumes for the database and Log volumes from a disaster recovery perspective where it takes less time to create Raw Logical Volumes and bring up the system faster. The upgrade utility will read the database or logs if they are on Raw Logical Volumes. You can still use Raw Logical Volumes for storage pool volumes.

� If you have multiple instances on the same operating system, you can run multiple Tivoli Storage Manager database upgrades at the same time, given that you have enough resources. When you upgrade one of the instances to V6.1, you need to upgrade all instances before you can start the other instances.

� We can use Tivoli Storage Manager export/import to go from V5.x to V6 to do the upgrade instead of using Tivoli Storage Manager database upgrade utilities

What you cannot doIn Tivoli Storage Manager V6.1:

� You cannot run multiple levels of Tivoli Storage Manager software on the same server.

� You cannot use an existing DB2 code install on a Windows system. In fact you must use the DB2 that installs with the Tivoli Storage Manager server. This restriction might be lifted at some point. You should check the following Technote for the latest status:


� Tivoli Storage Manager cannot use a DB2 database from a remote system.

� You cannot change operating systems platforms with the upgrade (for example, from AIX to Windows or vice verse). There are a few exceptions to this rule and more information is provided in the upgrade guide.

� You cannot merge multiple Tivoli Storage Manager databases with the upgrade.

� You cannot change operating systems platforms after the upgrade using DB2 export/import. Tivoli Storage Manager export/import must still be used for this.

� With Tivoli Storage Manager V6.1 you cannot have multiple Tivoli Storage Manager database backups placed on a tape. This is a known requirement that will be implemented in a future release of Tivoli Storage Manager.

� Database backup cannot be encrypted. This is a known requirement, but is not implemented in this release. If we want, we can take a backup to a device that supports encryption such as the TS1120. This however requires an external key manager.

� It is not supported to use Raw Logical Volumes for the database and log volumes. The database and log volumes must be on a file system. Tivoli Storage Manager can still use Raw Logical Volumes for storage pool volumes from a disaster recovery perspective where it takes less time to create Raw Logical Volumes, allowing you to bring up the system faster.

Chapter 16. Installation and upgrade planning for Tivoli Storage Manager V6.1 247


16.2.2 Upgrade considerations

For Windows Tivoli Storage Manager Servers – if the Tivoli Storage Manager server being upgraded contains multiple NICs, it might be necessary to disable all of them except one in order to use the Database Upgrade Wizards. The NICs can be re-enabled after the DB upgrade has completed.

If you have a shared library configuration, you must upgrade the server that is the library manager first and follow this by upgrading the library clients. Library clients must be at least level 5.4 or higher for compatibility with V6.1 Tivoli Storage Manager Server.

Consider building a test environment during the planning phaseMoving data from an original Tivoli Storage Manager server database to the new database requires higher rates of I/O activity, and consequently increased CPU utilization. In your planning, consider testing the upgrade on non-production systems. Testing gives you information about how long the upgrade of the server database will take, which will help you to plan for the time that the server will be unavailable. Remember, your mileage can vary, because some databases might take much longer than others to upgrade.

Testing also gives you more information about the size of the new database compared to the original, giving you more precise information about database storage needs. The results will feed into your production planning requirements.

If you have multiple servers, consider upgrading one server first, developing experience with how the upgrade process will work (unique process building). Use the results of the first upgrade to plan for upgrading the remaining servers.

If you are considering a consolidation of your Tivoli Storage Manager servers, this process needs to be tested. After the initial upgrade, all other consolidation activities are essentially using the server export command, which can result in extended durations for larger nodes. In some cases where a large amount of archive data resides, consider possibly extracting backup data only, then leaving the archive data to remain on the existing server until it is convenient to migrate later, with less impact to the overall environment.

16.3 Preparation

To prepare for the installation or upgrade, you must first review a few sections and consider developing a structured plan for this activity. The sub-sections immediately following provide platform specific links for both installation and upgrade, and a few other useful components that you must review prior to starting your tasks.

16.3.1 System requirements for the V6.1 server system

The system requirements for each platform vary, thus in this section we provide the URL links for you to review during the planning phase for either upgrading or installing of the Tivoli Storage Manager V6.1 server.


Installation platformsFor installation platforms, see the following links.

AIXhttp://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_srv_aix_sysreq_inst.html

HP-UXhttp://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_srv_hp_sysreq_inst.html

Linuxhttp://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_srv_lnx_sysreq_inst.html

Solarishttp://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_srv_sun_sysreq_inst.html

Windowshttp://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_srv_wnt_sysreq_inst.html

Upgrade platformsFor upgrade platforms, see the following links.

Hardware and software requirements for V5 serversThe system requirements for the upgrade utility are the same as the system requirements for a V5.5 server, because the upgrade utility is based on the V5.5 server code. For additional information, refer to the following Web sites to compare the system on which your Tivoli Storage Manager V5.3 or V5.4 server is running with the requirements for a V5.5 server.

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/r_srv_upgrd_v5srv_reqmts.html

Hardware and software requirements for the upgraded serverhttp://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/c_srv_upgrd_hwswreqs.html

AIXhttp://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/r_srv_upgrd_aix_sysreq.html

HP-UXhttp://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/r_srv_upgrd_hp_sysreq.html

Linuxhttp://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/r_srv_upgrd_lnx_sysreq.html


http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/r_srv_upgrd_v5srv_reqmts.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_srv_aix_sysreq_inst.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_srv_hp_sysreq_inst.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_srv_lnx_sysreq_inst.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_srv_sun_sysreq_inst.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_srv_wnt_sysreq_inst.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/c_srv_upgrd_hwswreqs.html

Solarishttp://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/r_srv_upgrd_sun_sysreq.html

Windowshttp://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/r_srv_upgrd_win_sysreq.html

Upgrade scripts, commands and utilitiesWe supply the following link for you to review some existing scripts, commands, and utilities that you might find useful.

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/r_srv_upgrd_ref.html

16.3.2 System requirements for the V6.1 reporting and monitoring

Tivoli Storage Manager reporting and monitoring feature runs on AIX, Linux, and Windows platforms only. You can review the system requirements at the following URL:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_rpt_inst_hwswreqs.html

16.3.3 Client environment requirements

Tivoli Storage Manager clients have software and hardware requirements for each supported platform, which you should review at the following URL:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.client.doc/c_inst_env.html

16.3.4 Tivoli Storage Manager Client compatibility

The Tivoli Storage Manager Client level is supported with which Server level, as shown in Table 16-1.

Table 16-1 Tivoli Storage Manager Client and Storage Agents compatibility

Tivoli Storage Manager Agent compatibilityTable 16-2 shows which Tivoli Storage Manager Agent level is supported with which Server level.

If you have a Tivoli Storage Manager client at this level:

It is compatible and is supported with these Tivoli Storage Manager Server/Storage Agent levels:

Tivoli Storage Manager Version 6.1 Versions 6.1, and 5.5

Tivoli Storage Manager Version 5.5 Versions 6.1, 5.5 and 5.4


Note: V5.4 clients do not include the special 5.3.6-level clients (Windows 2000, Solaris 8, and Linux x86 RHEL 3.


http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/r_rpt_inst_hwswreqs.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.client.doc/c_inst_env.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/r_srv_upgrd_ref.html

Table 16-2 Storage Agent and Tivoli Storage Manager server V6.1 compatibility chart

16.4 Database capacity planning

There are many things to plan for regarding the capacity of your database in V6.1. You need to know that DB2 spreads its database across operating system directories in “containers.”

We recommend to define the database and recovery log directories on separate physical volumes or file systems. Ideally, use multiple directories for database space and spread them across as many physical devices or logical unit numbers (LUNs) as there are directories. With Tivoli Storage Manager V6.1, we recommend for a production server to use at least four database directories (disks), where the number reflects the database size, however, this can grow up to 128 database directories for the DB2 database as required.

You can add DB2 directories with the new EXTEND DBSPACE command to an existing installation and this requires a restart of the server for the change to become active. An important item to mention is when we add a new database directory, after the initial load it will cause a REORG, which needs to be avoided if possible. A REORG is expensive and disruptive. One method that will not cause a REORG is to extend the existing file systems in UNIX or disks in Windows if there is a need for database space. Adding the physical disk, then extending the file systems (and subsequently the directories holding the DB2 databases) will not cause the REORG to occur.

To review the V6.1 product capacity planning information, and access product planning sheets, go to the following URL:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/t_srv_plan_capacity.html

16.4.1 Overview of the four different log types

It is very important to understand how the recovery logs work in V6.1. In this section we provide a brief description of the different logs.

With V6.1 the recovery logs are no longer owned by Tivoli Storage Manager; the database and logs are owned by DB2. There are four different logs in DB2 that we describe next.

The ACTIVE log The ACTIVE log is a Tivoli Storage Manager term, so when we talk to a DB2 person they might not understand what the term ACTIVE log is. The ACTIVE log has a fixed-size non-circular log, which is composed of 512 MB files. The default installation creates a 2 GB ACTIVE log size of four 512 MB log files. Those files are created when the database initially formats. The minimum size of the ACTIVE log is 2048 MB (2 GB); the maximum is 131,072 MB (128 GB).

If you have a Tivoli Storage Manager server at this level:

It is compatible and is supported with these Tivoli Storage Manager Storage Agent levels:


Note: Do not underestimate the log requirements when planning the capacity of the log files. If any of the active, archive, or secondary archive logs fill up, the server will eventually halt.



We recommend that you begin with an ACTIVE log size two times the size of the V5 maximum size (13 x 2 =26GB), monitor the space usage, and adjust the size of the ACTIVE log as needed. We must ensure that the ACTIVE log has enough space. Because you should have a log mirror on a separate disk, consider this in your planning.

The initial directory of ACTIVE logs is determined by the ActiveLogDir parameter (on dsmserv format / loadformat), this can be changed later in dsmserv.opt. If you make changes in the ActiveLogDir parameter, the Tivoli Storage Manager must be restarted for the change to take effect. Prior to making any changes to the active log directory path, perform a full database backup.

The ACTIVE log is in Roll-forward mode only, and is a sequential IO access device. The way this works in V6.1 is that the ACTIVE log is a part of the log that always contains the most recent log records (in-flight transactions) data.The ACTIVE Log files are copied to the ARCHIVE log directory when the ACTIVE log is full. DB2 creates files from the ACTIVE log when the ACTIVE log is full. If the ARCHIVE log directory is full, ACTIVE log files cannot be copied over to the ARCHIVE log directory. If the ACTIVE log files cannot be copied, they cannot be deleted, which leads to an out-of-log space in the ACTIVE log and no new ACTIVE logs can be created. Transactions can still be active when they are archived, but the active log file cannot be deleted until ALL transactions within the log file are either committed or aborted. This also applies to transactions that flow through an active log file.

The ARCHIVE logThe ARCHIVE log contains committed and in-flight transaction data log files that are needed after the database restore to roll transactions forward. If the ACTIVE log incurs an exhausted space condition, then the in-flight transactions are sent to the ARCHIVE log. The ARCHIVE log files are appended to the database backup in Tivoli Storage Manager and are deleted by DB2 automatically after the database backup.

You should plan on having up to three full backups worth of space for ARCHIVE logs or plan on doing backups more often. The ARCHIVE logs are also sequential IO access in nature, and they must be used in your configuration. The initial directory of ARCHIVE logs determined by ArchiveLogDir parameter (on dsmserv format / loadformat) and can be changed later in the dsmserv.opt file. Changing the ArchiveLogDir directory requires Tivoli Storage Manager to be restarted.

Log files older than two full backups ago are removed after a database backup. If ARCHIVE log directory becomes full, and no fail over ARCHIVE log location has been specified, then Tivoli Storage Manager just keeps logs in the ActiveLogDir location and creates new ones. If this fills, then Tivoli Storage Manager halts.

The size of the ARCHIVE log depends on the number of objects stored by client nodes over the period of time between full backups of the database. A full backup of the database causes obsolete ARCHIVE log files to be pruned, to recover space. The ARCHIVE log files that are included in a backup are automatically pruned after two more full database backups have been completed. Therefore, the ARCHIVE log should be large enough to contain the logs generated since the previous two full backups. If you perform a full backup of the database every day, the ARCHIVE log must be large enough to hold the log files for client activity that occurs over two days. You can run several database backups on the same day to keep the ARCHIVE logs from filling if you choose to do so.

Note: Even a 128 GB ACTIVE log can fill up in an extreme situation. We recommend that you define the ACTIVE log no greater than 120 GB so you can extend it if necessary.


ACTIVE log mirrorThe ACTIVE log mirror is a duplicate copy of the ACTIVE log; it should be the same size as the ACTIVE log, and the log mirror is optional. The additional space that the log mirror requires is another factor to consider when calculating your requirements, as is the need to locate this on a separate physical disk (and possibly a separate attaching path or subsystem to gain the greatest level of redundancy as possible). We recommend that you use the ACTIVE log mirror.

The initial directory of ACTIVE log mirrors is determined by MirrorLogDir parameter (on dsmserv format / loadformat) and can be changed later in dsmserv.opt. If you make changes in the ActiveLogDir parameter, the Tivoli Storage Manager must be restarted to the change to take effect.

The mirror log files are created in 512 MB sized files. If the mirror log directory becomes full, a message is issued, the server continues to operate; it does not fail.

The ARCHIVE FAILOVER logThe ARCHIVE FAILOVER log is used by the server if the ARCHIVE log directory runs out of space. Specifying an ARCHIVE FAILOVER log directory can prevent problems that occur if the archive log runs out of space. If the drive or file system where the ARCHIVE FAILOVER log directory is located becomes full (or unavailable), the data remains in the ACTIVE log directory. This condition can cause the ACTIVE log to fill up, which causes the server to stop.

The use of this feature is optional, but highly recommended. Consider use of large NFS mountpoint or large SATA disk for this. The IO access is sequential. You can set it with the ArchFailOverLogDir parameter (on dsmserv format / loadformat), or add it later in the dsmserv.opt file. Log files are removed after DB backup. Changing the ArchFailOverLogDir directory requires Tivoli Storage Manager to be restarted before it takes effect.

16.4.2 Recovery logs summary

To summarize, you need to understand how the logs work in V6.1 DB2, as part of Tivoli Storage Manager's database and recovery log solution. The logs should not be directly manipulated. They will be managed automatically by Tivoli Storage Manager and DB2.

You have to determine and configure the DB2 database and recovery log space that is required before starting the install or upgrade process. You need unique, empty directories (separate disk mount points is preferable) for the following components of the V6.1 server:

� The database:

– Multiple disks or mount points recommended

� The recovery log:

– Active log– Archive log– Optional: Log mirror for the active log– Optional: Secondary archive logs (failover location for archive log)

The ARCHIVE log size depends upon how much activity you have and how often you back up the database. As ACTIVE logs fill up, they are copied to the archive directory. They remain there until the database is backed up, at which time the logs are appended to the database backup. They get erased when the database backup completes. In V6.1.1, two days are held due to a DB2 issue, which is currently being worked on.

Attention: It is extremely important that the directories for the recovery logs do not fill up.


If the ACTIVE log is too small to handle the workload, it will fill up. If the ARCHIVE log directories are too small to contain two days worth of logs, they will fill up. If the ARCHIVE log directories fill up, the ACTIVE log will eventually fill up. If the ACTIVE log fills up for any of these reasons, the server will halt.

Place the database and the ACTIVE log on fast, reliable storage, with high availability characteristics. Ideally, use multiple directories for database space and locate them across as many physical devices or logical unit numbers (LUNs) as there are directories. Place the database and recovery log directories on separate physical volumes or file systems.

The ACTIVE log must be on a high-speed reliable disk. The ARCHIVE log can be on a slower disks. The failover archive log can be on even slower disks, assuming that it is used. infrequently (you can even use the network file server (NFS) for the failover archive logs).

To maintain database integrity, ensure that the storage hardware can withstand failures such as power outages and controller failure. You can improve database performance by using hardware that provides a fast, nonvolatile write cache for both the database and logs.

If there is an error writing to either the primary or log mirror, the failing path to the log is marked as bad and a message is written to the log. The writes continue to the remaining good log volume until the current log volume is filled. When DB2 needs to open the next log file, then the path is retested and reused if it is OK. If an error occurs in the remaining good path, Tivoli Storage Manager will halt.

Ultimately, with the cost of disk storage continuing to drop, do not hesitate to over-configure your database and log structure. The investment will pay dividends as compared to an under-configured environment. Balancing your IO is a critical area, especially for heavily loaded servers.

16.5 Planning an upgrade from V5 to V6

In this section we cover the steps needed to upgrade a Tivoli Storage Manager Server V5.x to Tivoli Storage Manager V6.1. We walk through an example step by step showing how we upgraded a V5.5 server to V6.1 using the network model and the wizard.

16.5.1 Database restructure

Tivoli Storage Manager V6.1 contains a major restructuring of the Tivoli Storage Manager database. We are converting from the proprietary B-tree database, which has been the heart of Tivoli Storage Manager for many years, to a DB2 database, which is external to Tivoli Storage Manager.

One of the things that can be done now is to query the database directly without the need to go through the Tivoli Storage Manager administrator command line. This approach does provide you some additional options.

There are several reasons for converting to the DB2 database. The Tivoli Storage Manager V5.5 database implementation is reaching its limits in terms of size, performance, and function. Many of you are experiencing the impact of reaching those limits, creating multiple instances of the Tivoli Storage Manager database to handle your workload.

Note: The DB2 database should be treated as read-only. Do not make any changes to the schema, configuration, or content.


Just as important, this change positions Tivoli Storage Manager database not only for additional growth in capacity, but also for new functions that will be easier to implement with this richer database employed. This change should also free Tivoli Storage Manager development resources from the intricacies of maintaining a database to begin to exploit a database.

The goal is equivalent performance compared to Tivoli Storage Manager V5.5, that is, the overall throughput, for a representative set of operations, should be comparable to that with the proprietary database. This is the first implementation of Tivoli Storage Manager database using DB2 and as such, there might be some side effects of using the new database. Some things will run faster and some might run a little slower and some things might just work differently than they have in the past, though the goal is to make this as transparent as possible.

In Tivoli Storage Manager V6.1 there is a significant increase in real memory utilization. The recommended memory size is approximately four times the current recommended values, for instance, in the past this has been 2 GB per instance on AIX, and now our recommendation is 8 GB per instance. This is not a minimum, nor is it a requirement, it is simply our recommendation for a normal workload,

Another change to keep in mind is growth in the database itself. Not only will the overall size of the database increase, but also DB2 might use additional disk space for temporary work based on your workload. There are two places that we have seen significant growth in the database, one is during the insertion of database entries during the upgrade process and the other during the execution of certain queries.

The database recovery log space requirement also increases for this upgrade. DB2 is managing this log space and you will need space for both an active log and for archive logs. The DB2 database is in what in V5 we would refer to as “roll-forward’ mode.” There is no support for circular logging.

We briefly describe the upgrade process here and then go into it in more detail later in this material. Simply stated, the upgrade process prepares the existing V5 database, extracts its contents, then inserts that extracted data into a newly created DB2 database.

Compared to previous release-to-release upgrades, this is a time consuming process. It is the time that this process takes that is one of the major reasons to carefully plan your upgrade strategy.

The fall-back plan is basically the same as it has been in the past, but perhaps a little more complex because of the addition of the DB2 installation. You will need to reinstall your previous release of Tivoli Storage Manager and restore its database. There are no changes to your existing storage pools, so the normal precautions for protecting previously backed data are sufficient, such as disabling migration and reclamation.

16.5.2 Estimating the upgrade time

The upgrade process creates a new DB2 database, and you have to configure the DB2 space before starting the upgrade. An important question is, how long can your Tivoli Storage Manager server be down? The following factors can affect the upgrade time of a V5 server:

� The size of the database being upgraded� The method chosen for moving the data from the V5 database to the V6 database� The number and speed of system processors� Storage device configuration


Database creationEstimate the extract and insert processes between 5 GB/hr and 10 GB/hr. This rate is currently what has been experienced for the upgrade process, however that assumes a “normal” Tivoli Storage Manager workload. It also assumes a pristine Tivoli Storage Manager database. The number of objects has an impact on insert, however the extract is purely sequential block reads.

This 5 GB/hr to 10 GB/hr rate is based on the amount of space that is actually used by the V5 database, not the allocated space. Your environment might produce different results. Testing upgrade operations in your environment is especially important for Tivoli Storage Manager servers that support essential systems.

Workload typeConsider the type of workload that the server has handled. A workload that consists of large numbers of small files, or files with very long file names, can cause a relatively longer upgrade time. An example of an abnormal configuration might be a Content Manager or many large file servers, which tend to manage more objects per GB, so they might be considerably slower when using GB/hr estimate.

Estimate the upgrade time to help plan for the amount of time that the server will be unavailable. The time that is required to complete the upgrade depends on multiple factors.

The Tivoli Storage Manager V5 server is not available for use while data is being extracted from the database. The network method for the data movement overlaps the extraction time with the insertion time. Using the network method might help reduce the total time required for the upgrade because of the overlap.

Windows Tivoli Storage Manager ServersIf the Tivoli Storage Manager server being upgraded contains multiple NICs, it might be necessary to disable all of them except one in order to use the DB Upgrade Wizards. The NICs can be re-enabled after the DB upgrade has completed.

Shared library configurationsIf you have a shared library configuration, upgrade the server that is the library manager first and follow this by upgrading the library clients. Library clients must be at least level 5.4 or above for compatibility with V6 Tivoli Storage Manager Server.

Here are some upgrade considerations for Library Manager configurations:

� If Library Manager moves to new server:

– Move V5.5 Library Manager to new system.– Update connectivity, paths, and so on.– Validate Library Manager configuration works with existing V5.5 code.– Upgrade Library Manager to new Tivoli Storage Manager in place.

� If Library Manager remains on existing server:

– What else is on that operating system instance?

� If there are Multiple Tivoli Storage Manager instances on single operating systems:– Only one version of Tivoli Storage Manager code can be installed at a time, same as

prior upgrades

Note: If the Tivoli Storage Manager server is V5.5.x or higher, the existing Tivoli Storage Manager server can restart, and if prior to V5.5.x, the DB must be restored if you need to restart the Tivoli Storage Manager server after running the upgrade utility.


� If upgrading in place (either media or network):

– All instances must upgraded at same time

� If upgrading to a new system (either media or network):

– You need to update network address on clients.– You need to update network address on storage agents.

16.5.3 Space requirements

You need to plan for the space requirements for the upgrade process, as well as for the server database and recovery log for the upgraded server. Consider the disk storage currently in use for the server, and whether changes in hardware can be timed to coincide with the upgrade of the server.

Space requirements for the Tivoli Storage Manager V5 server systemSpace is required for storing the backup of the server database, which is an important step in preparing for the upgrade process. If you are using the media method for moving the database, you need space for storing the extracted data.

The backup of the server database requires as much space as is used by your Tivoli Storage Manager V5 database. Store the backup on the form of sequential media that is convenient for you, either tape or disk.

Additional space requirements depend on the method that you choose for moving the data from the Tivoli Storage Manager V5 database:

Media methodYou need media to store the data that will be extracted from the Tivoli Storage Manager V5 database. The media can be tape, or disk space that is defined as a sequential-access disk device class. The space required for the extracted data is the same as the used space in your database. If your database is safely backed up, and you are certain that you no longer need to run the Tivoli Storage Manager V5 server, after you extract the data you can optionally release the space used by the Tivoli Storage Manager V5 database and recovery log.

Network methodYou must have the working copy of the Tivoli Storage Manager V5 database and recovery log on the Tivoli Storage Manager V5 system. If you are working with a copy of the database that was created for testing the upgrade process, you need enough space to hold the total allocated size of the database; you can use the minimum size for a V5 recovery log.

Space requirements for the Tivoli Storage Manager V6 server systemBefore beginning the upgrade process, plan for the space that is required for the database and recovery log. Where you locate the database and recovery log directories is very important to the operation of your server.

You need unique, empty directories for the following items for the upgraded server:

� The database


– Active log– Archive log– Optional: Active log mirror– Optional: Secondary archive log (archive failover log)


� The instance directory for the server:

The instance directory is a directory that will contain files specifically for this server instance (the server options file and other server-specific files). Locate the database and the active log on fast, reliable storage, with high availability characteristics. Ideally, use multiple directories for database space and locate them across as many physical devices or logical unit numbers (LUNs) as there are directories.

Place the database and recovery log directories on separate physical volumes or file systems. To maintain database integrity, ensure that the storage hardware can withstand failures such as power outages and controller failure. You can improve database performance by using hardware that provides a fast, nonvolatile write cache for both the database and logs.

Database space requirementsThe amount of database space that is required depends on the size of the original Tivoli Storage Manager V5 database, and on how much data the server will be managing. Additional information about the sizing of the DB2 database for Tivoli Storage Manager V6.1 can be found in “Estimating total space requirements” on page 260.

The amount of storage space for the database is managed automatically. The database space can be spread across up to 128 directories. After you specify the directories for the database, the server uses the disk space available to those directories as required.

Plan for 33 - 50% more than the space that is used by the Tivoli Storage Manager V5 database. Do not include allocated but unused space for the Tivoli Storage Manager V5 database in the estimate. Some databases can grow temporarily during the upgrade process; consider providing up to 80% more than the space that is used by the V5 database.

DB2 database sizing formulaEstimate the amount of space that the database will require by completing the following steps:






Future growthFor the best efficiency in database operations, anticipate future growth when you set up space for the database. If you underestimate the amount of space that is needed for the database and then must add directories later, the database manager might need to perform more database reorganization, which can consume resources on the system. Estimate requirements for additional database space based on 600 - 1000 bytes per additional object stored in the server. For more information about estimating database space requirements, see the Administrator’s Guide for your specific platform listed in the “Other publications” on page 627.


Visit the product support site for the latest information and recommendations:

http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

Recovery log space requirementsThe amount of recovery log space that is required depends on the amount of client activity with the server. The estimates based on this information should be used as a starting point. After the server is upgraded, monitor the active log and archive log directories to ensure that these directories have enough free space to handle the actual server workload.

For more information about estimating recovery log space requirements, see the Administrator’s Guide for your specific platform listed in the “Other publications” on page 627.

Active logThe default, minimum size of 2 GB is large enough to complete the upgrade process. The maximum size of the active log is 128 GB.

When you begin normal operations with the server after the upgrade, you might need to increase the size of the active log. The required size depends on the amount of concurrent activity that the server handles. A large number of concurrent client sessions might require a larger active log.

For simple backup and archive activity with no data deduplication, 26 GB for the active log is more than adequate. If you use data deduplication, and if you de duplicate very large objects (for example, image backups), use an active log size that is 20% of the database size.

Active log mirrorThe active log mirror is optional. Provide the same amount of space for the active log mirror as for the active log.

Archive logThe size required depends on the number of objects stored by client nodes over the period of time between full backups of the database. Remember that a full backup of the database causes obsolete archive log files to be pruned, to recover space. The archive log files that are included in a backup are automatically pruned after two more full database backups have been completed.

If you perform a full backup of the database every day, the archive log must be large enough to hold the log files for client activity that occurs over two days. Typically 600 - 4000 bytes of log space are used when an object is stored in the server. Therefore, you can estimate a starting size for the archive log using the following calculation:


For example:

5,000,000 objects/day x 3000 bytes/object x 2 days = 30,000,000,000 bytes, or 30 GB

Restriction: You cannot use raw logical volumes for the database. If you want to reuse space on the disk where raw logical volumes were located for an earlier version of the server, you must create file systems on the disk first.



Archive failover log (secondary log)If the archive log becomes full, the failover archive log is used. Specifying a failover archive log is useful only if you locate it on a different physical drive or file system than the archive log.

Specifying a failover directory can prevent problems that occur if the archive log runs out of space. If the drive or file system where the archive log directory is located becomes full and either there is no archive failover log directory or it also is full, the log files that are ready to be moved to the archive log instead remain in the active log directory. If the active log becomes full, the server stops.

The directory for the archive failover log can be a remote directory if local disk space is limited. Using a remote directory might be slower than a local disk or directory, but because the directory is used only if the archive log becomes full, the performance is not as important as for the other logs.

For the latest information and recommendations, go to the support site:


Estimating total space requirementsIn this section we discuss estimating total space requirements for the upgrade process and upgraded server and provide sizing models to help with the space estimation.

In addition to the space required for the upgraded server itself, some additional disk space is needed for the upgrade process. For example, if you are upgrading the server on the same system where it is currently located, you need enough space for two copies of the database during the upgrade process.

The space requirements for the upgraded, Tivoli Storage Manager V6.1 server depend on the size of the Tivoli Storage Manager V5 database and other factors, as discussed in previously in this chapter.

The space requirements for the upgrade process depend on how you move the data from the Tivoli Storage Manager V5 database to the new database. You can move the data to the new database using the media method or the network method, with the following requirements:

� The media method requires sequential media. The sequential media can be tape or sequential disk device class (FILE device type).

� The network method requires a network connection between systems, if you are upgrading on a new system.

Table 16-3 on page 261 shows basic tips for estimating each item, for each of the main scenarios. For details about sizing the Tivoli Storage Manager V6.1 database and recovery log, see “Space requirements for the V6 server system” on page 30.

Table 16-4 on page 262 shows a sample filled-in work sheet for a 100-GB, Tivoli Storage Manager V5 database that has 80% space utilization, with the assumption that the database increases by 33 - 50% when upgraded.

The database size of the Tivoli Storage Manager V6.1 database after the upgrade has completed is different from database to database. If Content Manager is being used, or the database contains many objects that have longer filenames, this space requirement will be larger. It was seen in one case during the beta that for a Content Manager system, the space requirement was twice the original size.



Table 16-3 contains tips for estimating space requirements. Select the scenario, then read down the column.

Table 16-3 Tips for estimating space requirements


Items that require space

Type of space Scenario 1� Same

system as V5 server

� Media method

Scenario 2� Same

system as V5 server

� Network method

Scenario 3� New system � Media

method

Scenario 4� New system � Network

method

V5 database: space allocated for the original database

Disk Space that is allocated for the V5 database

Space that is allocated for the V5 database

0 0

V5 database: final backup copy

Sequential media

Space that is used by the V5 database (based on% utilization)




V5 database: extracted data

Sequential media


0 Space that is used by the V5 database (based on% utilization)

0

V5 recovery log Disk V5 recovery log disk: The amount of space that is allocated for the V5 recovery log

V5 recovery log disk: The amount of space that is allocated for the V5 recovery log

0 0

V6.1 database: estimated size

Disk Disk space that is used by the V5 database plus 33 - 50% more

Disk space that is used by the V5 database plus 33 - 50% more



V6.1 database:first backup

Sequential media

Same as estimated database size




V6.1 active log directory

Disk 2 GB during the upgrade process; a higher value might be needed for normal use

2 GB during the upgrade process; a higher value might be needed for normal use



V6.1 active log mirror (optional)

Disk If used, same size as active log

If used, same size as active log



V6.1 archive log directory

Disk Estimate based on client activity and database backup frequency

Estimate based on client activity and database backup frequency




Table 16-4 shows a sample filled-in work sheet for a 100 GB, V5 database that has 80% space utilization, with the assumption that the database increases by 33 - 50% when upgraded.

Table 16-4 Sample space estimates for a 100 GB V5.5 database

Items that require space

Type of space Scenario 1� Same system

as V5 server� Media

method

Scenario 2� Same system

as V5 server� Network

method

Scenario 3� New system � Media

method

Scenario 4� New system � Network

method

V5 database: space allocated for the original database

Disk 100 GB 100 GB 0 0

V5 database: final backup copy

Sequential media

80 GB 80 GB 80 GB 80 GB

V5 database: extracted data

Sequential media

80 GB 0 80 GB 0

V5 recovery log Disk 12 12 0 0

V6.1 database: estimated size

Disk 106 - 120 GB 106 - 120 GB 106 - 120 GB 106 - 120 GB

V6.1 database:first backup

Sequential media

106 - 120 GB 106 - 120 GB 106 - 120 GB 106 - 120 GB

V6.1 active log directory

Disk 8 GB 8 GB 8 GB 8 GB

V6.1 active log mirror (optional)

Disk (8 GB) (8 GB) (8 GB) (8 GB)

V6.1 archive log directory

Disk 80 GB 80 GB 80 GB 80 GB

Total disk space required during the upgrade process

Disk 307 - 320 GB

(315 - 328 GB)

307 - 320 GB

(315 - 328 GB)

307 - 320 GB

(315 - 328 GB)

307 - 320 GB

(315 - 328 GB)

Total sequential media required during the upgrade process

Sequential media

267 - 280 GB 187 - 200 GB 267 - 280 GB 187 - 200 GB

Total disk space for the V6.1 server after upgrade and cleanup

Disk 195 - 208 GB

(203 - 216 GB)

195 - 208 GB

(203 - 216 GB)

195 - 208 GB

(203 - 216 GB)

195 - 208 GB

(203 - 216 GB)


16.5.4 Work sheet for planning space for the V6.1 server

You can use the work sheet in Table 16-5 to help you plan the amount and location of storage needed for the V6.1 server.

Table 16-5 Work sheet for space planning

16.5.5 High level process for upgrading the server to V6.1

Moving from earlier versions of the server to the V6.1 server requires more preparation and planning than previous upgrades. Because of the database program that the server is using, an existing database must be moved into the new database structure by using the upgrade tools that are provided.

Except for the database extraction and insertion processes, the upgrade process is similar to performing disaster recovery for a server. The server’s critical files (such as the server option file, and device configuration file) must be available, and devices used for storage pools must be made available to the upgraded server.

These are the major steps in the upgrade process:

1. Plan for system hardware and software requirements, and for the upgrade time. This is one area where your testing results will be applied. In addition, use information about the Tivoli Storage Manager upgrade process together with operational requirements for your existing servers to decide how and when to perform the upgrade.

2. Prepare new hardware that the upgraded server will use, or any increased capacity for your existing system to handle the upgrade.

3. Back up the server database and configuration files. Perform other preparation steps.

4. Install the server code. Installation tasks include:

a. Installing the new server code, which includes the server itself plus its database manager program, and configuring a user ID for the new instance

b. Installing the upgrade utilities package on the system where the existing Tivoli Storage Manager server is located

5. Upgrade the database. This task includes preparing the database, and then moving the database. These tasks are performed by using the upgrade utilities or the upgrade wizard.

The upgrade utilities or upgrade wizard extracts data from an existing database and inserts the data into a new Tivoli Storage Manager V6.1 database. Media or the network can be used for the data movement. As a database is moved into the new database

Item Space required Location

The instance directory for the server, which is a directory that contains files specifically for this server instance (the server options file and other server-specific files)

The database

Active log

Archive log

Optional: Log mirror for the active log

Optional: Secondary archive log (failover location for archive log)


structure, the validity of the data is checked against constraints that are enforced in the new database. The upgrade tools automatically correct some errors in the database. Other errors might need to be corrected manually.

If you are using the wizard, you are guided to perform the upgrade steps in the correct order. If you are performing the upgrade manually using utilities from a command line, follow the procedure carefully.

6. Verify the upgrade by performing basic operations and querying information about the system to confirm that all information transferred correctly. Review the information that compares the methods for performing the upgrade, and the descriptions of the upgrade scenarios, to help you decide how to perform the upgrade process for your servers.

16.6 Naming best practices

Coordinating the names for the various items associated with a server instance can make your life easier.

Instance user IDThe instance user ID is used as the basis for other names related to the server instance. The instance user ID is also called the instance owner.

� For example: tsminst1

The instance user ID is the user ID that must have ownership or read/write access authority to all directories that you create for the database, the recovery log, and storage pools that are FILE device type.

Tivoli Storage Manager database instance name The database instance name is the name of the server instance as it appears in the registry. The default server instance names have the form, Serverx.


Database instance directory The instance directory can have any name that you want. For easier identification, use a name that ties the directory to the instance name. You can use a name that includes the name of the instance as it appears (or will appear) in the registry:

� For example: c:\tsminst1

Database nameThe database name is always TSMDB1, for every server instance. This name cannot be changed.

Server name The server name is an internal name for Tivoli Storage Manager, and is used for operations that involve communication among multiple Tivoli Storage Manager servers. Examples include server-to-server communication and library sharing. The server name is also used when you add the server to the Administration Center so that it can be managed using that interface. Use a unique name for each server. For easy identification in the Administration Center (or from a QUERY SERVER command), use a name that reflects the location or purpose of the server.



If you use the instance configuration wizard, the default name that is suggested is the host name of the system that you are using. You can use a different name that is meaningful in your environment.

If you have more than one server on the system and you use the instance configuration wizard, you can use the default name for only one of the servers. You must enter a unique name for each server. For example:

� Liam_SERVER1� Leon_SERVER2

Directories for database space and recovery log The directories for database and recovery log space can be named according to local practices. For easier identification, consider using names that tie the directories to the server instance.

� e:\tsminst1\dbdir001 - dbdir database directories� f:\tsminst1\dbdir002 - dbdir database directories� g:\tsminst1\dbdir003 - dbdir database directories� h:\tsminst1\dbdir004 - dbdir database directories� i:\tsminst1\actlog - activelog directories� j:\tsminst1\actlogm - activelogmirror directories� k:\tsminst1\archlog - archivelog directories� l:\tsminst1\archlogf - archivefailover log directories

16.7 Performance

For best performance, use multiple LUNs that map to multiple independent disks, or that map to RAID arrays with a large stripe size (for example, 128 KB). Use a different file system on each LUN. Table 16-6 shows an example of LUN usage.

Table 16-6 Use of separate disks for database and logs

If the disk storage is supplied by a virtualization device (high-end storage controller, or a SAN virtualization device), ensure that none of the virtual LUNs are on the same physical disk drive. Ensure that the directories in use are on different physical disk drives within the virtualization device.

# of LUNs Usage Mount point

4-128 Database <instance>/dbdir001 and higher

1 Active log <instance>/activelog

1 Archive log <instance>/archivelog

1 Active log mirror <instance>/activelogm

1 Archive log failover <instance>/archivelogf


16.8 Upgrading an existing system versus a new system

Upgrading the Tivoli Storage ManagerV6.1 server on an existing system requires that the system be unavailable for production use during installation and when the data is moved into the new database. Moving the server to a new system when upgrading to the V6.1 server gives you more flexibility in how to perform the upgrade, but with some additional costs.

Table 16-7 lists items to consider when deciding how to perform the upgrade for a server.

Table 16-7 .Server upgrade verses new build considerations

Item Upgrade on an existing system

Upgrade on a new system

System hardware Additional resources (disk space, memory, and possibly processor capacity) are required on the existing system.

A new system that meets requirements, in addition to the existing system, is required.You must upgrade to a new system if the existing server is on one of the platforms that are not supported for V6.1.

Software Software on the system must meet requirements for V6.1. The V6.1 server cannot coexist with other versions on the same system.

Software on the new system must meet requirements for V6.1.Software on the original V5 system must meet requirements for the upgrade utilities (upgrade utilities requirements are the same as for a V5.5 server).

V5 server availability All V5 server instances on the system are unavailable after the V6.1 server program is installed. Data managed by a server instance cannot be accessed until the upgrade process is complete for that server instance.To revert to using the V5 server, you must reinstall the same level of the V5 server program as before, and restore the V5 database from a backup that was made before the upgrade process.

You can stage the upgrade of multiple servers, because the V5 server program can be left on the original system.A V5.5 server on the original system can be restarted after the database extract completes. A V5.3 or V5.4 server on the original system can be restarted, but its database must be restored first (using the database backup that was made before the upgrade process).

Database movement method

The database can be moved with a local-host network connection, or can be moved by using disk or external media.

You must have either a network connection between the existing and the new systems, or a device and media available to store the extracted database.


16.8.1 Comparison of methods for moving data to the V6.1 database

The upgrade utilities are required for moving data from an earlier version of the database into the Tivoli Storage Manager V6.1 database. You can use the upgrade wizard to run the utilities with guidance.

To move the database, you must install the upgrade utilities package on the system where the original server database is located. The utilities package is available from the FTP downloads site for the Tivoli Storage Manager product. Installing the upgrade utilities package is a separate task from installing the Tivoli Storage Manager V6.1 server.

You can move the database in one of two ways: the media method, or the network method.

Media methodYou can extract data from the original database to media, and later load the data into the new database. The new database can be located either on the same system or a different system.

Storage devices and storage pools

Existing attached devices can be used.You must change ownership or permissions for all disk space that is used for storage pools (device types of FILE or DISK). The user ID that you will create to be the owner of the upgraded server instance must be given ownership or read/write permission to the disk space for storage pools.

The new system must have access to all storage that is used by the original system.Definitions for devices such as FILE device types might need to be changed after the upgrade.You must change ownership or permissions for all disk space that is used for storage pools (device types of FILE or DISK). The user ID that you will create to be the owner of the upgraded server instance must be given ownership or read/write permission to the disk space for storage pools.

Client and storage agent connections

No changes are necessary. The network address on clients and storage agents must be updated after the upgrade, or network changes made so that the new system has the same address as the original system.

Item Upgrade on an existing system

Upgrade on a new system


Upgrading to an existing system (in place) using external mediaThis is a good method to choose if you are not upgrading to a new system, however you must review the new hardware requirements. In this particular option, you might have both the Tivoli Storage Manager V5 and Tivoli Storage Manager V6.1 server to use the same disk storage space. This is depicted in Figure 16-1.

Figure 16-1 Upgrading to an existing system using external media

Upgrading to a new system using existing mediaThe media method can be a good method to choose if you are upgrading to a new physical system for the server, and you cannot have both your old and new systems available at the same time or cannot connect them with a high speed network. This is shown in Figure 16-2.

Figure 16-2 Upgrading to a new system using external media


Exporting and importing using external mediaAs part of your upgrade and consolidation planning, you can choose to perform an upgrade, then a staged migration from the Tivoli Storage Manager V5 to Tivoli Storage Manager V6 server using the export/import functionality. This can be accomplished using external media as shown in Figure 16-3.

Figure 16-3 Export and import used for a staged Tivoli Storage Manager V5 to V6 node migration

Network methodThe network method reduces the amount of storage that is required because there are no requirements for disk or tapes to hold the data unloaded from the Tivoli Storage Manager V5 database. With either method, the original server cannot be running in production mode while the data is being extracted.


Upgrading to an existing system (in place) using the networkYou can simultaneously extract data from the original database and load the data into the new database. In this scenario, the new database can be located on the same system and connected using the network. See Figure 16-4.

Figure 16-4 Upgrading an existing system (in-place) using the network

Upgrading to a new system using the networkThe network method is a good method to choose if you are looking for maximum performance from the upgrade utility, particularly if you are migrating from one physical system to a new system, and the systems are connected by a high speed network. This is shown in Figure 16-5.

Figure 16-5 Upgrading to a new system using a network connection


Exporting and importing using external mediaAs part of your upgrade and consolidation planning, you can choose to perform an upgrade, then a stagged migration from the Tivoli Storage Manager V5 to Tivoli Storage Manager V6 server using the export/import functionality. This can be accomplished using the network as shown in Figure 16-6.

Figure 16-6 Export and importing using server to server communication for a staged migration

16.8.2 Details of the database upgrade process

In this section we summarize the database upgrade process for the two main components. We then provide details about the utilities and commands that are used in the process. Finally, we provide a high level review of the steps to perform a new install or upgrade.

Procedure for processing source Tivoli Storage Manager V5.x database� This procedure involves the following utilities:

– DSMUPGRD standalone utility– Based on 5.5 server code

� The main commands of the upgrade process are:

– PREPAREDB– QUERYDB– EXTRACTDB

� The secondary commands of the upgrade process are:

– UPDATE– EXTEND– LOG/DB

Procedure for processing target Tivoli Storage Manager V6.1 database� The following standalone server commands are used:

– DSMSERV– LOADFORMAT– INSERTDB


DSMUPGRD standalone utilityThe upgrade utilities prepare and extract data from a version 5.3, 5.4, or 5.5 server database for insertion into an empty Tivoli Storage Manager V6.1 server database. The DSMUPGRD utilities are run on the original database; this utility upgrades a server database version to V5.5, and performs some cleanup to prepare for the extraction process.

The DSMUPGRD utility has the same code as the V5.5.2 server. The difference is that its function is limited to upgrade related tasks; as such, it cannot be used to run a normal server. However, it is the same code as the server, and the decision to function as upgrade utility or server is based on the name.

DSMUPGRD* will operate as the upgrade:

� It is available on all platforms supported by V5.5 (but not V5.3 or V5.4).� It uses different install locations and package names than the V5 or V6.1 server.

The following major upgrade tasks are discussed in further detail in this chapter:

� PREPAREDB� EXTRACTDB� QUERYDB� Emergency LOG and DB extension� UPDATE (for Windows Registry maintenance)

PREPAREDBThe PREPAREDB command prepares a V5.x database for upgrade to V6.1, and is the required second step in the upgrade process. The first step is to back up the database in case you need to roll back the database to a state after the utility upgrade (for example, the V5.4 database to V5.5.2). This will upgrade the database version to V5.5 as a dsmserv upgradedb.

This checks for some known database problems such as moving from asterisk to ASCI - USS file space conversion status. The tool stops if it detects any USS file spaces that are not converted. Currently it does not run any database repair utilities, but that might change.

When the database problem check is finished, it backs up device configuration information to configured devconfig files and backs up the server instance’s registry entries on Windows.

EXTRACTDB overviewThe EXTRACTDB command extracts data from the V5.5 database, using sequential block reads. It is the base V5 piece of the upgrade utility, by extracting out the V5 database objects, for further use by the insertdb tool.

You can use the utility either to simultaneously extract and insert the data into a new database over a network, or to extract the data to media for later insertion into a new database. The data extraction operation can be run with multiple processes.

EXTRACTDB (media)The EXTRACTDB command extracts data from the V5.5 database and writes extracted data to sequential media.

Note: Tivoli Storage Manager V6.1 does not support the presence of NAS Backups with TOCs and the presence of Backup Sets. This will be fixed in V6.1.2.


Required PARMs� DEVclass=device class name (this must be an already defined deviceclass)� MANifest=filename (we record here information needed parameters as deviceclass name

and list the volumes to which we wrote)

Optional PARMs� VOLumenames=volume list� SCRatch=Yes|No

Saves volume list, devclass name in manifest file, and uses devclass definition from database, not devconfig file.

EXTRACTDB (network)This utility sends extracted data over network session, which uses server-to-server communications and treats target server as a V6.1 version of itself. This utility is specific to V6.1 upgrade, and skips tables which are not pertinent for V6.1 upgrade due to some redundant tables in the V5 database. This utility also manipulates data to ease inserts into the V6.1 database and thus positioning the data for the insertion process. This command requires minimal authorization with hard coded source and target server names:

$UPGRADESOURCE$, $UPGRADETARGET$

The server name/password is not required to be set.

Required PARMs� HLAddress=ipaddress (can be “localhost”)� LLAddress=portnumber

The target must be listening at specified address and port.

EXTRACTDB (general)General PARMs� EVentbasedused=Yes|Never� Was event based archive retention ever used?� YES results in extraction of extra expiration info from db� Never say NEVER if there is any doubt� Has no effect on new V5.3.6, V5.4.2, V5.5.0 servers or if “REPAIR EXPIRATION *

TYPE=ARCHIVE EVENTBASEUSED=FIX FIX=YES” was run.� Undocumented PARMs� MAXStream=n (currently disabled, default=1)� MAXPRocess=n (n from 1 to 20, default=4

EXTEND DB I LOGEmergency database and log extension, which behaves the same as DSMSERV EXTEND DB/LOG in V5.5 server code. This is used when PREPAREDB database upgrade runs out of database or log and will extend database or log even if database version is lower than V5.5.

UPDATEThis utility recreates “backup” copies of registry entries; it is required if upgrading to same system and V6 instance directories are different than V5 instance directories, and the V6 LOADFORMAT run before PREPAREDB. This utility is run from the V5.x instance directory.

Syntax� DSMUPGRD [-k key_name] UPDATE


16.8.3 Tivoli Storage Manager V6.1 upgrade utilities

In this section we discuss the Tivoli Storage Manager V6.1 pieces of the upgrade, with standalone commands within Tivoli Storage Manager V6.1 DSMSERV:

DSMSERV LOADFORMATDSMSERV INSERTDB

LOADFORMATThis utility formats a new Tivoli Storage Manager V6.1 database for the upgrade’s use, and uses the identical syntax and usage as DSMSERV FORMAT. This utility creates database and logs, defines tables, and does not insert any default values into the V6.1 database.

INSERTDBThis utility reads data from media or from the network session. It inserts this data into a V6.1 database, and has an explicit knowledge of Tivoli Storage Manager V5.5 database schema. The utility maps data from V5.5 schema to V6.1 schema, while validating the data before inserting it into the database. In some situations, the insertdb will correct data before inserting it and logs invalid rows that cannot be corrected.

INSERTDB (media)This utility reads extracted data from sequential media. This utility will read a volume list, devclass name from a manifest, and uses devclass definition from devconfig file. This utility requires a DEVCONFIG option to be specified in dsmserv.opt and requires a copy of devconfig file from source server.

Required PARMs� MANifest=filename

Optional PARMs� DEVclass=device class name

INSERTDB (network)This utility reads extracted data from the network session, which is sequential in nature. This also initializes the server and then waits for a connection.

Required PARMsNone

Optional PARMs� SESSWait=n (#minutes to wait, default=60)� ANR1336I INSERTDB: Ready for connections from the source server

INSERTDB (general)This utility validates database schema before inserting data into DB and performs all INSERTDB actions except insert into DB. This utility runs almost as fast as EXTRACTDB. It can provide data, checks data for errors, and provides insight on the amount of data transferred. The new parameter is targeted for V6.1.2.

Other PARMsPREVIEW=Yes|No


16.9 Upgrade scenarios

You can upgrade the server on the same system or a new system, and use either a media method or a network method to move data from the original server database to the upgraded server database. Descriptions of the scenarios illustrate the order of steps for the different approaches.

Select the scenario that you are interested in from Table 16-8. The scenarios are presented in overview form in this section, to summarize the steps that are performed in each case. In the following sections, we provide the detailed procedures for each scenario.

Table 16-8 Server upgrade scenarios

Note: DSMSERV INSERTDB repeatedly issues the status message ANR1525I with no sign that any progress is being made. For example:

ANR1524I INSERTDB: Beginning database update phase.

ANR1525I INSERTDB: Updated 0 of 25,185,883 database entries in 0:23:10.

ANR1525I INSERTDB: Updated 0 of 25,185,883 database entries in 0:53:13.

In the database update phase, DSMSERV INSERTDB merges information from two source tables into a single target table. The merge is performed as a single, long running DB2 UPDATE operation. The UPDATE operation does not provide status until it completes, which is why the ANR1525I message repeatedly shows 0 entries updated for such an extended period of time.

INSERTDB merges multiple sets of tables during the database update phase. After each set of tables is merged, the ANR1525I message will change to reflect the progress up to that point. However, each set of tables can take a considerable amount of time to merge, during which the status will remain the same. This should not be a cause for alarm; rather an indication that INSERTDB is still alive and continuing to function.

When INSERTDB enters the database update phase, most of the remaining work will be done by DB2. Unfortunately, only indirect methods are available to tell if it is making progress. One such method is to use a system monitor such as topas on AIX to confirm that the DB2 db2sysc process is operating. Consuming CPU cycles and performing I/O to the database volumes are both good indications that the update phase is progressing.

Scenario Location of upgraded serverMethod for moving data

Scenario 1 - for upgrading the server: new system, media method

New system Media method

Scenario 2 - for upgrading the server: new system, network method”

New system Network method

Scenario 3 - for upgrading the server: same system, media method

Same system as original server Media method

Scenario 4 - for upgrading the server: same system, network method

Same system Network method


16.9.1 Scenario 1: New system, media method

In this scenario, some upgrade tasks are performed on the original system and some on the new system. The database is extracted to media and later inserted into the V6.1 database.

You can use the wizard, or perform the upgrade by manually using the utilities. The wizard offers a guided approach to the upgrade of a server. By using the wizard, you can avoid some configuration steps that are complex when done manually.

16.9.2 Upgrading the server using the wizard

This is a high overview of a Tivoli Storage Manager V6.1 upgrade on a new system using the media method wizard (see Figure 16-7).

Figure 16-7 Upgrade to 6.1 on a new system using media wizard


The following steps are a summary of the procedure for this scenario:

1. Perform all preparation tasks on the original system. Preparation includes performing a database backup.

2. Install the DSMUPGRD utilities package on the original system. The utilities package must be installed whether you are using the upgrade wizard or performing the upgrade manually with utilities.

3. Install the Tivoli Storage Manager V6.1 server code on the new system.

4. Create the directories for the Tivoli Storage Manager V6.1 database and logs, and the user ID that will own the server instance.

5. Start the upgrade wizard to configure the new server and upgrade the Tivoli Storage Manager V5 database. With the wizard, you complete the following tasks:

a. On the original system, prepare the V5 database.

b. On the original system, extract the V5 database to external media.

c. On the new system, create and format an empty database to receive the data.

d. On the new system, insert the data from the media to which it was extracted.

e. Configure the new system for database backup.

6. Complete the post-installation tasks, including backing up the database and verifying the database contents.

16.9.3 Scenario 2: New system, network method

In this scenario, some upgrade tasks are performed on the original system and some on the new system. The data is extracted from the original server database and sent over the network connection to be inserted into the new server database.

You can use the wizard, or perform the upgrade by manually using the utilities. The wizard offers a guided approach to the upgrade of a server. We strongly recommend using the wizard; you can avoid some configuration steps that are complex when done manually.


16.9.4 Upgrading using the wizard

Here we provide an overview of the process to upgrade to Tivoli Storage Manager V6.1 on a new system using the network method wizard (see Figure 16-8).

Figure 16-8 Upgrade to V6.1 on a new system using the network wizard method

16.9.5 Scenario 3: Same system, media method

In this scenario, all upgrade tasks are performed on the same system. The database is extracted to media and later inserted into the Tivoli Storage Manager V6.1 database.



16.9.6 Summary of the wizard method scenario

Figure 16-9 shows a high overview of a Tivoli Storage Manager V6.1 upgrade on a same system using the media method wizard.

Figure 16-9 Upgrade to 6.1 on a same system using the media wizard method



1. Perform all preparation tasks, which includes performing a database backup.

2. Install the upgrade utilities package (DSMUPGRD) on the system. The utilities package must be installed whether you are using the upgrade wizard or performing the upgrade with utilities.

3. Prepare the Tivoli Storage Manager V5 database using the DSMUPGRD PREPAREDB utility.

4. Uninstall the Tivoli Storage Manager V5 server code.

5. Install the Tivoli Storage Manager V6.1 server code on the system.



a. Extract the V5 database to external media.

b. Create and format an empty database to receive the data.

c. Insert the data from the media to which it was extracted.

d. Configure the system for database backup.


16.9.7 Scenario 4: Same system, network method

In this scenario, all upgrade tasks are performed on the same system. The data is extracted from the original server database and inserted into the new server database at the same time.



16.9.8 Upgrading the server using the wizard

This is a high overview of a 6.1 upgrade on a same system using the network wizard method, as shown in Figure 16-10.

Figure 16-10 Upgrade on same system using media method



1. Perform all preparation tasks, which includes performing a database backup.

2. Install the upgrade utilities package (DSMUPGRD) on the system. The utilities package must be installed whether you are using the upgrade wizard or performing the upgrade with utilities.

3. Prepare the Tivoli Storage Manager V5 database using the DSMUPGRD PREPAREDB utility.

4. Uninstall the Tivoli Storage Manager V5 server code.

5. Install the Tivoli Storage Manager V6.1 server code on the system.



a. Create and format an empty database to receive the data.

b. Move the data from the Tivoli Storage Manager V5 database to the Tivoli Storage Manager V6.1 database.

c. Configure the system for database backup.


16.9.9 Hybrid upgrade migration method

This section describes a method for decreasing server downtime when migrating the database during an upgrade of a production Tivoli Storage Manager server from V5.x to V6. It is called a hybrid upgrade-migration method because it uses a combination of export and import operations, along with the standard V6 upgrade methods.

Hybrid method considerationsThe hybrid upgrade-migration method is subject to the planning considerations and restrictions identified in the following topics. This information is meant to supplement and be used with the Tivoli Storage Manager V6 Upgrade Guide, SC23-9554.

Attention: The hybrid upgrade-migration method has not been tested by IBM. The method involves the management of export data and timing-specific considerations that, if not understood and carefully planned, might result in the loss of data. Specifically, data might not be populated or transferred to the V6 target server.

Restrictions:

� IBM System Storage Archive Manager (also known as Tivoli Storage Manager for Data Retention) users do not use this method. Tivoli Storage Manager servers with retention protection enabled do not allow import operations. Therefore, the method described in this publication cannot be used with System Storage Archive Manager or Tivoli Storage Manager for Data Retention servers.

� Tivoli Storage Manager V5.x users with data residing on CENTERA devices must not use this method. Importing data from a CENTERA device class is not supported. However, files being imported can be stored on a CENTERA storage device.


The methods and restrictions in this section are meant to give Tivoli Storage Manager V5.x users ideas and suggestions in developing their upgrade plans. It is assumed that the user is proficient with Tivoli Storage Manager administration and can develop the upgrade plan customized for their environment and individual Tivoli Storage Manager servers. Administrators must also review and be familiar with the upgrade processes and methodologies as documented by the Tivoli Storage Manager V6 publications. Administrators must be knowledgeable about the server EXPORT and IMPORT functions, including timing implications, and how EXPORT can be affected by data being backed up or archived while the export operation is being performed.

Hybrid method introductionAll the upgrade methods described in the Tivoli Storage Manager V6 Upgrade Guide, SC23-9554 include migrating the V5.x database to a V6 server and terminating the operation of the V5.x server after the database data is extracted. Specifically, after the EXTRACT step of the UPGRADE process, the Tivoli Storage Manager V5.x server is stopped and is no longer in production or operation. And after the production database is migrated to the V6 server, all the V5.x server storage pools are made accessible to the V6 server. That server can then be put into production operation.

The Upgrade Guide methods (called standard methods in this document) work well. The methods are safe, for example, there is no inherent risk of loss of data or database objects being orphaned. However, the time to migrate a database from V5.x to V6 might require a production Tivoli Storage Manager server to be down for many hours or days. The length of downtime depends on a number of factors, including:

� The size of the database � The performance of the disk system containing the old and new database

You might be able to shorten the server downtime of the standard methods, using this hybrid upgrade-migration method.

Planning the upgradeYou must build your own detailed plan. The plan must take into account the considerations and restrictions that follow, and the availability of resources in your environment (such as the SAN infrastructure).

Before deciding to use the hybrid upgrade-migration method, estimate the time it takes to migrate the data using one of the standard methods versus the time to migrate using a hybrid upgrade-migration method. The time to extract and insert data from a database is dependent on the performance of the storage system on which the old and new databases reside. It is possible that the standard method applicable to your situation might complete in less time than the hybrid upgrade-migration method.

You can estimate the times of the different methods in these ways:

� Measure the time that it takes to extract the database (during a time when it is acceptable for the server to be down), and then insert the data into a test V6 server.

� Measure the time to export a sample of node data, and then import the data to the test V6 server.

Here is another method for estimating how long the upgrade process can take:

1. Restore a copy of the database to a test system.

2. Complete the upgrade process in the test environment using the restored copy of the production server.


Your estimate of the time to migrate, using the Hybrid Upgrade method, is a function of the exact steps of your plan.

For purposes of this testing, the storage devices (hierarchy) are not needed. However, differences in hardware (processor, I/O performance to disk, and so on) might affect the time measured for the upgrade process in the test environment. Use the same or equivalent hardware to achieve results that most accurately represent what can be achieved for your production Tivoli Storage Manager server upgrade.

RestrictionsTo employ the hybrid upgrade-migration method, your operational situation for particular Tivoli Storage Manager server instances must accommodate the following restrictions.

This method can only be used with the Upgrade Guide Scenarios 3 and 4, for example, upgrading the V5.x server to V6 on a new system using either the media or the network method.

Operational restrictionsThe following set of restrictions consists of restrictions on, or changes to, the operation of your Tivoli Storage Manager server during the duration of the migration when using this method. Also, we will refer to this set of restrictions in the following discussions:

� You should disable data migration between storage pools to keep the object pointers in the V6 server database synchronized with the actual location of the objects. You can disable migration for all storage pools by using the undocumented server option NOMIGRRECL. Enable the NOMIGRRECL option by adding it to the server options file. The advantage of using NOMIGRRECL is that it turns off all migration and reclamation all at once, instead of having to issue commands to disable migration and reclamation for the various storage pools. The disadvantage is that there is no documentation for additional information.

If you want to use a documented method instead, disable migration by setting the migration threshold to 100% on all primary storage pools with the following command:

update stgpool <stgpools-name> HIGHMIG=100

� Disable reclamation for all storage pools using tape device classes and FILE type device class to prevent orphaned objects in the V6 server database. As with migration, you can disable reclamation by using the NOMIGRRECL server option.

If you want to use a documented method instead, reclamation can be disabled with the command:

update stgpool <stgpools-name> REClaim=100

� Disable database expiration processing from the point in time that data is extracted from the V5.x server database until the V6 server is put into production. The reason for this restriction is that the V6 database, built from the insert process, still has references to client objects in storage pools of device class DISK. Expiration processing on the V5.x server after the extraction would allow the V5.x server to reuse the space on DISK storage pools. The V6 server would then have orphan objects in the database. If you use the EXPINTERVAL server option to automatically expire data, set the option to EXPINTERVAL 0. Alternatively, if you use scheduled administrative commands to expire data, disable or delete that schedule. If you use an external automation or scheduling tool to expire data, identify and stop that tool.

Important: If you are unable to accommodate these restrictions, do not use this method because it can cause problems, including possible loss of data.


� Do not move data between storage pools with the move data or move nodedata commands, either manually or automatically as part of scripts or administrative schedules. This restriction is necessary to prevent orphaned objects in the V6 server database.

� Either disable backup storage pool operations, or audit the volumes used for storage pool backups on the V6 server after it goes into production. Be aware that the storage-pool backup volumes created after the extractdb operation will not be usable after the V6 server is put into production.

– Suspend using active data pools, that were created with the COPY ACTIVEDATA command. Changes to active data pools during the interim period can cause the V6 server database to be out of synchronization with the actual storage pools.

– Do not make changes to policies or existing administrator ID definitions, or register any new administrator IDs on the V5.x server.

Hybrid method variationsThe hybrid upgrade-migration method is a supplement to the methods described in the Tivoli Storage Manager V6 Upgrade Guide, SC23-9554, rather than a replacement. There are three variations of this method:

1. Single export and import operation at time of production cut over to V6 server.

2. Multiple exports and one import (of multiple exports in one operation) at time of cut over.

3. Multiple exports and multiple imports before and at time of cut over.

Variations 2 and 3 might shorten the length of time that your Tivoli Storage Manager server is out of production compared to variation 1, but the implementation of 2 or 3 is more complex.

To track or distinguish tape volumes used for the export process, consider defining a new device class to be used with the EXPORT command.

Variation 1Follow the upgrade steps documented in Tivoli Storage Manager V6 Upgrade Guide, SC23-9554, “Scenario 3: Upgrading the server manually using utilities or Scenario 4 for upgrading the server: New system, network method” - up to and including extracting the database, with the extractdb command. However, instead of stopping the Tivoli Storage Manager V5.x server operation after the database data is extracted, that server is put back into operation.

If you used the NOMIGRRECL option to disable migration and reclamation, set that option in the V6 server options file as well.

In parallel with the continued operation of the V5.x server, the remaining steps of upgrading the server manually using utilities are performed. When the database backup is complete, the V6 server is almost ready to be put into operation.

Tip: Tivoli Storage Manager V6 has a number of changes and enhancements to the expiration process, including new command parameters. Evaluate these new capabilities for use in the production V6 server environment after the upgrade is completed.

Requirement: You must implement all the operational restrictions in “Operational restrictions” on page 284 before putting the V5.x server back into operation. Migration and reclamation must remain disabled on the V6 server.


However, there might now be client data that was stored into the V5.x server while the insertdb process was completing on the V6 server. This new data must be migrated. This is accomplished by exporting the new client (that is: node) data. The data must be exported to a media that can be used on the V6 server. Example 16-1 shows an export node command.

Example 16-1 export node command

export node * filedata=all fromdate=< extract_date> fromtime=<extract_time>

The data exported from the V5.x server is imported into the V6 server using the import node command in Example 16-2.

Example 16-2 import node command

import node * filedata=all mergefilespaces=yes

Now the V6 server can be put into operation.

Variation 2The basic improvement with Variations 2 and 3 over Variation 1 is to decrease the time for export and import during server cut over.

In Variation 1, the production Tivoli Storage Manager server is down during the extractdb process. The server is also down during the server cut over, which occurs after the insertdb is completed. The cut over period includes time to:

1. Export all the new node data from the V5.x server.

2. Switch the attachment of the storage pool devices.

3. Import all the new node data to the V6 server.

The length of time to export data from the V5.x server and import the data to the V6 server might be significant and undesirably long. This variation describes ways to decrease downtime resulting from export and import, but the overall downtime might not be better than variation 1. You must determine which variation is best for your environment.

In this variation, you perform multiple exports and one import - that is, import of multiple exports in one operation - at time of cut over. These multiple exports are incremental node data exports. This way, during the cut over period, a smaller amount of node data must be exported, which will be the last remaining node data ingested since the last incremental export:

1. Generate the incremental exports at regular intervals, for example, 4 or 8 hours, using the EXPORT command fromdate and fromtime, and todate and totime parameters. The parameters must be carefully specified so that the export increments are contiguous and not overlapping.

2. When you are ready to put the V6 server into production, export the final node data.

3. Shut down the V5.x server.

4. Connect the storage devices (containing all the storage pools) to the V6 server, and start the V6 server.

5. Import all the incremental exports.

Note: If data shredding is in use with storage pools from which node data is to be exported, you will need to use the additional allowshreddable=yes parameter.


Variation 3This final variation requires an excellent working knowledge of Tivoli Storage Manager and detailed planning.

The amount of time to perform the import operation (done at the point of production cut-over to the V6 server) might be decreased further by having to import only the last incremental export. However, this means that the other incremental exports must be imported while the V5.x server is still in operation.

Here is an example scenario:

� You have determined that the INSERTDB phase of processing will take 20 hours. During that time, the V5.x server is left in production, and every 4 hours, an EXPORT is performed.

� After the V6 server completes the INSERTDB processing, the V5.x server is still operational. During this time, the incremental exports taken from the V5.x server are imported on the V6 server.

� During this overlap period, client access to the V6 server must be disabled. Also, client schedules must be disabled on the V6 server when it is running, including when the import operations are performed. The reason is that you do not want the V6 server to start scheduled client operations in parallel with what is being done by the V5.x server, which is still in production.

� After all but the most recent EXPORT from the V5.x server have been imported to the V6 server, stop the V5.x server and import the final node data export. In this way, the effective server down-time is the time needed to perform the FINAL incremental import on the V6 server.

This approach requires:

1. Making all the original volumes of the destination storage pools unavailable.

2. Defining new volumes to the destination primary-storage pools on the V6 server (which is operational but not in production) on storage devices that must be available to the V6 server before the V5.x server storage devices are re-cabled to the V6 server.

The data imported earlier goes to these new volumes. After the V6 server is put into production, the client data on these volumes can be moved to the original storage-pool volumes. When the data move is complete, those volumes can be deleted.

If you choose to take this approach, disable normal server operations and availability on the V6 server when it is started. Taking these steps minimizes operational difficulties and error messages when you use the V6 server before it is put into production, when performing the early imports. The disabling of normal server operations can be done immediately after starting the V6 server. However, it is easier and decreases risk of unwanted activities if you disable the server operations before the V6 server is started. This can be accomplished by disabling the functions on the V5.x server before the database extraction is performed.


As indicated in “Operational restrictions” on page 284, some of these operations should remain disabled on the V5.x server even after the extractdb operation is performed. Table 16-9 gives a list of the server operations to consider disabling, and the commands or options to accomplish that.

Table 16-9 Server operations to consider disabling

16.10 Testing

Tivoli Storage Manager V6.1 has many new features, which have contributed to the need for additional planning and testing. Some of the most significant feature changes include:

� Deduplication� Disk structure for DB2, active logs and archive logs, storage pool volumes� Disaster recovery using the Disaster Recovery Manager feature� Reporting and monitoring

There are many additional changes to Tivoli Storage Manager V6.1, as described in Chapter 4, “Commands, utilities, and option changes” on page 31.

In addition, there are many methods of upgrading and moving data during the upgrade. Therefore, understanding all of your options and the cost of each is important (monetary and downtime costs might vary based on each scenario).

16.10.1 Testing the upgrade process for a server

Depending on the size and complexity of your environment, it might be necessary to test the upgrade to ensure a smooth upgrade process. Testing can help you plan for the amount of time that the server will be unavailable because of the upgrade, and to validate all processes such as DRM, reporting and monitoring have been tested and documented prior to the production implementation.

Server operation Command or option to disable the operation

Retain disablement on V5.x server

Database expiration Server option: expinterval=0

Yes

Storage pool reclamation (set for all storage pools)

Storage pool parameter: reclaim=100 (Not required if the NOMIGRRECL option is used.)

Yes

Storage pool migration Storage pool parameter: highmig=100 (Not required if the NOMIGRRECL option is used.)

Yes

Storage pool volume accessibility (make the old volume unavailable on the V6 server)

Volume parameter: access=unavailable

No

Client access to the V6 server (disable on the V6 server)

Server command: disable sessions client

No

Client and administrative schedules on the V6 server (disable on the V6 server)

Server option: disablescheds=yes

No


The original V5.x server and the new V6.1 server cannot co-exist on a system at the same time. To evaluate and test the V6.1 server, you must install Tivoli Storage Manager V6.1 on a new system.

To test with a copy of production data, or to test the upgrade process, you can use the upgrade utilities to create a test server. Follow the normal upgrade procedure, with these additional considerations:

� To avoid affecting your original production server, you must install the V6.1 server on a different system. Different versions of the server cannot be run on a system at the same time. In addition:

– You will need to provide a scaled down copy of your V5.x server in the test scenario.

– Ensure that the storage devices for your production server are not available to the test server. If the test server can detect the devices that your production server uses, it might start operations such as issuing resets on tape drives or unloading tapes.

� If you prefer not to add the second test server, then you must upgrade your current production server to at least V5.5.2. Then the DSMUPGRD utility can complete the upgrade to your test V6.1 server, and leave your production server untouched.

� Always back up your Tivoli Storage Manager database prior to any upgrade activity.

� If you do not want to upgrade your production server, nor add a test V5 server, then consider using an extractdb of the production database to the test server using either media or the network. The advantage of extracting the database to media is that you can repeatedly load the test database without stopping your production server each time.

For example, if your tape drives are connected in a storage area network (SAN), you might need to change the zones in your SAN to prevent the test server from detecting the devices.

For testing, you can use one of the following methods to use a backup copy of the database. The methods are given in outline form. See the detailed procedures for instructions for each step.

16.10.2 Test by extracting data from a separate copy of the server

Either the media method or the network method can be used to move the database. Follow these steps:

1. Prepare a test system. This is a different system than the production server, where you must install a separate copy of the V5.3, V5.4, or V5.5 server (the same version as your production server).

2. Back up the database of the production server.

3. Restore the database backup on the test system.

Tip: If upgrading using media, ensure that the device class is valid on the test system. For example, if you will be using a FILE device class for the extraction step, ensure that the path for the device class is valid on the test system. The path that is in the server database for the device class must be correct. If necessary, start the server and update the path. If you will be using a tape device class for the extraction step, ensure that the device names for the library and drives are correct.


4. From this point, you can use the detailed procedures in one of the following sections to complete your test:

– Tivoli Storage Manager Planning Guide, Chapter 4, “Scenario 1: Same system, media method,” located at the following URL:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd_s1_ssmm.html

– Tivoli Storage Manager Planning Guide, Chapter 5, “Scenario 2: Same system, network method,” located at the following URL:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd_s2_ssnm.html

16.10.3 Test by extracting data from the production server

This example process uses the media method to move the database to the test system:

1. Back up the database of the production server. Consider making a second copy of the database backup.

2. Install the DSMUPGRD utility on the same system as the production server. For details, see “Installing the upgrade utilities on the original server” on page 181.

3. Prepare the database and extract the data from the database of the production server to media. Run the DSMUPGRD PREPAREDB command to prepare the database. Then run the DSMUPGRD EXTRACTDB command to extract the database to media. For details, see:

– Tivoli Storage Manager Planning Guide, Chapter 6, “Scenario 3: Preparing the database of a V5 server for upgrade,” located at the following URL:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd_p55dbu_s3.html

– Tivoli Storage Manager Planning Guide, Chapter 6, “Scenario 3: Extracting the data to media,” located at the following URL:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd_dbext_media_s3.html

4. Restore the database backup to the production server. You can resume normal operations on the production server.

5. From this point, continue your test by using the detailed procedures for Scenario 3, using the test system as the new system.

– Start with the section in Tivoli Storage Manager Planning Guide, Chapter 7, “Scenario 3: Installing the V6.1 server,” located at following URL:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd_install_s3.html

Continue through the end of the procedures in Scenario 3. If you use the command-line instructions, skip the steps for preparing the database and extracting the data to media.


http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd_p55dbu_s3.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd_dbext_media_s3.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd_install_s3.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd_s1_ssmm.html

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd_s2_ssnm.html

16.11 Planning for operational changes

Starting with V6.1, you need to back up and monitor the server database changes. Check the operating procedures, scripts, and administrative schedules that you use for server operations:

� Plan to continue backing up the server database regularly by using administrative schedules, a maintenance script, or your own scripts. Back up the server database at least once per day.

� Understand how database and recovery log space is used, and how monitoring needs to change.

� Check scripts and administrative schedules. The V6.1 server adds new commands, changes some commands, and deletes some commands that are no longer needed. These changes will affect your automated operations. For more information about the new commands and utilities, go to Chapter 4, “Commands, utilities, and option changes” on page 31.

� Check the SELECT commands that you use regularly. Some parameters and syntax that were previously allowed are not accepted by the database manager program.

� If you use products from independent software vendors to interface with the server, ensure that the products are compatible with the V6.1 server.

Adapting existing Operational Reporting for V6.1Some current Tivoli Storage Manager customers who are upgrading to the V6.1 server will already have Operational Reporting in production, with their I/T support process built around its e-mail reporting, or HTML site reports.

At the time of writing this chapter, there are no plans to support the Operational Reporting tool for V6.1 servers, with the intention that the reporting and monitoring tool will be the replacement. Rebuilding your Tivoli Storage Manager support processes will take time, which is why we have provided this unofficial work around in this book.

This work around will allow Tivoli Storage Manager administrators to continue working with the Windows Management Console (Operational Reporting) interface for a period of time, until the transition to the new Reporting and Montitoring configuration can be implemented in production.

This work around is provided “as-is,” and there are no plans to alter or enhance the existing Windows Operational Reporting function in V5.5 to support V6.1 servers:

ftp://service.boulder.ibm.com/storage/tivoli-storage-management/patches/server/NT/5.5.2.1/

This must be installed as a separate Windows machine or VM system to monitor the V6.1 servers. After installing the Management Console V5.5.2.x, install the newly adjusted .xml files, by copying the replacement default_mon_eng.xml_6100.xml and the default_rep_eng_6100.xml files, and saving the original default_rep_eng.xml and default_mon_eng.xml as part of the process, as shown Figure 16-11.




Figure 16-11 Files to alter for in the console folder, for the Operational Reporting tool adjustment

These XML templates will be referenced after you have defined the Tivoli Storage Manager V6.1 server computer to the ORF. Then create the Daily Report and Hourly Monitor, click the properties of the Daily Report and Hourly Monitor, and as opposed to the default XML templates, select the ones below (copy them first to the console directory).

When attempting to add and configure a new Tivoli Storage Manager V6.1 instance, using Operational Reporting V5.5.2.1, you might receive some of the errors shown in Figure 16-12.

Figure 16-12 Operational Reporting errors when referencing a Tivoli Storage Manager V6.1 instance


16.12 Why use the database upgrade wizards

The Tivoli Storage Manager upgrade wizards have changed to the InstallAnywhere platform, which will further standardize the installation process across platforms. All the required components are packaged within the install bundle, and this greatly simplifies the installation process.

Wizards greatly simplify the upgrade processWe highly recommend to use the wizards; they are less complex than command line utilities. Not only is the database upgrade done, but the ability to do database backups is also mostly configured. The wizard will create and configure your server and database instance for you prior to doing the upgrade, and the wizards are supported on all Tivoli Storage Manager Server platforms.

Following is a portion of the process flow for one of the upgrade methods (upgrade to a new system using the network) after Tivoli Storage Manager V6.1 installation is completed on an AIX operating system:

1. First set up environmental variables for dsmupgrd utilities.

2. Next run the dsmupgrd preparedb command on source Tivoli Storage Manager 5.x system, then check for errors.

3. Create the userid, groups, instance directories, and database/log files for the instance.

4. Login and reset the password for the instance user ID.

5. For all the directories that were created, ensure that the access permissions are set correctly.

6. Change the access permissions for the storage disk pools so that the instance ID can write to them.

7. Create the DB2 instance using the db2icrt command (under root).

8. Next, Logoff and then Login to the instance ID.

9. Format the new database using dsmserv loadformat, and check for error messages.

10.. Start the insert process on the target server (dsmserv insertdb), and wait for the message ANR1336I indicating that the source server can be started.

11.. When ANR1336I is issued, start the source server (dsmupgrd extractdb).

12.. Monitor for completion, and then check for error messages.

13.If all completes correctly, configure the database backup for Tivoli Storage Manager V6.

Instead of doing the foregoing steps, you could simply use the database upgrade wizard. The wizards are installed with the product, and are used to perform all the steps here (and more). At the completion of the wizard, the Tivoli Storage Manager server is started and ready for use. The wizard configures the database backup, but does not actually perform the backup. You must still specify which devclass is to be used for the backups of the database and set up the schedules of the database backups.

Note: There are only two steps that are not completed for DB Backup with the wizards. A deviceclass has to be created (if needed) for use with DB Backups, and then that deviceclass must be specified on the SET DBRECOVERY command.


16.13 An upgrade test

We took a database backup of a V5.5 production database and restored that into a VMware server onto a new file system to test the upgrade to V6.1. When the restore was finished, we completed the following preparation steps.

16.13.1 Upgrading from V5.5 to V6.1, step by step

Follow these steps for the upgrade:

1. Be current and read the readme files for the database upgrade.

2. Read the IBM Tivoli Storage Manager: Server Upgrade Guide, SC23-9554.

3. Download the DB Upgrade Utilities by using the FTP downloads site.

ftp://service.boulder.ibm.com/storage/tivoli-storage-management/maintenance/server-upgrade/

4. Have your Tivoli Storage Manager V6.1 DVDs available and online information available.For more information, see the following sites:

– Storage Technical Exchange Web site:

http://www-01.ibm.com/software/sysmgmt/products/support/supp_tech_exch.html

– Tivoli Storage Manager Wiki:


5. To prepare for the database upgrade, follow this process:

– The source system should be at least Tivoli Storage Manager 5.3 level for testing the DB upgrade. The recommended starting point is Tivoli Storage Manager V5.5.2.

– The system should meet the requirements for memory, disk, and software as outlined in the readme files.

– If Tivoli Storage Manager is at 5.5.x, then the server can be restarted after PREPAREDB is run, in case some kind of corrective action is needed.

– Ensure that you have the database upgrade utility (installed on the source system.)

– Consider 24X7 requirements for Tivoli Storage Manager availability.

– Complete the disk space planning.

– Verify that your monitoring applications support Tivoli Storage Manager V6.1.

Event retention data If you have any event retention data and if you know that you have NO event retention based data on the V5 DB, then you can specify EVENTBASEDUSED=NEVER for the DB upgrade.

This will provide a slight performance boost for operating systems during the extract portion of the DB Upgrade Process. If you have SSAM, then use EVENTBASEDUSED=YES for the DB Upgrade. If you are not sure if event base retention has ever been used, take the default, which is EVENTBASEDUSED=YES.

Note: These steps assume that the upgrade utilities package is already located on the system where Tivoli Storage Manager V5 server is installed.





16.13.2 Additional preparation activities

Preparation could also include these activities:

� DB unload/load, which might help the extract process

� DB audit

� Applications such as CDP, Content Manager, and Space Manager assume that Tivoli Storage Manager server is always available.

� Customer databases might need to back up archive logs hourly.

� Preparing space for the upgrade process could include these activities:

– Determine the amount and type of space that is required for the upgrade process before beginning the process.

– Verify that the system has the amount of space that was estimated in the planning step. Use the planning work sheet that you filled in with your information. Refer to “Space requirements” on page 257.

16.14 Modifying the server before the upgrade

A convert command must be run on the server to prevent one type of problem during the upgrade process. Some modifications to typical server settings are recommended to prepare for the upgrade.

� From a Tivoli Storage Manager administrative command line, issue the command:

convert ussfilespace

This command fixes a problem that might exist in older Tivoli Storage Manager databases. If the problem does not exist in your database, the command completes quickly. If the problem exists in your database, the command might take some time to run.

� Just in case, for some reason, you might need to revert to the earlier version after the upgrade to V6.1, review the steps for reverting to the earlier version of the server in the section, “Reverting from V6.1 to the previous V5 server version” in IBM Tivoli Storage Manager:Server Upgrade Guide, SC23-9554. The results of the reversion will be better if you understand the steps and prepare for the possibility now.

Attention: Do not use the EVENTBASEDUSED=NEVER parameter on an SSAM Server or if you have any Archive copygroups using retinit=event. If you do this, it will cause archived objects to be given the wrong retention initiation date.

Note: To improve the upgrade time, we have discussed the Tivoli Storage Manager database reorganization as an option. This option has an unload/load itself and requires downtime, so in the end, you will not save time by doing this.

Important: Do not skip this step. If your database has the problem and you do not run this command now, the DSMUPGRD PREPAREDB utility fails when you run it. You must then restart the V5 server and run the CONVERT USSFILESPACE command before continuing with the upgrade process.


� Make the following adjustments to settings on your server and clients. These adjustments must be done to make it possible for you to revert to the original server after the upgrade, if problems occur:

– For each sequential-access storage pool, set the REUSEDELAY parameter to the number of days during which you want to be able to revert to the original server, if that becomes necessary. For example, if you want to be able to revert to the original server for up to 30 days after upgrading to V6.1, set the REUSEDELAY parameter to 31 days.

– For each copy storage pool, set the RECLAIM parameter to 100 (meaning 100%).

– If you typically use a DELETE VOLHISTORY command to delete database backups, ensure that the command does not delete database backups for at least the same number of days that you set for the REUSEDELAY period for sequential-access storage pools.

– For important clients that use the server, check that the value for the schedlogretention client option is set to retain the client schedule log for a long enough time. Update the option for clients if needed.

The entries in the client schedule log might be useful if the server must revert to the original version. If the retention period for the schedule log is too short, the schedule log information might be deleted too soon.

� In preparation for the upgrade, prevent activity on the server by disabling new sessions. Cancel any existing sessions. The commands in the following procedure are Tivoli Storage Manager administrative commands.

To prevent all clients, storage agents, and other servers from starting new sessions with the server, use the commands:

disable sessions clientdisable sessions server

� Prevent administrative activity from any user ID other than the administrator ID that is being used to perform the upgrade preparation. Lock out other administrator IDs if necessary:

lock admin administrator_name

� Check whether any sessions exist, and notify the users that the server is going to be stopped. To check for existing sessions, use the command:

query session

� Cancel sessions that are still running. Use the command:

cancel session

� Back up storage pools and the server database:

Immediately before upgrading the server, back up primary storage pools to copy storage pools, and perform a full database backup:

– Back up primary storage pools to copy storage pools using the BACKUP STGPOOL command. If you have been performing regular backups of the storage pools, this step backs up only the data that was added to the primary storage pools since they were last backed up.

– Back up the database using the following command. Use either a full or snapshot backup type.

backup db type=type devclass=device_class_name

The device class that you specify must exist and have volumes that are available to it. For example, to perform a snapshot backup of your database to the TAPECLASS device class using scratch volumes, enter:

backup db type=dbsnapshot devclass=tapeclass


– To use specific volumes instead of scratch volumes, specify the volume names in the command. Consider making two copies of the backup to protect the backup from media failures.

� Back up configuration information:

Before installing the new version, back up critical files and information for the server. Store the files in a safe place, because they are needed after the installation of the new software version is completed. You also need these files if you must revert to the previous version after the upgrade.

– Back up device configuration information:

backup devconfig filenames=file_name

– Back up volume history information:

backup volhistory filenames=file_name

Ensure that the volume history includes information about the database backup that you completed in the preceding steps. For example, issue the command:

query volhistory type=dbbackup

– Make copies of these files, which are located in the default directory for the server:

• Make a copy of the server options file, typically named dsmserv.opt dsmserv.dsk.• Optionally, make a copy of the accounting log file, dsmaccnt.log.

– Back up any scripts that have been used to perform daily housekeeping for the server. Examine the scripts for changes that are needed after the upgrade.

– Store the device configuration file, the volume history file, the server options file, and the other files in a safe place. Select a location that is not on the system that is being upgraded.

� Create a summary of database contents:

– Create a summary of the contents of the original database. After the upgrade, you can use the same commands to compare the results and to confirm that the database contents are intact. Run commands that give a summary of information about your database contents. For example, issue commands that summarize the file spaces being protected, and save the results. See the sample commands for ideas.

� Stop the server before installing the upgrade:

Stop all server processes and dismount any tapes that are mounted. Then stop the server.

The commands in the following procedure are Tivoli Storage Manager administrative commands.

– Cancel sessions if any are still running. Use the command:

cancel session

Allow time for the sessions to be stopped. Some sessions, such as backup by a backup-archive client, might take some time to stop.

– Determine whether server processes are running. Either cancel processes, or allow them to complete. Use the commands:

query processcancel process process_number

Allow time for the processes to be stopped. Some processes, such as storage pool migration, might take some time to stop.


– After all sessions and processes are stopped, determine whether any tapes are mounted. Dismount any tapes that are mounted. Use the commands:

query mountdismount volume volume_name

– Stop the server using the command:

halt

� Installing the upgrade utilities:

You must install the upgrade utilities on the system where the V5 server is located. The installation package for the utilities must be downloaded from a Web site. You need an upgrade version that is greater than or equal to the level of the Tivoli Storage Manager server you are upgrading.

– First perform all preparation tasks on the original (source) system. Preparation includes: For the storage pools set reuse delay to the number of days during you want to be able to revert back to the original server if that becomes necessary. For each copy storage pool, set the RECLAIM parameter to 100. Backup and make copies of device configuration, volumehistory and server options files. Backup storage pools and server database, create a summary of the database contents. You can use the DSMUPGRD utility for this.

– Log on to source server with an administrator ID to install the upgrade utilities on the system where the V5 server is located. and run the executable package. The default location for the installation of the utilities is based on the location where the V5 server was last installed. The package to install is available for download from the FTP downloads site. The upgrade utilities are used to prepare and extract the database from the original server.

For example, if the V5 server was installed using the default path, C:\Program Files\Tivoli\TSM\server, create a upgrade folder and the upgrade utilities should be installed in path C:\Program Files\Tivoli\TSM\upgrade. After the upgrade utilities are installed, continue with installing the V6.1 server on the target server.

– Log on to the target system as an administrator and change to the directory where you placed the executable file. In the next step, the files are extracted to the current directory. Ensure that the file is in the directory where you want the extracted files to be located.

Notes:

� When you use the upgrade utilities and if you have multiple servers running on the system, you must use the -k option to specify the name of the Windows registry key from which to retrieve information about the server being upgraded.

� Do not install the utilities in the same directory as the original server that is to be upgraded, this is a restriction and is not allowed.

� The utilities package must be installed whether you are using the upgrade wizard or performing the upgrade manually with utilities.



Either double-click the executable file, or enter the following command on the command line to extract the installation files. The files are extracted to the current directory:

6.1.0.0-TIV-TSMALL-platform.exe

Install the V6.1 server code on the new system. After the install is done, check the installation logs in the path C:\Program Files\Tivoli\TSM.

– Create the directories for the V6.1 database and logs, and the user ID that will own the server instance. We choose TSM1 as the DB2 user ID.

– Start the upgrade wizard by double-clicking in it or run the command on the path, c:\Program Files\Tivoli\TSM\server\dsmupgdx.exe, to configure the new server and upgrade the V5 database. With the wizard, you complete the following tasks:

• On the original system, prepare the V5 database.• On the new system, create and format an empty database to receive the data.• Move the data from the V5 database to the V6.1 database.• Configure the new system for database backup.

– Complete the post-installation tasks, including backing up the database and verifying the database contents.

16.14.1 Performance tips for the V5 database extraction process

The speed of the extraction process is typically limited by the speed of I/O to the destination for the extracted data. The length of time that the process runs also depends on the size of the database. The time will be approximately as much as the time required for a full backup of the database.

Performance tips depend on the method that you choose for moving the data from the V5 database:

� Media method:

– If you are extracting the data to tape, use a high-speed tape device.

– If you are extracting the data to disk, use a disk device or LUN that is different than the device in use for the V5 database and recovery log.

– If both the V5 database and the destination for the extracted data are on a virtualization device (high-end storage controller, or a SAN virtualization device), ensure that the two virtual LUNs are not on the same physical disk drive. Ensure that the space in use for the V5 database and the destination for the extracted data are on different physical disk drives within the virtualization device.

– If it is not possible to provide different LUNs for the V5 database and the extraction destination, the extraction process will perform more slowly. The slower speed of extraction might be acceptable, depending on the size of the database and your requirements for the upgrade.

� Network method:

– Use a high speed link if you are extracting the data to a different system.

– For upgrading a database greater than 2 - 3 GB, use at least a 1-Gb Ethernet network.

– If you are extracting the database on the same system, no external network connections are required.

Note: You need an upgrade version that is greater than or equal to the level of the Tivoli Storage Manager server that you are upgrading.


16.14.2 Performance tips for inserting data into the V6.1 database

The process for inserting the V5 extracted data into the V6.1 database is the longest-running part of an upgrade process, and is the most sensitive to the configuration of the system. On a system that meets the minimum requirements, the insertion process will run, but performance might be slow. For better performance, set up the system as described in these tips.

� Processors:

The insertion process is designed to exploit multiple processors or cores.

The insertion process will typically perform better on a system with a relatively small number of fast processors than on a system with more but slower processors.

� Disk storage:

The insertion process is designed to exploit high-bandwidth disk storage subsystems. The speed of the process is highly dependent on the disk storage that is used.

For best performance, use multiple LUNs that map to multiple independent disks, or that map to RAID arrays with a large stripe size (for example, 128 KB). Use a different file system on each LUN. Table 16-10 shows an example of good usage of LUNs.

Table 16-10 Use of separate disks for database and logs

16.15 Tivoli Storage Manager documentation

For a complete list of Tivoli Storage Manager documentation hardcopy order numbers, refer to “Related publications” on page 627.

# of LUN Usage Mount point

4-128 Database <instance>/dbdir001 and higher

1 Active log <instance>/activelog

1 Archive log <instance>/archivelog

1 Active log mirror <instance>/activelogm

1 Archive log failover <instance>/archivelogf

Note: If the disk storage is supplied by a virtualization device (high-end storage controller, or a SAN virtualization device), ensure that none of the virtual LUNs are on the same physical disk drive. Ensure that the directories in use are on different physical disk drives within the virtualization device.


Part 7 Installation, customization, and upgrade of Tivoli Storage Manager V6.1 Server and Client

This part of the book covers the Tivoli Storage Manager V6.1 installation and upgrade of the server and client information.

Part 7


Chapter 17. Installation of Tivoli Storage Manager V6.1 on AIX

In this chapter we show the step-by-step installation of the Tivoli Storage Manager on the AIX platform; however, it is also directly applicable to HP-UX, Solaris, and Linux platforms. We also intend to give you some insight on multiple installation methods, because the installation program has changed, and the process is very different than in previous releases.

To further understand the changes in the installation process, refer to Chapter 16, “Installation and upgrade planning for Tivoli Storage Manager V6.1” on page 245.

17


17.1 System requirements for AIX

In this section we discuss the system requirements for planning your AIX installation and provide references where needed.

17.1.1 Planning the installation

Planning your installation requires some thought to ensure that you understand all the new options that exist in V6.1. Review the topic “Preparation” on page 248 for details.

17.1.2 System requirements

This section lists the system requirements for the AIX install.

HardwareTable 17-1 describes the hardware requirements for your AIX system. For further details, refer to the Tivoli Storage manager for AIX, Installation Guide, Capacity Planning, GC23-9781 for assistance with your disk planning.

Table 17-1 Hardware requirements for Tivoli Storage Manager v6.1 for AIX

Table 17-2 describes the minimum software requirements for Tivoli Storage Manager v6.1 running on an AIX system.

Table 17-2 Software requirements for Tivoli Storage Manager V6 for AIX

Type of hardware Hardware requirements

Hardware 64-bit p4, p5 or p6 System p® computer

Disk space Minimum disk space:� 5 MB for the /var directory� 2 GB for the /opt directory� 160 MB for the /tmp directory� 300 MB for the /usr directory

Memory At least 2 GB. A minimum of 4 GB for production servers. 8 GB is optimal.

Type of software Minimum software requirements

Operating system AIX 5.3 running in a 64-bit kernel environment with the following additional requirements for DB@:� AIX 5.3 Technology Level (TL) 6 and Service Pack (SP) 2 plus

the fix for APAR IZ03063� Minimum C++ runtime level with the xlC.rte 9.0.0.8 and

xlC.aix50.rte 9.0.0.8 filesets. These filesets are included in the June 2008 cumulative fix package for IBM C++ Runtime Environment Components for AIX.

AIX 6.1 running in a 64-bit kernel environment requires the following filesets for DB2:� Minimum C++ runtime level with the xlC.rte 9.0.0.8 and



17.2 Installation tasks

To install Tivoli Storage Manager components, complete the following steps:

17.2.1 Prepare the installation source

If you are installing the products using the Tivoli Storage Manager DVD, complete the following steps:

1. Insert the Tivoli Storage Manager DVD into a DVD drive.

2. Ensure that the DVD is mounted on directory /dvdrom and change to that directory.

If you downloaded the executable file from Passport Advantage®, complete the following steps:

1. First, change to the directory where you placed the executable file.

2. Then change the file permissions by entering the following command (see Example 17-1):

chmod a+x 6.1.0.0-TIV-TSMALL-platform.bin

Where platform denotes the architecture that Tivoli Storage Manager is to be installed on.

Example 17-1 AIX command line example for the chmod command

chmod a+x 6.1.2.0-TIV-TSMALL-AIX.bin

3. Run the following command to extract the installation files:

./6.1.0.0-TIV-TSMALL-platform.bin

4. After the extraction, the following directories and files have been created (Example 17-2).

Example 17-2 Contents of the extraction directory

# ls -ltotal 3530528-rwxr-x--x 1 root system 1732513010 May 21 20:15 6.1.2.0-TIV-TSMALL-AIX.bindrwxr-xr-x 4 root system 256 May 19 14:46 COIdrwxr-xr-x 3 root system 256 May 19 14:46 DE-rwxr-xr-x 1 root system 1128 May 19 14:53 PostFailureTask.xml-rwxr-xr-x 1 root system 75111171 May 19 14:23 install.bindrwxr-xr-x 2 root system 256 May 21 11:36 lost+found

5. Disk consumption at this point for the COI directory is shown in Example 17-3, presented in 1024 KB blocks.

Communication protocol A configured communication method.

Drivers If you have an IBM 3570, IBM 3590, or IBM Ultrium tape library or drive, install the most current device driver before you install Tivoli Storage manager 6.1. You can find the device drivers at: ftp://ftp.software.ibm.com/storage/devdrvr/


Important: Log in as the root user. If you do not log in as root, certain key Tivoli Storage Manager functions will not work properly.

Chapter 17. Installation of Tivoli Storage Manager V6.1 on AIX 305

ftp://ftp.software.ibm.com/storage/devdrvr/

Example 17-3 Disk usage of the COI directory, following the extraction of the install package

# du -ks COI2050972 COI

6. Disk consumption for the DE directory is shown in Example 17-4, presented in 1024 KB blocks.

Example 17-4 Disk consumption of the DE directory, following the extraction of the install package

# du -ks DE125324 DE

17.2.2 Choosing the installation method for AIX

Installing Tivoli Storage Manager V6.1.x on AIX has two primary installation methods:

� Console Installation wizard:

– Use JRE and X11 on an AIX graphics console, or X11 output redirection to a remote X11 client.

� Command-line console wizard:

– Use the “-i console” if you have no graphic capabilities.

Example 17-5 demonstrates the error that will occur if the Installation Wizard is invoked on a system that has no graphic output capabilities.

Example 17-5 Example of an error due to no X11 configuration

# ./install.binPreparing to install...Extracting the JRE from the installer archive...Unpacking the JRE...Extracting the installation resources from the installer archive...Configuring the installer for this system's environment...

Launching installer...

Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Stack Trace:java.awt.HeadlessException:No X11 DISPLAY variable was set, but this program performed an operation which requires it. at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:196) at java.awt.Window.<init>(Window.java:346) at java.awt.Frame.<init>(Frame.java:452) at java.awt.Frame.<init>(Frame.java:417) at javax.swing.JFrame.<init>(JFrame.java:180) at com.zerog.ia.installer.LifeCycleManager.g(DashoA10*..) at com.zerog.ia.installer.LifeCycleManager.h(DashoA10*..) at com.zerog.ia.installer.LifeCycleManager.a(DashoA10*..) at com.zerog.ia.installer.Main.main(DashoA10*..) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at


sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at com.zerog.lax.LAX.launch(DashoA10*..) at com.zerog.lax.LAX.main(DashoA10*..)This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

17.3 Installing Tivoli Storage Manager for AIX software

This section describes the installation of the AIX software using different methods.

Using the command-line console wizardIn this section we discuss the use of the console wizard. After the extraction of the installation binary (or insertion and mounting of the install DVD), these steps are intended to follow the steps for installing Tivoli Storage Manager server on a system with no graphics console. There is also no X11 pre-configured, thus that leaves you only the command line options of the console wizard or the silent installation. Here are the steps:

1. The first installation step is to issue the command shown in Example 17-6, from the installation source directory.

Example 17-6 AIX Tivoli Storage Manager command line console for installation

# ./install.bin -i console

2. Next, choose your console local (language), as shown in Example 17-7.

Example 17-7 Select the locale for the install console

Preparing to install...Extracting the JRE from the installer archive...Unpacking the JRE...Extracting the installation resources from the installer archive...Configuring the installer for this system's environment...


Preparing CONSOLE Mode Installation...

===============================================================================Choose Locale...----------------

1- Deutsch ->2- English 3- Español 4- Français 5- Italiano 6- Português (Brasil)

Note: If you have connected using telnet, and the system you are installing on has a graphics console, you will not see this error, nor the graphical installation panels.


CHOOSE LOCALE BY NUMBER: 2

3. Following this selection, the next panel that is presented is the installation Welcome panel as shown in Example 17-8.

Example 17-8 Installation Welcome panel

Tivoli Storage Manager (created with InstallAnywhere by Macrovision)-------------------------------------------------------------------------------

===============================================================================Tivoli Storage Manager Install------------------------------

WelcomeTivoli Storage Manager 6.1

Licensed Materials - Property of IBM Corp. (c) IBM Corporation and other(s)1993, 2008. All rights reserved. US Government Users Restricted Rights --Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBMCorp.

It is strongly recommended that you quit all programs before continuing withthis installation.

PRESS <ENTER> TO CONTINUE:

4. Next, after pressing <enter>, you are presented with the license agreement panel, which also identifies options for traversing the text, as seen in Example 17-9.

Example 17-9 Tivoli Storage Manager V6.1.2 Component Selection panel

International Program License Agreement

Part 1 - General Terms

BY DOWNLOADING, INSTALLING, COPYING, ACCESSING, OR USING THE PROGRAM YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ACCEPTING THESE TERMS ON BEHALF OF ANOTHER PERSON OR A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT AND WARRANT THAT YOU HAVE FULL AUTHORITY TO BIND THAT PERSON, COMPANY, OR LEGAL ENTITY TO THESE TERMS. IF YOU DO NOT AGREE TO THESE TERMS,

- DO NOT DOWNLOAD, INSTALL, COPY, ACCESS, OR USE THE PROGRAM; AND

- PROMPTLY RETURN THE PROGRAM AND PROOF OF ENTITLEMENT TO THE PARTY FROM WHOM YOU ACQUIRED IT TO OBTAIN A REFUND OF THE AMOUNT YOU PAID. IF YOU DOWNLOADED THE PROGRAM, CONTACT THE PARTY FROM WHOM YOU ACQUIRED IT.

"IBM" is International Business Machines Corporation or one of its

Press Enter to continue viewing the license agreement, or enter "1" to accept the agreement, "2" to decline it, "3" to print it, "4" to read non-IBM terms, or "99" to go back to the previous screen.:


5. You must eventually select option “1” to accept the licensing terms to continue. After doing this, you must select what software components to install. In this example we are selecting options 1, 3, and 6. We recommend to install the Administration Center feature on another system, possibly sharing this secondary system with the Reporting feature software.

6. After selecting the components to install, the next task is to choose the Administrator Center ID and password as shown in Example 17-10.

Example 17-10 Administration Center install

Administration Center---------------------

To install the Administration Center enter the following information.

ISC user name: (DEFAULT: iscadmin): iscadmin

===============================================================================

ISC password::*********

===============================================================================

*Verify password::*********

===============================================================================

Port number: (DEFAULT: 9043):

7. Following this selection, a Deployment Engine Initialization occurs. We have removed multiple lines to reduce the amount of line outputs. This is shown in Example 17-11.

Example 17-11 Deployment Engine Initialization panel

Deployment Engine Initialization--------------------------------

Please Wait..completed: 1 ; total: 19

Lines have been removed ...

completed: 19 ; total: 19Completed.Completed.


8. Next, you are presented with a review panel as shown in Figure 17-1.

Figure 17-1 Pre-installation Summary panel

9. After the completion of the installation, the summary panel and exit prompt are presented, as shown in Example 17-12.

Example 17-12 Tivoli Storage Manager v6.1 successfully installed summary panel

Installing...-------------

[==================|==================|==================|==================] [------------------|------------------|------------------|------------------]

===============================================================================Installation Complete---------------------

See /var/tivoli/tsm/log.txt for details.

The following components were successfully installed:

TSM ServerDB2 9.5TSM Client APITSM LicenseeWASISCTSM Administration Center

Pre-Installation Summary------------------------

Please Review the Following Before Continuing:

Product Name: Tivoli Storage Manager

Install Folder: /opt/tivoli/tsm

Components: TSM Server,DB2 9.5,TSM Client API,TSM License,eWAS,ISC,TSM Administration Center

Disk Space Information (for Installation Target): Required: 2,251,666,227 bytes Available: 2,327,085,056 bytes



To continue, either configure a new server instance or upgrade an existingserver instance.

To configure a new server instance, choose one of the following methods:

Log in as root user or administrator and open the local new-instance wizard,dsmicfgx, located in the server installation directory. Log on to a Version 6.1 Tivoli Storage Manager Administration Center andstart the Create New Instance wizard. Configure the new instance manually. See the Tivoli Storage ManagerInformation Center, or the Installation Guide.

To upgrade an existing server instance, log in as root user or administratorand start the upgrade wizard, dsmupgdx, located in the server installationdirectory. You can also upgrade a server manually. See the Tivoli StorageManager Information Center, or the Server Upgrade Guide.

For more information about any of these tasks, see the Tivoli Storage ManagerInformation Center at: http://publib.boulder.ibm.com/infocenter/tsminfo/v6

PRESS <ENTER> TO EXIT THE INSTALLER:

10.After completing the installation process, we need to complete the configuration, as discussed in 17.5, “Post-installation steps for Tivoli Storage Manager” on page 316.

17.4 Installation using the console installation wizard

When using the installation wizard on AIX, with out a graphics console, you will first require an X11 remote setup. The following section describes this setup, prior to beginning with the installation wizard.

17.4.1 Setup of X11 environment for non-graphical environments

Suppose that you find it necessary to use the GUI, but the machine is remote or there is no graphic adapter/monitor available at the remote machine. In such a case, you might have to export the display of the Tivoli Storage Manager GUI to another machine.

In order to export the graphic display of one UNIX machine to another machine, an X11 server/client must be used. Cygwin is a publicly available solution.

The Cygwin software that is freely available from www.cygwin.org can be used to export the Tivoli Storage Manager GUI or any other graphic from the remote machine for that matter. In the following instructions we give you an example of how to export the display from an AIX machine to a Windows XP machine:

1. First, install Cygwin.

Go to http://www.cygwin.com and retrieve setup.exe to install Cygwin. After you run setup.exe, you have to select which packages to install. You need to install the X11 packages, and under the net subsection you might want to include the ssh components. In Example 17-13 we have included a list of minimum packages, based on the most recent level of Cygwin at the time this was written.


http://www.cygwin.com

Example 17-13 Cygwin categories to install

Under the X11 category: X-start-menu-icons X-startup-scripts cygwin-x-doc xorg-x11-base xorg-x11-bin xorg-x11-bin-dlls xorg-x11-f100 xorg-x11-fcyr xorg-x11-fenc xorg-x11-fscl xorg-x11-man-pages xorg-x11-man-pages-html xorg-x11-xwin xorg-Xterm xwinclipMinimum Under the “Net” category (if you use ssh) : openssh openssl ping

2. If ssh is running on the remote machine:

a. From a cygwin shell, enter the following command: startx

b. This will start another cygwin shell. From that new shell, enter the following command: xhost <remote_machine_ip>

c. From that same cygwin shell, start a ssh session with the remote machine: ssh -X -l <user> <remote_machine_ip>

d. From the ssh shell, start an X11 remote shell by issuing the xterm & command. Type exit to end the test connection, or continue to “Installation wizard using X11 redirection” on page 312 after you have completed this step.

3. if ssh is not running on the remote machine:

a. From a cygwin shell, enter the following command: startx

b. This will start another cygwin shell. From that new shell, enter the following command: xhost <remote_machine_ip>

c. Leave these shells running.

d. From a “normal MSDOS” window shell, use a telnet command to the remote machine:telnet <remote_machine_ip>

e. When you are logged in, enter the following command:export DISPLAY= <ip_of_windows_machine>:0.0

f. In the telnet shell, start an X11 remote shell by issuing the xterm & command. Type exit to end the test connection, or continue to “Installation wizard using X11 redirection” on page 312 after you have completed this step.

17.4.2 Installation wizard using X11 redirection

Using the installation wizard is one method of installing Tivoli Storage Manager. To install Tivoli Storage Manager, use the installation wizard and X11 redirection following the setup steps, as shown in “Setup of X11 environment for non-graphical environments” on page 311.


Then complete the following steps:

1. The first step is to set your temporary directory to use for installation space. A minimum of 68 MB of free space is required. This space is used to extract the JRE from the installer archive, as shown in Example 17-14.

Example 17-14 Set temporary directory

# IATEMPDIR=/code# export IATEMPDIR

2. Next, we create a separate logical volume for the target directory of /opt/tivoli/tsm, which we create at 2.4 GB in size. This will hold all of the base installation software.

3. Next, start the installation steps by issuing the command shown in Example 17-15 from the installation source directory.

Example 17-15 AIX Tivoli Storage Manager installation wizard

# ./install.bin

This command results in the output shown in Example 17-16.

Example 17-16 Result of install.bin command

# ./install.bin Preparing to install...Extracting the JRE from the installer archive...Unpacking the JRE...Extracting the installation resources from the installer archive...Configuring the installer for this system's environment...

Launching installer..

Now, at this point the X11 graphics redirection begins to the Windows system, as shown in Figure 17-2.

Figure 17-2 Initial X11 redirected AIX Installation Wizard panel


4. Select the language for your installation and follow the wizard directions, selecting OK to step through the wizard to choose English. Then, click Next to complete the Welcome panel.

5. Following this, you must accept the license agreement to proceed, as shown in Figure 17-3.

Figure 17-3 Software License Agreement

6. Next, we select the components that we want to install (server, licenses, and Administration Center). There is no default so you must make a selection or you will receive an error message and be returned to the components page. Our selections are shown in Figure 17-4.


Figure 17-4 Select Components for AIX Tivoli Storage Manager install

7. Because we selected the Administration Center component, we are prompted for a user name and password, as seen in Figure 17-5. We will use these later to log onto the Integrated Solutions Console and Administration Center.

Figure 17-5 Specify Administration Center user ID and password


8. After selecting Next on the Administration Center panel, the pre-installation summary panel appears, as shown in Figure 17-6.

Figure 17-6 Pre-Installation Summary window

9. After reviewing, we select the Install option to continue. Then, at the end of the installation, a message is displayed on the summary page that Tivoli Storage Manager successfully installed, and a summary is provided. If there were any errors during the installation, the summary page lists the errors and directs you to an error log file. Fix the errors before continuing. The installation log is stored in the following location:

/var/tivoli/tsm/log.txt

17.5 Post-installation steps for Tivoli Storage Manager

After completing the Tivoli Storage Manager V6.1 installation, the next step is to customize the AIX environment, preparing for the running of either the dsmserv format command, or further customization using the configuration wizard or the Administration Center. This customization includes tasks discussed in the following section, “Preparing the AIX server for Tivoli Storage Manager instances”.

17.5.1 Preparing the AIX server for Tivoli Storage Manager instances

Tivoli Storage Manager will use default locations, however we recommend to preconfigure your disk structure first, possibly considering a naming convention that facilitates multiple instances. In AIX, this might imply Volume Group, Logical Volume, and mount points, which reflect an instance naming convention.

Note: The Tivoli Storage Manager client application programming interface (API) is automatically installed when you select the server component.


Disk structureTivoli Storage Manager will use default locations, however it is recommended to preconfigure your disk structure first, possibly considering a naming convention that facilitates multiple instances. After you have created your disk structure, then provide these path names during the install process. The following example shows our test configuration.

Table 17-3 Disk paths required and the test environment setup

The file systems created for this AIX system are shown in Example 17-17. This demonstrates one of many ways to name and mount volumes for use with a tsm1 instance.

Example 17-17 AIX file systems, including all the custom logical volume and JFS2 created

Filesystem 512-blocks Free %Used Iused %Iused Mounted on/dev/hd4 655360 289784 56% 11942 25% //dev/hd2 4587520 333488 93% 44675 49% /usr/dev/hd9var 262144 103120 61% 4767 29% /var/dev/hd3 655360 115128 83% 4035 23% /tmp/dev/hd1 917504 916456 1% 14 1% /home/dev/hd11admin 262144 261416 1% 5 1% /admin/proc - - - - - /proc/dev/hd10opt 1703936 1143584 33% 3153 3% /opt/dev/download_lv 5242880 1144808 79% 17 1% /download/dev/codelv 52428800 47126688 11% 2296 1% /code/dev/tsmbinlv 4980736 460856 91% 26700 33% /opt/tivoli/tsm/dev/tsmbinlv 4980736 394256 93% 26714 37% /opt/tivoli/tsm/dev/dbdir001lv 4194304 3963168 6% 44 1% /tsm1/dbdir001/dev/dbdir002lv 4194304 3963152 6% 44 1% /tsm1/dbdir002/dev/dbdir003lv 4194304 3963144 6% 44 1% /tsm1/dbdir003/dev/dbdir004lv 4194304 3963152 6% 44 1% /tsm1/dbdir004/dev/actlog 8519680 1168120 87% 14 1% /tsm1/activelog/dev/actlogm 8519680 8495760 1% 12 1% /tsm1/activelogm/dev/archlog 16777216 9427808 44% 14 1% /tsm1/archlog/dev/archlogf 8388608 8386600 1% 12 1% /tsm1/archlogf

AIX volume group

AIX logical volume Naming convention Default size (MB)

Test system sizing (MB)

Separate disk volume if possible

tsmvg /dev/tsmbinlv /opt/tivoli/tsm 3072 yes

<instance>vg /dev/hd1 (default) /home/<instance> 400 yes

<instance>dbvg /dev/dbdir001lv <instance>/dbdir001 2048 Yes




<instance>logvg /dev/actloglv <instance>/activelog 2048 8192 Yes

<instance>logvg /dev/actlogmlv <instance>/activelogm 2048 8192 Yes

<instance>logvg /dev/archlog <instance>/archlog 2048 16384 Yes

<instance>logvg /dev/archlogf <instance>/archlogf 2048 8192 Yes


Create a user ID for each instanceCreate a user ID for each server instance that you plan to implement. For this setup purpose, we are configuring the instance tsm1 as the name of our first instance. The tasks involved the creation of the group, user ID, and home directory for our Tivoli Storage Manager instance, as shown in Example 17-18.

Example 17-18 Tivoli Storage Manager instance user ID creation in AIX

# mkgroup id=1001 tsmsrvrs# mkuser -a id=1002 pgrp=tsmsrvrs home=/home/tsm1 tsm1# passwd tsm2Changing password for "tsm1"tsm1's New password:Enter the new password again:

Next, log in using the user ID and password, and you will be prompted to change the password for that user ID, as shown in Example 17-19.

Example 17-19 Logging into AIX and changing the password for TSM1 new instance creation.


Change the ownership of the newly created file system mount pointsChanging the ownership of the tsm1 mounts and directories can be accomplished by issuing the commands shown in Example 17-20.

Example 17-20 AIX chown command and review of owner and group settings

# cd /tsm1# pwd/tsm1# chown -R tsm1.tsmsrvrs *# ls -ltotal 0drwxr-xr-x 4 tsm1 tsmsrvrs 256 Jun 01 12:33 activelogdrwxr-xr-x 4 tsm1 tsmsrvrs 256 Jun 01 12:41 activelogmdrwxr-xr-x 4 tsm1 tsmsrvrs 256 Jun 01 12:33 archlogdrwxr-xr-x 5 tsm1 tsmsrvrs 256 Jun 01 12:33 archlogfdrwxr-xr-x 4 tsm1 tsmsrvrs 256 Jun 01 12:30 dbdir001drwxr-xr-x 4 tsm1 tsmsrvrs 256 Jun 01 12:30 dbdir002drwxr-xr-x 4 tsm1 tsmsrvrs 256 Jun 01 12:30 dbdir003drwxr-xr-x 4 tsm1 tsmsrvrs 256 Jun 01 12:30 dbdir004

Create a new server options fileCreating a new server options file (dsmserv.opt) and copying this file into the instance home directory (/home/tsm1), then configuring the option file with the appropriate communication settings will be required. Refer to the IBM Tivoli Storage manager for AIX: Installation Guide for more details regarding dsmserv.opt parameters and settings.


Preparing the DB2 database and recovery logsFormatting the new Tivoli Storage Manager server database and recovery log is no longer a Tivoli Storage Manager server function, when done step-by-step outside of the GUI interfaces. The next command db2icrt will update the instance details within DB2. The command is run as shown in Example 17-21.

Example 17-21 The command to run to configure a Tivoli Storage Manager V6.1 server instance

# /opt/tivoli/tsm/db2/instance/db2icrt -a SERVER -u tsm1 tsm1DBI1070I Program db2icrt completed successfully.

Reviewing what db2icrt doesThe following list breaks down what this step is accomplishing:

1. db2incrt creates the sqllib directory structure within the <instance> folder or directory (/home/tsm1 in this example). The new directory structure and support files consumed approximately 293 MB, as shown in Example 17-22.

Example 17-22 Space consumed by the creation of a Tivoli Storage Manager server instance

# pwd/home/tsm1# ls -ltotal 168-rwxr----- 1 tsm1 tsmsrvrs 415 May 26 19:30 .profile-rw------- 1 root system 124 May 26 19:40 .sh_history-rw------- 1 tsm1 tsmsrvrs 39 May 26 19:24 .vi_history-rw-r--r-- 1 tsm1 tsmsrvrs 69607 May 26 19:23 dsmserv.optdrwxrwsr-t 18 tsm1 tsmsrvrs 4096 May 26 19:30 sqllib# du -ks sqllib300588 sqllib

2. db2incrt also establishes the database instance within DB2, and the directory and file hierarchy to manage this, as shown in Example 17-23.

Example 17-23 DB2 files to manage the new Tivoli Storage Manager instance

# ls -Rl tsm1total 0drwxrwxr-x 4 tsm1 tsmsrvrs 256 May 26 20:22 NODE0000tsm1/NODE0000:total 8drwxr-x--- 4 tsm1 tsmsrvrs 4096 Jun 14 00:59 SQL00001drwxrwxr-x 2 tsm1 tsmsrvrs 256 May 26 20:22 sqldbdir

tsm1/NODE0000/SQL00001:total 13160-rw-r----- 1 tsm1 tsmsrvrs 1770 Jun 13 18:56 DB2TSCHG.HIS-rw------- 1 tsm1 tsmsrvrs 1280 Jun 11 21:15 SQLBP.1-rw------- 1 tsm1 tsmsrvrs 1280 Jun 11 21:15 SQLBP.2-rw------- 1 tsm1 tsmsrvrs 4096 May 26 20:22 SQLDBCON-rw------- 1 tsm1 tsmsrvrs 16384 Jun 13 19:16 SQLDBCONF-rw-r----- 1 tsm1 tsmsrvrs 9 Jun 13 18:58 SQLINSLK-rw------- 1 tsm1 tsmsrvrs 24576 Jun 13 19:04 SQLOGCTL.LFH.1-rw------- 1 tsm1 tsmsrvrs 24576 Jun 13 19:04 SQLOGCTL.LFH.2drwxr-x--- 2 tsm1 tsmsrvrs 256 May 26 20:27 SQLOGDIR-rw------- 1 tsm1 tsmsrvrs 8192 Jun 13 19:04 SQLOGMIR.LFH


-rw------- 1 tsm1 tsmsrvrs 135168 May 26 20:22 SQLSGF.1-rw------- 1 tsm1 tsmsrvrs 135168 May 26 20:22 SQLSGF.2-rw------- 1 tsm1 tsmsrvrs 2621440 Jun 13 19:05 SQLSPCS.1-rw------- 1 tsm1 tsmsrvrs 2621440 Jun 13 19:05 SQLSPCS.2-rw-r----- 1 tsm1 tsmsrvrs 0 May 26 20:22 SQLTMPLKdrwxr-x--- 3 tsm1 tsmsrvrs 256 May 26 20:22 db2event-rw-r----- 1 tsm1 tsmsrvrs 557526 Jun 14 00:59 db2rhist.asc-rw-r----- 1 tsm1 tsmsrvrs 557526 Jun 14 00:59 db2rhist.bak

tsm1/NODE0000/SQL00001/SQLOGDIR:total 0

tsm1/NODE0000/SQL00001/db2event:total 0drwxr-x--- 2 tsm1 tsmsrvrs 256 Jun 12 01:42 db2detaildeadlock

tsm1/NODE0000/SQL00001/db2event/db2detaildeadlock:total 4808-rw-r--r-- 1 tsm1 tsmsrvrs 2096516 Jun 12 01:42 00000000.evt-rw-r--r-- 1 tsm1 tsmsrvrs 352369 Jun 13 19:04 00000001.evt-rw-r----- 1 tsm1 tsmsrvrs 39 Jun 12 01:42 db2event.ctl

tsm1/NODE0000/sqldbdir:total 24-rw-rw-r-- 1 tsm1 tsmsrvrs 1512 May 26 20:30 sqldbbak-rw-rw-r-- 1 tsm1 tsmsrvrs 1512 May 26 20:30 sqldbdir-rw-rw-r-- 1 tsm1 tsmsrvrs 540 May 26 20:23 sqldbins

3. The next step is to log out of AIX as the root user, and log in as the instance user ID (tsm1). Upon completing this step, you will find that an environment for DB2 has been established, as discussed in the previous steps.

4. In the next step we update the default directory for the database to reflect the instance directory, by running the db2 update command as shown in Example 17-24.

Example 17-24 Setting the default directory for the database to be the same as the instance directory.

$ pwd/home/tsm1$ db2 update dbm cfg using dftdbpath /tsm1DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completedsuccessfully.

5. This db2 upd command establishes the db2 configuration for the tsmdb1 database, and can be reviewed by running a db2 => get snapshot for database on TSMDB1, as shown in Example 17-25.

Example 17-25 Get snapshot for database on TSMDB1 DB2 command

cd /home/tsm1/sqllib/bindb2 => get snapshot for database on TSMDB1

Database Snapshot

Database name = TSMDB1Database path = /home/tsm1/tsm1/NODE0000/SQL00001/


Input database alias = TSMDB1Database status = ActiveCatalog database partition number = 0Catalog network node name =Operating system running at database server= AIX 64BITLocation of the database = LocalFirst database connect timestamp = 06/01/2009 12:44:05.254311Last reset timestamp =Last backup timestamp = 06/01/2009 12:41:33.000000Snapshot timestamp = 06/01/2009 13:59:45.841818

Number of automatic storage paths = 4Automatic storage path = /tsm1/dbdir001 Node number = 0 File system ID = 9223372238718238723 Storage path free space (bytes) = 2029142016 File system used space (bytes) = 118341632 File system total space (bytes) = 2147483648Automatic storage path = /tsm1/dbdir002 Node number = 0 File system ID = 9223372238718238724 Storage path free space (bytes) = 2029133824 File system used space (bytes) = 118349824 File system total space (bytes) = 2147483648Automatic storage path = /tsm1/dbdir003 Node number = 0 File system ID = 9223372238718238725 Storage path free space (bytes) = 2029129728 File system used space (bytes) = 118353920 File system total space (bytes) = 2147483648Automatic storage path = /tsm1/dbdir004 Node number = 0 File system ID = 9223372238718238726 Storage path free space (bytes) = 2029133824 File system used space (bytes) = 118349824 File system total space (bytes) = 2147483648

6. Next, format the files for the database and logs, using the Tivoli Storage Manager server command dsmserv format as shown in Example 17-26.

Example 17-26 dsmserv format command syntax for setting up a server instance in V6.1

$ dsmserv format dbdir=/tsm1/dbdir activelogsize=8192 activelogdir=/tsm1/active_log archlogdir=/tsm1/archive_log archfailoverlogdir=/tsm1/archive_failover_log mirrorlogdir=/tsm1/active_mirror_log

7. The successful output of the dsmserv format command is shown in Example 17-27.

Example 17-27 Output of the dsmserv format command in Tivoli Storage Manager V6.1

ANR7800I DSMSERV generated at 16:29:44 on Mar 13 2009.





ANR7801I Subsystem process ID is 323600.ANR0900I Processing options file /home/tsm1/dsmserv.opt.ANR7811I Using instance directory /home/tsm1.ANR4726I The ICC support module has been loaded.ANR0152I Database manager successfully started.ANR0152I Database manager successfully started.ANR1380I The buffer pool monitor switch is enabled.ANR0992I Server's database formatting complete.ANR0369I Stopping the database manager because of a server shutdown.ANR2976I Offline DB backup for database TSMDB1 started.ANR2974I Offline DB backup for database TSMDB1 completed successfully.

8. Following the successful formatting, the next step is to start the Tivoli Storage Manager V6.1 server in the foreground. To perform this step, we use the new parameters provided in the dsmserv command, as shown in Example 17-28. Refer to Table 4-5 on page 36 for information about the DSMSERV command.

Example 17-28 Starting the Tivoli Storage Manager V6.1 server instance in the foreground

$ /opt/tivoli/tsm/server/bin/dsmserv -u tsm1 -i /home/tsm1

9. The foreground output of the Tivoli Storage Manager V6.1 startup appears similar to that of previous releases, with the exception of Database Manager startup, as shown in Example 17-29.

Example 17-29 Tivoli Storage Manager server instance startup output on AIX

ANR7800I DSMSERV generated at 16:29:44 on Mar 13 2009.


Licensed Materials - Property of IBM(C) Copyright IBM Corporation 1990, 2008.All rights reserved.U.S. Government Users Restricted Rights - Use, duplication or disclosurerestricted by GSA ADP Schedule Contract with IBM Corporation.ANR7801I Subsystem process ID is 368828.ANR0900I Processing options file /home/tsm1/dsmserv.opt.ANR7811I Using instance directory /home/tsm1.ANR4726I The ICC support module has been loaded.ANR0990I Server restart-recovery in progress.ANR0152I Database manager successfully started.ANR1380I The buffer pool monitor switch is enabled.ANR1635I The server machine GUID, c8.8d.1e.ec.41.e6.11.de.98.6e.08.63.09.0c.05-.0c, has initialized.ANR2100I Activity log process has started.ANR4726I The NAS-NDMP support module has been loaded.ANR1794W TSM SAN discovery is disabled by options.ANR2803I License manager started.ANR0984I Process 1 for EXPIRE INVENTORY (Automatic) started in the BACKGROUND


at 13:31:05.ANR8285I Shared Memory driver ready for connection with clients on port 1510ANR0811I Inventory client file expiration started as process 1.ANR8200I TCP/IP Version 4 driver ready for connection with clients on port1500.ANR2560I Schedule manager started.ANR0167I Inventory file expiration process 1 processed for 0 minutes.ANR0812I Inventory file expiration process 1 completed: processed 0 nodes,examined 0 objects, deleting 0 backup objects, 0 archive objects, 0 DB backupvolumes, and 0 recovery plan files. 0 objects were retried and 0 errors wereencountered.ANR0985I Process 1 for EXPIRE INVENTORY (Automatic) running in the BACKGROUNDcompleted with completion state SUCCESS at 13:31:07.ANR2841W Server is NOT IN COMPLIANCE with license terms.ANR0984I Process 2 for AUDIT LICENSE started in the BACKGROUND at 13:31:07.ANR2820I Automatic license audit started as process 2.ANR2825I License audit process 2 completed successfully - 0 nodes audited.ANR0985I Process 2 for AUDIT LICENSE running in the BACKGROUND completed withcompletion state SUCCESS at 13:31:08.ANR2841W Server is NOT IN COMPLIANCE with license terms.TSM:SERVER1>ANR0993I Server initialization complete.ANR0916I TIVOLI STORAGE MANAGER distributed by Tivoli is now ready for use.Storage Management Server for AIX - Version 6, Release 1, Level 0.0TSM:SERVER1>

10.The startup time for a new server instance is approximately 8 minutes, as shown by using the AIX time command, and allowing for halt time, as shown in Example 17-30.

Example 17-30 Output of the AIX time command: V6.1 startup and immediate halt time

real 7m58.24suser 0m4.02ssys 0m2.27s

DB2 configuration for database backupWe must now configure the API to allow for a DB2 database backup. If you use the Tivoli Storage Manager Server Instance Configuration wizard to create a server instance, configuration is done automatically. If you are configuring an instance manually, for the backup to work, the following requirements must be met:

� Tivoli Storage Manager API is installed on server machine (done by COI install).

� Tivoli Storage Manager API has the correct client option settings.

� DSMI_DIR, DSMI_CONFIG, DSMI_LOG environment variables are set in DB2 instance process.

� DSMI_DIR, DSMI_CONFIG, DSMI_LOG point to the correct places:

– API executables– API configuration files– API log file directory



The steps required to complete this task are as follows:

1. We set the DSMI_ api environment variables in the <instance>/sqllib/db2profile file, as shown in Example 17-31.

Example 17-31 The line items added to the sqllib/db2profile file.

export DSMI_CONFIG=/home/tsm1/tsmdbmgr.optexport DSMI_DIR=/usr/tivoli/tsm/client/api/bin64export DSMI_LOG=/home/tsm1

2. Then log out, and back into the instance, or issue the command ~/.profile as shown in Example 17-32 to re-read the profile.

Example 17-32

$ ~/.profile

3. Next, create a file called tsmdbmgr.opt in the /home/tsm1 directory and add the following line as shown in Example 17-33.

Example 17-33 Content of the /ome/tsm1/tsmdbmgr.opt file.

servername tsmdbmgr_tsm1

4. Next, edit the /usr/tivoli/tsm/client/api/bin64/dsm.sys. Avoid placing the server name, TSMDBMGR_TSM1, first in dsm.sys because it should not be the system-wide default. In this example, the added lines are after the stanza for server_a, as shown in Example 17-34.

Example 17-34 /usr/tivoli/tsm/client/api/bin64/dsm.sys

Servername server_aCOMMMethod TCPipTCPPort 1500TCPServeraddress node.domain.company.COM

servername TSMDBMGR_TSM1 commmethod tcpip tcpserveraddr localhost tcpport 1500 passwordaccess generate passworddir /home/tsm1 errorlogname /home/tsm1/tsmdbmgr.lognodename $$_TSMDBMGR_$$

5. Next, stop and then restart DB2, as shown in Example 17-35.

Example 17-35 Stop and restarting DB2

$ db2stop$ db2start

6. Next, set the API password for the instance TSM1, using the password (current and new) as TSMDBMGR, as root user, as shown in Example 17-36.

Example 17-36 Setting the API password for DB2.

# cd /home/tsm1/sqllib/adsm# ./dsmapipw


************************************************************** Tivoli Storage Manager ** API Version = 6.1.0 **************************************************************Enter your current password:Enter your new password:Enter your new password again:

7. Finally, we can submit the database backup; issue the backup database command. Example 17-37 documents the results, and shows that we successfully completed the task.

Example 17-37 The first manual backup

tsm: UTAH-TSM1> backup db devc=dbb_file type=full

To reference the product manual for this process, refer to the following site.


Registering an AdministratorDuring this type of installation, there was no prompt for any Administrator ID or password.

1. After starting the server instance in the foreground, we must register an administrative user and password, using reg admin admin admin1 and finally grant authority using the command grant auth admin classes=system as a system user, as shown in Example 17-38.

Example 17-38 Registering an administrator and granting system authority

TSM:SERVER1>reg admin admin admin1ANR2017I Administrator SERVER_CONSOLE issued command: REGISTER ADMIN admin?***?ANR2068I Administrator ADMIN registered.TSM:SERVER1>grant auth admin classes=systemANR2017I Administrator SERVER_CONSOLE issued command: GRANT AUTHORITY adminclasses=systemANR2076I System privilege granted to administrator ADMIN.

2. Following the administrator registration, we establish the automatic startup of the ISC/AC by running the script: /opt/tivoli/tsm/AC/products/tsm/bin/setTSMUnixLinks.sh, which will update the /etc/inittab with the following details, shown in Example 17-39.

Example 17-39 /etc/inittab entry as a result of running setTSMUnixLinks.sh script

IBMTSM:2:once:"/opt/tivoli/tsm"/AC/products/tsm/bin/rc.IBMTSM start >/dev/console 2>&1

3. Then, for the time, we will manually start up the ISC/AC server process (Example 17-40).

Example 17-40 Manual command to start the ISC/AC Server processes

# /opt/tivoli/tsm/AC/products/tsm/bin/rc.IBMTSM start &



4. Following the startup command, the output of the Integrated Solutions Console is shown in Example 17-41.

Example 17-41 ISC/AC startup command output

ADMU0116I: Tool information is being logged in file/opt/tivoli/tsm/AC/ISCW61/profiles/TsmAC/logs/tsmServer/startServer.logADMU0128I: Starting tool with the TsmAC profileADMU3100I: Reading configuration for server: tsmServerADMU3200I: Server launched. Waiting for initialization status.ADMU3000I: Server tsmServer open for e-business; process id is 319680

5. Then, the following step we will connect remotely to the ISC/AC using HTTPS, using the connection address https://9.12.5.12:9043/ibm/console, as shown in Figure 17-7.

Figure 17-7 Integration Solutions Console Welcome panel URL address


https://9.12.5.12:9043/ibm/console

6. Following the connection success, log into the Integrated Solutions Console userid and password that were established during the installation process, as shown in Figure 17-8.

Figure 17-8 Login to the Integrated Solutions Console Welcome panel

7. When you are logged in, at this point you can view the Integrated Solutions Console. However, at this point, you can log out because this step is verified as working correctly. Logout is shown in Figure 17-9.


Figure 17-9 Demonstrating the logout of the V6.1 Integrated Solutions Console

17.5.2 Post-completion tasks

In this section we discuss the post-completion tasks.

Adjusting your DBMEMPERCENT parametersThe DBMEMPERCENT server option parameter sets a limit on the percentage of the system memory that is used for the database manager. By default, the percentage of the virtual address space that is dedicated to the database manager processes is set to 70 to 80 % of system RAM. To change this setting to a value from 10 to 99 %, modify the DBMEMPERCENT server option. Ensure that the value allows adequate memory for both the Tivoli Storage Manager server and any other applications that are running on the system. AUTO is the default value.

It is generally not necessary to change this setting on a system that is dedicated to a single Tivoli Storage Manager server. If there are other applications that require significant amounts of memory on a system, changing this setting to an appropriate amount reduces paging and improves system performance. For systems with multiple Tivoli Storage Manager servers, changing this setting for each server is recommended. For example, this could be set to 25% for each of three servers on a system. Each server could also have a different value for this setting, as appropriate for the workload on that server.

Adding a the new server instance in the Integration Solutions ConsoleNow the Tivoli Storage Manager V6.1 instance is ready to associate within the ISC, and is currently running in the background. Log into the ISC with the user ID and password defined during the installation process, and then follow the next figures shown.


1. Start with Figure 17-10. which starts by expanding the Tivoli Storage Manager option in the left side panel.

Figure 17-10 Integrated Solutions Console: Select Tivoli Storage Manager

2. Then select the Manage Server option as shown in Figure 17-11.

Figure 17-11 Integrated Solutions Console: Manage Servers option


3. Next, use the Select Action drop down and choose Add Server Connection, as shown in Figure 17-12.

Figure 17-12 Choosing the Add a Server Connection

4. Next, type in the connection details for the new TSM1 instance, as shown in Figure 17-13.

Figure 17-13 Adding a server connection for server instance within the Integrated Solutions Console


5. After clicking OK, wait for the successful completion panel as shown in Figure 17-14. Then click the OK button once again.

Figure 17-14 Summary page after adding a server connection in the Integrated Solutions Console

6. Finally, for test and review of the server connection, click the TSM1 server link, as shown in Figure 17-15.

Figure 17-15 V6.1 Manage Servers panel in the Integrated Solutions Console interface


7. On the next panel, click the Database and Log option on the left side panel, as shown in Figure 17-16.

Figure 17-16 TSM1 server connection general panel

8. Lastly, you can observe the initial database size, with the preformatted log size, which was input during the dsmformat stage of the installation, as shown in Figure 17-17.

Figure 17-17 Database and recoverylog size shown in Tivoli Storage Manager V6.1

Autostart setup for Tivoli Storage Manager V6.1In the following steps we prepare the autostart setup:

1. To ensure that the TSM1 instance starts automatically after a system reboot, the following line must be inserted into the AIX /etc/inittab file, as shown in Example 17-42.

Example 17-42 Entry into the /etc/inittab to startup Tivoli Storage Manager V6.1 instance automatically

tsm1:2:once:/opt/tivoli/tsm/server/bin/rc.dsmserv -u tsm1 -i /home/tsm1 -q >/dev/console 2>&1


2. Next, to set up the autostart function for the Administrator Center, you must complete the following tasks.

a. Log in with the root user ID. b. Change to the /opt/tivoli/tsm/AC/products/tsm/bin directory. c. Run the following script: setTSMUnixLinks.sh

3. This script inserts a line in the /etc/inittab files as shown in Example 17-43.

Example 17-43 Entry into the /etc/inittab to startup V6.1 Admin Center service on AIX

IBMTSM:2:once:"/opt/tivoli/tsm"/AC/products/tsm/bin/rc.IBMTSM start >/dev/console 2>&1

17.5.3 Configuring using the dsmicfgx and X11 redirection

Following the software installation, we will now use the X11 redirection with the configuration wizard to start the local version of the wizard. The telnet session already has the export DISPLAY set for X11 redirection, as already explained in “Setup of X11 environment for non-graphical environments” on page 311.

1. Our first step is to pre-configure our AIX environment, as demonstrated in “Preparing the AIX server for Tivoli Storage Manager instances” on page 316. This step must be completed prior to invoking the configuration panel, because the configuration wizard will require all this detail to be input.

2. Next, invoke the dsmicfgx program in the /opt/tivoli/tsm/server/bin directory, within a telnet session, as shown in Example 17-44.

Example 17-44 dsmicfgx program invocation

# cd /opt/tivoli/tsm/server/bin# export DISPLAY=9.12.6.78:0.0# ./dsmicfgxPreparing to install...Extracting the JRE from the installer archive...Unpacking the JRE...Extracting the installation resources from the installer archive...Configuring the installer for this system's environment...



3. The Instance Configuration Wizard is launched. First, choose the language, as shown in Figure 17-18.

Figure 17-18 Choosing the language in the dsmicfgx panel

4. After clicking OK, the introduction panel is displayed as shown in Figure 17-19.

Figure 17-19 Instance Configuration Wizard Introduction

5. Click Next, and the instance user ID and password are requested. This panel with our response is shown in Figure 17-20.


Figure 17-20 Instance User ID specification

6. Click Next, then continue by supplying the path of the instance files (Figure 17-21).

Figure 17-21 Configuration wizard instance directory panel


7. Clicking Next, we progress to the database directories configuration panel, as shown in Figure 17-22.

Figure 17-22 Configuration wizard for the database directories.

Note: If you have not updated the permissions for your instance directories (chown -R tsm1.tsmsrvrs /tms1), you will receive an error, after which you then click OK, fix the permissions, and click Next to retry the operation.


8. Next, we select the recovery log directories, using the Choose button to select the predefined directories for these logs, with the completed panel shown in Figure 17-23.

Figure 17-23 Configuration wizard recovery log directory panel

Note: You must have your file system slightly larger than the 8 GB required for the recovery log, or this step might return an error.


9. After clicking Next, the server information panel appears, and we can verify that all the fields are as we require, as shown in Figure 17-24.

Figure 17-24 Server configuration information


10.Clicking Next, the following panel is for the administrator credentials.This refers to the Tivoli Storage Manager instance administrator, which is referenced when configuring the server connection within the administration center or directly connecting using the dsmadmc command. This panel is shown in Figure 17-25. The minimum password criteria of one number included is enforced by this panel.

Figure 17-25 Administrator Credentials window


11.After clicking Next, the following panel presented is for server communication. This panel includes IPv6, shared memory, and SSL communication options. In this example we are accepting the default, as shown in Figure 17-26.

Figure 17-26 Server Communication panel


12.Clicking Next, you are presented with the configuration summary panel, as shown in Figure 17-27.

Figure 17-27 Configuration Summary panel


13.After clicking Next, the configuration wizard begins; it will present any errors if found. An example of an error due to insufficient space for the database is shown in Figure 17-28.

Figure 17-28 Configure instance panel

17.6 Upgrading from Tivoli Storage Manager V6.1.0

After the base V6.1 level of software has been installed and configured, our next step will be the upgrade to the maintenance level of V6.1.2 (the most current level at the time of writing this book).

Installing update software using AIX install processThe update software can be obtained from the IBM ftp site:

ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance/server/v6r1/AIX/LATEST/

After downloading the latest software, uncompress and expand it into a temporary directory, as shown in Example 17-45.

Example 17-45 Tivoli Storage Manager code listing

# ls.toctivoli.tsm.devices.6.1.2.0.bfftivoli.tsm.devices.msg.en_US.6.1.2.0.bfftivoli.tsm.server.6.1.2.0.bfftivoli.tsm.server.license.6.1.2.0.bfftivoli.tsm.server.msg.en_US.6.1.2.0.bff


ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance/server/v6r1/AIX/LATEST/

Next, issue the AIX update_all command to install the updates, as shown in Example 17-46.

Example 17-46 smitty update_all

# smitty update_all

The resulting output of the installation is shown in Example 17-47. Much of the text has been removed to reduced the volume of output captured.

Example 17-47 AIX smitty update_all command example for applying V6.1.2 update

COMMAND STATUS

Command: running stdout: yes stderr: no

Before command completion, additional instructions may appear below.

geninstall -I "a -cgNqwXY -J" -Z -d . -f File 2>&1

Text removed....

+-----------------------------------------------------------------------------+ Summaries:+-----------------------------------------------------------------------------+

Installation Summary--------------------Name Level Part Event Result-------------------------------------------------------------------------------tivoli.tsm.server.msg.en_US 6.1.2.0 USR APPLY SUCCESStivoli.tsm.server.license.c 6.1.2.0 USR APPLY SUCCESStivoli.tsm.server 6.1.2.0 USR APPLY SUCCESStivoli.tsm.server 6.1.2.0 ROOT APPLY SUCCESStivoli.tsm.server.license.r 6.1.2.0 USR APPLY SUCCESS

17.7 Problem determination and recovery actions

In this section we show several queries and logs to use in should an error occur.

17.7.1 Database queries and validation

Example 17-48 demonstrates a query to view DB2 configuration.

Example 17-48 DB2 database snapshot query

cd /home/tsm1/sqllib/bindb2 => get snapshot for database on TSMDB1

Database Snapshot

Database name = TSMDB1Database path = /home/tsm1/tsm1/NODE0000/SQL00001/Input database alias = TSMDB1Database status = Active


Catalog database partition number = 0Catalog network node name =Operating system running at database server= AIX 64BITLocation of the database = LocalFirst database connect timestamp = 06/01/2009 12:44:05.254311Last reset timestamp =Last backup timestamp = 06/01/2009 12:41:33.000000Snapshot timestamp = 06/01/2009 13:59:45.841818

Number of automatic storage paths = 4Automatic storage path = /tsm1/dbdir001 Node number = 0 File system ID = 9223372238718238723 Storage path free space (bytes) = 2029142016 File system used space (bytes) = 118341632 File system total space (bytes) = 2147483648Automatic storage path = /tsm1/dbdir002 Node number = 0 File system ID = 9223372238718238724 Storage path free space (bytes) = 2029133824 File system used space (bytes) = 118349824 File system total space (bytes) = 2147483648Automatic storage path = /tsm1/dbdir003 Node number = 0 File system ID = 9223372238718238725 Storage path free space (bytes) = 2029129728 File system used space (bytes) = 118353920 File system total space (bytes) = 2147483648Automatic storage path = /tsm1/dbdir004 Node number = 0 File system ID = 9223372238718238726 Storage path free space (bytes) = 2029133824 File system used space (bytes) = 118349824 File system total space (bytes) = 2147483648

DB2 configuraton parms removed to reduce output ....

Lock list memory in use (Bytes) = 34816Deadlocks detected = 0Lock escalations = 0Exclusive lock escalations = 0Agents currently waiting on locks = 0Lock Timeouts = 0Number of indoubt transactions = 0

Buffer pool statistics removed to reduce output ...

Direct reads = 11352Direct writes = 3204Direct read requests = 1562Direct write requests = 534Direct reads elapsed time (ms) = 4617Direct write elapsed time (ms) = 5988Database files closed = 0


Log space available to the database (Bytes)= 4274752694Log space used by the database (Bytes) = 3437386Maximum secondary log space used (Bytes) = 0Maximum total log space used (Bytes) = 3455911Secondary logs allocated currently = 0Log pages read = 0Log read time (sec.ns) = 0.000000004Log pages written = 1978Log write time (sec.ns) = 33.000000004Number write log IOs = 1788Number read log IOs = 0Number partial page log IOs = 864Number log buffer full = 0Log data found in buffer = 0Appl id holding the oldest transaction = 8Log to be redone for recovery (Bytes) = 3413557Log accounted for by dirty pages (Bytes) = 3413557

Memory usage for database:

Node number = 0 Memory Pool Type = Backup/Restore/Util Heap Current size (bytes) = 65536 High water mark (bytes) = 65536 Configured size (bytes) = 213581824

Node number = 0 Memory Pool Type = Package Cache Heap Current size (bytes) = 6881280 High water mark (bytes) = 8454144 Configured size (bytes) = 7864320

Memory Pool Type = Other Memory Current size (bytes) = 196608 High water mark (bytes) = 196608 Configured size (bytes) = 20971520

Node number = 0 Memory Pool Type = Catalog Cache Heap Current size (bytes) = 1048576 High water mark (bytes) = 1048576 Configured size (bytes) = 4294967296

Node number = 0 Memory Pool Type = Buffer Pool Heap Secondary ID = 4 Current size (bytes) = 101580800 High water mark (bytes) = 247398400 Configured size (bytes) = 4294967296

Removal multiple Buffer Pool Heap stanza entries.....

Node number = 0 Memory Pool Type = Buffer Pool Heap


Secondary ID = System 4k buffer pool Current size (bytes) = 393216 High water mark (bytes) = 393216 Configured size (bytes) = 4294967296

Node number = 0 Memory Pool Type = Shared Sort Heap Current size (bytes) = 65536 High water mark (bytes) = 1048576 Configured size (bytes) = 36831232

Node number = 0 Memory Pool Type = Lock Manager Heap Current size (bytes) = 11534336 High water mark (bytes) = 13762560 Configured size (bytes) = 13828096

Node number = 0 Memory Pool Type = Database Heap Current size (bytes) = 37093376 High water mark (bytes) = 37093376 Configured size (bytes) = 50266112

Node number = 0 Memory Pool Type = Application Heap Secondary ID = 557 Current size (bytes) = 65536 High water mark (bytes) = 65536 Configured size (bytes) = 1048576

Removal of multiple Application Heap stanza entries .....

Node number = 0 Memory Pool Type = Applications Shared Heap Current size (bytes) = 1835008 High water mark (bytes) = 1835008 Configured size (bytes) = 81920000

db2 => quitDB20000I The QUIT command completed successfully.

17.7.2 Logs

This section lists logs that will be useful in product status and problem determination:

� Zip file containing all logs is located in:

/var/tivoli/tsm/logs.zip

� Main log file is located in:

<install_location>/coi/plan/MachinePlan_localhost/logs/MachinePlan_localhost_[INSTALL_0414_22.35].log

� DB2 logs are located in:

<install_location>/coi/plan/MachinePlan_localhost/00002_DB2_9.5/DB2_9.5.log<install_location>/coi/plan/tmp


� Administration Center logs are located in:

<install_location>/coi/plan/MachinePlan_localhost/00003_TSM_AdminCenter/logs:addJVMPropertyTCR.logaddSharedLibTCR.logaddUserRole.logdeployEarTCR.logdeployWarTCR.logdeployWarTSM.loginstall.propertiesprocessReq-stderr.logprocessReq-stdout.xmlsetupDatasourceTCR.logsetupTCR.logstartServer.logstopServer.log

� Deployment Engine logs are located in:

/usr/ibm/common/acsi/logs/rootDE_Install.logacu_de.logde_cbe.logde_msg.logde_trace.log

17.7.3 Completely removing the Deployment Engine if required

During an installation or testing scenario, there might be some reason that you would need to remove the Deployment Engine (DE). Avoid doing this unless it is your last option. However, if necessary, here are some processes to follow to clean up on AIX.

� Remove the /var/ibm/common directory.

� Remove the /usr/ibm/common directory.

� Clean up the /tmp directory, by removing the acu_de.log file.

� Remove the /tmp/<username> directory, where <username> is the id of the user that installed DE (for example, “root”).

� Remove all DE references from the /etc/inittab system file. The DE entries should be delineated by “#Begin AC Solution Install block” and “#End AC Solution Install block”. Remove all of the text between those delimiters, and the delimiting text, as well.

17.8 Backup considerations for production on V6.1

After the installation process as documented, there are backup considerations to observe.

Did you remember to set up a database backup methodology?During our setup of the lab environment and many Tivoli Storage Manager servers, one instance seemed to have been forgotten. We began generating some moderate client load overnight, and in the morning found the server instance offline. In this situation, we would normally bring the instance up in the foreground to verify its state, and the remainder we would like to share as a sequence of events.


As demonstrated in Example 17-49, we start the Tivoli Storage Manager V6.1 server in the foreground and immediately discover a point of failure that we can work with.

Example 17-49 Database backup information

$ /opt/tivoli/tsm/server/bin/rc.dsmserv -u tsm1 -i /home/tsm1ANR7800I DSMSERV generated at 11:52:37 on Jun 4 2009.




ANR7801I Subsystem process ID is 458996.ANR0900I Processing options file /home/tsm1/dsmserv.opt.ANR7811I Using instance directory /home/tsm1.ANR4726I The ICC support module has been loaded.ANR0990I Server restart-recovery in progress.ANR0152I Database manager successfully started.ANR0130E rdbdb.c(1315): Server LOG space exhausted.

In Tivoli Storage Manager V5.5, an extend log command would be required, provided that you were not already at the 13 GB limit. However, in V6.1, we have a different recovery log process, which helps to understand in order to correct this current system down condition.

There are four log functions with our new Tivoli Storage Manager and DB2 environment, so which one might be the root cause in this situation? The space situation is shown in Example 17-50.

Example 17-50 Vermont-tsm1 file system state after the log exhausted error.

$ df -k/dev/tsmbinlv 2490368 194964 93% 26719 37% /opt/tivoli/tsm/dev/dbdir1lv 2097152 293824 86% 44 1% /tsm1/dbdir1/dev/dbdir2lv 2097152 293812 86% 44 1% /tsm1/dbdir2/dev/dbdir3lv 2097152 293816 86% 44 1% /tsm1/dbdir3/dev/dbdir4lv 2097152 293812 86% 44 1% /tsm1/dbdir4/dev/actlog 4259840 504060 87% 14 1% /tsm1/activelog/dev/actlogm 4259840 504060 87% 12 1% /tsm1/activelogm/dev/archlog 8388608 40180 100% 22 1% /tsm1/archlog/dev/archlogf 4194304 495100 89% 24 1% /tsm1/archlogf

As seen, none of the file systems that hold logs have 512 MB of available space, thus all would be considered full to DB2. So, which one do we need to add file system space to in order to successfully restart Tivoli Storage Manager, then perform a full database backup?

The answer to this question is the archlog (archive log), and this is because the recovery log size was set during the installation process, and is essentially fixed at this point. So if we add space to the archive log, which is the “overflow” log location, then when we start up Tivoli Storage Manager and DB2, we have room to process additional transactions, long enough to complete the full database backup.


Next, we increase the JFS2 file system for the archive log as demonstrated in Example 17-51.

Example 17-51 AIX command chfs -a which is used to expand the JFS2 file system

# chfs -a size=19777216 /tsm1/archlogFilesystem size changed to 19791872

Now, we have more than 512 MB of space available on the /tsm1/archlog file system, and we restart the Tivoli Storage Manager V6.1 server in the foreground as before, then configure for a database backup to file, which will clear the logs. It will take two full backups to clear out the archive logs. Prior to the startup in the foreground, we add three statements into the /home/tsm1/dsmserv.opt file to ensure reclamation, expire inventory, and client schedules (see Example 17-52).

Example 17-52 dsmserv.opt additions to ensure no database and recovery log activity will run

EXPINTERVAL 0NOMIGRRECLDISABLESCHEDS YES

Now, we are ready to start the foreground Tivoli Storage Manager server V6.1, as shown in Example 17-53.

Example 17-53 Foreground V6.1 startup after correcting the log exhaustion problem

TSM:VERMONT-TSM1>define devc dbb_file devt=file dir=/code/dbb_backupsANR2017I Administrator SERVER_CONSOLE issued command: DEFINE DEVCLASS dbb_filedevt=file dir=/code/dbb_backupsANR2203I Device class DBB_FILE defined.

TSM:VERMONT-TSM1>set dbrecovery dbb_fileANR2017I Administrator SERVER_CONSOLE issued command: SET DBRECOVERY dbb_fileANR2782I SET DBRECOVERY completed successfully and device class for automaticDB backup is set to DBB_FILE.

TSM:VERMONT-TSM1>ba db type=full devc=dbb_file scratch=yesANR2017I Administrator SERVER_CONSOLE issued command: BACKUP DB type=fulldevc=dbb_file scratch=yesANR4559I Backup DB is in progress.ANR0984I Process 2 for DATABASE BACKUP started in the BACKGROUND at 11:47:17.ANR2280I Full database backup started as process 2.

TSM:VERMONT-TSM1>ANR0406I Session 1 started for node $$_TSMDBMGR_$$ (DB2/AIX64) (Tcp/Iploopback(32834)).ANR8340I FILE volume /code/dbb_backups/45437242.DBV mounted.ANR0511I Session 1 opened output volume /code/dbb_backups/45437242.DBV.ANR1360I Output volume /code/dbb_backups/45437242.DBV opened (sequence number 1).ANR8341I End-of-volume reached for FILE volume /code/dbb_backups/45437242.DBV.ANR1362I Output volume /code/dbb_backups/45437242.DBV closed (full).ANR0514I Session 1 closed volume /code/dbb_backups/45437242.DBV.ANR8340I FILE volume /code/dbb_backups/45437299.DBV mounted.ANR0511I Session 1 opened output volume /code/dbb_backups/45437299.DBV.ANR1360I Output volume /code/dbb_backups/45437299.DBV opened (sequence number 2).


ANR8341I End-of-volume reached for FILE volume /code/dbb_backups/45437299.DBV.ANR1362I Output volume /code/dbb_backups/45437299.DBV closed (full).ANR0514I Session 1 closed volume /code/dbb_backups/45437299.DBV.ANR8340I FILE volume /code/dbb_backups/45437353.DBV mounted.ANR0511I Session 1 opened output volume /code/dbb_backups/45437353.DBV.ANR1360I Output volume /code/dbb_backups/45437353.DBV opened (sequence number 3).ANR8341I End-of-volume reached for FILE volume /code/dbb_backups/45437353.DBV.ANR1362I Output volume /code/dbb_backups/45437353.DBV closed (full).ANR0514I Session 1 closed volume /code/dbb_backups/45437353.DBV.ANR8340I FILE volume /code/dbb_backups/45437411.DBV mounted.ANR0511I Session 1 opened output volume /code/dbb_backups/45437411.DBV.ANR1360I Output volume /code/dbb_backups/45437411.DBV opened (sequence number 4).ANR1361I Output volume /code/dbb_backups/45437411.DBV closed.ANR0514I Session 1 closed volume /code/dbb_backups/45437411.DBV.ANR0403I Session 1 ended for node $$_TSMDBMGR_$$ (DB2/AIX64).ANR0406I Session 2 started for node $$_TSMDBMGR_$$ (DB2/AIX64) (Tcp/Ip loopback(32835)).ANR8340I FILE volume /code/dbb_backups/45437452.DBV mounted.ANR0511I Session 2 opened output volume /code/dbb_backups/45437452.DBV.ANR1360I Output volume /code/dbb_backups/45437452.DBV opened (sequence number 1).ANR1361I Output volume /code/dbb_backups/45437452.DBV closed.ANR0514I Session 2 closed volume /code/dbb_backups/45437452.DBV.ANR0403I Session 2 ended for node $$_TSMDBMGR_$$ (DB2/AIX64).ANR4550I Full database backup (process 2) completed.ANR0985I Process 2 for DATABASE BACKUP running in the BACKGROUND completed with completion state SUCCESS at 11:50:54.

ba db devc=dbb_file type=full scratch=yesANR2017I Administrator SERVER_CONSOLE issued command: BACKUP DB devc=dbb_filetype=full scratch=yesANR4559I Backup DB is in progress.ANR0984I Process 1 for DATABASE BACKUP started in the BACKGROUND at 14:16:48.ANR2280I Full database backup started as process 1.TSM:VERMONT-TSM1>ANR0406I Session 1 started for node $$_TSMDBMGR_$$ (DB2/AIX64) (Tcp/Iploopback(32839)).ANR8340I FILE volume /code/dbb_backups/45446210.DBV mounted.ANR0511I Session 1 opened output volume /code/dbb_backups/45446210.DBV.ANR1360I Output volume /code/dbb_backups/45446210.DBV opened (sequence number1).ANR8341I End-of-volume reached for FILE volume /code/dbb_backups/45446210.DBV.ANR1362I Output volume /code/dbb_backups/45446210.DBV closed (full).ANR0514I Session 1 closed volume /code/dbb_backups/45446210.DBV.ANR8340I FILE volume /code/dbb_backups/45446268.DBV mounted.ANR0511I Session 1 opened output volume /code/dbb_backups/45446268.DBV.ANR1360I Output volume /code/dbb_backups/45446268.DBV opened (sequence number2).ANR8341I End-of-volume reached for FILE volume /code/dbb_backups/45446268.DBV.ANR1362I Output volume /code/dbb_backups/45446268.DBV closed (full).ANR0514I Session 1 closed volume /code/dbb_backups/45446268.DBV.ANR8340I FILE volume /code/dbb_backups/45446321.DBV mounted.ANR0511I Session 1 opened output volume /code/dbb_backups/45446321.DBV.ANR1360I Output volume /code/dbb_backups/45446321.DBV opened (sequence number3).ANR8341I End-of-volume reached for FILE volume /code/dbb_backups/45446321.DBV.


ANR1362I Output volume /code/dbb_backups/45446321.DBV closed (full).ANR0514I Session 1 closed volume /code/dbb_backups/45446321.DBV.ANR8340I FILE volume /code/dbb_backups/45446377.DBV mounted.ANR0511I Session 1 opened output volume /code/dbb_backups/45446377.DBV.ANR1360I Output volume /code/dbb_backups/45446377.DBV opened (sequence number4).ANR1361I Output volume /code/dbb_backups/45446377.DBV closed.ANR0514I Session 1 closed volume /code/dbb_backups/45446377.DBV.ANR0403I Session 1 ended for node $$_TSMDBMGR_$$ (DB2/AIX64).ANR0406I Session 2 started for node $$_TSMDBMGR_$$ (DB2/AIX64) (Tcp/Iploopback(32840)).ANR8340I FILE volume /code/dbb_backups/45446428.DBV mounted.ANR0511I Session 2 opened output volume /code/dbb_backups/45446428.DBV.ANR1360I Output volume /code/dbb_backups/45446428.DBV opened (sequence number1).ANR1361I Output volume /code/dbb_backups/45446428.DBV closed.ANR0514I Session 2 closed volume /code/dbb_backups/45446428.DBV.ANR0403I Session 2 ended for node $$_TSMDBMGR_$$ (DB2/AIX64).ANR4550I Full database backup (process 1) completed.ANR0985I Process 1 for DATABASE BACKUP running in the BACKGROUND completed withcompletion state SUCCESS at 14:20:30.ba volhistoryANR2017I Administrator SERVER_CONSOLE issued command: BACKUP VOLHISTORYANR2463I BACKUP VOLHISTORY: Server sequential volume history information waswritten to all configured history files.

We have now worked around our exhausted log issue, with a few points the we would like to further emphasize:

1. Ensure that your backup methodology and frequency aligns with your rate of new and update activity.

2. Ensure that you position the database and logging file systems on technology that allows simple expansion.

3. Plan for archive log and archive failover growth space.

4. Beyond these directly related points, always ensure that your volume history file is backed up following your database backups.


Chapter 18. Installation of Tivoli Storage Manager V6.1 on Windows

In this chapter we present an overview of the various components of Tivoli Storage Manager V6.1 Server. We show a step-by-step installation of a Tivoli Storage Manager V6.1 Server on the Windows platform.

A successful implementation of IBM Tivoli Storage Manager benefits enormously from planning prior to attempting to set up the environment. We assume a basic knowledge of IBM Tivoli Storage Manager, which you can gain by reading the companion Redbooks publication, IBM Tivoli Storage Management Concepts, SG24-4877.

If you have not already done so, stop and take the time to read this publication. You will gain a better understanding of this product and be more successful if you take the time to plan and design your total solution before you begin the installation.

18


18.1 IBM Tivoli Storage Manager planning for installation

In this chapter we describe the installation of a Tivoli Storage Manager V6.1 server on a Windows system. This includes the necessary preparation and configuration to install V6.1 on a new system. We use and document the different installation techniques available and walk you through the installation tasks.

Our intent here is to give you an understanding of what the requirements are to install Tivoli Storage Manager V6.1 using the DB2 database.

We first cover what you get in this release, as well as what you do not get that you might have been expecting. Then we go through the steps in preparation, regarding items that you need to think about when you do the installation.

Let us now move forward to discuss the differences in the Tivoli Storage Manager V6.1 installation.

What you should know firstBefore you install IBM Tivoli Storage Manager for the first time, familiarize yourself with the following items:

� The Windows operating system that is running on the Tivoli Storage Manager server workstation and server

� The operating systems that are running on any Tivoli Storage Manager client workstations.

� Storage devices that will be available to Tivoli Storage Manager

� Communication protocols that are installed on your clients and servers

� Any special system configurations you plan to use, such as Microsoft Active Directory or Microsoft Cluster Server (MSCS)

Users who are experienced DB2 administrators can choose to perform advanced SQL queries and use DB2 tools to monitor the database.

However, do not use DB2 tools to change DB2 configuration settings from those that are that are preset by Tivoli Storage Manager, or alter the DB2 environment for Tivoli Storage Manager in other ways, such as with other products. The Tivoli Storage Manager V6.1 server has been built and tested extensively using the Data Definition Language (DDL) and database configuration that Tivoli Storage Manager deploys.

18.2 System requirements for Windows

Next, we provide an overview of the hardware and software requirements for installing and configuring Tivoli Storage Manager V6.1. For detailed information, see the Web site:


Restriction: You cannot install and run the Version 6.1 server on a system that already has DB2 installed on it, whether DB2 was installed by itself or as part of some other application. The Version 6.1 server requires the installation and use of the DB2 version that is packaged with the Version 6.1 server. No other version of DB2 can exist on the system.



18.2.1 Hardware

Table 18-1 describes the hardware requirements for your Windows system. For further details, refer to the Tivoli Storage manager for Windows, Installation Guide, Capacity Planning to help with your disk planning.

Check that the system memory meets the server requirements. If you plan to run multiple Tivoli Storage Manager instances of the V6.1 server on the system, each Tivoli Storage Manager Instance requires the memory listed for one server. Multiply the memory for one server by the number of Tivoli Storage Manager Instances planned for the system.

Table 18-1 Hardware requirements for Tivoli Storage Manager V6.1 for Windows

18.2.2 Software

Table 18-2 describes the minimum software requirements for Tivoli Storage Manager V6.1 running on a Windows system.

Table 18-2 Software requirements for Tivoli Storage Manager V6 for Windows


Hardware Intel Pentium compatible processor or multiprocessor-based computer

Disk space At least 3 GB of free disk storage (for a default installation) Plan for more space for the database logs:� 200 MB partition size in the C:\ drive� 200 MB temporary directory space� 300 MB in the Tivoli Storage Manager Instance directory

Additional disk space is required for database and log files. The server is installed in the drive you select, and the database and logs can be installed in another drive

Memory At least 2 GB. A minimum of 4 GB for production servers. We recommend 8 GB, for normality loaded servers

Note: We strongly recommend for Windows 32 bit that you migrate into Windows 64 bit.


Operating system One of the following operating systems:

� Microsoft Windows Server 2003: Standard, Enterprise, or Datacenter Edition

� Microsoft Windows Server 2003: Standard, Enterprise, or Datacenter x64 Edition (64-bit)

� Microsoft Windows Storage Server 2003� Microsoft Windows Storage Server 2003 x64� Microsoft Windows Server 2008: Standard, Enterprise, or

Datacenter Edition� Microsoft Windows Server 2008: Standard, Enterprise, or

Datacenter x64 Edition (64-bit)

Communication protocol At least one of the following communication protocols (installed by default with the current Windows operating systems): � Named Pipes� TCP/IP Version 4 or Version 6� Shared Memory

Chapter 18. Installation of Tivoli Storage Manager V6.1 on Windows 355

18.3 Planning for space for the V6.1 server

Planning for Tivoli Storage Manager includes determining the number of client nodes to be managed by the Tivoli Storage Manager server, the backup and recovery needs of those clients, and the number and general size of client data files.

Estimating database space requirementsThe size of the database depends on the number of client files to be stored and the method by which the server manages them. If you can estimate the maximum number of files that might be in server storage at any time, you can estimate the database size from the following information:




Detailed planning information can be found in “Database space requirements” on page 258 and Chapter 5, “IBM Tivoli Storage Manager database” on page 41.

18.4 Tivoli Storage Manager V6.1 components

The package that comes with Tivoli Storage Manager V6.1 consists of several components. Here we list the components and a high level overview of each component:

� Composite Offering Installer:

Composite Offering Installer (COI) infrastructure (COI) is a technology that was created by the Autonomic Computing Self-Configuration and Deployment offering team and was designed to assist IBM development teams in coordinating the deployment (installation and configuration) of a suite of products and components in both single-machine and multi-machine environments.

Web browser A Web browser to log in and use the console. The Web browser can be installed on the same or a separate system. The following browsers are supported:� Microsoft Internet Explorer 6.0 SP1� Microsoft Internet Explorer 7.0� FireFox 1.5� FireFox 2.0� FireFox 3.0� Mozilla 1.7.8Your browser must support the server code page. If your browser does not support the server code page, the windows might be unreadable. If your browser meets these requirements but does not correctly display a Tivoli Storage Manager Web-based interface, consider trying a different browser.



� The Deployment Engine:

The Deployment Engine is a collection of common software packaging, deployment, and configuration technologies from IBM Tivoli. The common technologies provide a standard way for application developers to package their software for deployment to a number of popular operating system and application environments. In addition, Deployment Engine can manage subsequent functionality and maintenance updates on the deployed software as performed by the administrator.

� InstallAnywhere:

InstallAnywhere is an application that creates wizard installers for multiple platforms where the options are shown in the installer.

� Payloads:

Tivoli Storage Manager native packages for server, license, device driver, storage agent, languages, and client application programming interfaces (APIs). DB2, WebSphere® Application Server), Integrated Solution Console (ISC), and the Administration Center Web Application Archive (WAR) file.

18.4.1 Package names

The package names in Tivoli Storage Manager Release V6.1 are 6.1.0.0-TIV-TSMALL-WindowsI32.exe, and 6.1.0.0-TIV-TSMALL-WindowsX64.exe.

The fix packs for Tivoli Storage Manager are available on the ftp site:

ftp://ftp.software.ibm.com/storage/tivoli-storage-management/

18.4.2 Package extraction

To extract the package, double-click the *.exe files or execute 6.1.0.0-TIV-TSMALL-<PF>.exe on the command line.

After you have extracted the package, the structure consists of the Composite Offering Installer, Deployment Engine, PostFailureTask.xml, READme.htm, and install.exe files.

18.4.3 Installing components

The Tivoli Storage Manager server and client API, languages, licenses, device driver, storage agent, and Administration Center comprise the Tivoli Storage Manager components.

You can install the following components with Tivoli Storage Manager Version 6.1:

� Tivoli Storage Manager server� Tivoli Storage Manager server languages� Tivoli Storage Manager licenses� Tivoli Storage Manager device driver� Tivoli Storage Manager storage agent� Tivoli Storage Manager Administration Center� Tivoli Storage Manager reporting and monitoring

It is advisable to install Tivoli Storage Manager Administration Center and Tivoli Storage Manager reporting and monitoring on the same server.



Table 18-3 describes all of these components in detail.

Table 18-3 Tivoli Storage Manager components

18.5 Installing the Tivoli Storage Manager components

Install the Tivoli Storage Manager server components on the computer that manages the storage devices and the Tivoli Storage Manager client code on every workstation or server that will transfer data to Tivoli Storage Manager server-managed storage.

Note: The current restriction that is documented in the Tivoli Storage Manager publications for the installation of other DB2 versions (or applications that deploy and use DB2) on the same Windows system as a Tivoli Storage Manager V6 server is still in place and not affected by the support discussed here. Similar support for Windows systems is currently being evaluated. Assuming that the testing and evaluation do not uncover any issues to prevent it, the target is to remove this restriction with a follow-on TECHNOTE towards the end of third quarter of 2009 or in fourth quarter of 2009.

Tivoli Storage Manager component

Description Additional information

Server (required) This component includes the Tivoli Storage Manager database, management console, client API, and tools to help you configure and manage Tivoli Storage Manager.

Refer to the Tivoli Storage Manager server overview in the Administrator’s Guide. Refer to “Other publications” on page 627 for the exact book title and order number for your platform.

Language pack (optional) Each language pack (one for each language) contains language-specific information for the server and the management console.

Licenses (required) This component includes support for all Tivoli Storage Manager licensed features. After you install this package, you must configure the licenses that you have purchased.

Refer to the chapter on managing server operations in the Administrator’s Guide Refer to “Other publications” on page 627 for the exact book title and order number for your platform.

Device driver (optional) This component extends Tivoli Storage Manager media management capability. The Tivoli Storage Manager device driver is generally preferred for use with the Tivoli Storage Manager server. It is required for use with automated library devices and optical disk devices, unless you are using Windows Removable Storage Manager to manage the media.

Refer to the chapter on adding devices in the Administrator’s Guide. A list of devices supported by this driver is available from the Tivoli Storage Manager Web site: http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html



Tivoli Storage Manager server maintenance releases, client software, and publications are available from the Tivoli Storage Manager Web site at:


Tivoli Storage Manager fix packs are available on the ftp site:


Using the Tivoli Storage Manager installation software, you can install the following components:

� Tivoli Storage Manager server� Tivoli Storage Manager server languages� Tivoli Storage Manager license� Tivoli Storage Manager device driver� Tivoli Storage Manager storage agent� Tivoli Storage Manager Administration Center

You can use the following steps to install the Tivoli Storage Manager components:

1. If you are installing the products using the Tivoli Storage Manager DVD, complete the following steps:

a. Log on as an administrator. Insert the Tivoli Storage Manager server DVD.

b. If autorun is on, the DVD browser window opens.

c. If autorun is off, use Windows Explorer to go to the DVD drive, double-click the DVD, and then double-click install.exe.

d. To access Windows Explorer, go to Start → Programs → Accessories or right-click the Start button. The Tivoli Storage Manager server DVD browser window opens.

2. If you downloaded the executable file from Passport Advantage, complete the following steps:

a. Change to the directory where you placed the executable file.

b. Either double-click the following executable file or enter the following command from the Windows command line to extract the installation files:

- 6.1.0.0-TIV-TSMALL-platform.exe

Where platform denotes the operating system.

The extracted files will go into your current directory.

There are three basic ways to install Tivoli Storage Manager. We strongly recommend the use of the Wizard, which will do all the work for you:

� Installation wizard: See 18.6, “Installation wizard installation” on page 360.

� Command-line console wizard: See “Command-line console wizard” on page 370.

� Silent mode: See “Silent mode installation” on page 374.

Note: We highly recommend that you read the readme.first file to see the changes in the Tivoli Storage Manager version that you are about to install, the hardware and software prerequisites, and any additional installation steps that might be needed.

Note: The Tivoli Storage Manager client Application Programming Interface (API) is automatically installed when you select the server component.




18.6 Installation wizard installation

Here we show you, step by step, the Tivoli Storage Manager installation and configuration, and provide images of the GUI installation wizard interface.

The wizard will do the majority of the steps for you:

1. First select the language for your installation as shown in Figure 18-1. Click OK to continue.

Figure 18-1 Select a language


2. The Welcome panel is shown in Figure 18-2. Review the information and click Next to continue.

Figure 18-2 Welcome panel


3. Next, review the Software License Agreement. You must accept the license agreement to proceed. Select I accept both the IBM and non-IBM terms (see Figure 18-3). Click Next to continue.

Figure 18-3 Software License Agreement


4. The next step is to choose the installation folder. The path is, by default:

C:\Program File\Tivoli\TSM

Click Next to proceed (see Figure 18-4).

Figure 18-4 Choose Install Folder.

Here we select the components to install. There is no default, so you must make a selection or you will receive an error message and be returned to the components page. If you select the Administration Center component, you are prompted for a user name and password. You will use these later to log onto the Integrated Solutions Console and Administration Center.

Note: If you previously installed a server, ensure that you select the same directory when you install a language pack, license, or device driver. If you previously installed a storage agent, ensure that you select the same directory if you return to install a device driver. A server and a storage agent cannot be installed on the same workstation.


5. We selected the Tivoli Storage Manager Server and License components as shown in Figure 18-5. Click Next to proceed.

Figure 18-5 Select Components to install

The DB2 Version 9.5 is installed during the Tivoli Storage Manager server installation. You are prompted to create and confirm a password. Defaults are provided for the DB2 user name and database name.


6. The password must contain an @ or # character if we are installing on Windows Server 2008. An empty database instance called DB2TSM is created during the installation. This DB2TSM database instance is not used by Tivoli Storage Manager (see Figure 18-6). Click Next to continue.

Figure 18-6 Specify Component Settings


7. The install wizard now configures the IBM Autonomic Deployment Engine on the local machine as shown in Figure 18-7. Click Next to proceed.

Figure 18-7 Deployment Engine Initialization


8. Figure 18-8 shows the summary of the Pre-Installation tasks. You can see which components you choose to install, where you have defined the instance server1 folder and also the disk space information for the installation target. Click Next to proceed with the Tivoli Storage Manager installation.

Figure 18-8 Deployment Engine Installation: Pre-Installation Summary


9. Figure 18-9 shows the Tivoli Storage Manager installation progress, and the V6.1 Server is in the install phase.

Figure 18-9 Installing the Tivoli Storage Manager


10.Figure 18-10 shows how the Tivoli Storage Manager installation completed:

a. At the end of the installation, a message is displayed on the summary page that Tivoli Storage Manager was successfully installed, and a summary is provided.

b. If there were any errors during the installation, another summary page lists the errors and directs you to an error log file. Fix the errors before continuing.

The installation log is stored in the location of the directory that was chosen for installation. Look for the files, log.txt and logs.zip. For details, see: C:\Program Files\Tivoli\TSM\log.txt.

Click Next to proceed.

Figure 18-10 Installation of the Tivoli Storage Manager is completed

11.Here we continue to either configure a new server instance or upgrade an existing server instance. Choose one of the following methods:

a. To configure a new server instance:

• Log in as an administrator and open the local new-instance wizard, dsmicfgx, located in the server installation directory.

• Log in to a Version 6.1 Tivoli Storage Manager Administration Center and start the Create New Instance wizard. Configure the new instance manually. See the Tivoli Storage Manager Information Center, or the IBM Tivoli Storage Manager for Windows Installation Guide V6.1, GC23-9785.

b. To upgrade an existing server instance:

• Log in as an administrator and start the upgrade wizard, dsmupgdx.exe file, located in the server installation directory.

• You can also upgrade a server manually. See the Tivoli Storage Manager Information Center, or the IBM Tivoli Storage Manager Server Upgrade Guide, SC23-9554.


For more information about any of these tasks, see the Tivoli Storage Manager Information Center at:


18.7 Command-line console wizard

Here we show how to install the Tivoli Storage Manager using the console installation wizard. This is the second method of installing Tivoli Storage Manager. Complete the following steps:

1. From the directory where you have downloaded the install package to submit, enter the following commands:

a. To start the wizard without saving your responses, enter the following command:

install.exe -i console

b. To start the wizard and save your responses, enter the following command, and specify the -r option:

install.exe -i console -r C:\response.rsp

2. Select the language for your installation and follow the prompts. Select the components that you want to install (server, languages, licenses, device driver, storage agent, and Administration Center). There is no default, so you must make a selection or you will receive an error message.

Next, we show you a basic Tivoli Storage Manager default installation and configuration and provide images of the Console Mode wizard interface.

From the directory where you have downloaded the install package, submit install.exe -i console to start the installation. Example 18-1 shows the starting panel where we have to choose the appropriate locale for the installation.

Example 18-1 Here we choose the locale language

Choose Locale...----------------

1- Deutsch 2- English 3- Español 4- Français 5- Italiano 6- Português (Brasil)

CHOOSE LOCALE BY NUMBER: 2

Example 18-2 shows the Welcome panel. Press Enter to move to the next panel.

Example 18-2 Windows Command Line Installation: Welcome panel

Tivoli Storage Manager (created with InstallAnywhere by Macrovision)-------------------------------------------------------------------------------

===============================================================================Tivoli Storage Manager Install



WelcomeTivoli Storage Manager 6.1

Licensed Materials - Property of IBM Corp. (c) IBM Corporation and other(s)1993, 2008. All rights reserved. US Government Users Restricted Rights --Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBMCorp.

It is strongly recommended that you quit all programs before continuing withthis installation.


The next step will be to review the Software License Agreement, You must accept the license agreement to proceed. Enter 1 as shown in Example 18-3.

Example 18-3 Windows Command Line Installation: Review License Information

International Program License Agreement

Part 1 - General Terms

BY DOWNLOADING, INSTALLING, COPYING, ACCESSING, OR USING THE PROGRAM YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ACCEPTING THESE TERMS ON BEHALF OF ANOTHER PERSON OR A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT AND WARRANT THAT YOU HAVE FULL AUTHORITY TO BIND THAT PERSON, COMPANY, OR LEGAL ENTITY TO THESE TERMS. IF YOU DO NOT AGREE TO THESE TERMS,

- DO NOT DOWNLOAD, INSTALL, COPY, ACCESS, OR USE THE PROGRAM; AND

- PROMPTLY RETURN THE PROGRAM AND PROOF OF ENTITLEMENT TO THE PARTY FROM WHOM YOU ACQUIRED IT TO OBTAIN A REFUND OF THE AMOUNT YOU PAID. IF YOU DOWNLOADED THE PROGRAM, CONTACT THE PARTY FROM WHOM YOU ACQUIRED IT.

Press Enter to continue viewing the license agreement, or enter "1" to accept the agreement, "2" to decline it, "3" to print it, "4" to read non-IBM terms, or "99" to go back to the previous screen.: 1

Here we decide to install the Tivoli Storage Manager Server and the License components in the default folder. Example 18-4 shows the related steps.

Example 18-4 Windows Command Line Installation: Install Folder and Component Selection

Choose Install Folder---------------------Where would you like to install?

Default Install Folder: C:\Program Files\Tivoli\TSM

ENTER AN ABSOLUTE PATH, OR PRESS <ENTER> TO ACCEPT THE DEFAULT :===============================================================================


Component Selection-------------------

Select the components to install.

1- Tivoli Storage Manager Server 2- Tivoli Storage Manager Server Languages 3- Tivoli Storage Manager License 4- Tivoli Storage Manager Device Driver 5- Tivoli Storage Manager Storage Agent 6- Tivoli Storage Manager Administration Center

ENTER A COMMA-SEPARATED LIST OF NUMBERS REPRESENTING THE DESIRED CHOICES, OR PRESS <ENTER> TO ACCEPT THE DEFAULT: 1,3

Example 18-5 shows the parameters to specify during database server instance creation. We choose to use the default user ID, db2user1, and the default database name of DB2. For the password, use either the Tivoli Storage Manager DB2 administrative -user ID and password, or a new user ID and password that you create now.

Example 18-5 Windows Command Line Installation: Create database server instance

DB2 Enterprise Server Edition

Enter the following information to create a DB2 database for your server instance. Use either the Tivoli Storage Manager DB2 administrative-user ID and password, or a new user ID and password that you create now.

DB2 administrative-user ID: (DEFAULT: db2user1):

===============================================================================

DB2 Password::*********

===============================================================================

Verify Password::*********

Database name: (DEFAULT: DB2):

Example 18-6 shows the messages submitted during deployment engine initialization. For easier readability, we removed some lines. After the engine is initialized, we press Enter to move on with the installation.

Example 18-6 Windows Command Line Installation: Deployment Engine Initialization

Deployment Engine Initialization--------------------------------Please Wait..completed: 1 ; total: 19..lines removed..completed: 19 ; total: 19Completed.


Pre-Installation Summary:

Please Review the Following Before Continuing:Product Name: Tivoli Storage ManagerInstall Folder: C:\Program Files\Tivoli\TSMComponents: TSM Server,DB2 9.5,TSM Client API,TSM License

Disk Space Information (for Installation Target): Required: 1 363 977 792 bytes Available: 5 314 523 136 bytes


Next you will see a message indicating that the install is progressing and finally complete (see Example 18-7). You are provided a summary of the components that were installed.

Example 18-7 Windows Command Line Installation

Installing...

[==================|==================|==================|==================] [------------------|------------------|------------------|------------------]

===============================================================================Installation Complete---------------------

See C:\Program Files\Tivoli\TSM\log.txt for details.

The following components were successfully installed:TSM ServerDB2 9.5TSM License

To continue, either configure a new server instance or upgrade an existing server instance.


Log in as root user or administrator and open the local new-instance wizard, dsmicfgx, located in the server installation directory.Log on to a Version 6.1 Tivoli Storage Manager Administration Center and start the Create New Instance wizard.Configure the new instance manually. See the Tivoli Storage Manager Information Center, or the Installation Guide.

To upgrade an existing server instance, log in as root user or administrator and start the upgrade wizard, dsmupgdx, located in the server installation directory.You can also upgrade a server manually. See the Tivoli Storage Manager Information Center, or the Server Upgrade Guide.


For more information about any of these tasks, see the Tivoli Storage Manager Information Center at: http://publib.boulder.ibm.com/infocenter/tsminfo/v6

PRESS <ENTER> TO EXIT THE INSTALLER

You have the choices to continue, then either configure a new server instance or upgrade an existing server instance:

1. To configure a new server instance, choose one of the following methods:

a. Log in as an administrator and open the local new-instance wizard, dsmicfgx.exe, located in the server installation directory.

b. Log on to a Version 6.1 Tivoli Storage Manager Administration Center and start the Create New Instance wizard.

c. Configure the new instance manually. See the Tivoli Storage Manager Information Center, or the Installation Guide.

2. To upgrade an existing server instance, log in as root user or administrator and start the upgrade wizard, dsmupgdx, located in the server installation directory.

You can also upgrade a server manually. See the Tivoli Storage Manager Information Center, or the Tivoli Storage Manager Server Upgrade Guide, SC23-9554. For more information about any of these tasks, see the Tivoli Storage Manager Information Center at:


18.8 Silent mode installation

Here we describe how to install V6.1 using the silent mode. Installing in silent mode (in the background) is the third method of installing Tivoli Storage Manager.

18.8.1 Silent mode without saving responses

From the directory where you have downloaded the install package, submit to start the silent installation without saving your responses. Enter the following command on a single line with a space between the attributes (see Example 18-8).

Example 18-8 Start silent mode install without responses

install.exe -i silent -DLICENSE_ACCEPTED=true -DINSTALL_SERVER=1 -DINSTALL_SERVER_LANGUAGES=0 -DINSTALL_LICENSE=1 -DINSTALL_DEVICES=0 -DINSTALL_STAGENT=0 -DINSTALL_ADMINCENTER=0 -DDB2_USER=db2user1 -DDB2_PW=db2user1 -DDB2_NAME=DB2 -DUSER_INSTALL_DIR=i"C:\Program Files\Tivoli\TSM"

Note: After you start the silent installation, it immediately closes the foreground window and runs in the background. To receive a return code from the silent installation, run it using a batch script.

Note: It is important to use brackets if you have spaces in the path name.



18.8.2 Silent mode saving responses

To start the silent installation and save your responses, enter the following command, and specify the -r option (see Example 18-9).

Example 18-9 Start silent mode with responses

install.exe -i silent -DLICENSE_ACCEPTED=true -DINSTALL_SERVER=1 -DINSTALL_SERVER_LANGUAGES=0 -DINSTALL_LICENSE=1 -DINSTALL_DEVICES=0 -DINSTALL_STAGENT=0 -DINSTALL_ADMINCENTER=0 -DDB2_USER=db2user1 -DDB2_PW=db2user1 -DDB2_NAME=DB2 -DUSER_INSTALL_DIR=C:\Program Files\Tivoli\TSM" -r C:\response.rsp

Existing response file To use an existing response file, enter the following command: install.exe -i silent -DLICENSE_ACCEPTED=true -f response_file (see Example 18-10).

Example 18-10 Start silent mode using existing response file

install.exe -i silent -DLICENSE_ACCEPTED=true -f response_file where the response_file is the full directory path to a file that you previously created in the Tivoli Storage Manager installation process. The response file contains variables you selected in a prior installation. If you include LICENSE_ACCEPTED=true in the response file manually, then issue this command: install.exe -i silent -f response_file

Batch script To run the silent installation so that you can see the progress of the installation, create a batch script by completing the following steps:

1. Create a file and name it install.bat. The file name must end with .bat, not bat.txt.

2. Choose an installation option (with or without a response file) and enter the command into the install.bat file and save it.

Example 18-11 Silent install using batch script

For example: install.exe -i silent -DLICENSE_ACCEPTED=true -f response_file

3. Open a command prompt to run the batch file. Issue the command: install.bat

4. After the installation is complete, issue the following command to retrieve the return code: echo %ERRORLEVEL%

Example 18-12 shows that we have created an install.bat file with the required information for the install.bat file.

Example 18-12 Silent install with batch script using parameters

install.exe -i silent -DLICENSE_ACCEPTED=true -DINSTALL_SERVER=1 -DINSTALL_SERVER_LANGUAGES=0 -DINSTALL_LICENSE=1 -DINSTALL_DEVICES=0 -DINSTALL_STAGENT=0 -DINSTALL_ADMINCENTER=0 -DDB2_USER=db2user1 -DDB2_PW=db2user1 -DDB2_NAME=DB2 -DUSER_INSTALL_DIR="C:\Program Files\Tivoli\TSM" -r C:\response.rsp

Next we show you a basic Tivoli Storage Manager default installation and configuration and provide images of Silent Mode interface using the install.bat file.

When using the echo %ERRORLEVEL% command you will get a return code and you are returned to the command prompt as shown in Example 18-13.


Example 18-13 Tivoli Storage Manager Silent Installation

C:\TSM_images\6.1_Server>install.bat

C:\TSM_images\6.1_Server>install.exe -i silent -r C:\response.rsp -DLICENSE_ACCEPTED=true -DINSTALL_SERVER=1 -DINSTALL_SERVER_LANGUAGES=0 -DINSTALL_LICENSE=1 -DINSTALL_DEVICES=0 -DINSTALL_STAGENT=0 -DINSTALL_ADMINCENTER=0 -DDB2_USER=db2user1 -DDB2_PW=db2user1 -DDB2_NAME=DB2 -DUSER_INSTALL_DIR="C:\Program Files\Tivoli\TSM"

C:\TSM_images\6.1_Server>echo %ERRORLEVEL%0

C:\TSM_images\6.1_Server>

Example 18-13 shows that we got return code 0 and the silent installation was successful. For return codes see “Debugging techniques” on page 402.

18.9 Creating directories and user ID for the server instance


� Log in as an administrator and open the local new-instance wizard, dsmicfgx, located in the server installation directory.

� Log on to a Version 6.1 Tivoli Storage Manager Administration Center and start the Create New Instance wizard.

� Configure the new instance manually.

18.9.1 Creating the directories for the server instance

Here we create the directories and the user ID for the server instance. Create the directories that the Tivoli Storage Manager server instance needs for database and recovery logs, and create the user ID for the Tivoli Storage Manager server instance. Review the information about planning space for the server before completing this task.

First we need to create the directories that the Tivoli Storage Manager server instance needs for database and recovery logs using the mkdir command. You need unique, empty directories for each of the items listed in Example 18-14 on page 376. Create the database directories, the active log directory, and the archive log directory on various physical volumes.

Example 18-14 Create directories for database and recovery logs

C:\>mkdir e:\tsminst1\dbdir001C:\>mkdir f:\tsminst1\dbdir002C:\>mkdir g:\tsminst1\dbdir003C:\>mkdir h:\tsminst1\dbdir004C:\>mkdir i:\tsminst1\actlogC:\>mkdir j:\tsminst1\actlogmC:\>mkdir k:\tsminst1\archlogC:\>mkdir l:\tsminst1\archlogf


18.9.2 Creating the user ID for the server instance

You create the user ID with the command line in Windows:

1. Enter the command: net user tsminst1 * /add

2. Type a password for the user.

3. Retype the password to confirm.

4. Confirm that the command completed successfully.

Here are some further considerations regarding user accounts:

� The groups DB2ADMNS and DB2USERS are created during the installation. Make the tsminst1user in the DB2ADMNS and DB2USERS groups.

You use this user ID when you create the server instance in a later step. Identify the user account that will own the Tivoli Storage Manager server instance. When the server is started as a Windows service, this is the account that the service will log on to. The user account must have administrative authority on the system. One user account can own more than one server instance.

If you have multiple servers on one system, there is no need to run each server with a different user account. You can have one user ID associated with multiple servers on a Windows system.

� Check the directories. For all directories that were created for the server instance, ensure that the user ID for the server instance has read/write access. The directories to check include the instance directory and all database and log directories.

� In the Microsoft Management Console, you can see in which groups the user ID belongs.

18.10 Configuring a new Tivoli Storage Manager Server instance

After you have installed Tivoli Storage Manager Version V6.1 and prepared for the configuration, configure a Tivoli Storage Manager server instance by selecting one of the following options:

� Log in as an administrator and open the local new-instance wizard, dsmicfgx, located in the server installation directory.

� Log on to a Version 6.1 Tivoli Storage Manager Administration Center and start the Create New Instance wizard.

� Configure the new instance manually.

Preparing the configuration of Tivoli Storage Manager V6.1Here we take the first steps after we have installed the Tivoli Storage Manager V6.1.

Either use the configuration wizard to configure the Tivoli Storage Manager instance or configure the instance manually.

After you install Tivoli Storage Manager Version 6.1, one of the options for configuring Tivoli Storage Manager is to use the configuration wizard on your local system. By using the wizard, you can avoid some configuration steps that are complex when done manually. Start the wizard on the system where you installed the Tivoli Storage Manager Version 6.1 server.


� Ensure that the following requirements are met:

The systems must have one of the following protocols enabled: secure shell (SSH), remote shell (RSH), Remote Execution Protocol (REXEC), or Windows server message block (SMB). SMB is the interface used by File and Print Sharing (also known as CIFS).

To use the SMB protocol, you must ensure that File and Print Sharing is enabled, and that port 445 is not blocked by your firewall. If you are running on Windows Server 2008 or Windows Vista, you might also need to disable User Account Control (at least while running this wizard).

If you choose not to disable User Account Control, you must ensure that one of the other protocols is configured to allow the wizard to run. You must be able to log on to the system using a protocol that is enabled on the system, using either the user ID that was created after the installation, or some other user ID that exists on the system. When using the wizard, you must provide the user ID and password to access the system.

18.11 Using the Tivoli Storage Manager configuration wizard

To start the local version of the wizard: Double-click the dsmicfgx.exe program in the C:\Program Files\Tivoli\TSM\server directory.

Follow the instructions to complete the configuration. The wizard can be stopped and restarted, but the server will not be operational until the entire configuration process is complete.

Configuring the server instance using the wizardHere we start configuring the Tivoli Storage Manager using the configuration wizard, the local version of the wizard.

1. We execute the dsmicfgx.exe installer program in the C:\Program Files\Tivoli\TSM\server directory. Follow the instructions to complete the configuration. The wizard can be stopped and restarted, but the server will not be operational until the entire configuration process is complete. We have to select the language for the installation. Click OK to continue (see Figure 18-11).

Figure 18-11 Wizard Installation


2. Here we see the Instance Configuration Wizard Introduction window. Click Next to continue as shown in Figure 18-12.

Figure 18-12 IBM Tivoli Storage Manager Instance Configuration Wizard

3. The instance user ID is the ID that is used by the database manager to read and write the database and log files. This user ID must have write permission to all directories containing database and log files.

The instance user ID is not necessarily the same user ID that you will use to run the Tivoli Storage Manager server.The user ID must already exist on the system, and must not be disabled or locked.

The primary group of the specified user will become the administrative group of the database. Any other users in this group can manage the database (including starting and stopping the database manager). If you want to restrict this access, you should create a separate group for the instance user ID, so that only the instance user ID can manage this database.

4. To validate the user ID and password, a connection will be made to the local system using either SSH, RSH, or REXEC. You must enable one of these protocols to allow the wizard to proceed.

To validate the user ID and password, a connection will be made to the local system using either SSH, RSH, REXEC, or SMB protocols. SMB is the interface used by File and Print Sharing (also known as CIFS). In order to use the SMB protocol, you must make sure File and Print Sharing is enabled, and that port 445 is not blocked by your firewall. Issue:

netsh firewall set service type = fileandprint mode = enable


5. Additionally, if you are running on Windows Server 2008 or Windows Vista, you might need to disable User Account Control (at least while running this wizard). If you choose not to disable User Account Control, you must make sure one of the other protocols is configured to allow the wizard to proceed.

6. Here we manually specify the Tivoli Storage Manager Instance name of the new Instance and specify the user ID and password under which the database manager for this Instance, Click Next to continue (see Figure 18-13).

Figure 18-13 IBM Tivoli Storage Manager Instance Configuration Wizard - Instance User ID


7. Set the path to the Instance Directory that stores all the server configuration, such as the server options file, trace files, and other files specific to this instance, Click Choose and browse to the installation folder. Here we manually create the Server1 folder. Click Next to continue (see Figure 18-14).

Figure 18-14 IBM Tivoli Storage Manager Instance Configuration Wizard - Instance Directory


8. There are two ways to specify the database directories:

a. Create a temporary file, and place each database directory on its own line in the file, then specify the location of the file in the top field, or

b. Specify each database directory directly in the bottom field, one directory per line.

Here we have specified the text file containing a list of database directories, Click Next to continue (see Figure 18-15).

Figure 18-15 IBM Tivoli Storage Manager Instance Configuration Wizard - Database Directories file

The Tivoli Storage Manager database is stored in a series of directories managed by the database manager. To improve data throughput, specify a large number of directories to allow the database manager to spread the workload over multiple disks.


9. Each database directory must be empty, and, for maximum performance, should reside on its own dedicated disk. Here we have chosen to specify a list of four directories per line to use for the Tivoli Storage Manager database. Note that you can use up to 128 directories for the instance. Click Next to continue (see Figure 18-16).

Figure 18-16 IBM Tivoli Storage Manager Instance Configuration Wizard - Database Directory

10.Now we specify the directories for the database and log volumes:

– The active log directory contains all transactions currently in progress on the server. If the system crashes or the server stops, the active log is all that is required to restart the server. The active log is broken up into files. After all transactions in a log file are completed, the log file is copied to an archive log directory.

– If a log file cannot be copied to the primary archive log directory, it is copied to the ArchiveLogFailover log directory, if specified. If a log file cannot be copied to either log directory, it remains in the active directory.

– If the active log fills up, transactions will fail. Therefore, ensure that the archive log directories are online with sufficient space to hold the log files. Logs in the archive log directories can be copied to another location, but these logs must be returned to the archive directory to perform a database restore operation.

– The mirror log directory contains the same contents as the active log directory, and is used for redundancy in case of disk failure. If your active log directory resides on a disk that is already mirrored or has other RAID protection, you might not need to specify a mirror log directory.


11.In the Recovery Log Directory window, here we have shortened the names for the recovery logs:

� ActiveLog as Actlog� ArchiveLog as Archlog� ActiveLogMirror as Actlogm� ArchiveLogFailover as Archlogf

Click Next to continue (see Figure 18-17).

Figure 18-17 IBM Tivoli Storage Manager Instance Configuration Wizard- Recovery Log Directories


12.We specify the server name and select the language. Click Next to continue (see Figure 18-18).

Figure 18-18 IBM Tivoli Storage Manager Instance Configuration Wizard - Server Information

The administrator name must be 1-64 characters and must contain only alphanumeric characters. The administrator name is not case sensitive.


13.The administrator password must be 4-64 characters, contain only alphanumeric characters, and must contain at least 1 numeral. Click Next to continue (Figure 18-19).

Figure 18-19 IBM Tivoli Storage Manager Instance Configuration Wizard - Administrator Credentials

Tivoli Storage Manager requires TCP/IP communications for client or administrator access. You must specify a port for each, but both ports can be the same.


14.In addition to TCP/IP, you can also select Shared Memory Communication. This uses a TCP/IP port for initial contact, and the port specified must be different than the client port or the administrator port. Click Next to continue (see Figure 18-20).

Figure 18-20 IBM Tivoli Storage Manager Instance Configuration Wizard - Server Communication


15.Here we have configuration summary where we can see the user ID we have created, where we have the instance directory, the four database containers we have defined, and the log files directories Click Next to continue (see Figure 18-21).

Figure 18-21 IBM Tivoli Storage Manager Instance Configuration Wizard - Configuration Summary


16.The instance is now being configured. Configuration will take several minutes to complete. The progress of the configuration is shown in Figure 18-22.

Figure 18-22 IBM Tivoli Storage Manager Instance Configuration Wizard - Configure Instance


17.During the server installation format processing for the Tivoli Storage Manager V6.1 instance, you will see that the server performs a backup of the database. This can be seen by the messages shown in Figure 18-23:

ANR2976I Offline DB backup for database TSMDB1 started.ANR2974I Offline DB backup for database TSMDB1 completed successfully.

Figure 18-23 IBM Tivoli Storage Manager Instance Configuration Wizard - database backup

Note: This initial backup is required by DB2 in order for Tivoli Storage Manager to set the recovery log processing mode to ROLLFORWARD. At this point, this database backup only contains the server schema Data Definition Language (DDL). This database backup is performed to a file in the local file system. This database backup is subsequently deleted by Tivoli Storage Manager because it only contains the server schema definitions, which can be recreated by Tivoli Storage Manager anyway.

After completing the installation and configuration of the Tivoli Storage Manager server, we recommended that you perform a FULL database backup. This database backup and any subsequent database backups will be tracked in the server volume history, as expected, and used as part of the server Disaster Recovery Manager (DRM) processing, and such.


18.The Tivoli Storage Manager Server1 instance is now configured. Click Next to continue (see Figure 18-24).

Figure 18-24 IBM Tivoli Storage Manager Instance Configuration Wizard - configuration complete


19.Here we have finished the installation and the server is now up and running. Log in to the admin center or through the admin command line to set up storage pools and polices (see Figure 18-25).

Figure 18-25 IBM Tivoli Storage Manager Instance Configuration Wizard - Configuration Successful

18.12 Creating the server instance manuallyIn this section we show the process to manually create directories and the user ID for the server instance and start the Tivoli Storage Manager server. First we create directories that the server requires. You need unique, empty directories for the database directories, the active log directory, and the archive log directory on different physical volumes. Refer to “Installation and upgrade planning for Tivoli Storage Manager V6.1” on page 245 for details.

Setting up your directories for the Tivoli Storage Manager instance Set up your directories as follows:

1. We use the mkdir command to create directories using the commands in Example 18-15.

Example 18-15 Manually creating required directories

mkdir e:\tsminst1\dbdir001mkdir f:\tsminst1\dbdir002mkdir g:\tsminst1\dbdir003mkdir h:\tsminst1\dbdir004mkdir i:\tsminst1\actlogmkdir j:\tsminst1\actlogmmkdir k:\tsminst1\archlogmkdir l:\tsminst1\archlogf


2. In the Microsoft Management Console, you can see which groups the user ID tsm1 belongs to as shown in Figure 18-26. This is the user ID under which the database manager for the instance runs.

Figure 18-26 User ID properties in Windows Microsoft Management Console

18.12.1 Manually creating a Tivoli Storage Manager instance

Here we show how to create a Tivoli Storage Manager instance by issuing the db2icrt command by the command line.

The instance directory stores the following files for the server instance:

� The server options file, dsmserv.opt

� The dsmserv.v6lock file

� Device configuration file, if the DEVCONFIG server option does not specify a fully qualified name

� Volume history file, if the VOLUMEHISTORY server option does not specify a fully qualified name

� Volumes for DEVTYPE=FILE storage pools, if the directory for the device class is not fully specified, or not fully qualified

� User exits

� Trace output (if not fully qualified)

Important: Before you run the db2icrt command, ensure that the user and the instance directory of the user exists. If there is no instance directory, you must create it.


Starting to create an instanceFirst, we log in as an administrator and create a Tivoli Storage Manager instance, using the db2icrt command.

1. The user account that you specify here becomes the user ID that owns the V6.1 server (the instance user ID). Enter the following command on a command line:

db2icrt -u tsminst1 tsminst1

You are prompted to enter the password for instance user ID tsm1. Later, when you create and format the database, you use the instance name that you specified with this command, using the -k option.

2. If needed, change the default path for the database to be the drive where the instance directory for the server is located. Complete the following steps

Click Start → Programs → IBM DB2 → DB2TSM1 → Command Line Tools → Command Line Processor. Enter quit to exit the command line processor.

A window with a command prompt should now be open, with the environment properly set up to successfully issue the commands in the next steps.

3. Change the default path for the database to be the drive where the instance directory for the server is located. The instance_name is the same as the instance name that you specified when you issued the db2icrt command. For example, to set the environment variable for the Server1 server instance, issue the following command:

set DB2INSTANCE=tsminst1

Issue the command to set the default drive:

db2 update dbm cfg using dftdbpath instance_location

For example, if the instance directory is c:\server1, the instance location is drive d: and this is a directory where databases are cataloged in an instanceEnter the command:

db2 update dbm cfg using dftdbpath d:

4. Create a new server1 folder and a new server options file in server1 folder (see 18.12.3, “Configuring server and client communications” on page 399).

Formatting the database and logsUse the DSMSERV FORMAT command to initialize a server instance.

No other server activity is allowed while initializing the database and recovery log. After you have completed setting up server communications, you are ready to initialize the database. Do not place the directories on file systems that might run out of space. If certain directories (for example, the archive log) become unavailable or full, the server stops. See the IBM Tivoli Storage Manager for Windows Administrator's Guide V6.1, SC23-9773 for more details.

Note: The installation program creates a set of registry keys. One of these keys points to the directory where a default server, named SERVER1, is created. To install an additional server, create a new directory and use the DSMSERV FORMAT utility, with the -k parameter, from that directory. That directory becomes the location of the server. The registry tracks the installed servers.


Here is one example to FORMAT a database with the default ActiveLog size 2 GB database logs.

Issue the DSMSERV FORMAT command to start the format of the database (see Example 18-16).

Example 18-16 Database format

dsmserv -k tsminst1 format dbdir=e:\tsm1\dbdir001,f:\tsm1\dbdir002,g:\tsm1\dbdir003,h:\tsm1\dbdir004 activelogdir=i:\tsm1\actlog archlogdir=k:\tsm1\archlog mirrorlogdir=j:\tsm1\actlogm archfailoverlogdir=l:\tsm1\archlogf

The output from the DSMSERV FORMAT command is shown in Example 18-17.

Example 18-17 DSMSERV FORMAT command output

ANR0900I Processing options file C:\Program Files\Tivoli\TSM\tsminst1\dsmserv.optANR7800I DSMSERV generated at 16:44:45 on Mar 13 2009.




ANR4726I The ICC support module has been loaded.ANR0152I Database manager successfully started.ANR0152I Database manager successfully started.ANR1380I The buffer pool monitor switch is enabled.ANR0992I Server's database formatting complete.ANR0369I Stopping the database manager because of a server shutdown.ANR2976I Offline DB backup for database TSMDB1 started.ANR2974I Offline DB backup for database TSMDB1 completed successfully.

Preparing the database manager for backupTo back up the data in the database to Tivoli Storage Manager, you must enable the database manager and configure the Tivoli Storage Manager application programming interface (API).

Complete the following steps before issuing either the BACKUP DB or the RESTORE DB commands.

In the following commands, the examples use d:\server1 for the database instance and C:\Program Files\Tivoli\TSM\server1 for the Tivoli Storage Manager instance directory.

1. Here we create the tsmdbmgr.env file in the C:\Program Files\Tivoli\TSM\tsminst1 directory with the contents in Example 18-18.

Example 18-18 Contents of tsmdbmgr.env file

DSMI_CONFIG=C:\PROGRA~1\Tivoli\TSM\tsminst1\tsmdbmgr.optDSMI_LOG=C:\PROGRA~1\Tivoli\TSM\tsminst1


2. We then set the DSMI_ api environment-variable configuration for the database instance.

Open a DB2 command window. One method of doing this is by going to the C:\Program Files\Tivoli\TSM\db2\bin directory, or if you installed Tivoli Storage Manager in a different location, go to the db2\bin subdirectory in your main installation directory.

Issue this command:

db2cmd

A new window opens where you then issue the command:

db2set -i tsminst1 DB2_VENDOR_INI=”C:\Program Files\Tivoli\TSM\tsminst1\tsmdbmgr.env”

3. Create the tsmdbmgr.opt file in the C:\Program Files\Tivoli\TSM\tsminst1 directory with the contents in Example 18-19.

Example 18-19 tsmdbmgr.opt file

nodename $$_TSMDBMGR_$$commmethod tcpiptcpserveraddr localhosttcpport 1500passwordaccess generate errorlogname C:\Program Files\Tivoli\TSM\tsminst1\TSMDBMGR_TSMSERVER1.log

4. Then we stop and start the database instance:

Open a DB2 command window. One method of doing this is by going to the C:\Program Files\Tivoli\TSM\db2\bin directory, or if you installed Tivoli Storage Manager in a different location, go to the db2\bin subdirectory in your main installation directory. Issue the commands in Example 18-20 to set the database instance, stop DB2, and then start DB2.

Example 18-20 Stop and start the database instance

db2cmdSET DB2INSTANCE=tsminst1db2stopdb2start

5. Issue the commands in Example 18-21 to set the API environmental variable.

Example 18-21 DSMI_CONFIG command

C:\Program Files\Tivoli\TSM\db2\BIN>set DSMI_CONFIG=C:\Program Files\Tivoli\TSM\tsminst1\tsmdbmgr.optC:\Program Files\Tivoli\TSM\db2\BIN>"C:\Program Files\Tivoli\TSM\server\dsmsutil” UPDATEPW /NODE:$$_TSMDBMGR_$$ /PASSWORD:TSMDBMGR /VALIDATE:NO

Here are the results of the commands. Note that we have updated the password in the registry (see Example 18-22).

Example 18-22

TSM Windows NT Client Service Configuration UtilityCommand Line Interface - Version 6, Release 1, Level 0.0 1027FB(C) Copyright IBM Corporation, 1990, 2008, All Rights Reserved.Last Updated Oct 28 2008TSM Api Version 6.1.0

Command: Update Registry Password


Machine: TSM-1(Local Machine)

The Registry password for node $$_TSMDBMGR_$$ has been updated

Starting the server instanceVerify that the server instance is correctly set up by starting one or more Tivoli Storage Manager server instances.

Remember that starting the server is an operating system-level operation and has certain restrictions. If you do not have the permissions to use the dsmserv program, you cannot start it. If you do not have authority to read and write files in the instance directory, you cannot start that instance of the server.

� Starting the server using Windows services.msc from the Start menu → Run, or with the DSMSERV utility to start the Tivoli Storage Manager server.

To start the server from the C:\Program Files\Tivoli\TSM server directory, enter the command: dsmserv -k server_instance where server_instance is the name of your server instance. Server1 is the default for the first instance of the Tivoli Storage Manager server on a system. Example 18-23 shows the command to start our instance named tsminst1.

Example 18-23 Start the server instance tsminst1

"c:\Program Files\Tivoli\TSM\server\dsmserv -k tsminst1

Stopping the serverYou can stop the server without warning if an unexpected problem requires you to return control to the operating system. To avoid losing administrative and client node connections, stop the server only after current sessions have completed or been canceled. To stop the server, issue the halt command from the Tivoli Storage Manager command prompt. The server console stops.

Creating a Windows service for the server instanceInstall the Tivoli Storage Manager server as a Windows service during manual configuration of the Tivoli Storage Manager server.

After you have completed formatting the database and log, you are ready to create a Windows service for your server instance.

1. Change to the C:\Program Files\Tivoli\TSM\console directory, or if you installed Tivoli Storage Manager in a different location, go to the console subdirectory in your main installation directory. An executable (install.exe) in this directory installs the Tivoli Storage Manager server as a Windows service.

Note: If you receive a Windows error 216 message when you try to start the server, it is a result of using a 64-bit package on 32-bit Windows. Retrieve the 32-bit Windows package and reinstall Tivoli Storage Manager.

Note: If you start the Tivoli Storage Manager server as a service, after you stop it, the database service continues to run.


2. Install the Windows service, using the same server name that you used to start the Tivoli Storage Manager server. Issue the commands:

install "TSM server#" "C:\Program Files\Tivoli\TSM\server\dsmsvc.exe" windowsacctname windowsacctpassword

For example, if the server instance is Server1, enter the following command on one line:

install "TSM server1" "C:\Program Files\Tivoli\TSM\server\dsmsvc.exe" windowsacctname windowsacctpassword

If a different name was used or there are multiple server instances running on the system, modify the service name.

3. When installing the Windows service, you have to manually change the service to an automatic startup type. Do this by going to Windows Administrative Tools → Services.

Example 1. If you are installing the Windows service using an administrator account to log on, issue the following commands:

install "TSM Server1""C:\Program Files\Tivoli\TSM\server\dsmsvc.exe"admin_name admin_password

The admin_name is the Windows administrator name and the admin_password is the password for that administrator.

4. If you are installing the Windows service using LocalSystem as the logon account, issue the following command:

install "TSM Server1" "C:\Program Files\Tivoli\TSM\server\dsmsvc.exe" localsystem ""

The LocalSystem account does not have a password, so use the double quotes (? ?) to specify a NULL password.

Registering licensesImmediately register any Tivoli Storage Manager licensed functions that you purchase so you do not lose any data after you start server operations, such as backing up your data.

Use the REGISTER LICENSE command for this task.

18.12.2 Running multiple server instances on a single system

It is possible to create more server instances on your system. Each Tivoli Storage Manager server instance has its own instance directory, database and log directories. The set of files for one instance of the server are stored separately from those used by another server instance on the same system. For each new instance, optionally creating the new instance user.

To manage the system memory that is used by each server, use the DBMEMPERCENT server option to limit the percentage of system memory that can be used by the database manager of each server. Refer to the IBM Tivoli Storage Manager for Windows Administrator's Guide V6.1, SC23-9773 for more information about DBMEMPERCENT.

If all servers are equally important, use the same value for each server. If one server is a production server and other servers are test servers, set the value for the production server to a higher value than the test servers.


18.12.3 Configuring server and client communications

After installing Tivoli Storage Manager, you can set up client and server communications by specifying options in the Tivoli Storage Manager server and client options files. Set these server options before you start the server.

When you start the server, the new options go into effect. If you modify any server options after starting the server, you must stop and restart the server to activate the updated options. Use the Server Options utility that is available from the Tivoli Storage Manager Console to view and specify server communications options. This utility is available from the Service Information view in the server tree. By default, the server uses the TCP/IP, Named Pipes, and HTTP communication methods.

If you start the server console and see warning messages that a protocol could not be used by the server, either the protocol is not installed or the settings do not match the Windows protocol settings. For a client to use a protocol that is enabled on the server, the client options file must contain corresponding values for communication options. From the Server Options utility, you can view the values for each protocol. For more information about server options, see the IBM Tivoli Storage Manager for Windows Administrator's Guide V6.1, SC23-9773.

18.12.4 TCP/IP options

Select from a range of TCP/IP options for the Tivoli Storage Manager server or retain the default.

� TCPPORT

The server TCP/IP port address. The default value is 1500.

� TCPWINDOWSIZE

Specifies the size of the TCP/IP buffer that is used when sending or receiving data. The window size that is used in a session is the smaller of the server and client window sizes. Larger window sizes use additional memory but can improve performance. To use the default window size for the operating system, specify zero.

� TCPNODELAY

Specifies whether or not the server sends small messages or lets TCP/IP buffer the messages. Sending small messages can improve throughput but increases the number of packets sent over the network. Specify YES to send small messages or NO to let TCP/IP buffer them. The default is YES.

� TCPADMINPORT

Specifies the port number on which the server TCP/IP communication driver is to wait for requests other than client sessions. The default value is 1500.

� SSLTCPPORT

(SSL-only) Specifies the Secure Sockets Layer (SSL) port number on which the server TCP/IP communication driver waits for requests for SSL-enabled sessions for the command-line backup-archive client and the command-line administrative client.

� SSLTCPADMINPORT

Specifies the port address on which the server TCP/IP communication driver waits for requests for SSL-enabled sessions for the command-line administrative client.

Note: You can use TCP/IP Version 4, Version 6, or both.


The following list shows some TCP/IP options that you can use to set up your system.

� commmethod tcpip � tcpport 1500 � tcpwindowsize 63 � tcpnodelay yes

18.12.5 Named Pipes options

The Named Pipes communication method is ideal when running the server and client on the same Windows machine. Named Pipes require no special configuration.

Here is an example of a Named Pipes setting: (see Example 18-24).

Example 18-24 Named Pipes setting

commmethod namedpipenamedpipename \\.\pipe\adsmpipe

18.12.6 Shared memory options

You can use shared memory communications between clients and servers on the same system. To use shared memory, TCP/IP Version 4 must be installed on the system.

In this example, SHMPORT specifies the TCP/IP port address of a server when using shared memory. Use the SHMPORT option to specify a different TCP/IP port. The default port address is 1510. A shared memory setting is shown in Example 18-25.

Example 18-25 Shared memory options

commmethod sharedmemshmport 1510

18.12.7 SNMP DPI subagent options

Tivoli Storage Manager implements a simple network management protocol (SNMP) subagent. You can configure the SNMP subagent to send traps to an SNMP manager, such as NetView®, and to provide support for a Management Information Base (MIB).

For details about configuring SNMP for use with Tivoli Storage Manager, see the Administrator’s Guide for your platform. The subagent communicates with the snmp daemon, which in turn communicates with a management application. The snmp daemon must support the DPI® protocol. The subagent process is separate from the Tivoli Storage Manager server process, but the subagent gets its information from a server options file. When the SNMP management application is enabled, it can get information and messages from servers.

Use the list of SNMP DPI options in Example 18-26 as an example of a SNMP setting. You must specify the COMMMETHOD option. For details about the other options, see the IBM Tivoli Storage Manager for Windows Administrator's Guide V6.1, SC23-9773.

Example 18-26 SNMP DPI options

commmethod snmpsnmpheartbeatinterval 5snmpmessagecategory severity


18.12.8 Monitoring the server

When you start using the server in production operation, monitor the space used by the server to ensure that the amount of space is adequate. Make adjustments as needed.

Monitor the active log by querying the database log, to ensure that the size is correct for the workload that is handled by the server instance. When the server workload is up to its typical expected level, and the space that is used by the active log is 80 % of the space that is available to the active log directory, you should increase the amount of log space.

Whether you need to increase the space depends on the types of transactions in the server’s workload, because transaction characteristics affect how the active log space is used.

The number and size of files in backup operations can affect the space usage in the active log, as follows:

� Clients such as file servers that back up large numbers of small files can cause large numbers of transactions that complete during a short period of time. The transactions might use a large amount of space in the active log, but for a short period of time.

� Clients such as a mail server or a database server that back up large chunks of data in few transactions can cause small numbers of transactions that take a long time to complete. The transactions might use a small amount of space in the active log, but for a long period of time.

18.12.9 Network connection types

Backup operations that occur over fast network connections cause transactions that complete more quickly. The transactions use space in the active log for a shorter period of time.

Backup operations that occur over relatively slower connections cause transactions that take a longer time to complete. The transactions use space in the active log for a longer period of time. If the server is handling transactions with a wide variety of characteristics, the space that is used for the active log might go up and down by a large amount over time. For such a server, you might need to ensure that the active log typically has a smaller percentage of its space used. The extra space allows the active log to grow for transactions that take a very long time to complete, for example.

Monitoring the ARCHIVE logMonitor the archive log to ensure that space is always available. Remember that If the archive log becomes full, and the failover archive log becomes full, the active log can become full and the server will stop. The goal is to make enough space available to the archive log so that it never uses all its available space.

You are likely to notice the following patterns:

� Initially, the archive log grows rapidly as typical client-backup operations occur.

� Database backups occur regularly, either as scheduled or done manually.

� After at least two, full database backups occur, log pruning occurs automatically. The space used by the archive log decreases when the pruning occurs.

� Normal client operations continue, and the archive log grows again.

� Database backups occur regularly, and log pruning occurs as often as full database backups occur. With this pattern, the archive log grows initially, then decreases, then might grow again. Over a period of time, as normal operations continue, the amount of space used by the archive log should reach a relatively constant level.


If the archive log continues to grow, consider taking one or more of these actions:

� Add space to the archive log. This might mean moving the archive log to a different file system. For information about moving the archive log, see the IBM Tivoli Storage Manager for Windows Administrator's Guide V6.1, SC23-9773.

� Increase the frequency of full database backups, so that log pruning occurs more frequently.

� If you defined a directory for the failover archive log, determine whether any logs get stored in that directory during normal operations. If the failover log space is being used, consider increasing the size of the archive log. The goal is that the failover archive log is used only under unusual conditions, not in normal operation.

18.13 Debugging techniques

In cases where you might need to investigate log messages, there are several files in which to find additional information.

18.13.1 Investigating log messages

Here we describe various ways to debug the installation:

� Logs are available in logs.zip. For Windows, the path is <Install Dir>\logs.zip.

� Start with the main log file in the following location:

coi\plan\install\MachinePlan_localhost\logs\MachinePlan_localhost_[INSTALL_0414_22.35].log

� Look for steps where installation has failed. This leads us to our next log:

MachinePlan_localhost_[INSTALL_0414_22.35].log

� DB2 step logs:

coi\plan\install\MachinePlan_localhost\00002_DB2_9.5\DB2_9.5.logcoi\plan\tmp:

� Administration Center step logs:

coi\plan\install\MachinePlan_localhost\00003_TSM_AdminCenter\logs:

� Deployment Engine logs:

C:\Program Files\IBM\Common\acsi\logs\<system user>


18.13.2 How to completely remove Deployment Engine

Normally you should avoid removing the Deployment Engine (DE), but in some cases it can be necessary. Here we explain how to completely remove the DE:

� Remove the C:\Program Files\IBM\Common directory.

� Clean up the system %TEMP% directory by removing the acu_de.log file, if it is there.

� Remove the %TEMP%\<username> directory, where <username> is the id of the user that installed DE (for example, “Administrator”), if it is there.

� In the Windows Services panel (Start → Settings → Control Panel → Administrative Tools → Services), ensure that the “ACSI Service” entry does not exist. If it does exist, make sure it is not started, and attempt to delete the service entry from the list. Windows might not allow this, however, but it should be safe to leave the name in the list, as long as it is not in the Started state.

Problem determinationIf the Deployment Engine is not working properly and is causing the Tivoli Storage Manager installs to fail, follow these instructions:

1. Check log.txt for the following entry return code: SI_UP_TO_DATE

– Windows: (Install directory)\log.txt

– UNIX: /var/tivoli/tsm/log.txt

2. If there is a problem with the Deployment Engine, ensure that the following files do not exist:

– Windows:

(Install directory)\\_uninst\plan\inventory\inventoryCheck.properties

– UNIX:

/opt/tivoli/tsm/_uninst/plan/inventory/inventoryCheck.properties

Windows problem solution Follow these steps:

1. Stop the DE service:

Control Panel → Administrative Tools → Services → IBM ADE Service

2. Run:

C:\Program Files\IBM\Common\acsi\setenv.cmd

3. Start the DE service:

Control Panel → Administrative Tools → Services → IBM ADE Service

UNIX problem solution Follow these steps:

1. Stop the DE service:

/usr/ibm/common/acsi/bin/acsisrv.sh -stop

2. Run:

/var/ibm/common/acsi/setenv.sh

3. Start the DE service:

/usr/ibm/common/acsi/bin/acsisrv.sh -start


18.14 Gathering logs

In the case where logs.zip is not created during the installation, you can gather these logs manually by following the paths listed in Table 18-4.

Table 18-4 log.zip creation

Log type Log name UNIX location Windows location

Install Anywhere log.txt /var/tivoli/tsm Chosen install directory

Deployment Engine

acu_de.log /usr/ibm/common/asci/logs/root C:\Program Files\IBM\Common\asci\logs\Administrator

Deployment Engine

de.cbe.log /usr/ibm/common/asci/logs/root C:\Program Files\IBM\Common\asci\logs\Administrator

Deployment Engine

de_install.log /usr/ibm/common/asci/logs/root C:\Program Files\IBM\Common\asci\logs\Administrator

Deployment Engine

de_msg.log /usr/ibm/common/asci/logs/root C:\Program Files\IBM\Common\asci\logs\Administrator

Deployment Engine

de_trace*.log /usr/ibm/common/asci/logs/root C:\Program Files\IBM\Common\asci\logs\Administrator

Deployment Engine

si_trace.log /usr/ibm/common/asci/logs/root C:\Program Files\IBM\Common\asci\logs\Administrator

Deployment Engine

si_msg.log /usr/ibm/common/asci/logs/root C:\Program Files\IBM\Common\asci\logs\Administrator

Deployment Engine

si_cbe.log /usr/ibm/common/asci/logs/root C:\Program Files\IBM\Common\asci\logs\Administrator

Composite Offering Installer

install folder /opt/tivoli/tsm/_uninst/plan (Chosen install directory)\\_uninst\plan

Composite Offering Installer

inventory folder

/opt/tivoli/tsm/_uninst/plan (Chosen install directory)\\_uninst\plan

DB2 tmp folder /opt/tivoli/tsm/_uninst/plan (Chosen install directory)\\_uninst\plan

DB2 logs folder /opt/tivoli/tsm/_uninst/plan (Chosen install directory)\\_uninst\plan

Tivoli Storage Manager Administration Center

logs folder /opt/tivoli/tsm/AC/ISCW61 (Chosen install directory)/AC/ISCW61


Code description of various exit error codes in InstallAnywhereThe following list describes these exit error codes:

� 0 - Success: The installation completed successfully without any warnings or errors.

� 1 - The installation completed successfully, but one or more of the actions from the installation sequence caused a warning or a non-fatal error.

� -1 - One or more of the actions from the installation sequence caused a fatal error.

� 1000 - The installation was cancelled by the user.

� 1001 - The installation includes an invalid command line option.

� 2000 - Unhandled error.

� 2001 - The installation failed the authorization check, it might indicate an expired version.

� 2002 - The installation failed a rules check. A rule placed on the installer itself failed.

� 2003 - An unresolved dependency in silent mode caused the installer to exit.

� 2004 - The installation failed because not enough disk space was detected during the execution of the Install action.

� 2005 - The installation failed while trying to install on a Windows 64-bit system, but installation did not include support for Windows 64-bit systems.

� 2006 - The installation failed because it was launched in a UI mode that is not supported by this installer.

� 3000 - Unhandled error specific to a launcher.

� 3001 - The installation failed due to an error specific to the lax.main.class property.

� 3002 - The installation failed due to an error specific to the lax.main.method property.

� 3003 - The installation was unable to access the method specified in the lax.main.method property.

� 3004 - The installation failed due to an exception error caused by the lax.main.method property.

� 3005 - The installation failed because no value was assigned to the lax.application.name property.

� 3006 - The installation was unable to access the value assigned to the lax.nl.java.launcher.main.class property.

� 3007 - The installation failed due to an error specific to the lax.nl.java.launcher.main.class property.

� 3008 - The installation failed due to an error specific to the lax.nl.java.launcher.main.method property.

� 3009 - The installation was unable to access the method specified in the lax.nl.launcher.java.main.method property.

� 4000 - A Java executable could not be found at the directory specified by the java.home system property.

� 4001 - An incorrect path to the installer jar caused the relauncher to launch incorrectly.


Chapter 19. Tivoli Storage Manager V6.1 Backup-Archive Client update and installation changes

In this chapter we present an overview of the changes to Tivoli Storage Manager V6.1 Backup-Archive Client. An installation of a Tivoli Storage Manager V6.1 Client on the Windows platform is included.

19


19.1 Backup-Archive Client updates

The Tivoli Storage Manager Backup-Archive Client helps you protect information on your computers. You can maintain backup versions of your files that you can restore if the original files are damaged or lost. You can also archive files that you do not currently need, preserve them in their current state, and retrieve them when necessary.

The Tivoli Storage Manager clients work in conjunction with the Tivoli Storage Manager server. Set up your Tivoli Storage Manager server to obtain backup or archive access to the server. Refer to the server publications to install and configure a Tivoli Storage Manager server:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.nav.doc/c_product_overview.htm

19.1.1 New function in Tivoli Storage Manager V6.1

In this section we provide an overview of the enhancements to the Backup-Archive Client in Tivoli Storage Manager V6.1:

� NetApp Snapshot Difference API (SnapDiff API) support:

When used with the incremental command, the snapdiff option streamlines the incremental process by performing an incremental backup of the files reported as changed by the NetApp Snapshot Difference API, instead of scanning the volume looking for files that have changed.

The diffsnapshot option controls whether Tivoli Storage Manager should create the differential snapshot when performing a snapdiff incremental backup. If the differential snapshot is not created by Tivoli Storage Manager, the latest snapshot found on the volume is used as the differential snapshot and as the source for the backup operation

The default value is to create the differential snapshot. This option is ignored the first time the snapdiff option is used. The first time the snapdiff option is used on a volume, a snapshot must be created and used as the source for a full incremental backup. Snapshots that are created by Tivoli Storage Manager are deleted by Tivoli Storage Manager after the next incremental snapdiff backup is complete.

Snapshots can be created with the NetApp FilerView® tool. Use the latest parameter if you want Tivoli Storage Manager to use the most recent snapshot that was created. Whatever method is used to create named snapshots, snapshot names differing only by case will not work properly with the snapdiff option. Snapshots that are created by Tivoli Storage Manager will not have the case problem.

Snapshots created by methods outside of Tivoli Storage Manager are never deleted by Tivoli Storage Manager. This option is valid for all Windows clients, except for IA 64-bit.

� Full VM backup and restore support:

The Tivoli Storage Manager backup VM command has been enhanced to provide full VM backup capabilities in addition to the file-level backup capabilities previously provided. You can copy full VM virtual disk exports to the backup proxy from snapshots. The entire virtual machine is backed up as a single item, similar to a Tivoli Storage Manager image backup. The exports are broken into 2 GB file chunks that the Tivoli Storage Manager Backup-Archive Client backs up at a file level.

The backup VM command backs up virtual machines that are specified in the VMLIST option. The backup VM command is used to back up VMware virtual machines from the VMware Consolidated Backup proxy system.


http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=/com.ibm.itsm.nav.doc/c_product_overview.htm

� Support for restoring Active Directory individual objects:

You can use Active Directory individual object recovery and item-level restore during normal day-to-day operations to recover from accidental corruption or deletion of Active Directory objects by restoring one or more individual Active Directory objects. This feature does not require you to shut down or restart the Active Directory server

You can use the adlocation option with the query adobjects or restore adobjects commands to indicate whether the Active Directory objects are to be queried or restored from the local Active Directory Deleted Objects container or from a system state backup on the Tivoli Storage Manager server. The adlocation option is only valid for Windows Server 2003 and Windows Server 2008 clients only. The Tivoli Storage Manager client API does not support this option.

� The query adobjects command:

Use the query adobjects command to display information about the deleted objects that are located on the local Active Directory domain. On Windows Server 2008 clients, Active Directory object information can also be displayed from full system-state backups on the server. This command is valid for the Windows Server 2003 and Windows Server 2008 clients only

� The Windows Native GUI has been replaced with the Java GUI:

The Windows GUI is a Java application. The non-Java Windows Native GUI is installed as dsmmfc.exe in the installation directory. However, it has not been updated with the new Tivoli Storage Manager Version 6.1 features.

� Support for the querysummary option:

You can use the querysummary processing option to extend the query archive and query backup commands. This support provides a restore preview so that you can determine whether to use the classic or no-query restore method.

� Support for the srvoptsetencryptiondisabled option:

You can use the srvoptsetencryptiondisabled processing option to ignore encryption options in a client options set from a Tivoli Storage Manager server.

� Mac OS X-specific information:

– The Tivoli Storage Manager for UNIX and Linux Backup-Archive Clients Installation and User's Guide includes the Mac OS X-specific information.

– The Tivoli Storage Manager for Mac OS X Backup-Archive Client now supports the NLS languages supported by the Tivoli Storage Manager.

– The Tivoli Storage Manager API is now supported on Mac OS X.

� Improved memory usage for backup of Hierarchical Storage Management (HSM) managed file systems:

The Tivoli Storage Manager Backup-Archive Client can do a full incremental backup of very large HSM managed file systems containing 100,000,000 files or more.

� UTF-8 encoding support is added for Tivoli Storage Manager UNIX and Linux clients:

UTF-8 is added for the language locales that are already supported by the Tivoli Storage Manager Backup-Archive Client.

The Tivoli Storage Manager Version 6.1 client message catalogs and help files are encoded in UTF-8. If you are installing Tivoli Storage Manager client message catalogs for languages other than English, you must also have the appropriate iconv UTF-8 converters installed on your system. If the appropriate iconv UTF-8 converters are not installed, all Tivoli Storage Manager client messages will be displayed in English.

Chapter 19. Tivoli Storage Manager V6.1 Backup-Archive Client update and installation changes 409

� Availability of 64–bit binaries:

The client packages for Linux on POWER, Linux zSeries, and one of the AIX clients contain 64-bit binaries.

� Enhanced help facilities:

The command-line client help command is enhanced so that you can specify the command, option, or message on which you want help information.

In the graphical user interface, message boxes are enhanced with a button that you can click to see detailed message information.

19.1.2 Related commands

In this section we describe the various commands that you can use.

� help:

Use the help command to display information about commands, options, and messages.

� query archive:

The query archive command displays a list of your archived files and the following information about each file: file size, archive date, file specification, expiration date, and archive description.

� query backup:

The query backup command displays a list of backup versions of your files that are stored on the Tivoli Storage Manager, or that are inside a backup set from the server when the backupsetname option is specified.

� querysummary:

The querysummary option provides statistics about files, directories and objects that are returned by the query backup or query archive commands.

� restore adobjects:

Use the restore adobjects command to restore individual Active Directory objects from the local Deleted Objects container. On Windows Server 2008 clients, individual Active Directory objects can also be restored from full system-state backups on the Tivoli Storage Manager server.

� restore VM:

Use the restore VM command to restore a full VM backup, and to return the full VM backup files to the vmbackdir directory on the backup proxy. The VMware converter program can be used to move the restored files back to a running state on a VMware server.

� set password:

The set password command changes the Tivoli Storage Manager password for your workstation. If you omit the old and new passwords when you enter the set password command, you are prompted once for the old password and twice for the new password.

� snapdiff:

The snapdiff option is for backing up NAS/N-Series file server volumes that are NFS or CIFS attached.

� srvoptsetencryptiondisabled:

The srvoptsetencryptiondisabled option allows the client to ignore encryption options in a client options set from a Tivoli Storage Manager server.


� stagingdirectory:

The stagingdirectory option defines the location where the client can keep any data it generates in order to perform its operations. The data is deleted when processing is complete.

� vmbackdir:

Use the vmbackdir option with the backup VM command to specify the location that VMware Consolidated Backup will use to export and copy the full VM files before Tivoli Storage Manager sends them to the server when performing a full VM backup.

� vmbacknodelete:

Use the vmbacknodelete option with the backup VM command to specify that the full VM backup files copied to the backup proxy should not be deleted at the end of the backup.

� vmbackuptype:

Use the vmbackuptype option with the backup VM or query VM commands to specify the type of VMware backup to complete on the backup proxy. You can specify either a file-level backup or a full VM backup

19.2 Installation of the Tivoli Storage Manager V6.1 client

In this section we discuss how to install a Tivoli Storage Manager client.

19.2.1 Migrating from earlier versions

The following section contains considerations when you are migrating to Tivoli Storage Manager Version 6.1 from a previous version or hardware platform. We provide guidelines to help prevent disruption to your backup and archive activities during the migration.

� An upgrade path for clients and servers is provided. As part of a migration plan from Tivoli Storage Manager Version 5.5 to Tivoli Storage Manager Version 6.1, Tivoli Storage Manager clients and servers can be upgraded at different times. This configuration is supported as long as the older version is supported.

� NAS backups performed on a Tivoli Storage Manager Version 6.1 server using the server’s BACKUP NODE command can only be restored using the server’s RESTORE NODE command or a Tivoli Storage Manager V6.1 client.

� A Tivoli Storage Manager Version 5.5 client can perform backup, restore, archive, and retrieve functions to a Tivoli Storage Manager V6.1 server.

� A Tivoli Storage Manager V6.1 client can perform backup, restore, archive, retrieve, and query functions to a Tivoli Storage Manager Version 5.5 server.

� If you back up or archive data from a Tivoli Storage Manager Version 5.4 or Version 5.5 client to any Tivoli Storage Manager server, you can restore or retrieve that data using a Tivoli Storage Manager V6.1 client.

� If you back up or archive data from a Tivoli Storage Manager V6.1 client, you cannot restore or retrieve that data using a Tivoli Storage Manager Version 5.5 or earlier client.

� All administrative clients can administer Tivoli Storage Manager Version 5.5 and V6.1 servers.

� The format of the Tivoli Storage Manager passwords stored in the Windows Registry has changed. If you install the Version 5.4.0 or later IBM Tivoli Storage Manager API client or Tivoli Data Protection, which is using the Tivoli Storage Manager API, and you attempt to


use the Version 5.3 or earlier IBM Tivoli Storage Manager Backup-Archive Client, you will be unable to start the Tivoli Storage Manager Backup-Archive Client Scheduler service or client acceptor daemon service.

� The method for processing system state data changed in Tivoli Storage Manager Version 5.5 such that system state (and system service) backup from prior clients is supported but no longer recommended. When you use the Tivoli Storage Manager Version 5.5 client, you will generate new system state backups using the new methods. You cannot perform the following operations:

– Generating a backup set with system state data. If you use the system state data backed up with the Tivoli Storage Manager Version 5.5 client to generate a backup set, you must be connected to a Tivoli Storage Manager Version 5.3.6 or later, Version 5.4.1 or later, or Version 5.5.0 server.

– Restoring system state and system services file spaces that were backed up by a Tivoli Storage Manager Version 5.4.x or earlier client.

– Using a Tivoli Storage Manager Client prior to Version 6.1 to restore system state backed up by a Tivoli Storage Manager Client Version 6.1 or above.

– Restoring the system state in certain situations: The Windows client can be regressed from Tivoli Storage Manager Version 5.5 to Tivoli Storage Manager Version 5.4 without any impact, except that system state backed up by the Tivoli Storage Manager Version 5.5 client cannot be restored by the Tivoli Storage Manager Version 5.4 client. If the system had not yet been backed up by the Tivoli Storage Manager Version 5.5 client, but was still the version backed up at the Tivoli Storage Manager Version 5.4 level, the Tivoli Storage Manager Version 5.4 client would be able to restore the system state. The system state would not be restorable by the Tivoli Storage Manager Version 5.4 client if the system state had already been backed up by the Tivoli Storage Manager Version 5.5 client.

– Specifying systemservices in the domain statement (for example, domain systemservices).

– Using the backup systemservices command.

– Using the restore systemservices command in normal production or recovery scenarios. Instead, you should use restore systemstate <service name> to restore a particular system service.

– Using the query systemservices command.

– Using the show systemservices command.

19.2.2 Considerations for migrating between processor architectures

When migrating between the Tivoli Storage Manager processor architectures (x32, x64, and IA64), there are some items that you need to consider for a successful migration from one architecture to another. Consider the following items when migrating from one processor architecture to another:

� The restore of DFS links backed up from 32-bit Windows environments to 64-bit Windows environments, is not supported.

� The restore of DFS links backed up from 64-bit Windows environments to 32-bit Windows environments, is not supported.

� System state or system object data is incompatible between different processor architectures. Therefore, when migrating client data between different processor architectures, it is recommended that you avoid backing up the system object or system state data from one architecture into the same file spaces containing the system object or system state data from another architecture.


To avoid commingling the data, before the migration, you can ask your Tivoli Storage Manager administrator to do either of the following actions:

– Rename the existing system object or system state file spaces. After the migration is complete and you have new backups of the system object or system state data, your Tivoli Storage Manager administrator can delete the renamed file spaces. The file spaces to rename include one or more of the following:

• SYSTEM OBJECT• SYSTEM STATE• SYSTEM SERVICES• ASR

– Delete the existing file spaces (listed above) for your node.

Renamed file spaces remain on the server and are managed as stabilized file spaces. These file spaces contain all the original data, which can still be restored until the file spaces are deleted. You can find additional information in the IBM Tivoli Storage Manager for Windows Administrator’s Guide V6.1, SC23-9773.

19.2.3 Unicode considerations

In this section we discuss Unicode considerations:

� When an existing file space is renamed during Unicode conversion, any access rules defined for the file space remain applicable to the original file space. New access rules must be defined to apply to the new Unicode file space, if necessary.

� When backing up files to a file space that is not Unicode-enabled, the Unicode-enabled client skips the files and directories with names containing characters from a code page other than the current locale.

� If files and directories with names containing characters from a code page other than the current locale were previously backed up with a client that was not Unicode-enabled, Tivoli Storage Manager will expire them in the file space that is not Unicode-enabled. However, the Unicode-enabled client can back up or archive these files to a Unicode-enabled file space.

� When migrating from a client that is not Unicode-enabled to a Unicode client, file names with double-byte characters mixed with single-byte characters might be restored in mixed single-byte character set (SBCS) format. This is only a display issue.

� When a client performs a selective backup of an object and the original file space is renamed, the new Unicode-enabled file space contains only that object. Tivoli Storage Manager will back up all other directories and file spaces during the next full incremental backup.

� The Unicode-enabled client has a file and directory name size limitation of 504 bytes. Depending on the Unicode characters (2-byte, 3-byte, or 4-byte) used, this translates to a maximum of 126 to 252 characters.

Important: If you do not follow the migration instructions properly, you might have two file spaces, one Unicode and one non-Unicode, with different file space identifiers (fsID) for the same client volume. In this case, the Tivoli Storage Manager client uses the non-Unicode file space as the default file space for backup and restore operations.


19.2.4 Additional migration information

This section explains some additional information that you need to know when migrating your Tivoli Storage Manager client.

When you install the Web client, you must install the Web-client language files that correspond to those languages you want to use. The Windows GUI has been migrated to a Java application, and it is the default application. The non-Java Windows native GUI is installed as the dsmmfc.exe file in the installation directory, but it has not been updated with the new Tivoli Storage Manager Version 6.1 features.

To view the non-English online help from the Web Client applet, you must install the language versions of the help files on the agent, the system where the Tivoli Storage Manager Backup-Archive client was installed. If the language versions are not installed or are not available, the online help will be displayed in English. A command-line administrative client is available on all UNIX, Linux, and Windows client platforms. See the client_message.chg file in the client package for a list of new and changed messages since the previous Tivoli Storage Manager release.

19.2.5 Upgrading Open File Support or online image

The Open File Support (OFS) and online image installation features have been replaced with a single Logical Volume Snapshot Agent (LVSA) feature. This feature is selected by default unless you are upgrading from an installation where OFS or online image was being used. You can install LVSA for use during both online image and OFS operations, but those features are not automatically enabled. To enable OFS, the snapshotproviderfs option must be set in the dsm.opt file, and to enable online image, the snapshotproviderimage option must be set in the dsm.opt file.

Volume Shadow Copy Service (VSS) is also supported for OFS and online image operations. You can enable VSS by setting the snapshotproviderfs and snapshotproviderimage options in the dsm.opt file. If you use VSS, you do not need to install LVSA. Use the Setup wizard to select NONE, VSS, or LVSA for each of the OFS and online image functions. If LVSA is selected and it is not already installed on your system, it will be installed.

If you are migrating from a previous version of the Tivoli Storage Manager client where you were using the LVSA for OFS or online image, and you decide during the installation to continue to use the LVSA, then you do not need to explicitly set the snapshotproviderfs or snapshotproviderimage options. Because you do not need to set these options, it is easier to install the new client on a large number of systems, because the dsm.opt file will not need to be updated to continue to use the OFS or online image functions.

19.2.6 NDMP support requirements (Extended Edition only)

Through support of Network Data Management Protocol (NDMP), Tivoli Storage Manager can efficiently back up and restore NAS file systems to tape drives or libraries that are locally attached to Network Appliance and EMC Celerra NAS file servers. NDMP support is available only on IBM Tivoli Storage Manager Extended Edition.

NDMP support requires the following hardware and software:

� Tivoli Storage Manager Extended Edition

For supported combinations of tape drive and tape library, refer to:




19.2.7 Installing from the Tivoli Storage Manager DVD

The UNIX and Linux client images are contained on several Tivoli Storage Manager product DVDs. Refer to the following Web site for the program directories with information about available UNIX client installation media:


The Tivoli Storage Manager Windows client is included on the desktop client installation DVD in the setup directory structure.

You can install the clients using any of the following methods:

� Install directly from the DVD.

� Create client images to install.

� Transfer installable files from the DVD to a target workstation. You can copy all of the clients to your server workstation so that client workstations can get the files from the x:\tsmcli directory. The following sample command is for Windows:

xcopy h:\setup\* x:\ /s

19.2.8 Installation steps

Before installing the software on your workstation, stop all instances of the Tivoli Storage Manager client (for example, services, interactive clients). If the Logical Volume Snapshot Agent (LVSA) component is selected for install, a reboot is required to install or update the tsmlvsa.sys filter driver.

The supported Windows platforms are:

� Windows XP� Windows Vista� Windows Server 2003� Windows Server 2003 R2� Windows Server 2008.

To install the software on your Windows system, follow these steps:

1. Insert the DVD that contains the Tivoli Storage Manager Windows client into your DVD drive. If you have autorun enabled, the installation dialog should start when the DVD loads. If the installation dialog does not start automatically, you can start it manually.

Select Run from the Start menu and at the prompt, type: x:\setup where x is your DVD drive. Click OK.

2. Follow the instructions displayed on the panel. If files from a previous version are in the installation directory, the Windows installer presents the option to Modify, Repair, or Remove. To install a new version of the product, first remove the currently installed version using the Remove option. To add a component that was not initially installed, select the Modify option.

Note: All of the examples in this chapter use the h drive as the DVD or mounted drive. Substitute h with the DVD drive of your system.



Language packs The Tivoli Storage Manager client now makes use of language packs for non-English language support. Each supported language has its own installation package that must be installed in order to use Tivoli Storage Manager in a supported, non-English language. The Tivoli Storage Manager client is a prerequisite for installing a Tivoli Storage Manager Client Language Pack.

Additional considerationsHere are some more considerations regarding the various clients:

� The Backup-Archive Client, the API, and the Web Client are interdependent. If you select the Backup-Archive Client, you must also select the API. Similarly, if you select the Web client, you must also select the Backup-Archive Client and the API.

� The Backup-Archive Client component includes the client scheduler files.

� The installer displays the exact amount of disk space that is required for each program feature. Ensure that there is enough disk space on the destination drive for the files you choose to install. The installation program will not install to a destination drive with insufficient disk space.

19.2.9 Installation steps

In this section we describe the installation steps using the setup wizard:

1. If you do not have a dsm.opt file, a setup wizard is launched automatically when you start the GUI (see Figure 19-1). The setup wizard can help you configure an initial options file. Select Install Products from the Main Menu.

Figure 19-1 Installation of the Tivoli Storage Manager Client Version 6.1.0.0 Main Menu


2. From the Install Products window, select Tivoli Storage Manager Backup-Archive Client as shown in Figure 19-2.

Figure 19-2 Install Products window of the Tivoli Storage Manager Client Version 6.1.0.0

3. The next window is the Choose Setup Language as shown in Figure 19-3. After selecting your preferred language, click OK to continue.

Figure 19-3 Installation of the Tivoli Storage Manager Client Version 6.1.0.0


4. The InstallShield Wizard opens as shown in Figure 19-4.

Figure 19-4 Instal Shield Wizard of the Tivoli Storage Manager Client Version 6.1.0.0

5. The next window allows you to specify the destination folder (see Figure 19-5). You can accept the default or click Change in order to specify your installation destination. Click Next to continue.

Figure 19-5 Specify Destination Folder


6. Next you choose the type of install: Typical or Custom.

– Typical installs the minimum necessary to provide normal backup and archive functions. This includes the Backup-Archive Client, the API Runtime files, and the Web Client.

– Custom install takes you to the Custom Setup window. From this window, you can click any program feature icon to modify that feature if it is not mandatory for installation. You can select from the following program features:

• Backup-Archive Client• Backup-Archive Client GUI Files (Mandatory; cannot be deselected)• Backup-Archive Client Web Files (Mandatory; cannot be deselected)• Client API Runtime Files (Mandatory; cannot be deselected)• Client API SDK Files (Optional)• Administrative Client Command Line Files• Logical Volume Snapshot Agent (LVSA) (Optional; not enabled by default)

7. In our lab environment, we chose Custom install, so you can see the available options as shown in Figure 19-6. Click Next to continue.

Figure 19-6 Setup Type for installation of the Tivoli Storage Manager Client


8. The Custom Setup window is displayed as shown in Figure 19-7. You can select the available features and click Next to continue.


9. After specifying the install options, the Install Wizard is ready to install the Tivoli Storage Manager Client as shown in Figure 19-8. You can either click Install to begin the Client install, Back to go to previous panels and modify your selections, or Cancel to exit the InstallShield Wizard. Here we have chosen to click Install.

Figure 19-8 Install Wizard is ready to begin the Tivoli Storage Manager Client installation


10.When the install is complete, you will be presented with a completion window as shown in Figure 19-9. Click Finish to continue.

Figure 19-9 Installation of the Tivoli Storage Manager Client completion window

11.You will then be prompted to restart your system after the Tivoli Storage Manager Client installation as shown in Figure 19-10.

Figure 19-10 Restart system option window

Tivoli Storage Manager client options file Configuration WizardHere we show the use of the Configuration Wizard:

1. If the Tivoli Storage Manager client GUI does not detect an options file when you run it, it will automatically launch the Configuration Wizard to help you create one (see Figure 19-11). Click Next to continue.


Figure 19-11 Client Options File Configuration Wizard

2. Your first choose whether to Create a new options file, Upgrade my options file, or Import from an existing options file for use. Because this is a new client install, the option to Update my options file is greyed out. We select to Create a new options file, and click Next to continue as shown in Figure 19-12.

Figure 19-12 Select how to proceed with the Client options file


3. Next you specify the Client Node Name as shown in Figure 19-13. We specified ITSO-BA1. Click Next to continue.

Figure 19-13 Specify Client Node Name

4. The TSM Client/Server Communications window is shown in Figure 19-14. One of the most important purposes of the options file is to specify the communication protocol necessary to establish communications between your backup client and the backup server. For our installation, we select TCP/IP. Click Next to continue.

Figure 19-14 ITSM Client/Server Communications window


5. After specifying TCP/IP, we need to enter the IP address of the Tivoli Storage Manager Server or the address of the server as shown in Figure 19-15. We specified the Tivoli Storage Manager server name and accepted the default port number. Click Next to continue.

Figure 19-15 Tivoli Storage Manager server name or IP address and communication port

6. Figure 19-16 shows the recommended Include/Exclude list. You can select the entire list or specific files. When you have made your choice, click Next to continue.



7. The Common File Exclusion Selection window presents common file Extensions that you might want to exclude from backup. You can select all the file extensions or specific ones. After you have made your choice, click Next to continue (see Figure 19-17).


8. The Domain for Backup window is displayed. Here you select to back up all local file systems or specify specific drives. You also specify the type of backup to perform (see Figure 19-18).

Figure 19-18 Specify the drives to back up


9. After you have made your choices for the Client Options file, you are given the option to go back and make changes of apply the changes and save the TSM Client Options to disk (see Figure 19-19). Click Apply to continue.

Figure 19-19 Create the TSM Client Options file

10.When the TSM Client Options file has been saved, you will be presented with the window in Figure 19-20. Click Finish to close the wizard.

Figure 19-20 TSM Client Options wizard is complete


11.You can now login the Tivoli Storage Manager client server as shown in Figure 19-21.

Figure 19-21 Log in to the Tivoli Storage Manager Client Version 6.1.0.0

12.Figure 19-22 shows the options you are presented based on the Tivoli Storage Manager Client Options file.

Figure 19-22 Welcome to Tivoli Storage Manager Client Version 6.1.0.0


Part 8 Tivoli Storage Manager V6.1 monitoring, reporting, ISC, and Administration Center

This part of the book covers the monitoring and reporting capabilities provided in Tivoli Storage Manager V6.1 along with the ISC and Administration Center.

Part 8


Chapter 20. Monitoring and reporting in Tivoli Storage Manager V6.1

In this chapter we explain monitoring and reporting in Tivoli Storage Manager V6.1. For this release of Tivoli Storage Manager, we have introduced a new system for reporting, which is based on components commonly used in many other Tivoli Monitoring products.

Tivoli Storage Manager Monitoring and Reporting is designed as a standalone package that can install everything on one system (however, this system must be separate from your Tivoli Storage Manager V6.1 servers). The code for the new system is a separate installable package; it is not built into the Tivoli Storage Manager Server code.

20


20.1 Monitoring and reporting overview

Tivoli Storage Manager Monitoring and Reporting is a new package with Tivoli Storage Manager V6.1, which provides a set of new features supporting connections with Tivoli Storage Manager Servers at levels 5.4, 5.5, and 6.1. It replaces and improves upon the older “Operational Reporting” tool, which is no longer included, from Tivoli Storage Manager V6.1 onward. In addition to this new package, there are still the built-in tools within the Web-based ISC, which allow a user to run basic reports against Tivoli Storage Manager without the need for Monitoring and Reporting to be installed.

Overall, the Tivoli Storage Manager V6.1 Monitoring and Reporting components are as follows:

� Tivoli Storage Manager Administration Center (Health Monitor): This component is used to see the health status of a Tivoli Storage Manager Server. This feature does not need the Monitoring and Reporting package to be installed in order to work. It connects to Tivoli Storage Manager Server by a Tivoli Storage Manager administrative user connection.

� Tivoli Storage Manager Administration Center (Reporting): This is a basic set of reports that can be run directly on the Tivoli Storage Manager Server. This feature does not need the Monitoring and Reporting package to be installed in order to work. It connects to Tivoli Storage Manager Server by a Tivoli Storage Manager administrative user connection.

� Tivoli Storage Manager Monitoring: This new feature consists of real-time reporting from Tivoli Storage Manager. From a user perspective, it is available from the Tivoli Event Portal (TEP) component of IBM Tivoli Monitoring (ITM). This feature needs the Monitoring and Reporting package to be installed in order to be available. It connects to Tivoli Storage Manager Server by a Tivoli Storage Manager administrative user.

� Tivoli Storage Manager Reporting: This new feature consists of reports that are run against a database of events captured by the Tivoli Storage Manager Monitoring component. The reports are shown in a separate part of the ISC from Tivoli Storage Manager, called “Tivoli Common Reporting”, and the reports are run against a database installed for the purpose, called Tivoli Data Warehouse (TDW). This feature needs the Monitoring and Reporting package to be installed in order to be available, and depends on Monitoring being installed and working. It does not connect directly to a Tivoli Storage Manager Server; instead it extracts data from Tivoli Storage Manager Monitoring.

20.1.1 Administration Center: Health Monitor

The Tivoli Storage Manager Administration Center GUI has a feature called “Health Monitor” whose purpose is to allow an administrator a quick way to see the health of a Tivoli Storage Manager Server. “Health Monitor” is shown in Figure 20-1. This feature is a part of the ISC, and is separate from the rest of the Monitoring and Reporting features. It has not changed substantially since the level 5.5 release of Tivoli Storage Manager.


Figure 20-1 Heath Monitor from the Tivoli Storage Manager Administration Center

20.1.2 Administration Center: Reporting

As in previous versions, the Tivoli Storage Manager Administration Center has a section called “Reporting”, as shown in Figure 20-2. This has not been removed with the upgrade to Tivoli Storage Manager V6.1, however it is unconnected with the new “Monitoring and Reporting” package.

This feature is most useful on standalone Tivoli Storage Manager Servers without the optional Monitoring and Reporting server installed, because it provides a basic usage report, and separate basic security report. It works by connecting straight to the Tivoli Storage Manager Server by a Tivoli Storage Manager administrative connection, it does not require any other infrastructure.

Figure 20-2 Reporting section of Administration Center

Chapter 20. Monitoring and reporting in Tivoli Storage Manager V6.1 433

20.1.3 Tivoli Storage Manager Monitoring and Reporting

Tivoli Storage Manager V6.1 Monitoring and Reporting is a new package that consists of existing and new IBM products. All of them are new to the Tivoli Storage Manager product, although most have been used in other Tivoli products.

The principal components of the new Tivoli Storage Manager Monitoring feature are:

� IBM DB2

� IBM Tivoli Monitoring (ITM)

� IBM Tivoli Enterprise Portal (TEP)

– Tivoli Storage Manager/TEP Workspaces

For Tivoli Storage Manager Reporting, we also have the following features:

� IBM Tivoli Data Warehouse (TDW)

� Tivoli Common Reporting (TCR)

– Tivoli Storage Manager/TCR report definitions– Business Intelligence and Reporting Tools (BIRT):

Allows users to create customized reports for use with TCR (optional)

� Tivoli Storage Manager Integrated Solution Console and Administration Center (ISC)

– This hosts the TCR component, which reports on data in the TDW.

Monitoring and Reporting uses the standard Tivoli Storage Manager Deployment Engine for installation, so while this list looks large, the package is actually straightforward to install. The basic components (DB2, ITM, TEP, TDW) are included in one installation package for your convenience. The additional BIRT package is separate, and BIRT is only required if you want to create customized reports: it is not mandatory if the built-in reports are sufficient, or if you are downloading preconfigured reports from another source (for example, from Tivoli OPAL).

Setup optionsThere are a couple of options when setting up Monitoring and Reporting:

� For customers with an already existing licensed ITM setup, Tivoli Storage Manager can make use of this, provided it is at level 6.2 FP1.

� For customers with no existing ITM setup, Tivoli Storage Manager provides a complete version, which is usable for monitoring Tivoli Storage Manager only. With this option, the Monitoring and Reporting system must comply with the requirements listed on the planning section of the Tivoli Storage Manager documentation: principally that the Monitoring and Reporting system has a server of its own. Although is not supported to install Monitoring and Reporting on the same system as the Tivoli Storage Manager 6.1 server, using a separate VM or LPAR would be fine.

Monitoring and Reporting functionsHere we list the main functions:

� You can monitor and report on 5.4, 5.5, and 6.1 servers.

� There is no need to license DB2, ITM, or TCR separately.

� The server installs on Windows, AIX, and Linux86 platforms.

� You can manage Tivoli Storage Manager Servers on any supported platform.

� It is a new stand-alone monitoring and reporting server based on IBM Tivoli Monitoring (ITM) and Tivoli Common Reporting (TCR).


� The monitoring agent installs directly on selected server platforms or runs on the monitoring server.

� It uses Deployment Engine to install all components easily.

� It provides a new Reporting and Monitoring solution for Tivoli Storage Manager.

� It will report on any Tivoli Storage Manager server at or later than version 5.3.

� It compliments and integrates with Tivoli Storage Manager Administration Center.

� It is “light” enough to be installed to manage a single Tivoli Storage Manager server.

� It is scalable enough to manage a farm of Tivoli Storage Manager servers.

� It integrates with reporting tools from other IBM products.

� It integrates with monitoring tools from other IBM products.

Reporting and Monitoring frequently asked questionsNext we list some frequently asked questions or points to be aware of regarding Reporting and Monitoring.

How does a user see Reporting and Monitoring?� The reporting GUI is the Tivoli Storage Manager Administration Center

� The monitoring GUI is TEP

Can Monitoring be installed without Reporting?� Yes

Can Reporting be installed without Monitoring?� No

Is it supported and downloadable for Tivoli Storage Manager 5.x Servers?� Yes

Can it be installed on the Tivoli Storage Manager Server?� For Tivoli Storage Manager 5.x: Yes, but not recommended, due to resource

consumption.

� For Tivoli Storage Manager 6.1: No, not supported, due to conflicting DB2 Versions.

� We recommend installing the standard Tivoli Storage Manager Administration Center and Reporting/Monitoring on the same server to manage multiple mixed Tivoli Storage Manager Servers.

Is it all in one installation package?� Yes, all required components will automatically install.

What about the old Tivoli Storage Manager Operational Reporting� It will be discontinued. Tivoli Storage ManagerV6.1 changes are incompatible with

Operational Reporting.

Is scheduling built-into the product?� Not yet, it is under consideration for future releases.

Do I need extra licenses?� No, it is part of Tivoli Storage Manager Base/EE


Do I need to write my own Monitors or Reports?� No, we deliver pre-configured Monitors and predefined Reports.

Can I write my own reports?� Yes, they can be developed with BIRT using Eclipse 3.3.1.1

Can customers customize their own Monitors?� Yes, it is very easy in TEP.

Does it plug in to an existing ITM installation?� Yes, you can see Tivoli Storage Manager Monitoring as well as all other ITM Monitors

(license required).

Does it plug into an existing Tivoli Storage Manager Administration Center installation?

� Yes, we recommend to use one server for managing/reporting/monitoring Tivoli Storage Manager. It plugs into Tivoli Storage Manager V6.1 Administration Center only.

Can I monitor and report on multiple Tivoli Storage Manager Servers?� Yes, you can even monitor and report on different Tivoli Storage Manager versions.

Note: We recommend a service engagement to create custom reports, because BIRT is not trivial.

Note: The Tivoli Storage Manager V6.1 server for the AIX, HP-UX, Linux, and Sun Solaris platforms now allows other products that deploy and use DB2 to be installed on the same machine. The Tivoli Storage Manager V6.1 product publications originally listed this as being a restriction. After further evaluation, this restriction is removed, and a future revision to the publications will reflect this.


20.2 Monitoring and reporting installation

Tivoli Storage Manager allows other products that use the DB2 product to be deployed and used on the same system if the following criteria or considerations are met:

1. The other products that use the DB2 product are using DB2 version 9 or later. The DB2 products introduced product encapsulation and segregation support beginning with DB2 V9 and later. This support allows for running multiple copies of DB2 on the same system and at different code levels. The following link documents this DB2 support along with extensive information:

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.admin.dbobj.doc/doc/r0024057.html

2. When you install different DB2 products on the system that has the Tivoli Storage Manager V6.1 server, ensure that the user IDs, fence user IDs, installation location, other directories, and related information that you specify are different from all the IDs and locations that you used for the Tivoli Storage Manager server installation and configuration. If you used the dsmicfgx wizard or dsmupgdx wizard to configure or upgrade the server, these are values that you entered when running the wizard. If you used the manual configuration or upgrade procedures, review the procedures that you used if necessary, to recall the values that were used for the server.

3. Carefully consider the resources and capability of the system that is being used for Tivoli Storage Manager along with the requirements for other products that use the DB2 product. To provide sufficient resources for the other DB2 applications, you might need to change the Tivoli Storage Manager settings on the system to allow the server to use less system memory and resources. Similarly, if the workloads for the other DB2 applications compete for CPU or memory resources with the Tivoli Storage Manager server, the performance of the Tivoli Storage Manager server might be adversely affected in its ability to service the desired client workload or other server operations that are needed.

From a best-practices perspective, it might be appropriate to consider using LPAR, WPAR, or other virtual machine support to accomplish this. For example, running the other application that uses DB2 in its own virtualized machine segregates resources and provides more capability for the tuning and allocation of CPU, memory, and other system resources to this application as well as the resources available to Tivoli Storage Manager.

Note for Windows systems: The current restriction that is documented in the Tivoli Storage Manager publications for the installation of other DB2 versions (or applications that deploy and use DB2) on the same Windows system as a Tivoli Storage Manager V6 server is still in place and is not affected by the support discussed here. Similar support for Windows systems is currently being evaluated. Assuming that the testing and evaluation do not uncover any issues to prevent it, the target is to remove this restriction by year end 2009.


http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.admin.dbobj.doc/doc/r0024057.html

20.3 Installing the Monitoring and Reporting feature

Before you can use the new Monitoring and Reporting feature, you have to install it. This process currently requires a separate server for installation. While it can be installed on Linux, AIX or Windows, for this demonstration example, we have deployed this feature on the Windows platform.

Monitoring and Reporting uses the Deployment Engine with a common user interface to the rest of the Tivoli Storage Manager V6.1 installers. The package for Monitoring and Reporting is separate from the Tivoli Storage Manager Server package.

Here are the steps in the installation process:

1. Upon extracting the code and invoking the installer, the first panel is the Welcome panel of Tivoli Storage Manager for Reporting and Monitoring install. It contains license information. Click Next to continue as shown in Figure 20-3.

Figure 20-3 Tivoli Storage Manager for Reporting and Monitoring installer Welcome panel


2. Next you select the components that you want to install. For our installation, we select all the components of Tivoli Monitoring and Reporting, as well as the ISC. The components will be installed on the Monitoring and Reporting server. The Tivoli Storage Manager server is separate from this. The only option that we do not select here is the Languages option, because we will be using the default English for our example, as shown in Figure 20-4.

Figure 20-4 Install options


3. The next window is the DB2 Enterprise Server Edition, where you provide the information required to create the DB2 database (see Figure 20-5). Enter the DB2 Administrator password and click Next to continue.

Figure 20-5 DB2 configuration setup


4. Figure 20-6 shows the Encryption key entry panel. We accepted the default encryption key. Click Next to continue.

Figure 20-6 SSL Encryption key entry


5. Figure 20-7 shows the Database Access Setup panel. Enter the password for the TEPS and ITMUser user ID. Note it, and click Next to continue.

Figure 20-7 DB2 database access password setup


6. Figure 20-8 shows the Administration Center credential entry panel. Enter the required information and click Next to continue.

Figure 20-8 ISC User name and Password for Administration Center credentials


7. Figure 20-9 is the Choose Install Folder window, where you specify the location of the Install destination folder. Accept the default or enter the installation directory for your server. Click Next to continue.

Figure 20-9 Installation Folder specification


8. Figure 20-10 shows the Pre-Installation Summary panel. Review the information. If you are satisfied with the information, click Install to continue.

Figure 20-10 Pre-Installation Summary window


9. Figure 20-11 shows the installation progress.

Figure 20-11 Installing Tivoli Storage Manager for Monitoring and Reporting


10.Figure 20-12 shows the completion of the Monitoring and Reporting Installation. The panel contains a summary of what was installed. Click Done to complete the install and exit.

Figure 20-12 Installation Summary

20.4 Business Intelligence and Reporting Tools

Business Intelligence and Reporting Tools (BIRT) is an open source tool from the eclipse.org foundation. It is aimed principally at the generation of reports in Web applications.

In order to generate customized reports for Tivoli Storage Manager, we use the BIRT editor to generate a report template. When this template is run inside Tivoli Storage Manager, it produces a report with data relevant to that timeframe (for example, the last 24 hours is a common timeframe). Although the template does not change from day to day, the resulting reports do. Each day the report reflects the activity of the previous day. We only actually use the BIRT designer to produce new or modified templates, if we want to change the data in a report (for example, to insert a new graph, so that the graph appears in the reports every day from then on).


Downloading Downloading BIRT is fairly simple, given access to a Web browser with Internet access. Download the All-In-One package from the BIRT Web site, which is available from:

http://download.eclipse.org/birt/downloads/

The actual package that we use in the Windows example is approximately 220 MB and is v2.5.0 of BIRT, although previous versions are also known to have worked. A redirect link to the code package is:

http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/galileo/R/eclipse-reporting-galileo-win32.zip

When the file is downloaded, simply unpack it to the location of your choice. After this is done, set the Java Virtual Machine location for BIRT to use. There are a couple of different ways to set this (for example, adding the java bin directory of the JVM to the PATH for the system).

An ideal way to do this under Windows is to create a shortcut to eclipse.exe, then modify the “properties” of the shortcut, setting the -vm parameter of Eclipse. By setting the JVM this way, you do not affect anything else on the system.

Note: BIRT is a Java tool, but it does not ship with a Java Virtual Machine (JVM). Without a JVM, it cannot run. The IBM JVM is installed along with the Monitoring and Reporting package from the Tivoli Storage Manager installation, so we can use that to run the BIRT code.

The default path of the IBM JVM on Windows is C:\Program Files\IBM\Java50\jre\bin.


http://download.eclipse.org/birt/downloads/

http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/galileo/R/eclipse-reporting-galileo-win32.zip

Chapter 21. Integrated Solutions Console and Administration Center

In this chapter we describe the new functions in Administration Center that were introduced in V6.1.

The Administration Center Web-interface provides an easy way to manage multiple server instances from a single browser window. It has been available as of Tivoli Storage Manager V5.3, and is hosted within the Integrated Solution Console (ISC) framework. The ISC is a general framework, supporting multiple modules that serve different purposes. The Administration Center module enables you to manage and monitor your Tivoli Storage Manager environment specifically.

21


21.1 Introduction

Starting in Tivoli Storage Manager V5.3, the Integrated Solutions Console was introduced, which in the beginning was of limited use to most Tivoli Storage Manager administrators, and from a user design and experience perspective, represented a 180 degree shift in how Tivoli Storage Manager management was done. The previous interface in V5.2 and prior was mostly accessed from an object perspective, and the ISC and Administration Center introduced a task driven perspective.

This design shift was intuitive for new administrators, and a challenge for the existing more experienced administrators, who struggled with locating tasks with in the GUI hierarchy. This operational gap was handled by extending the life of the ADMIN or WEBADMIN GUI, which was frozen at 5.2.x and its support extended until V5.5 new installations.

This release of the new ISC and Administration Center marks the first significant update in functionality since it was first introduced in V5.3, and applies some much anticipated improvements.

21.1.1 New installations

Both products, Administration Center and Integrated Solutions Console, are included in the Tivoli Storage Manager product distribution, and will be installed with the Tivoli Storage Manager server, as an optional component. In previous versions these components were distributed separately.

21.1.2 Upgrade and co-existence

When you install a V6.1 Tivoli Storage Manager server, you will have to install the matching Integrated Solution Console V7.1 and Administration Center V6.1. If you try to configure the Tivoli Storage Manager V6.1 server connection in the older ISC/AC, you will receive the error shown in Figure 21-1.

Figure 21-1 Down level error when Tivoli Storage Manager server is V6.1 and the ISC/AC is lower


Upgrading involves collecting the configuration information from a previous version of the Administration Center and duplicating it in the new version.

Coexistence involves running the Administration Center V6.1 on the same machine at the same time as you run the previous version. To support this coexistence, you need to provide non-default port assignments. For upgrade scenarios involving the possibility of rolling back to the previous version, you can choose to have the same port definitions and run either one version or the other.

If your disk space permits, having the two versions of the Administration Center coexist is the recommended upgrade strategy (using different IP ports). It lets users have a functioning Administration Center during the time that it takes for the upgrade to complete. It also ensures that the configuration of the previous Administration Center is still accessible during the upgrade procedure.

Upgrade does not uninstall the previous version, which is still functional. After the upgrade completes successfully, you can uninstall the previous Administration Center using the documented process.

21.1.3 Upgrade considerations

Both the new and older versions of the Integrated Solutions Console and the Administration Center components will co-exist on the same system, using different port references.

There has been significant change in the technologies on which the both the Integrated Solutions Console V7.1 and the Administration Center V6.1 are built. As a consequence, you must manually complete the upgrade of both packages by collecting the configuration information and re-creating this in the new configuration.

When upgrading from an earlier version of the Administration Center to Version 6.1, you must define your Integrated Solutions Console user IDs to the new Administration Center. In addition, you must provide credentials for each of the Tivoli Storage Manager servers.

If the current version of Administration Center is to be uninstalled, first obtain information about users and server credentials, then save the tsmservers.xml file, which is located in the install directory on the Administration Center.

When installing the Administration Center Version 6.1, note the following considerations:

� ISC user IDs are not recreated in the new Administration Center.

� The Tivoli Storage Manager server's database file and tsmservers.xml are copied from the earlier Administration Center, if located. The file format is compatible between versions.

� Tivoli Storage Manager server credentials are not recreated in the new Administration Center, thus you must manually duplicate the user configuration of your earlier Administration Center. Ensure that you:

– Obtain the information about users and server credentials from the earlier Administration Center.

– Define each ISC user previously defined to the earlier Administration Center.

– Define to each ISC user its set of Tivoli Storage Manager server connections.

– Uninstall the earlier Administration Center.

Chapter 21. Integrated Solutions Console and Administration Center 451

21.2 Administration Center updates and enhancements

Here we describe the Administration Center changes that have occurred in V6.1.

21.2.1 Policy Domain configuration panels

When making changes to the policy sets, the V6.1 Administration Center no longer validates and activates the changes.

21.2.2 Updated Integrated Solutions Console

In V6.1, the Administration Center is hosted by the IBM Integrated Solutions Console (ISC) Advanced Edition Version 7.1. After installation of the Integrated Solutions Console installation completes, open a Web browser and enter the following URL, which will display the logon panel for the Integrated Solutions Console:

https://local_host:9043/ibm/console

This panel indicates a successful installation of the Integrated Solutions Console. To learn about console updates:

� Start the ISC.� Click Help in the ISC banner.� In the Help navigation tree, click Console Updates.

Further discussion on the ISC updates can be found in the 21.4, “Integrated Solutions Console changes” on page 487.

21.2.3 WebSphere Windows service

In V6.1, the WebSphere Windows service is named Tivoli Storage Manager Administration Center - TsmAC.

21.3 Administration Center features in V6.1

Here we describe many features in the Tivoli Storage Manager Administration Center V6.1 that are new since V5.5.

21.3.1 Identify managing servers

The table of servers that is the hub of the enterprise-management work page has a column that identifies the managing server, if one exists, for each listed server. By sorting or filtering on the column, you can display the set of servers that are managed by a given server.

21.3.2 Hover help for table links

The Administration Center typically displays Tivoli Storage Manager objects in a table. In V6.1, when the cursor hovers over an object image, hover help text is displayed. The hover help identifies the default action that results when you click the link that is associated with the object.


21.3.3 Information links for server and Administration Center messages

When a problem or issue occurs with the server or Administration Center, you are immediately notified and provided with a brief message about the problem or issue. The message number is also provided. In V6.1, you can obtain detailed information about a message by clicking the link that is associated with the message number. The information is displayed in a new browser window.

21.3.4 Maintenance script enhancements

Tivoli Storage Manager utilizes a maintenance script to perform scheduled maintenance tasks. In V6.1, you can generate a maintenance script in one of two styles: predefined and custom.

� A predefined maintenance script is one that is generated through a wizard. This script contains standard commands that cannot be altered. A predefined script can only be modified in the wizard.

� A custom maintenance script is created using the Administration Center maintenance script editor. To have more control of your maintenance tasks, you can modify the commands that you specify. You can also use the editor to update your custom maintenance script.

21.3.5 Client nodes and backup sets enhancements

The redesigned Administration Center displays information about backup sets, client nodes, and client-node groups in one portlet. The design includes search functions that you can use to find and display information more quickly. When you select a client node, a summary panel is displayed with the current operation status, server actions, and client-node actions. The work item, Client nodes and backup sets, appears in the ISC navigation tree. See section “Client nodes and backup set enhancements” on page 467 for more detail on this topic.

21.3.6 Centralized server-connection management

In V6.1, server-connection tasks, such as adding a server connection, changing a password, and creating a server instance, are consolidated in a single location: the Manage Servers work item, located in the ISC navigation tree. With actions available in this work item, you can quickly upload server-connection information to the Administration Center using an XML file. This file can optionally include a set of server credentials for multiple servers. To help create an XML file, you can download a list of server connections, without the credential information.

21.3.7 Changes to management-class activation

In V6.1, Tivoli Storage Manager no longer activates changes to existing management classes automatically. You must activate the changes manually. Before the changes take effect, they are validated, and the results of the validation are displayed. You or another administrator can review them, and then either confirm or cancel the activation. Because changes are manually activated, you can prepare the management class in advance and activate the changes at an appropriate time.


21.3.8 DRM support for Active Data Pools

Changes to the Administration Center that are related to the Disaster Recovery Manager, are as follows:

� Disaster Recovery Management Property Notebook:

– New Tab Active Data Pools added with similar functionality to the Copy Pools Tab

� Volume Property Forms – for DRM or Remote DRM volumes:

– Display pool information for volumes associated with an active data pool

� (Long) Move DRMEDIA Wizard:

– Ability to overwrite Active Data Pool settings in addition to Copy pool settings– Relevant text updates at Welcome and Summary Panels

� Create Recovery Plan (Prepare) Wizard:

– Ability to overwrite Active Data Pool settings in addition to Copy and Primary pool settings

– Relevant text updates at Welcome and Summary Panels

– View Disaster Recovery Media/ View Remote Disaster Recovery Media actions (Off the DRM Servers Table)

� Update panel description to include active data pools:

– Reference in addition to copy pools reference

� View Disaster Recovery Media/View Remote Disaster Recovery Media Main Portlets:

– Update portlet table column header from Copy Pool to Destination Pool, referring to both Copy and Active data pools

� View Disaster Recovery Media/View Remote Disaster Recovery Media Main Portlets — Advanced Filter Form:

– Add new input field for Active-data pool, similar to the one for Copy pool filtering

21.3.9 Health Monitor

There are many new panels in the Administration Center that continue to add functionality to the interface. The health monitor option within the Administration Center is still relevant, regardless of the arrival of the new Reporting and Monitoring feature.

Why the Health Monitor is still requiredThe new Reporting and Monitoring solution is heavyweight, as it requires an additional server and installation of agents, and run on a completely separate browser instance with a different look and feel. The information reported on by ITM will be a slightly different set of information than the health monitor information, and presented for different views and perspectives.

This version has also copied the server processes and sessions section to the Health Monitor from the server properties notebook.

The reason for some of these changes was that server health details for V6.1 and higher servers are very different from V5.5 and previous servers, thus they needed a new design. This updated Health Monitor model is now aware of the server platform.


ChangesIn the following section we discuss changes to the health monitoring feature of the Administration Center.

Session and process information available in the health monitorThe Administration Center health monitor now includes information about server processes and sessions. The information is also available in the properties notebooks for servers.

Multi-threaded model introducedThis version of the Health Monitor moves from a single threaded sequential model to a multi-threaded model that scales better with the number of servers in the environment. This also improves performance as it now uses one thread per server, up to 8 threads by default.

Default changed to unlock the health monitorThe default value is now TRUE, and the ADMIN_CENTER credentials are now used for the client node cache information.

Resync health monitor passwordThis function of the health monitor uses threads and is much faster. For each server, it does a Q ADMIN ADMIN_CENTER command. If an ID does not exist, it creates one; if it is locked, it unlocks it; and sets the password to the current password used by the Administration Center. Then, it instantly starts a new worker thread to perform queries on that server.

Minor fixes incorporatedThe following minor fixes have been incorporated:

� Health Monitor did not have any knowledge of platform type; but now it does.� When checking drive counts, Health Monitor counted “offline” drives, missing

“unavailable” drives; this is now fixed. � Activity log counts reported by the health monitor at the top of the page did not match the

numbers in the table when you click the link. This is because the health monitor counts for the last 24 hours and are filtered, and the table uses unfiltered results from the last hour.

Tivoli Storage Manager server health monitoringAn additional feature is provided in V6.1 for Tivoli Storage Manager server health monitoring, which now allows for the administrator to follow links, drilling down into the server in question to query errors or status conditions. To access this new feature, click the Health Monitor in the Tasks panel, as shown in Figure 21-2.

Figure 21-2 Health Monitor Tasks panel


Next, from the Select Action drop-down menu, click View Health Details as shown in Figure 21-3.

Figure 21-3 Choosing View Health Details for the vermont-tsm1 server instance

By selecting to View Health Details, you see details for schedule, database and recovery log, current activities such as sessions, processes, and activity log messages, and storage pool status. All of these are shown in Figure 21-4.

Figure 21-4 Health monitor panel highlighting multiple areas for review


As seen in Figure 21-4 the actlog portlet shows errors. If you click one and the error link, they are summarized, with an additional link on the actual error itself, shown in Figure 21-5.

Figure 21-5 Error message link

In our scenario, we proceed as follows:

1. We click the link to ANR0944E and are able to review the manual entry for ANR0944E, as shown in Figure 21-6.

Figure 21-6 Error message detail displayed using the hot link supplied in the Health Monitor portlet


2. Expanding the Storage Device Status portlet, from the Select Action drop-down menu, there is a level of control such as dismounting tape volumes, as shown in Figure 21-7.

Figure 21-7 Storage Device Status Portlet

21.3.10 Reporting

Reporting has a new feature that allows the creation of a .CSV file to be downloaded directly to your connecting system:

1. The path to find this function is shown in Figure 21-8.

Figure 21-8 Integrated Solutions Center: Reporting


2. Next, select the Usage Report and from the Select Action drop-down menu, click Run Report as shown in Figure 21-9.

Figure 21-9 Run Report action

3. Next, select the action of Export Data as shown in Figure 21-10.

Figure 21-10 Export Data action


4. Finally, the option to either open or save the file on your local system, as shown in Figure 21-11.

Figure 21-11 Save Administration Center report as CSV

21.3.11 Creating a new server instance

The Administration Center V6.1 now allows the creation of a new Tivoli Server Manager server instance using the graphical interface. The following sequence of screen captures demonstrates the process:

1. We start with the panel shown in Figure 21-12.

Figure 21-12 Selecting Manage Servers → Select Action → Create Server Instance process


2. Then, following this panel, we click Next after reviewing the information, as shown in Figure 21-13.

Figure 21-13 Selecting Next to accept the default in the Create Server Instance process

3. In the next panel we provide the address and System Administrator user ID and password. In our lab, we fill in the blank fields for the root login of the AIX Tivoli Storage Manager server Utah, as shown in Figure 21-14.

Figure 21-14 Filling in the ip_address, admin ID and password in the Create Server Instance process.


4. Following this panel, we must create the AIX user ID and password for this instance, as shown in the Example 21-1.

Example 21-1 Setting up a user ID and password in the AIX server prior to the instance creation

# mkuser -a id=1003 pgrp=tsmsrvrs home=/home/tsm2 tsm2# passwd tsm2Changing password for "tsm2"tsm2's New password:Enter the new password again:

5. Next, log in using the user ID and password, and you will be prompted to change the password as that user ID, as shown in Example 21-2.

Example 21-2 Logging into AIX and changing the password for TSM2 new instance creation


6. Fill in the details for the instance in the Configure Instance User ID panel. With AIX (and UNIX platforms) you must have the User ID, group, and directory structure already created on the target Tivoli Storage Manager server, as shown in Figure 21-15. Click Next to continue.

Figure 21-15 Inputting the instance ID and password for the Create Server Instance process.

7. Input the instance path and database paths in the Instance Directories panel, as shown in Figure 21-16. Click Next to continue.


Figure 21-16 Inputting the instance directories for the Create Server Instance process

8. With the next panel, you continue inputting the instance directories. Notice with this panel how the shaded (colored) areas imply the mandatory fields, and the fields with no shading are optional fields (see Figure 21-17). After entering the required information, click Next to continue.

Figure 21-17 Input for the instance directory panels for the Create Server Instance process


9. The next step in this process is filling out the Server Information panel, including the instance name and the language, which we have done as shown in Figure 21-18. You also specify how the server starts when the machine boots. Click Next to continue.

Figure 21-18 Server information panel input for the Create Server Instance process

10.Next you specify a Tivoli Storage Manager administrator to create when configuring the new server instance as shown in Figure 21-19. After specifying the required information, click Next to continue.

Figure 21-19 Instance administrator credential specification


11.The next configuration panel shown in Figure 21-20 shows the default for tcpport and tcpadminport. Because this is the second instance, you must change the default tcpport to 1501 (something other than the tcpports currently being used).

Figure 21-20 Server communications parameters

12.The next panel is a summary of the information you specified in the previous panels (see Figure 21-21). Review the information, and if you are satisfied with it, click Next to create the new server instance.

Figure 21-21 Summary of new server instance information


13.Figure 21-22 shows that there is insufficient space to create the new server instance.

Figure 21-22 Error shown due to insufficient space during the Create Server Instance process

14.We then increase the size of the instance file system to allow at least 400 MB of free space, and then repeat all of the previous scenario from Figure 21-12 on page 460 through Figure 21-21 on page 465.

15.Following this correction, the configuration starts, and then completes successfully, as shown here in Figure 21-23. When the instance is created, click OK.

Figure 21-23 .Completion panel for the Create Server Instance process


16.On the Manage Servers panel shown in Figure 21-24, you can see that we have successfully added a second instance, UTAH-TSM2.

Figure 21-24 View of the completed instance under the Managed Server listing

21.3.12 Client nodes and backup set enhancements

Prior to Tivoli Storage Manager V6.1, backup sets were only accessible from the nodes notebook.

For V6.1, a global view is added. The Client Nodes and Backup Sets tab will have three portlets; the bottom portlet will be the backup sets collection. This feature for configuration of backup sets has been added to the Client Nodes menu of the Administration Center.

In the following series of screen captures, we will add a client node, then create a backup set:

1. From the ISC console, select the Client Nodes and Backupsets option under the Tivoli Storage Manager section, as shown in Figure 21-25.

Figure 21-25 Selection of Client Nodes and Backupsets option


2. This will open three independent configuration panels; the first one is the Client Nodes configuration panel, as shown in Figure 21-26.

Figure 21-26 Client Nodes configuration panel

3. The second configuration panel opened is the Client Node Groups panel, as shown in Figure 21-27.

Figure 21-27 Client Node Groups panel

4. Then, the third panel is for backup sets configuration, as shown in Figure 21-28, which we discuss in greater detail in the section “Backup sets” on page 471.

Figure 21-28 Backup Set Collections panel


5. Next, the following series of screen captures demonstrate the configuration of a Client Node Group. To start, from the Client Node Groups panel, select the All Client Node Groups tab. From the Select Action drop-down menu, click Create Node Group as shown in Figure 21-29.

Figure 21-29 Client Node Group configuration panel

6. Then, select the Tivoli Storage Manager server instance the client will be associated with, and the new group name. Provide an optional Description as shown in Figure 21-30.

Figure 21-30 Client Node Group configuration panel, choosing the server instance for the group

After filling out the input fields, click OK. The resulting panel is displayed as shown in Figure 21-31.

Figure 21-31 Client Node Group result panel

Next, we move on to the creation of the client node. From the Select Action drop-down menu, click Create a Client Node as shown in Figure 21-32.


Figure 21-32 Create client node

7. Next, we fill in the fields required for our node configuration, as shown in Figure 21-33. Click OK to continue.

Figure 21-33 Create client node panel

After clicking OK, the ALL Client Nodes tab shows the completed task with the new client node listed (see Figure 21-34).

Figure 21-34 Create client node result panel


After reviewing the creation of the client node, select the By Server tab view. This provides a different look to the Administration Center node grouping and summary as shown in Figure 21-35.

Figure 21-35 Client listings shorted by managed server panel

Clicking the arrow next to the Client Node name will expand the section, displaying more detailed information. This design has been implemented throughout the new Administration Center interface.

Figure 21-36 demonstrates behavior changes within the wizard panels with this release. If you right-click the newly created client Riley_E, you now have the ability to take action directly from the object. In other areas of the Administration Center, you still have to select the object requiring update, then use the Select Action drop-down menu selection.

Figure 21-36 Options now available using right-click within the Administration Center client node panel

Backup setsThe backup set wizard has two additional panels, one to allow the point-in-time and data type information to be entered (the shredding choice was moved to this panel); and another for TOC selection. The TOC panel will only be visited if the data type selection includes file.

For entry in the wizard off the new Nodes and Backup Sets page, there will be some additional changes in navigation. After the General panel, the user will be allowed to select the members; the first panel is a choice of nodes or node groups, the second panel is a table of nodes or node groups, depending on the first panel selection. If the selection result is a single node, then the navigation will go to the existing file space selection panels, but if more than one node was selected, the navigation will proceed to the volume selection panel.


All file spaces will be backed up if multiple nodes are selected. The AC cannot handle file space selection for multiple nodes. Due to some issues with different code pages, the AC uses file space ID in the generate command, and because file space ID can be different for the same file space name across nodes, this will not work for multiple nodes.

Figure 21-37 shows the flow of the backup set wizard navigation panels, which include many changes.

Figure 21-37 Backup set wizard navigation

Referencing the flow chart in Figure 21-37, notice the entry from the Backup set tab where we create a backup for a number of client nodes and client node groups. There is a path change when only a single node (either one node from the nodes table, or one node group with only a single node) is selected. When multiple nodes are selected, all file spaces will be backed up, using the BOTH flag for Unicode.

Backup set collection conceptThe server does have any terminology to describe a multi-node backup set, nor any commands to display the “group” information only. The backup set query displays the individual backup sets. The backup set name can be specified in the command, to display all the backup sets with that name, but each will display separately.

The Administration Center will use the terminology of Collection for a group of backup sets that were generated with a single generate backup set command. These backup sets will displayed as a single entity (a single row), and a hyper-link or row action can be used to display the details for the collection, which will switch to another panel with a display of the common information, as well as a row for each individual backup set in the collection.

As a best practice, the Administration Center will not allow different retention dates to be set for a backup set in a collection, it will only update the retention for all backup sets in the collection. The media for a backup set collection is treated as a single entity, so the volumes do not expire in Tivoli Storage Manager until the backup set with the longest retention expires. If there are multiple retention periods in a collection, the Administration Center will display the longest on the collection page, and on the details page it will display a message with the range of retention periods.

The backup set page in the Client node notebook will include an indication if the backup set is part of a collection. The modify backup set panel launched from the client node notebook will not allow any changes for backup sets that are part of a collection. The information on the page will include instructions to go to the Client Nodes and Backup Set page to modify this backup set.


Backup set collection and details panelsBackup set creation and expiration date information might not be what it initially appears. The expiration date displayed on the panels is calculated using the creation date of the backup set, and the retention period information from the server. The expiration date displayed is retention period days after the creation date. If the backup set was generated by selecting a date – that is, the backup set only contains data that existed on the server on a specified date and time, then the creation date on the server, and used by the Administration Center is the date specified on that command, not the actual day the backup set was created. The backup set will expire retention days after that date on the command, not from the day the command was issued.

The retention period and expiration date displayed the collection and details panels will be based on the longest retention period in the collection, because this is how long the volumes will be retained.

The collections panel will populate the table when a server is selected and the update table button is pushed. The currently displayed server name will appear above the table.

The details panel will have a table with rows for node/data type combinations. Because all the backup sets in the collection have the same name, creation date, volumes and description, these items are displayed above the table with the node names.

The details panel retention/expiration information will be displayed above the table as well. A message will be displayed if all backup sets do not have the same retention period. The individual retention periods will only be visible from the client node notebook backup set tab.

The details panel table will have at least one row for each node that has a backup set in the selected connection. If a node has multiple data types in the collection, then there will be multiple table rows. For example, a node with an Image and File backup set with this backup set name will have two rows in the table,

Table of Contents for backup setsThe existence of a TOC will be displayed on the backup set tables. Because the TOC is only on individual backup sets, it will be displayed as a check mark on the backup set rows in the Details panel, and on the backup set panel in the client node notebook. From these panels, the action to create a TOC will be available. The modify backup set panel will include information about the existence of a TOC, but have no TOC related actions. The generate backup set wizard, and add backup set form will have a selection for TOC processing during the creation of the backup set(s).

The Generate TOC command will cause the entire backup set to be read, and in many cases will take longer than the Administration Center time out to execute (see the section regarding increasing the IC time-out for V6.1). The server command does not have a background process option, so the normal Administration Center handling of giving a process number is not available. To handle this in the Administration Center, the command will be issued, the results checked every ½ second for three seconds, then the command will be “abandoned” by the Administration Center to run on the server. This will allow the Administration Center to report any immediate results, or command failures. When the command is “abandoned” a message will be displayed for the user to view the activity log for the results of the processing.

Breadcrumb navigationThe new backup set panels, and the existing backup set contents panel will have breadcrumb navigation. Instead of having a close button on the bottom left corner, the upper left corner of the panel will show the path. The user will be able to “go back” one or two panels by clicking directly on the hyperlink for the desired panel.


An example would be the Backup Set Contents page entered from the new Backup Sets table. The navigation to the panel would be by selecting a specific backup set collection from the initial page using the hyperlink or details actions, and from the backup set details page, selecting a specific backup set, and the Display Content action. The upper left will have hyperlinks to take the user directly back to either the Collections panel or the details panel.

The Display content action will have a confirmation message, indicating that this is a long running command and might time out. This is new for Tivoli Storage Manager V6.1 because this command will cause the backup set to be read, and can take a long time to process. It is very likely that it will time out before the response from the server is received in most cases.

Important backup set changes starting in V6.1.2In Tivoli Storage Manager V6.1.2 server, the format of a backup set has been changed to accommodate data sent by a V6.1.0 or higher client. Any GENERATE BACKUPSET command that includes data from a V6.1.0 or higher client will create a backup set in the new format. All older V5 clients will reject the new format and will not be able to restore from such a backup set, so it is important to not mix V5 and V6 client levels in the same GENERATE BACKUPSET command. Backup sets that only include data from V5 clients will be in the old format and can be restored by V5 and V6 clients. Also, the V6.1.0 client does not recognize the new format and will not be able to restore from such a backup set. The V6.1.0.2 client will recognize the new format and will be able to restore the backup set.

21.3.13 Maintenance plan enhancements

There are three guided maintenance plans: Basic, Basic plus Storage Pool Backup, and Basic plus Storage Pool Backup and DRM.

� Basic Maintenance Plan, which allows us to perform the database backup, migrate primary storage pools, expire inventory, and reclaim sequential storage pools

� Basic plus Storage Pool Backup, which adds the backup of primary storage pools and the copy of active data from a primary pools to active-data pools.

� Basic plus Storage Pool Backup and DRM, which adds the preparation of a Disaster Recovery Plan file and identifies the copy storage pool and database backup volumes to be moved

Table 21-1 shows the task paths to access the maintenance scripts shown previously in Figure 21-37 on page 472.

Table 21-1 Server script task path for script creation and maintenance

Task Path

Create To create a script:1. Click Storage Devices in the work items list.2. In the Servers table, click a server name. 3. In the server's properties portlet, click the Scripts tab. 4. In the table, click Select Action → Create Script.

To get assistance in creating a script that performs key maintenance tasks:

1. Click Server Maintenance in the work items list. 2. In the table, click Select Action → Create Maintenance Script or Create

Custom Maintenance Script.


Creation of a maintenance scriptThe following sequence of screen captures visually demonstrates the wizard for the creation of a maintenance script, of which only one is supported at any time:

1. We begin the creation starting with Figure 21-38. From the Integrated Solutions Console panel, select the Server Maintenance option under the Tivoli Storage Manager in the left-hand pane.

Figure 21-38 Selecting the Server Maintenance task in the Administration Center

2. In the next panel you will see a list of the servers that you have added to the console. Select the server for which you want to add a maintenance script. From the Select Action drop-down menu, select Create Maintenance Script as shown in Figure 21-39.

View and modify To view and modify a script:

1. Click Storage Devices in the work items list. 2. In the Servers table, click a server name. 3. In the server's properties portlet, click the Scripts tab. 4. In the table, select a script. 5. Click Select Action → Modify Script.

To modify a maintenance script:

1. Click Server Maintenance in the work items list. 2. In the table, select a maintenance script. 3. Click Select Action → Modify Maintenance Script.

Task Path


Figure 21-39 Selecting the create maintenance script action

3. The next panel is the Welcome panel. Click Next to continue as shown in Figure 21-40.

Figure 21-40 Create maintenance script Welcome panel


4. In the next panel, clicking Next will present the opportunity to select a predefined script, as shown in Figure 21-41. We will be using the DRM feature, so we select the third option and click Next to continue.

Figure 21-41 Creation of a maintenance script wizard panel for predefined script selection

5. We now proceed to the creation of the Backup Server Database panel, where we are presented with a backup scheme to protect the Tivoli Storage Manager V6.1 database. We select the correct device class, and the default of six daily incrementals, then a weekly full backup, as shown in Figure 21-42. Click Next to continue.


Figure 21-42 Selecting the device class for the server database backup

6. The wizard moves on to DRM processing as shown in Figure 21-43. Here you can define the library volumes to be moved. Click Next to continue.

Figure 21-43 Library volumes to be moved by DRM within the server maintenance script wizard


7. In the next panel you specify the options used to identify the library volumes and the DRM state to be moved within the maintenance script as shown in Figure 21-44. Click Next to continue.

Figure 21-44 Library volumes and DRM to state transition within the server maintenance script wizard


8. In the next panel, you specify where the recovery plan file is written, as shown in Figure 21-45. When you have made your selection, click Next to continue.

Figure 21-45 Recovery plan configuration panel within the server maintenance script wizard

9. In the next panel, you choose the appropriate migration details as shown in Figure 21-46. Click Next to continue.


Figure 21-46 Migration configuration panel within the server maintenance script wizard

10.In the next panel, you specify the expiration process that removes backup and archive data from server storage. After specifying the expiration process parameters as shown in Figure 21-47, click Next to continue.

Figure 21-47 Expiration duration configuration panel within the server maintenance script wizard


11.In the Reclaim Tapes panel, you specify the storage pools to run reclamation, the unused space capacity percentage that triggers reclamation, and the time limit for reclamation. After entering the required data (see Figure 21-48), click Next to continue.

Figure 21-48 Reclamation detail configuration in the server maintenance script wizard


12.In the Schedule Maintenance panel, you specify when you want the maintenance script to run on a regular basis. After specifying the options in Figure 21-49, click Next to continue.

Figure 21-49 Maintenance script wizard schedule selection

13.The Summary page is presented as shown in Figure 21-50. The options that you specified in the wizard are summarized. Click Finish to continue.

Figure 21-50 Maintenance script wizard summary page


14.Clicking Finish will create the script. Next, we view the script from the command line, using the Tivoli Storage Manager administrative command, q script f=d, as shown in Figure 21-51.

Figure 21-51 Generated script as a result of using the maintenance creation wizard

Modifying an existing maintenance script You have the ability to change an existing maintenance script. In this scenario, we change the database backup methodology:

1. In the Server Maintenance panel, select the server, and using the Select Action drop-down menu, select Modify Maintenance Script as shown in Figure 21-52.


Figure 21-52 Modifying a maintenance script

2. You are presented with general information about the maintenance script as shown in Figure 21-53. In the left hand pane, click Back Up Database to continue.

Figure 21-53 Modifying a maintenance script task menu


3. The Back Up Database options that were previously entered in Figure 21-42 on page 478 are presented. In this scenario we change the type of backup to the Full backup option. We click the Apply and OK buttons, and are then presented with the configuration panel as shown in Figure 21-54.

Figure 21-54 Backup database selection panel using the server maintenance wizard

4. Following these actions, we then return back to the command line and compare the script section that has been altered. First, the incremental database backup lines are shown in Figure 21-55.

Figure 21-55 Database backup lines originally created in the maintenance script

5. Now, we view the newest update to the database backup lines in the server maintenance script as shown in Figure 21-56.


Figure 21-56 Results following the modification of the server maintenance script to database backup

In summary, our discussion of maintenance scripts and panel flows demonstrates some significant improvements in the Tivoli Storage Manager Administration Center feature for V6.1.

21.4 Integrated Solutions Console changes

This section describes functions that are available in the IBM Integrated Solutions Console Advanced Edition Version 7.1. These updates are made to the console for WebSphere Application Server Version 6.1 typically by the installation of an IBM product or upgrade. Features described here supersede any functionality described elsewhere in the help that might state otherwise.

The following advanced features are included in this console installation:

� Multitasking:

The console allows you to switch between active pages, or tasks, by selecting tabs displayed in the page bar over the work area. Console modules on each page have the capability to preserve any unsaved data that you have entered into fields or to launch other applications, either on the same page or on a new page. Be aware that not all console modules implement this functionality.

� Partial refresh:

Console modules can refresh their content without sending a request to the application server that forces the entire console page to be refreshed. For modules that implement this feature, you will notice faster response times while working with the console. The console administrator can configure the refresh settings for console modules that implement this feature.

� Preserving scroll location:

The console provides better positioning of the vertical scroll bar in the browser to help you stay on task. For example, after an action that causes a page refresh, the window is scrolled back to the same vertical position. For pages with a large amount of content, this avoids having to scroll to find your previous location.

� Startup pages:

Users can select which navigation view to display when they log in. In addition, users can select one or more pages to open after logging in.

� Single sign-on:

A Credential Store is provided that allows users to store sensitive information in encrypted form. This module provides a way for console modules to obtain user names and passwords to use when authenticating to back end systems with separate authentication requirements.

– Credential Store:

Use the Credential Store to save sensitive information in encrypted form. This module is ideal for saving login information (such as user names and passwords) so that


console modules that need to authenticate console users to back-end systems can retrieve those credentials without prompting the user. Each key containing sensitive information can be identified by an application using the credential key name. Before using this module, consult the application documentation or service representative to determine the semantics required for the key.

– Field descriptions:

New - Opens a new panel which displays fields used to create the new credential information. The information provided depends on the application or system that will be using this information.

For example, to authenticate to a remote machine named ServerA, you could set the key name to ServerA, set the credential name to the login username, and set the credential value to the login password. Then a console module can retrieve the username and password using the String ServerA and log the user in without presenting a login prompt.

21.4.1 Tivoli Common Reporting

There is now a link into ITM to provide the interface into a configured monitor and reporting environment, as discussed in more detail in Chapter 20, “Monitoring and reporting in Tivoli Storage Manager V6.1” on page 431.

21.4.2 Single user ID signon

In previous versions of the Integrated Solutions Console (ISC), a single user ID could be signed in and active at the same time (multiple iscadmin accounts, for example). This security hole has now been addressed in this latest version of the ISC. With an iscadmin user already logged in, we attempt to open another session and log in with the same user ID, and the results are shown in Figure 21-57.

Figure 21-57 A second login attempt using the same user ID for the ISC is blocked

As a result of this change, now enforcing security in the ISC, along with its ability to handle a single signon for other configured applications, we highly recommend that you configure a separate user ID for each administrative user.


21.4.3 Credential Store

The layout of the Integrated Solutions Console has changed, and what used to be the Credential Vault is now referred to as the Credential Store. The newer look and feel provides a more concise relationship between the Tivoli Storage Manager server object and the ISC user ID. Figure 21-58 shows the Credential Store panel listing the Credential Store keys that have been created.

Figure 21-58 Accessing the Credential Store data

Clicking the Vermont-TSM1 server link, we can edit the existing key (see Figure 21-59).

Figure 21-59 Clicking the server link, the exact credential details can be updated

The Edit Credential Storage Key panel allows the ISC user to alter the Tivoli Storage Manager server access credentials by changing the user ID and password for the selected key as shown in Figure 21-60.


Figure 21-60 Final Credential Store panel to alter credentials for a server link

From the Credential Store panel, you can delete an old Tivoli Storage Manager instance which is no longer required, as shown in Figure 21-61.

Figure 21-61 Old Tivoli Storage Manager server link is deleted using the Credential Store panel

21.4.4 Manage Global Refresh

There is a new option in the Settings view that can be used for managing global refresh times for the health monitor, storage devices, and report portlets.

Console administrators use Manage Global Refresh to configure portlet refresh settings for all users of the console. Here are some of the tasks for which this feature is used:

� Giving permission to console users to edit their own portlet refresh options.

� Configuring default refresh settings for console modules. Administrators can set values for refresh mode, refresh interval, and show timer settings. These settings become the default values for the User Configure Portlet Refresh.

� Setting the minimum refresh interval for each console module. Use this setting to prevent the performance impacts of too many calls to the server to refresh content (see the Minimum Refresh Interval description).


This feature includes the following mode options:

� No refresh indicates that the portlet content will not be refreshed automatically. The refresh timer is not displayed in the portlet title bar, but the portlet can still be refreshed manually.

� Timed refresh indicates that the portlet content is refreshed automatically based on the value of the refresh interval.

� Smart refresh indicates that after the refresh interval has timed out, the client should query the portlet on the server to determine if it should refresh the content. If the portlet has updates to provide, then the content is updated on the client. Otherwise, no change is made and the timer is started again.

� Unregister will disable the portlet refresh capabilities for this portlet. The portlet still displays in Manage Global Refresh. Portlet refresh can be subsequently restored by setting this value to one of the other settings.

The Manage Global Refresh portlet is shown in Figure 21-62.

Figure 21-62 Global Refresh management portlet

In this example, we are changing the tape library refresh from 600 to 1200 seconds, which would reduce the number of queries to all servers for all the AC configured servers. This is shown in Figure 21-63.

Figure 21-63 .Changing the global refresh for the tape libraries


21.4.5 Quick references

The following links are provided for your quick reference to various related publications and articles published by the Tivoli Storage Manager team.

Frequently asked questions about the Tivoli Storage Manager Administration Center can be reviewed at the URL:

http://www-01.ibm.com/support/docview.wss?rs=663&tcss=Newsletter&uid=swg21193419

A quick reference chart showing the Tivoli Storage Manager Administration Center Wizard reference can be reviewed at the URL:


A reference to the creation of Tivoli Storage Manager objects using the Administration Center can be reviewed at the URL:


21.5 Additional notes of interest

Here we provide the following useful information about the Integrated Solutions Console.

Path changesIn V5.3 through V5.5, the Integrated Solutions Console default location was:

� [ISC root]\Tivoli\dsm\bin\ (Windows) � [ISC root]/Tivoli/dsm/bin/ (UNIX and Linux)

This has changed for V6.1. to the following paths;

� [TSM root]\AC\products\tsm\bin (Windows) � [TSM root]/AC/products/tsm/bin (UNIX and Linux)

Integrated Solutions Console default timing changeAlthough this feature was available in a previous version, it was not well documented, therefore it is included in this chapter. To start the utility, use the following command;

� supportUtil.bat (Windows)� supportUtil.sh (UNIX and Linux)

Example 21-3 demonstrates updating the default time-out from 30 to 120 minutes.

Example 21-3 Using the supportUtil.sh in AIX to change the ISC default time-out setting.

# ./supportUtil.sh

User ID: iscadminPassword:

Administration Center Support Utility - Main Menu==================================================

1. Manage Administration Center tracing2. Manage the maximum memory size the Administration Center can use3. Manage the Administration Center session timeout setting





4. Collect trace files, logs and system information to send to support5. Generate a heap dump of the Java virtual machine6. Generate a Java core dump of the Java virtual machine7. View the log file for this utility

9. Exit

Enter Selection: 3

Administration Center Support Utility - Manage the Session===========================================================

1. Update the Administration Center session timeout setting2. View the Administration Center session timeout setting

99. Return to main menu

Enter Selection: 1

The session timeout setting determines how long a session can be idle before it times out. After a timeout occurs the user must log in again. The default timeout setting is 30 minutes. The minimum timeout setting is 10 minutes. To cancel this operation enter an empty value.

Enter the new session timeout (minutes): 120Updating the session timeout to 120 minutes........

Session timeout successfully updated. Restart ISC for changes to take effect.

Press Enter to continue . . .

Administration Center Support Utility - Manage the Session===========================================================

1. Update the Administration Center session timeout setting2. View the Administration Center session timeout setting

99. Return to main menu

Enter Selection: 99

Administration Center Support Utility - Main Menu==================================================

1. Manage Administration Center tracing2. Manage the maximum memory size the Administration Center can use3. Manage the Administration Center session timeout setting4. Collect trace files, logs and system information to send to support5. Generate a heap dump of the Java virtual machine6. Generate a Java core dump of the Java virtual machine7. View the log file for this utility

9. Exit


Enter Selection: 9Exiting#


Part 9 Tivoli Storage Manager V6.1 upgrade consolidation

This part of the book contains planning considerations and a typical scenario for upgrading to Tivoli Storage Manager V6.1 from a prior release.

Part 9


Chapter 22. Upgrading to Tivoli Storage Manager V6.1

In this chapter we show the step-by-step upgrade process of an existing Tivoli Storage Manager on the Windows platform, to the new Tivoli Storage Manager 6.1. It is our intention to provide you with insight on multiple upgrade methods, because the upgrade program has changed, and the process is very different than in previous releases.

To further understand the changes in the upgrade process, refer to the Tivoli Storage Manager Server Upgrade Guide, SC23-9554.

22


22.1 Upgrade strategy

Investing time in planning for the upgrade to Tivoli Storage Manager V6.1 is critical for success. New requirements and new processes make the planning phase more important than ever when working with your Tivoli Storage Manager server.

Some considerations would be the moving of data from an original Tivoli Storage Manager V5 server database to the Tivoli Storage Manager V6.1 database. This process will use a large percentage of a system’s processor and requires a high amount of I/O activity. You have options regarding how to perform this task, whether across a network connection or utilizing storage media.

In your planning, consider testing the upgrade on non-production systems. Testing gives you information about how long the upgrade of the server database will take, which will help you to plan for the time that the server will be unavailable. Some databases might take much longer than others to upgrade.

Testing also gives you more information about the size of the new database compared to the original, giving you more precise information about database storage needs.

If you have multiple servers, consider upgrading one server first, to get experience with how the upgrade process will work for your data. Use the results of the first upgrade to plan for upgrading the remaining servers.

22.1.1 The process for upgrading the server to V6.1

Moving from earlier versions of the server to the V6.1 server requires more preparation and planning than for previous upgrades. Because of the database program that the server is using, an existing database must be moved into the new database structure by using the upgrade tools that are provided.

Except for the database extraction and insertion processes, the upgrade process is similar to performing disaster recovery for a server. The server’s critical files (such as the server option file, and device configuration file) must be available, and devices used for storage pools must be made available to the upgraded server.

These are the major steps in the upgrade process:

1. Plan for system hardware and software requirements, and for the upgrade time. This is one area which your testing results will be applied. In addition, use information about the Tivoli Storage Manager upgrade process together with operational requirements for your existing servers to decide how and when to perform the upgrade.

2. Prepare new hardware that the upgraded server will use, or any increased capacity for your existing system to handle the upgrade.

3. Back up the server database and configuration files. Perform other preparation steps.

4. Install the server code. Installation tasks include:

a. Installing the new server code, which includes the server itself plus its database manager program, and configuring a user ID for the new instance.

b. Installing the upgrade utilities package on the system where the existing Tivoli Storage Manager server is located.

5. Upgrade the database. This task includes preparing the database, and then moving the database. These tasks are performed by using the upgrade utilities or the upgrade wizard.


The upgrade utilities or upgrade wizard extracts data from an existing database and inserts the data into a new Tivoli Storage Manager V6.1 database. Media or the network can be used for the data movement. As a database is moved into the new database structure, the validity of the data is checked against constraints that are enforced in the new database. The upgrade tools automatically correct some errors in the database. Other errors might need to be corrected manually.

If you use the wizard, you are guided to perform the upgrade steps in the correct order. If you are performing the upgrade manually using utilities from a command line, follow the procedure carefully.

6. Verify the upgrade by performing basic operations and querying information about the system to confirm that all information transferred correctly. Review the information that compares the methods for performing the upgrade, and the descriptions of the upgrade scenarios, to help you decide how to perform the upgrade process for your servers.

22.1.2 The DSMUPGRD upgrade utilities

The upgrade utilities prepare and extract data from a Tivoli Storage Manager version 5.3, 5.4, or 5.5 server database for insertion into an empty version 6.1 server database. The DSMUPGRD utilities are run on the original database.

The DSMUPGRD PREPAREDB utility upgrades a server database version to V5.5, and performs some cleanup to prepare for the extraction process.

The DSMUPGRD EXTRACTDB utility extracts the data from a server database. You can use the utility to either simultaneously extract and insert the data into a new database over a network, or extract the data to media for later insertion into a new database. The data extraction operation can be run with multiple processes.

If a problem occurs during the database preparation or extraction, the DSMUPGRD EXTEND DB and DSMUPGRD EXTEND LOG utilities are available to make more space available for the upgrade process.

Refer to “Details of the database upgrade process” on page 271 for detailed information about the DSMUPGRD upgrade utilities.

22.2 Hardware and software server requirements for upgrade

You should use the requirements described here as a starting point. Check the product support site for the latest information.

Important: At this point you should read Chapter 16, “Installation and upgrade planning for Tivoli Storage Manager V6.1” on page 245 before going any further. It contains information that you need for a successful upgrade to Tivoli Storage Manager V6.1.

Important: After a V5.3 or V5.4 server database is upgraded to V5.5, the database can no longer be used by a V5.3 or V5.4 server. If you do not want the database on your production server to be upgraded, you can restore the database backup on another system, then upgrade that copy of the database.

Chapter 22. Upgrading to Tivoli Storage Manager V6.1 499

22.2.1 Hardware and software requirements for V5 server upgrade

A Tivoli Storage Manager V5.3, V5.4, or V5.5 server can be upgraded to V6.1. The upgrade utility package must be installed on the system where the V5 database is located. The V5 system must meet the requirements for running the upgrade utilities, even if you intend to place the upgraded server on a new system.

V5.3 or V5.4 servers might be running on platforms that are not supported by the upgrade utilities. Therefore, you might need to update your system before you begin the upgrade procedure. Use the information in Table 22-1 to determine whether you are using one of the operating system versions that must upgraded.

Table 22-1 Operating system versions to upgrade for upgrade utilities

Restriction: You cannot install and run the V6.1 server on a system that already has DB2 installed on it, whether DB2 was installed by itself or as part of some other application. The V6.1 server requires the installation and use of the DB2 version that is packaged with the V6.1 server. No other version of DB2 can exist on the system.

Tip: It is not necessary to upgrade a V5.3 or V5.4 server to V5.5 level before upgrading to V6.1 level.

Platform If you are running this version: You must upgrade to this version (or later) to use the upgrade utilities

AIX � IBM AIX 5L™ V5.1 (32 or 64 bit)� AIX V5.2 (32 or 64 bit)

� AIX V5.3 (64 bit only)� AIX V6.1 (64 bit only)

HP-UX � PA-RISC:HP-UX 11i V1.0 (32 or 64 bit)

� PA-RISC:HP-UX 11i v2 (64 bit)HP-UX 11i v3 (64 bit)

Linux on Power � Red Hat Enterprise Linux 3 (supported on POWER5™ processors only)

� SUSE Linux Enterprise Server 8/UnitedLinux 1.0 (supported only on processors prior to POWER5)

� Miracle Linux 4.0 or Asianux 2.0� GNU C libraries 2.2.5-108

� Red Hat Enterprise Linux 4� Red Hat Enterprise Linux 5� SUSE Linux Enterprise Server 9

and 10 � Asianux 2.0 - Red Flag DC 5.0 and

Haansoft Linux 2006 or Asianux 3.0� V2.3.3 or later of the GNU C

libraries that are installed on the target system

Linux x86 � Red Hat Enterprise Linux 3 (AS,WS, ES)

� SUSE Linux Enterprise Server (SLES) 8 / UnitedLinux 1.0

� V2.2.5-213 of the GNU C libraries


and 10� Asianux 2.0 - Red Flag DC 5.0,

Miracle Linux 4.0, and Haansoft Linux 2006 or Asianux 3.0

� V2.3.3 or later of the GNU C libraries that are installed on the target system


22.2.2 Upgrade utility additional information

The system requirements for the upgrade utility are the same as the system requirements for a V5.5 server, because the upgrade utility is based on the V5.5 server code. For additional information, see one of the following Web sites to compare the system on which your V5.3 or V5.4 server is running with the system requirements for a V5.5 server:

� AIX:

http://www.ibm.com/support/docview.wss?rs=663&context=SSGSG7&uid=swg21052220

� HP-UX:


Linux x86_64 � Red Hat Enterprise Linux 3� Red Flag Advanced Server 4.1� SUSE LINUX Enterprise Server

8� V2.2.5-213 of the GNU C

libraries


and 10� Asianux 2.0 - Red Flag DC 5.0,

Miracle Linux 4.0, and Haansoft Linux 2006 or Asianux 3.0

� V2.3.3 or later of the GNU C libraries installed on the target machine

Linux zSeries � SUSE Linux Enterprise Server 8 / UnitedLinux 1.0

� Version 2.2.5-108 of the GNU C libraries


and 10� 2.3.3 or later of the GNU C libraries

that are installed on the target system

Sun Solaris � Sun Solaris 8 (64 bit) � SPARC 64 bit:Sun Solaris 9Sun Solaris 10

� x86_64:Sun Solaris 9

Microsoft Windows

� Windows 2000 Professional� Windows 2000 Server� Windows 2000 Advanced Server� Windows 2000 Datacenter

Server

� Windows Server 2003 (Standard, Enterprise, or Datacenter) Edition

� Windows Server 2003 (Standard, Enterprise, or Datacenter) x64 Edition

� Windows Server 2008 (Standard, Enterprise, or Datacenter) Edition

� Windows Server 2008 (Standard, Enterprise, or Datacenter) x64 Edition

Platform If you are running this version: You must upgrade to this version (or later) to use the upgrade utilities




� Linux:

– Linux on POWER:


– Linux x86:


– Linux x86_64:


– Linux zSeries:


� Sun Solaris:


� Windows:


22.2.3 Hardware and software requirements for the upgraded server

Use the requirements described here as a starting point for the upgrade to Tivoli Storage Manager V6.1. Find the latest information about hardware and software requirements on the product support site, which is located at:


Some platforms that were supported for earlier versions of the server are not supported for V6.1. If the server that you want to upgrade is running on one of these platforms, you cannot upgrade your server to V6.1 on the same platform. You must install your V6.1 server on a system that is a specific supported platform, depending on the original platform (see Table 22-2).

Table 22-2 Upgraded server requirements

22.2.4 Server requirements on AIX systems

Check that your AIX system meets the following requirements.

Hardware requirementsFor information about estimating the total disk space that is required, see 22.3.3, “Estimating total space requirements for upgrade process and server” on page 514.

Platform for V5 server Required platform for upgrade to V6.1

HP-UX running on a PA-RISC system HP-UX running on an Itanium® system

Linux running on an Itanium system (IA64) Linux running on an x86_64 system

Linux running on a 32-bit x86 system Linux running on an x86_64 system

Windows running on an Itanium system (IA64) Windows running on an x86_64 system









Table 22-3 describes the minimum hardware requirements.

Table 22-3 Hardware requirements

Software requirementsTable 22-4 describes the minimum software requirements.

Table 22-4 Software requirements


Hardware A 64-bit Itanium system.

Disk space The following minimum disk space:� 5 MB for the /var directory� 2 GB for the /opt directory� 160 MB for the /tmp directory� 300 MB for the /usr directoryAdditional disk space might be required for database and log files. The size of the database depends on the number of client files to be stored and the method by which the server manages them.



Operating System AIX 5.3 running in a 64-bit kernel environment with the following additional requirements for DB2:� AIX 5.3 Technology Level (TL) 6 and Service Pack (SP) 2 plus the

fix for APAR IZ03063� Minimum C++ runtime level with the xlC.rte 9.0.0.8 and


AIX 6.1 running in a 64-bit kernel environment requires the following filesets for DB2:� Minimum C++ runtime level with the xlC.rte 9.0.0.8 and

xlC.aix61.rte.9.0.0.8 filesets. These filesets are included in the June 2008 cumulative fix package for IBM C++ Runtime Environment Components for AIX.

Applications IBM Java 1.5 or later

Web browser A Web browser to retrieve an online installation package. The following browsers are supported:� Microsoft Internet Explorer 6.0 SP1� Microsoft Internet Explorer 7.0� FireFox 1.5� FireFox 2.0� FireFox 3.0� Mozilla 1.7.8Your browser must support the server code page. If your browser does not support the server code page, the windows might be unreadable. If your browser meets these requirements but does not correctly display a Tivoli Storage Manager Web-based interface, consider using a different browser.

Communication protocol A configured communication method.


22.2.5 Server requirements on HP-UX systems

Check that your HP-UX system meets the following requirements.

You cannot run a V6.1 server on a PA-RISC system that is running HP-UX operating system. If the server that you want to upgrade is running on this platform, you cannot upgrade your server to V6.1 on the same platform. You must install your V6.1 server on an Itanium system that is running the HP-UX operating system, and then use the network or media method to upgrade your V5 server to that system.

Hardware requirementsTable 22-5 describes the minimum hardware requirements. For information about estimating the total disk space that is required, see 22.3.3, “Estimating total space requirements for upgrade process and server” on page 514.

Table 22-5 Hardware requirements

Drivers If you have an IBM 3570, IBM 3590, or IBM Ultrium tape library or drive, install the most current device driver before you install Tivoli Storage Manager 6.1. You can locate the device drivers at:ftp://ftp.software.ibm.com/storage/devdrvr/



Hardware A 64-bit Itanium system.






System resources such as semaphores and kernel values might require special configuration and tuning.

Table 22-6 Software requirements for HP/UX

22.2.6 Server requirements on Linux systems

Check that your Linux system meets the following requirements.

Some platforms that were supported for earlier versions of the server are not supported for V6.1:

� Linux running on an Itanium system (IA64)� Linux running on a 32-bit x86 system

If the server that you want to upgrade is running on one of these platforms, you cannot upgrade your server to V6.1 on the same platform. You must install your V6.1 server on an x86_64 system that is running the Linux operating system, and then use the network or media method to upgrade your V5 server to that system.

Server requirements for Linux on POWER systemsThe Tivoli Storage Manager server has the following minimum requirements for hardware and software.

Hardware requirementsTable 22-7 describes the minimum hardware requirements. For information about estimating the total disk space that is required, see “Estimating total space requirements for upgrade process and server” on page 514.


Operating System Considerations:� The HP Itanium system must have operating system 11 iv2 or 11

iv3 with the most current maintenance levels installed. If you are using 11 iV2, you must install PHSS_38140.

� The latest available service patches for the operating system should be applied. Older levels without patches do not work with the device drivers that Tivoli Storage Manager uses.

� The HP maxfiles parameter specifies the number of files a process is allowed to open at any given time. The default value for HP is 60. However, this value is very low and can cause server problems. To ensure proper server operation, increase the maxfiles value to at least 512.


Communication protocol A communication method that is installed and activated (shared memory is the default).

Devices and Drivers � A DVD device that is available for the installation process, if you are installing from DVD media.

� The most current device driver. This must be installed before you install Tivoli Storage Manager.

You can locate the device drivers at:ftp://ftp.software.ibm.com/storage/devdrvr/



Table 22-7 Hardware requirements for Linux on POWER


Table 22-8 Software requirements for Linux on Power

22.2.7 Server requirements for Linux on x86_64 systems

The Tivoli Storage Manager V6.1 server has the following minimum requirements for hardware and software.


Hardware Linux on POWER IBM system such as one of the systems listed in the following Linux for Power server solution Web site:http://www-03.ibm.com/systems/power/software/linux/about/index.html




Operating System The Tivoli Storage Manager server on Linux on Power (ppc64 architecture) requires one following operating systems:� Red Hat Enterprise Linux 5, Update 3 or later� SUSE Linux Enterprise Server 10, Update 2 or later� Asianux 3.0

Libraries GNU C libraries, Version 2.4-31.30 and later

Applications IBM Java 1.5 or later.

Communication protocol � TCP/IP Version 4 or Version 6, which is standard with Linux� Shared memory protocol (with Tivoli Storage Manager Version 6.1

System p client)

Web browser A Web browser to obtain the Linux installation packages. The following browsers are supported:� Microsoft Internet Explorer 6.0 SP1� Microsoft Internet Explorer 7.0� FireFox 1.5� FireFox 2.0� FireFox 3.0� Mozilla 1.7.8Your browser must support the server code page. If your browser does not support the server code page, the windows might be unreadable. If your browser meets these requirements but does not correctly display a Tivoli Storage Manager Web-based interface, consider using a different browser.


http://www-03.ibm.com/systems/power/software/linux/about/index.html

Hardware requirementsTable 22-9 describes the minimum hardware requirements.

For information about estimating the total disk space that is required, see “Estimating total space requirements for upgrade process and server” on page 514.

Table 22-9 Hardware requirements for Linux on x86_64


Table 22-10 Linux x86_64 software requirements


Hardware An AMD64 or Intel EMT-64 processor

Disk space The following minimum values for disk space:� 5 MB for the /var directory� 4 GB for the /opt directory� 190 MB for the /tmp directory� 300 MB for the /usr directoryAdditional disk space might be required for database and log files. The size of the database depends on the number of client files to be stored and the method by which the server manages them.



Operating System The Tivoli Storage Manager server on Linux x86_64 requires one of the following operating systems:� Red Hat Enterprise Linux 5� SUSE Linux Enterprise Server 10� Asianux 3.0

Libraries For Linux x86_64, GNU C libraries, Version 2.3.3-98.38 or later that is installed on the Tivoli Storage Manager system.



Web browser A Web browser to obtain the Linux installation packages. The following browsers are supported:� Microsoft Internet Explorer 6.0 SP1� Microsoft Internet Explorer 7.0� FireFox 1.5� FireFox 2.0� FireFox 3.0Mozilla 1.7.8Your browser must support the server code page. If your browser does not support the server code page, the windows might be unreadable. If your browser meets these requirements but does not correctly display a Tivoli Storage Manager Web-based interface, consider using a different browser.


22.2.8 Server requirements for Linux on System z systems

The Tivoli Storage Manager server has the following minimum requirements for hardware and software.

Hardware requirementsTable 22-11 describes the minimum hardware requirements. For information about estimating the total disk space that is required, see “Estimating total space requirements for upgrade process and server” on page 514.

Table 22-11 Hardware requirements for Linux on System z


Table 22-12 Software requirements for Linux on System z


Hardware An IBM Linux on System z® 900, IBM Linux on System z 800, or IBM Linux on System z 990 server with either native logical partitions (LPARS) or VM guests. You can use 64-bit LPARs and VM guests. 64-bit LPARS and VM guests are used by the storage agent to perform LAN-free operation.

Disk space Disk space The following minimum values for disk space:� 5 MB for the /var directory� 4 GB for the /opt directory� 190 MB for the /tmp directory� 300 MB for the /usr directoryAdditional disk space might be required for database and log files. The size of the database depends on the number of client files to be stored and the method by which the server manages them.



Operating System The Tivoli Storage Manager server on Linux on System z (s390x 64-bit architecture) requires one of the following operating systems:� Red Hat Enterprise Linux 5, Update 3 or later� SUSE Linux Enterprise Server 10, Update 2 or later

Library Library GNU C library, Version 2.4-31.43.6 is installed on the Tivoli Storage Manager system.




22.2.9 Server requirements on Sun Solaris systems

Check that your Sun Solaris system meets the requirements in this section.


For information about estimating the total disk space that is required, see “Estimating total space requirements for upgrade process and server” on page 514.

Table 22-13 Hardware requirements for Sun Solaris

Web browser A Web browser to obtain the Linux installation packages. The following browsers are supported:� Microsoft Internet Explorer 6.0 SP1� Microsoft Internet Explorer 7.0� FireFox 1.5� FireFox 2.0� FireFox 3.0� Mozilla 1.7.8Your browser must support the server code page. If your browser does not support the server code page, the windows might be unreadable. If your browser meets these requirements but does not correctly display a Tivoli Storage Manager Web-based interface, consider using a different browser.



Operating system One of the following processors required:� Sun Ultra SPARC-based (sun4u architecture)� Sun Ultra SPARC-based processors (sun4v architecture)� x86_64-based processors (AMD64 or EM64T architecture

Disk space The following list is the minimum disk space for Sun Ultra SPARC-based processors (sun4u and sun4v architecture) and for x86_64-based processors (AMD64 or EM64T architecture) for the respective directories and logs:� 5 MB for the /var directory� 2 GB for the /opt directory� 310MB for the /tmp directory� 300 MB for the /usr directoryAdditional disk space might be required for database and log files. The size of the database depends on the number of client files to be stored and the method by which the server manages them.



Software requirementsTable 22-14 describes the minimum software requirements for upgrading the Tivoli Storage Manager V6.1 server on Sun Solaris.

Table 22-14 Software requirements

22.2.10 Server requirements on Microsoft Windows systems

Check that your Microsoft Windows system meets the following requirements.

You cannot run a V6.1 server on an Itanium system (IA64) that is running the Windows operating system. If the server that you want to upgrade is running on this platform, you cannot upgrade your server to V6.1 on the same platform. You must install your V6.1 server on an x86_64 system that is running the Windows operating system, and then use the network or media method to upgrade your V5 server to that system.


For information about estimating the total disk space that is required, see “Estimating total space requirements for upgrade process and server” on page 514

Table 22-15 Hardware requirements for Windows server


Operating System You need one of the following systems:� Sun Solaris 10 or later, running in 64-bit mode on a Sun Ultra

Sparcsystem with sun4u architecture� Sun Solaris 10 or later, running in 64-bit mode on a system

withAMD64 or EM64T architecture


Communication protocol TCP/IP

Devices and drivers If you have an IBM 3570, 3590 or Ultrium tape library or drive, install the most current device driver before you install Tivoli Storage Manager Version 6.1. You can locate the device drivers at:ftp://ftp.software.ibm.com/storage/devdrvr/


Hardware Intel Pentium compatible processor or multiprocessor-based computer

Disk space Basic requirements:� At least 3 GB of free disk storage (for a typical installation)� 200 MB temporary directory space� 200 MB partition size in the C:\ driveAdditional disk space might be required for database and log files. The server is installed in the drive that you select, and the database and logs can be installed in another drive.





Table 22-16 Software requirements for Windows upgrade

22.3 Planning space for the upgrade process and server

Plan for the space requirements for the upgrade process, and for the server database and recovery log for the upgraded server. Consider the disk storage currently in use for the server, and whether changes in hardware can be timed to coincide with the upgrade of the server.


Operating System One of the following systems:� Microsoft Windows Server 2003: Standard, Enterprise, or

Datacenter Edition� Microsoft Windows Server 2003: Standard, Enterprise or

Datacenter x64 Edition (64-bit)� Microsoft Windows Storage Server 2003� Microsoft Windows Storage Server 2003 x64� Microsoft Windows Server 2008: Standard, Enterprise, or

Datacenter Edition� Microsoft Windows Server 2008: Standard, Enterprise, or

Datacenter x64 Edition (64-bit)

Applications � IBM Java 1.5 or later

Communication protocol � Named Pipes� TCP/IP Version 4 or Version 6

Web browser A Web browser to log in and use the console. The Web browser can be installed on the same or a separate system. The following browsers are supported:� Microsoft Internet Explorer 6.0 SP1� Microsoft Internet Explorer 7.0� FireFox 1.5� FireFox 2.0� FireFox 3.0� Mozilla 1.7.8Your browser must support the server code page. If your browser does not support the server code page, the windows might be unreadable. If your browser meets these requirements but does not correctly display a Tivoli Storage Manager Web-based interface, consider trying a different browser.

System functions The Windows system functions, such as Device Manager, are supported on the 64-bit Tivoli Storage Manager Console.Normal Windows system functions are available for both the 32-bit and 64-bit server using the Manage Computer function of the Windows system.


22.3.1 Space requirements for the V5 server system

Space is required for storing the backup of the server database, which is an important step in preparing for the upgrade process. If you are using the media method for moving the database, you need space for storing the extracted data.

The backup of the server database requires as much space as is used by your V5 database. Store the backup on the form of sequential media that is convenient for you, either tape or disk.

Additional space requirements depend on the method that you choose for moving the data from the V5 database:

Media methodYou need media to store the data that will be extracted from the V5 database. The media can be tape, or disk space that is defined as a sequential-access disk device class. The space required for the extracted data is the same as the used space in your database. If your database is safely backed up, and you are certain that you no longer need to run the V5 server, after you extract the data you can optionally release the space used by the V5 database and recovery log.

Network methodYou must have the working copy of the V5 database and recovery log on 26 IBM Tivoli Storage Manager: Server Upgrade Guide the V5 system. If you are working with a copy of the database that was created for testing the upgrade process, you need enough space to hold the total allocated size of the database; you can use the minimum size for a V5 recovery log.

Related tasksSee 22.3.3, “Estimating total space requirements for upgrade process and server” on page 514.

22.3.2 Space requirements for the Tivoli Storage Manager V6 server system

Before beginning the upgrade process, plan for the space that is required for the database and recovery log.

You need unique, empty directories for the following items for the upgraded server:

� The database


– Active log– Archive log– Optional: Log mirror for the active log– Optional: Secondary archive logs (failover location for archive log)

� The instance directory for the server, which is a directory that will contain files specifically for this server instance (the server options file and other server-specific files).

Database space requirementsThe amount of database space that is required depends on the size of the original V5 database, and on how much data the server will be managing. Refer to the IBM Tivoli Storage Manager Server Upgrade Guide, SC23-9554 for detailed reference, as well as the following sources.


Upgrading the database space requirementsVisit the following site for detailed information:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.upgrd.doc/t_srv_upgrd_plandb.html

Database space requirements for continued productionVisit the following site for detailed information:

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/t_srv_inst_db_space.html

Initial tips for setup and sizingThe amount of storage space for the database is managed automatically. The database space can be spread across multiple directories. After you specify the directories for the database, the server uses the disk space available to those directories as required.

Locate the database and recovery log directories on separate physical volumes or file systems. Ideally, use multiple directories for database space (we are recommending at least four as a minimum) and locate them across as many physical devices or logical unit numbers (LUNs) as there are directories.

Plan for 33 - 50% more than the space that is used by the V5 database. (Do not include allocated but unused space for the V5 database in the estimate.) Some databases can grow temporarily during the upgrade process; consider providing up to 80% more than the space that is used by the V5 database.

Space estimatesEstimate the amount of space that the database will require by completing the following steps:






For the best efficiency in database operations, anticipate future growth when you set up space for the database. If you underestimate the amount of space that is needed for the database and then must add directories later, the database manage might need to perform more database reorganization, which can consume resources on the system. Estimate requirements for additional database space based on 600 - 1000 bytes per additional object stored in the server.

Visit the support site for the latest information and recommendations.



http://publib.boulder.ibm.com/infocenter/tsminfo/v6/topic/com.ibm.itsm.srv.install.doc/t_srv_inst_db_space.html

Recovery log space requirementsThe amount of recovery log space that is required depends on the amount of client activity with the server.The estimates based on this information should be used as a starting point. After the server is upgraded, monitor the active log and archive log directories to ensure that these directories have enough free space to handle the actual server workload.

Active logThe minimum size of 2 GB is large enough to complete the upgrade process. When you begin normal operations with the server, you might need to increase the size of the active log. The required size depends on the amount of concurrent activity that the server handles. A large number of concurrent client sessions might require a larger active log. For example, the server might need an 8 GB or larger active log.

Active log mirrorThe active log mirror is optional. Its size requirement is the same as the size of the active log.

Archive logThe size required depends on the number of objects stored by client nodes over the period of time between full backups of the database.

Remember that a full backup of the database causes obsolete archive log files to be pruned, to recover space. The archive log files that are included in a backup are automatically pruned after two more full database backups have been completed.

If you perform a full backup of the database every day, the archive log must be large enough to hold the log files for client activity that occurs over two days. Typically 600 - 4000 bytes of log space are used when an object is stored in the server. Therefore you can estimate a starting size for the archive log using the following calculation:


For example:

5,000,000 objects/day x 3000 bytes/object x 2 days = 30,000,000,000 bytes, or 30 GB

Secondary (failover) archive logIf the archive log becomes full, the failover archive log is used. Specifying a failover archive log is useful only if you locate it on a different physical drive or file system than the archive log.

For the latest information and recommendations, go to the support site:


22.3.3 Estimating total space requirements for upgrade process and server

In addition to the space required for the upgraded server itself, some additional disk space is needed for the upgrade process. For example, if you are upgrading the server on the same system where it is currently located, you need enough space for two copies of the database during the upgrade process.



The space requirements for the upgraded, Tivoli Storage Manager V6.1 server depend on the size of the V5 database and other factors. The space requirements for the upgrade process also depend on how you move the data from the V5 database to the new database. You can move the data to the new database using the media method or the network method, with the following requirements:

� The media method requires sequential media. The sequential media can be tape or sequential disk device class (FILE device type).

� The network method requires a network connection between systems, if you are upgrading on a new system.

Table 16-3 on page 261 shows basic tips for estimating each item, for each of the main scenarios. Select the scenario then read down the column.

Table 16-4 on page 262 shows a sample filled-in work sheet for a 100-GB, V5 database that has 80% space utilization, with the assumption that the database increases by 33 - 50% when upgraded.

22.4 Estimating the upgrade time

The time that is required to complete the upgrade of a V5 server depends on factors such as the size of the database being upgraded, number and speed of system processors, storage device configuration, and the method chosen for moving the data from the V5 database to the V6 database.

The network method for the data movement overlaps the extraction time with the insertion time. Using the network method might help reduce the total time required for the upgrade because of the overlap.

In benchmark environments in IBM labs, upgrade operations have achieved between 5-10 GB per hour, depending on the configuration. Your environment might produce different results.

22.4.1 Performance tips for the extraction process

The speed of the extraction process is typically the faster of the update phases, and is limited by the speed of I/O for both the source and the destination for the extracted data. Both the read and write for the extraction is sequential in nature.

Performance tips depend on the method that you choose for moving the data from the V5 database:

� Media method:

– If you are extracting the data to tape, use a high-speed tape device.

– If you are extracting the data to disk, use a disk device or LUN that is different than the device in use for the V5 database and recovery log.

– If you are performing a V5 unload, then load to a test system, the test system disk should be optimized for the highest I/O rate possible.

If both the V5 database and the destination for the extracted data are on a virtualization device (high-end storage controller, or a SAN virtualization device), ensure that the two virtual LUNs are not on the same physical disk drive. Ensure that the space in use for the V5 database and the destination for the extracted data are on different physical disk drives within the virtualization device.


If it is not possible to provide different LUNs for the V5 database and the extraction destination, the extraction process will perform more slowly. The slower speed of extraction might be acceptable, depending on the size of the database and your requirements for the upgrade.

� Network method:

Use a high speed link if you are extracting the data to a different system. For upgrading a database greater than 2 - 3 GB, use at least a 1-Gb Ethernet network.

If you are extracting the database on the same system, no external network connections are required, however you will have options for the use of shared memory, or named pipes as your network transport layer.

22.4.2 Performance tips for inserting data into the V6.1 database

The process for inserting the V5 extracted data into the V6.1 database is the longest-running part of an upgrade process, and is the most sensitive to the configuration of the system. On a system that meets the minimum requirements, the insertion process will run, but performance might be slow. For better performance, set up the system as described in the tips:

� Processors:

The insertion process is designed to exploit multiple processors or cores (multi-threaded). The insertion process will typically perform better on a system with a relatively small number of fast processors, rather than a system with more slower processors.

Much of the activity is I/O interrupt related, thus faster processors would be more effectively utilized.

� Disk storage:

The insertion process is designed to exploit high-bandwidth disk storage subsystems. The speed of the process is highly dependent on the disk storage that is used for the source and target disk.

For best performance, use multiple LUNs that map to multiple independent disks, or that map to RAID arrays with a large stripe size (for example, 128 KB). Use a different file system on each LUN.

Table 22-17 shows an example of good usage of LUNs.

Table 22-17 LUN usage

If the disk storage is supplied by a virtualization device (high-end storage controller, or a SAN virtualization device), ensure that none of the virtual LUNs are on the same physical disk drive. Ensure that the directories in use are on different physical disk drives within the virtualization device.

LUN Usage

1 Active log

2 Archive log

3,4,5,6 Database directories

7 Extracted V5 database (needed only if the media method is used to extract the V5 database to a sequential disk device class)

8 Binary file system for each instance


22.5 Planning for upgrading multiple servers and components

If your environment includes multiple servers and storage agents, evaluate the compatibility of the versions being run with an upgraded V6.1 server. Plan to upgrade one server first in a test environment. Then stage the upgrade of additional servers and storage agents. Remember that your library manager server (or server instance) must be upgraded first.

Components available for installationIn addition to the server, you can choose to install device drivers, language packs, the Administration Center, and the reporting and monitoring feature.

This book focuses on installing the server itself. For information about installing other components, see the Installation Guide for your operating system.

22.5.1 Compatibility with servers and components running at earlier versions

Details about what levels of server, client, storage agent, library manager server, library client servers, and configuration manager servers can work together are available from the product support site, which is located at:


22.5.2 Planning for upgrading multiple servers on a single system

After you install the V6.1 server on a system, you can no longer run any V5 servers on that system. You must upgrade the database for each server instance separately.

You can use the upgrade wizard, or manually use the upgrade utilities to upgrade the servers:

� If you use the upgrade wizard, run the wizard once for each server instance.

You can upgrade multiple servers at the same time. Each time that you start the upgrade wizard, you work with a single server, but you can start the wizard in multiple windows at the same time.

� If you use the upgrade utilities manually from a command line, repeat the procedure for upgrading each server instance.

You can begin running one upgraded server instance while other server instances are still being upgraded.

22.5.3 Planning for upgrading library managers and library clients

To work with a version 6.1 library manager, servers that are library clients must be at version 5.4 or later.

If servers are using shared libraries, upgrade the server that is the library manager first. Then upgrade the servers that are library clients.

If you are moving a library manager or library clients to new systems for the upgrade to V6.1, consider moving the servers to the new systems before upgrading the servers. By moving the servers first, you can reestablish connectivity to all servers and devices before the upgrade. Then upgrade the library manager, followed by upgrading the library clients.



For the most recent information about supported levels of library clients, go to the following Web site:


22.5.4 Planning for upgrading clients

To connect to a V6.1 server, client nodes must be running a version 5.4 or later client program.

22.5.5 Planning for upgrading storage agents

To connect to a V6.1 server, storage agents must be at version 5.5 or later.

If you have storage agents at earlier versions, upgrade them to V5.5 before upgrading the server to V6.1. Verify that LAN-free data movement works as expected before upgrading the server.

For the most recent information about supported levels of storage agents, go to the Web site:


22.6 Testing

Tivoli Storage Manager 6.1 has many new features, which have contributed to new hardware and software requirements. There are some major server enhancements which require additional planning considerations include:

� Integrated Solutions Console and Administration Center� Reporting and Monitoring� Deduplication� Disk structure for DB2, active logs and archive logs, storage pool volumes� Disaster recovery using the Disaster Recovery Manager feature� Adapting an existing V5.x Tivoli Storage Manager server infrastructure with V6.1

In addition, there are many methods of upgrading, so understanding all your options and the cost of each is important (actual monetary and downtime costs might vary based on each scenario).

For considerations when building test cases for upgrade scenarios, go to “Testing” on page 288.

22.7 Preparing for operational changes

Starting with V6.1, how you back up and monitor the server database changes. Check the operating procedures, scripts, and administrative schedules that you use for server operations:

� Plan to continue backing up the server database regularly by using administrative schedules, a maintenance script, or your own scripts. Back up the server database at least once per day.

� Understand how database and recovery log space is used, and how monitoring needs to change.




� Check scripts and administrative schedules. The V6.1 server adds new commands, changes some commands, and deletes some commands that are no longer needed. These changes will affect your automated operations. For more information about new commands and utilities, go to Chapter 4, “Commands, utilities, and option changes” on page 31.

� Check SELECT commands that you use regularly. Some parameters and syntax that were previously allowed are not accepted by the database manager program.

� If you use products from independent software vendors to interface with the server, ensure that the products are compatible with the V6.1 server.

� Additional information about operational changes can be found in “Planning for operational changes” on page 291.


Chapter 23. Tivoli Storage Manager V6.1 Upgrade Scenarios

The objective of this book is to provide material describing how to take the necessary steps before and after the upgrade from Tivoli Storage Manager V5 to V6. In this chapter we present scenarios to accomplish this purpose.

23


23.1 The basics of planning the upgrade

A successful upgrade of IBM Tivoli Storage Manager benefits enormously from planning prior to attempting to set up the environment.

The planning for what equipment is needed (such as hardware platform, size of processor, and network connectively) should all have been done before starting with the upgrade to IBM Tivoli Storage Manager V6.1. You should have read Chapter 16, “Installation and upgrade planning for Tivoli Storage Manager V6.1” on page 245 and Chapter 22, “Upgrading to Tivoli Storage Manager V6.1” on page 497.

In the current chapter, we cover the steps needed to upgrade to V6.1 and walk through an example showing step by step how we upgraded a V5.5 server to V6.1 using the network model and the wizard. The example is based on upgrading a fairly simple Tivoli Storage Manager configuration, but you will be able to see how the issues that we have covered prior to this can impact the upgrade strategy.

23.2 Upgrade scenarios

You can upgrade the server on the same system or a new system, and use either a media method or a network method to move data from the original server database to the upgraded server database. Descriptions of the scenarios illustrate the order of steps for the different approaches.

For the test upgrade we have selected Scenario 2 from Table 23-1. In this scenario, some upgrade tasks are performed on the original system and some on the new system. The data is extracted from the original server database and sent over the network connection to be inserted into the new server database.

You can use the wizard, or perform the upgrade by manually using the utilities. The wizard offers a guided approach to the upgrade of a server. We strongly recommend using the wizard; you can avoid some configuration steps that are complex when done manually.

Table 23-1 Server upgrade scenarios

Scenario Location of upgraded server Method for moving data

Scenario 1 for upgrading the server: new system, media method

New system Media method

Scenario 2 for upgrading the server: new system, network method”

New system Network method

Scenario 3 for upgrading the server: same system, media method

Same system as original server Media method

Scenario 4 for upgrading the server: same system, network method

Same system as original server Network method


23.3 Upgrading from V5.5 to V6.1 step by step

We took a database backup of a Tivoli Storage Manager V5.5 production database and restored that into a VMware server onto a new file system to test the upgrade to V6.1. When the restored was finished, we continued on to prepare for the upgrade.

We completed the following preparation steps:

1. Be current and read the readme files for the database upgrade.

2. Read IBM Tivoli Storage Manager: Server Upgrade Guide, SC23-9554.

3. Download DB Upgrade Utilities by using the ftp downloads site:


4. Have your Tivoli Storage Manager V6.1 DVDs available and online information available.

For more information, see the following references:

– Storage Technical Exchange Web site:


– Tivoli Storage Manager Wiki:


5. To prepare for the database upgrade process, we followed this process:

– The source system should be at least Tivoli Storage Manager 5.3 level for testing the DB upgrade. The recommended starting point is Tivoli Storage Manager V5.5.2.

– The system should meet the requirements for memory, disk, and software as outlined in the readme files.

– If Tivoli Storage Manager is at 5.5.x, then server can be restarted after PREPAREDB is run in case some kind of corrective action is needed.

– Ensure that the database upgrade utility is installed on the source system.

– Consider 24X7 requirements for Tivoli Storage Manager availability.

– Complete the disk space planning.

– Verify that your monitoring applications support Tivoli Storage Manager V6.1

Event retention data Assuming that you have any event retention data and you know that you have NO event retention based data on the V5 DB, then you can specify EVENTBASEDUSED=NEVER for the DB upgrade. This will provide a slight performance boost for operating systems during the extract portion of the DB Upgrade Process.

However, if you have SSAM, then use EVENTBASEDUSED=YES for the DB Upgrade. If you are not sure if event based retention has ever been used, take the default, which is EVENTBASEDUSED=YES.

Do not use the EVENTBASEDUSED=NEVER parameter on an SSAM Server or if you have any Archive copygroups using retinit=event. If you do this, it will cause archived objects to be given the wrong retention initiation date.

Note: These steps assume that the upgrade utilities package is already installed on the system where the V5 server is installed.

Chapter 23. Tivoli Storage Manager V6.1 Upgrade Scenarios 523




Other preparation considerationsPreparation could also include the following considerations:

� DB unload/load might help the extract process.

� DB audit is another possibility.

� Applications such as CDP, Content Manager, and Space Manager assume that the Tivoli Storage Manager server is always available.

� Customer databases might need to back up archive logs hourly.

� Preparing space for the upgrade process might involve:

– Determining the amount and type of space that is required for the upgrade process before beginning the process.

– Verifying that the system has the amount of space that was estimated in the planning step. Use the planning work sheet that you filled in with your information. Refer to “Space requirements” on page 257.

23.3.1 Modifying the server before the upgrade

A convert command must be run on the server to prevent one type of problem during the upgrade process. Some modifications to typical server settings are recommended to prepare for the upgrade:

� From a Tivoli Storage Manager administrative command line, issue the command:

convert ussfilespace

This command fixes a problem that might exist in older Tivoli Storage Manager databases. If the problem does not exist in your database, the command completes quickly. If the problem exists in your database, the command might take some time to run.

� Review the steps for reverting to the earlier version of the server in the section, “Reverting from V6.1 to the previous V5 server version” in the IBM Tivoli Storage Manager: Server Upgrade Guide, SC23-9554. If for some reason you need to revert to the earlier version after the upgrade to V6.1, the results of the reversion will be better if you understand the steps and prepare for the possibility now.

� Make the following adjustments to settings on your server and clients. These adjustments must be done to make it possible for you to revert to the original server after the upgrade, if problems occur:

– For each sequential-access storage pool, set the REUSEDELAY parameter to the number of days during which you want to be able to revert to the original server, if that becomes necessary. For example, if you want to be able to revert to the original server for up to 30 days after upgrading to V6.1, set the REUSEDELAY parameter to 31 days.

Note: We have discussed the Tivoli Storage Manager database re-organization as an option to improve the upgrade time. However, this option has an unload/load itself and requires downtime, so in the end, actually you will not save time by doing this.

Important: Do not skip this step. If your database has the problem and you do not run this command now, the DSMUPGRD PREPAREDB utility fails when you run it. You must then restart the V5 server and run the CONVERT USSFILESPACE command before continuing with the upgrade process.


– For each copy storage pool, set the RECLAIM parameter to 100 (meaning 100%).

– If you typically use a DELETE VOLHISTORY command to delete database backups, ensure that the command does not delete database backups for at least the same number of days that you set for the REUSEDELAY period for sequential-access storage pools.

– For important clients that use the server, check that the value for the schedlogretention client option is set to retain the client schedule log for a long enough time. Update the option for clients if needed.

The entries in the client schedule log might be useful if the server must revert to the original version. If the retention period for the schedule log is too short, the schedule log information might be deleted too soon.

� In preparation for the upgrade, prevent activity on the server by disabling new sessions. Cancel any existing sessions. The commands in the following procedure are Tivoli Storage Manager administrative commands.

To prevent all clients, storage agents, and other servers from starting new sessions with the server, use the commands:

disable sessions clientdisable sessions server

� Prevent administrative activity from any user ID other than the administrator ID that is being used to perform the upgrade preparation. Lock out other administrator IDs if necessary:

lock admin administrator_name

� Check whether any sessions exist, and notify the users that the server is going to be stopped. To check for existing sessions, use the command:

query session

� Cancel sessions that are still running. Use the command:

cancel session

� Back up storage pools and the server database as follows:

Immediately before upgrading the server, back up primary storage pools to copy storage pools, and perform a full database backup.

– Back up primary storage pools to copy storage pools using the BACKUP STGPOOL command. If you have been performing regular backups of the storage pools, this step backs up only the data that was added to the primary storage pools since they were last backed up.

– Back up the database using the following command. Use either a full or snapshot backup type.

backup db type=type devclass=device_class_name

The device class that you specify must exist and have volumes that are available to it. For example, to perform a snapshot backup of your database to the TAPECLASS device class using scratch volumes, enter:

backup db type=dbsnapshot devclass=tapeclass

– To use specific volumes instead of scratch volumes, specify the volume names in the command. Consider making two copies of the backup to protect the backup from media failures.


� Back up the configuration information:

Before installing the new version, back up critical files and information for the server. Store the files in a safe place, because they are needed after the installation of the new software version is completed. You also need these files if you must revert to the previous version after the upgrade:

– Back up device configuration information:

backup devconfig filenames=file_name

– Back up volume history information:

backup volhistory filenames=file_name

Ensure that the volume history includes information about the database backup that you completed in the preceding steps. For example, issue the command:

query volhistory type=dbbackup

– Make copies of these files, which are located in the default directory for the server:the server options file, typically named dsmserv.opt dsmserv.dsk

– Optionally, make a copy of the accounting log file: dsmaccnt.log

– Back up any scripts that have been used to perform daily housekeeping for the server. Examine the scripts for changes that are needed after the upgrade.

– Store the device configuration file, the volume history file, the server options file, and the other files in a safe place. Select a location that is not on the system that is being upgraded.

� Create a summary of database contents:

– Create a summary of the contents of the original database. After the upgrade, you can use the same commands to compare the results and to confirm that the database contents are intact. Run commands that give a summary of information about your database contents. For example, issue commands that summarize the file spaces being protected, and save the results. See the sample commands for ideas.

� Stop the server before installing the upgrade:

Stop all server processes and dismount any tapes that are mounted. Then stop the server.The following procedure contains Tivoli Storage Manager administrative commands:

– Cancel sessions if any are still running. Use the command:

cancel session

Allow time for the sessions to be stopped. Some sessions, such as backup by a backup-archive client, might take some time to stop.

– Determine whether server processes are running. Either cancel processes, or allow them to complete. Use the commands:

query processcancel process process_number

Allow time for the processes to be stopped. Some processes, such as storage pool migration, might take some time to stop.

– After all sessions and processes are stopped, determine whether any tapes are mounted. Dismount any tapes that are mounted. Use the commands:

query mountdismount volume volume_name

– Stop the server using the command:

halt


� Installing the upgrade utilities:

You must install the upgrade utilities on the system where the V5 server is located. The installation package for the utilities must be downloaded from a Web site. You need an upgrade version that is greater than or equal to the level of the Tivoli Storage Manager server you are upgrading.

– First perform all preparation tasks on the original (source) system: For the storage pools, set reuse delay to the number of days during you want to be able to revert back to the original server if that becomes necessary. For each copy storage pool, set the RECLAIM parameter to 100. Back up and make copies of device configuration, volume history, and server options files. Back up storage pools and server database, and create a summary of the database contents. You can use the DSMUPGRD utility for this.

– Log on to the source server with an administrator ID to install the upgrade utilities on the system where the V5 server is located. and run the executable package. The default location for the installation of the utilities is based on the location where the V5 server was last installed. The package to install is available for download from the FTP downloads site. The upgrade utilities are used to prepare and extract the database from the original server.

For example, if the V5 server was installed using the default path: C:\Program Files\Tivoli\TSM\server

Create an upgrade folder and install the upgrade utilities in the path: C:\Program Files\Tivoli\TSM\upgrade

After the upgrade utilities are installed, continue with installing the V6.1 server on the target server.

– Log on to the target system as an administrator and change to the directory where you placed the executable file. In the next step, the files are extracted to the current directory. Ensure that the file is in the directory where you want the extracted files to be located.

Either double-click the executable file, or enter the following command on the command line to extract the installation files: 6.1.0.0-TIV-TSMALL-platform.exe

The files are extracted to the current directory.

Install the V6.1 server code on the new system. After the install is done, check the installation logs in the path: C:\Program Files\Tivoli\TSM

– Create the directories for the V6.1 database and logs, and the user ID that will own the server instance. We choose TSM1 as the DB2 user ID.

Notes:


� Do not install the utilities in the same directory as the original server that is to be upgraded, this is a restriction and is not allowed.

� The utilities package must be installed whether you are using the upgrade wizard or performing the upgrade manually with utilities.


– Start the upgrade wizard by double-clicking it, or run the command on the following path to configure the new server and upgrade the V5 database:

c:\Program Files\Tivoli\TSM\server\dsmupgdx.exe

– With the wizard, you complete the following tasks:

• On the original system, prepare the V5 database.• On the new system, create and format an empty database to receive the data.• Move the data from the V5 database to the V6.1 database.• Configure the new system for database backup.

– Complete the post-installation tasks, including backing up the database and verifying the database contents.

23.3.2 Upgrade steps: V5.5 server to V6.1 on Windows platform

Here we show step by step how we upgraded a V5.5 server to V6.1 on a Windows platform using the network upgrade method on a new server.

Example 23-1 shows the commands we used to create the directories that the Tivoli Storage Manager server instance needs for database and recovery logs.

Example 23-1 Create directories for database and recovery logs

C:\mkdir e:\tsm1\dbdir001C:\mkdir f:\tsm1\dbdir002C:\mkdir g:\tsm1\dbdir003C:\mkdir h:\tsm1\dbdir004C:\mkdir i:\tsm1\actlogC:\mkdir j:\tsm1\actlogmC:\mkdir k:\tsm1\archlogC:\mkdir l:\tsm1\archlogf

Installing the upgrade utilities on Microsoft Windows systemsOn the target system, we run the upgrade tool. To install the upgrade utilities on the system, we first download the package from the FTP downloads site. The upgrade utilities are used to prepare and extract the database from the original server:

1. Obtain the upgrade utilities package from the FTP downloads site:

ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance/server-upgrade/v5r5/WIN

a. Open the 5.5.x.x directory. The 5.5.x.x number must be the same as or later than the level of the V5 server that you are upgrading.

b. Select the package and download it to a convenient location on the server system. The name of the package has the following form:

5.5.x.x-TIV-TSMUPG-Windows.exe

The numbers at the beginning of the package name identify the release level of the upgrade utilities package. The level of the upgrade utilities package must be the same as or later than the level of the V5 server that you are upgrading.

2. Log on with an administrator ID.

Note: You need an upgrade version that is greater than or equal to the level of the Tivoli Storage Manager server that you are upgrading.


ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance/server-upgrade/v5r5/WIN

3. Run the executable package for the upgrade utilities.

The default location for the installation of the utilities is based on the location where the V5 server was last installed. For example, if the V5 server was installed using the default path, C:\Program Files\Tivoli\TSM\server, the upgrade utilities are installed in C:\Program Files\Tivoli\TSM\upgrade.

4. On the source system, run the install.exe, then run the upgrade wizard tool, dsmupgdx.exe in the c:\Program Files\Tivoli\TSM\server\ directory. The V6.1 server upgrade window will open.

We choose the appropriate language and click OK to continue (see Figure 23-1).

Figure 23-1 Upgrade utility install - language selection

Tip: When you use the upgrade utilities, if you have multiple servers running on the system, you must use the -k option to specify the name of the Windows registry key from which to retrieve information about the server being upgraded. The default value for the option is SERVER1. Use the -o option with the DSMUPGRD command to specify the location of the server options file.


5. The next window is the Welcome panel. Carefully read the information and before you begin, make sure that you have installed the upgrade utilities package in the system where the original version 5.3 or later is located. Click Next to continue (see Figure 23-2).

Figure 23-2 Tivoli Storage Manager 6.1 server upgrade


6. To validate the user ID and password, a connection will be made to the local system using SSH, RSH, REXEC, or SMB protocol. SMB is the interface used by File and Print Sharing (also known as CIFS). To use the SMB protocol, you must make sure that File and Print Sharing is enabled, and that port 445 is not blocked by your firewall.

Additionally, if you are running on Windows Server 2008 or Windows Vista, you might need to disable User Account Control (at least while running this wizard). If you choose not to disable User Account Control, you must make sure one of the other protocols is configured to allow the wizard to proceed.

The installer checks to see if you have administrator rights, and if that is successful, you see the Target System Authentication panel (see Figure 23-3). This panel helps to connect to other systems where V5 is installed and asks where the server is to be upgraded. You also fill in the host name and the administrator ID to establish a connection. Click Next to continue.

Figure 23-3 Tivoli Storage Manager V6.1 server upgrade


7. If you are upgrading a new server, select Begin a new upgrade process... If you are restarting an upgrade or continuing an upgrade in progress, select Continue the upgrade process... and select the dsmserv.dsk file representing the upgrade that you want to restart or continue. If you have no upgrades in progress, the Continue selection is disabled.

Here you have the option to begin an upgrade already selected because this is the first upgrade on this server (see Figure 23-4). Click Next to continue.

Figure 23-4 Tivoli Storage Manager V6.1 server upgrade - Select Upgrade


8. Here there five options, and you will come back to this panel over and over again when a phase is completed during the upgrade process. The only selectable option on this panel here is Prepare the database for the upgrade, where you start the prepare of the selected Tivoli Storage Manager database.

If you want to interrupt the upgrade process, it is best to do it while on this panel. Upon restarting the wizard, you can continue where you left off. If an upgrade phase is not yet allowed, it is disabled. If you select to re-run a phase that has already completed, you must re-run all phases after the phase you select to re-run. For example, if you are ready to begin the Insertion phase, but instead choose to re-run the Prepare phase, you must then complete all steps after the Prepare phase again. You cannot skip a phase (see Figure 23-5. Click Next to continue.

Figure 23-5 Tivoli Storage Manager 6.1 server upgrade prepare database for upgrade


9. Then you are asked to select the Tivoli Storage Manager Server instance to upgrade where the dsmserv.dsk and dsmserv.opt file resides (see Figure 23-6). Click Next to continue.

Figure 23-6 Tivoli Storage Manager 6.1 server upgrade - Select Upgrade


10. You can see the database and recovery log volumes created during the V5.5 database restore that we performed in order to be able to run a test restore. Verify that the paths of the database and logs being upgraded are correct and click Next to prepare this database for the upgrade (see Figure 23-7).

Figure 23-7 Tivoli Storage Manager 6.1 server upgrade - Verify Server Selection


11.Now we have started the Prepare phase. You can see the database prepare content in the Prepare Database window. It is an Echo for looking for the ANR1291 message to set the return code to 0, meaning that the Preparation phase was completed. You can view the full text of a message from the Tivoli Storage Manager Information Center at:


To display a message, enter the message ID in the Search field and click Go (see Figure 23-8).

Figure 23-8 Tivoli Storage Manager 6.1 server upgrade preparation phase

Note: If the upgrade wizard shows a non-zero return code, scroll up and check the messages displayed in the panel, or check the output file for the operation. If there is a success message that is wrapped, then the operation did complete successfully.

Under the target machine, C:\Program Files\Tivoli\TSM\server1, we have the prepare.out file, where we also can see the contents output from the prepare process.



12.When you click Next, you are brought back to the Select Upgrade Phase window where you select that we want to perform an upgrade.

The wizard will come back to this panel as you progress through the upgrade. If you wish to interrupt the upgrade process, it is best to do it while on this panel. Upon restarting the wizard, you can continue where you left off. If a phase is not yet allowed, it is disabled. If you select to re-run a phase that has already completed, you must re-run all phases after the phase you select to re-run.

For example, if you are ready to begin the Insertion phase, but instead choose to re-run the Prepare phase, you must then complete all steps after the Prepare phase again. You cannot skip a phase (see Figure 23-9). Click Next to continue.

Figure 23-9 Tivoli Storage Manager 6.1 - Server Upgrade Phase


13.Here we can see information that the server upgrade can be performed using one of two methods: media or network (see Figure 23-10). In our scenario we select to use the network option.

The media method extracts all data from the existing database and stores it on tape or other media. The data is then loaded into the target system from the media.

The network method requires that both source and target servers to be up and running. The data is transmitted directly from the source server to the target server over the network. This method requires:

– Enough disk space to have both the source and target servers up and running at the same time if the upgrade is done on the same server.

– A network connection of sufficient bandwidth between the source system and the target system. The network method also works if both databases are on the same system.

Click Next to continue.



14.When you click Next, you are brought back to the Select Upgrade Phase window. Note that the third choice (Extract the existing database to media) and the fifth choice (Insert the data into the new server instance) are not enabled. This is because we are doing the Extract and Insert at the same time and therefore we have the configure the new server instance button already selected (see Figure 23-11).

As stated previously, the wizard will come back to this panel as you progress through the upgrade. If you wish to interrupt the upgrade process, it is best to do it while on this panel. Upon restarting the wizard, you can continue where you left off.

Click Next to continue.

Figure 23-11 Tivoli Storage Manager 6.1 server upgrade - Configure the new server instance


15.The Modify Disk Configuration window indicates this phase of the upgrade process requires that the new database and log directories are available on the target system. If you are reusing disks from the existing database, make any desired or necessary changes to your file systems or disk subsystems before proceeding. Click Next to begin the creation of the new server instance (see Figure 23-12).

Figure 23-12 Tivoli Storage Manager 6.1 server upgrade - Modify Disk Configuration


16.In the Instance User ID window, specify the user ID and the password of the new instance owner. Note that a user ID can own only one instance, so ensure that you select the user ID that does not already own an instance. This user ID must already exist on the system. When you click Next, the wizard will attempt to establish a third connection to the local machine (see Figure 23-13).

Figure 23-13 Tivoli Storage Manager 6.1 server upgrade - Instance User ID


17.Next specify the instance directory that stores all of the server instance information such as the server options file, trace files, and other files specific to this instance (see Figure 23-14). You must manually create the server instance folder. If you click Choose before creating that folder, you will get an error message similar to this:

Directory C:\Program Files\Tivoli\TSM\Server1 was not found or is not accessible

Figure 23-14 Tivoli Storage Manager 6.1 server upgrade - Instance Directory


18.The Tivoli Storage Manager database is stored in a series of directories (containers) managed by the database manager (DB2). To improve data throughput, specify a large number of directories to allow the database manager to spread the workload over multiple disks:

– There are two ways to specify the database directories: Create a temporary file, and place each database directory on its own line in the file, then specify the location of the file in the top field, or specify each database directory directly in the bottom field, one directory per line.

– Each database directory must be empty, and, for maximum performance, should reside on its own dedicated disk. We chose to specify a list of four directories per line to use for the Tivoli Storage Manager database (see Figure 23-15).

Note that you can use up to 128 directories for the database. After specifying the directories, click Next to continue.

Figure 23-15 Tivoli Storage Manager 6.1 server upgrade - Database Directories


19.In the Recovery Log Directories panel, specify the directories of the database recovery logs (see Figure 23-16):

– The active log directory contains all transactions currently in progress on the server. If the system crashes or the server stops, the active log is all that is required to restart the server. The active log is broken up into files. After all transactions in a log file are completed, the log file is copied to an archive log directory.

– If a log file cannot be copied to the primary archive log directory, it is copied to the ArchiveLogFailover log directory, if specified. If a log file cannot be copied to either log directory, it remains in the active directory.

– If the active log fills up, transactions will fail. Therefore, ensure that the archive log directories are online with sufficient space to hold the log files. Logs in the archive log directories can be moved to another location, but these logs must be returned to the archive directory to perform a database restore operation.

– The mirror log directory contains the same contents as the active log directory, and is used for redundancy in case of disk failure. If your active log directory resides on a disk that is already mirrored or has other RAID protection, you might not need to specify a mirror log directory.

After specifying the database recovery log directories, click Next to continue.

Figure 23-16 Tivoli Storage Manager 6.1 server upgrade - Recovery Log Directories


20.The Configuration Summary window provides a list of the information you have input previously. It shows the Instance user ID, the Tivoli Storage Manager instance directory, the four database containers defined, and the log files directories (see Figure 23-17). Click Next to continue.

Figure 23-17 Tivoli Storage Manager 6.1 server upgrade - Configuration Summary


21.Here we have started the configuration of the instance. The configuration has many steps and will take several minutes. After the configuration is finished, we can see that the load format was completed with return code 0 (see Figure 23-18).

Figure 23-18 Tivoli Storage Manager 6.1 server upgrade - Configure Instance

Note: What happens to the database backup performed during dsmserv format or dsmserv loadformat is that during the server installation format processing for V6.1, you can see that the server performs a backup of the database, as indicated by the messages:

ANR2976I Offline DB backup for database TSMDB1 started.ANR2974I Offline DB backup for database TSMDB1 completed successfully.

This initial backup is required by DB2 in order for Tivoli Storage Manager to set the recovery log processing mode to ROLLFORWARD. At this point, this database backup only contains the server schema (DDL). This database backup is performed to a file in the local file system. This database backup is subsequently deleted by Tivoli Storage Manager because it only contains the server schema definitions which can be recreated by Tivoli Storage Manager anyway.

After completing the installation and configuration of the Tivoli Storage Manager server, we recommend that you perform a FULL database backup. This database backup and any subsequent database backups will be tracked in the server volume history, as expected, and used as part of the server disaster recovery manager (DRM) processing.


22.The last phase is to insert the data into the new server instance (see Figure 23-19). Remember that if you cancel the installation step, Select the phase of the upgrade to perform, the wizard will come back to this panel as you progress through the upgrade. Click Next to continue.

Figure 23-19 Tivoli Storage Manager 6.1 server upgrade - insert data into the new server instance


23.We have now reached the final step in the server upgrade (see Figure 23-20).

Figure 23-20 Tivoli Storage Manager 6.1 server upgrade - Load New Database


24.The contents of the existing database will now be loaded into the new data base. Remember that we are using the network method and the new server will be started first, then the existing database will be started and the data will be transferred. Click Next to begin the load process.

Data from the existing server will be inserted into the new database (see Figure 23-21).

Figure 23-21 Tivoli Storage Manager 6.1 server upgrade - Load New Database


25.Monitor the insertion process by viewing the messages in the display area. The messages can also be viewed afterwards by scrolling the message text in the windows (see Figure 23-22).



26.Figure 23-23 shows that we got the error code 405 on the INSERTDB process and the error code 0 on the EXTRACTDB process.

Figure 23-23 Tivoli Storage Manager 6.1 server upgrade - upgrade messages

27.You can view the full text of a message from the Tivoli Storage Manager Information Center at:


To display a message, enter the message ID in the Search field and click Go.

23.3.3 Summary of the upgrade

The messages in the Load New Database window must be always be checked, so all informational messages are displayed from the Insert and Extraction process.

Messages from the database insertion process:Example 23-2 here contains the messages in the Load New Database window from Figure 23-22 on page 550 and Figure 23-23 on page 551.

Example 23-2 Insertion process messages

ANR1336I INSERTDB: Ready for connections from the source server. Remaining time: 1:00:00ANR8206I TCP/IP Version 4 administrative driver ready for connection with clients on port 1500.ANR8200I TCP/IP Version 4 driver ready for connection with clients on port 1525.



ANR1336I INSERTDB: Ready for connections from the source server. Remaining time: 0:59:30ANR0408I Session 1 started for server $UPGRADESOURCE$ (Windows) (Tcp/Ip) for V6 Database Upgrade. ANR1337I A DBSPACE trigger has been removed. Not used in V6.1ANR1337I A LOGSPACE trigger has been removed.ANR1379I INSERTDB: Read 34,249,632 bytes and inserted 251,422 database entries in 0:00:00 (0.00 megabytes per hour).ANR1379I INSERTDB: Read 606,450,451 bytes and inserted 4,391,709 database entries in 0:05:11 (6690.68 megabytes per hour).ANR1379I INSERTDB: Read 1,085,441,646 bytes and inserted 7,607,483 database entries in 0:10:18 (6029.13 megabytes per hour).ANR1379I INSERTDB: Read 1,325,219,033 bytes and inserted 9,413,251 database entries in 0:15:26 (4910.15 megabytes per hour).ANR1379I INSERTDB: Read 1,575,287,817 bytes and inserted 11,155,415 database entries in 0:20:29 (4399.67 megabytes per hour).ANR1379I INSERTDB: Read 1,821,897,938 bytes and inserted 13,048,509 database entries in 0:25:34 (4076.40 megabytes per hour).ANR1379I INSERTDB: Read 2,084,615,297 bytes and inserted 14,751,729 database entries in 0:30:36 (3898.04 megabytes per hour).ANR0409I Session 1 ended for server $UPGRADESOURCE$ (Windows).ANR0136I Table updating statistics performed successfully for 5 of 5.ANR1524I INSERTDB: Beginning database update phase.ANR1525I INSERTDB: Updated 234 of 4,373,439 database entries in 0:02:15.ANR1525I INSERTDB: Updated 234 of 4,373,439 database entries in 0:07:15.ANR1525I INSERTDB: Updated 4,373,439 of 4,373,439 database entries in 0:11:05 ANR1395I INSERTDB: Process 1, database insert, has completed.ANR1397I INSERTDB: Found 82 database objects.ANR1398I INSERTDB: Processed 82 database objects.ANR1399I INSERTDB: Failed to process 0 database objects.ANR1517I INSERTDB: Processed 15,859,059 database records.ANR1518I INSERTDB: Read 2,207,931,666 bytes.ANR1519I INSERTDB: Elapsed time was 0:55:07.ANR1445I INSERTDB: Throughput was 2291.50 megabytes per hour.ANR1446I RUNSTATS: Table updating statistics started.ANR0136I Table updating statistics performed successfully for 119 of 119.ANR1528I RUNSTATS: Table updating statistics completed in 0:14:43.ANR0369I Stopping the database manager because of a server shutdown.

A closer look of the messagesFirst we see the messages, ANR1337I A DBSPACE trigger has been removed, and ANR1337I A LOGSPACE trigger has been removed. We have these options in the test database dsmserv.opt file and we got these messages because these options are now removed in V6.1

Insertion process completed with return code 405We can see that have a return code 405 from the Insert process, although we have a message ANR1395I that indicates success. This is due to a problem in the message parsing code where the string is searching from the beginning of the thread instead of the whole string. The ANR1395I message that indicates success is not found in the string, and the Insertion process completed with return code 405.

Upgrade wizard non zero return code on successful INSERTDBThe insertion message ANR1525I was received during our upgrade:


ANR1525I INSERTDB: Updated 4,373,439 of 4,373,439 database entries in 0:11:05.ANR1395I INSERTDB: Process 1, database insert, has completed.

The Insertion process completed with return code 405. For the INSERTDB, the message ANR1395I indicates success.

Messages from the database extraction processHere we view the messages from the extraction process during the upgrade process (see Example 23-3).

Example 23-3 Extraction process messages

Waiting for the new server to initialize...ANR0900I Processing options file C:\Program Files\Tivoli\TSM\server1\dsmserv.opt.ANR7800I DSMSERV generated at 12:07:33 on Mar 12 2009.Tivoli Storage Manager for WindowsVersion 5, Release 5, Level 2.0Licensed Materials - Property of IBM(C) Copyright IBM Corporation 1990, 2007.All rights reserved.U.S. Government Users Restricted Rights - Use, duplication or disclosurerestricted by GSA ADP Schedule Contract with IBM Corporation.ANR4726I The ICC support module has been loaded.ANR0990I Server restart-recovery in progress.ANR0200I Recovery log assigned capacity is 1000 megabytes.ANR0201I Database assigned capacity is 5000 megabytes.ANR0306I Recovery log volume mount in progress.ANR0285I Database page shadowing started using file dbpgshdw.bdt.ANR0353I Recovery log analysis pass in progress.ANR0354I Recovery log redo pass in progress.ANR0355I Recovery log undo pass in progress.ANR0352I Transaction recovery complete.ANR1635I The server machine GUID, 23.47.17.a1.e3.cf.11.dd.b7.b4.00.50.56.90.7c.69, has initialized.ANR4726I The NAS-NDMP support module has been loaded.Removed som uncessesary information from the output..ANR4029I EXTRACTDB: Database checkpoint started.ANR4030I EXTRACTDB: Database checkpoint completed.ANR0610I EXTRACTDB started by ADMINISTRATOR as process 1.ANR0408I Session 1 started for server $UPGRADETARGET$ (Windows) (Tcp/Ip) for V6 Database Upgrade. ANR1392I EXTRACTDB: Extracted 3,736,534 database entries in 197,824 pages and wrote 515,744,948 bytes in 0:05:00 (5892.00 megabytes per hour).ANR1392I EXTRACTDB: Extracted 7,143,650 database entries in 410,279 pages and wrote 1,030,018,805 bytes in 0:10:00 (5892.00 megabytes per hour).ANR1392I EXTRACTDB: Extracted 9,045,569 database entries in 506,661 pages and wrote 1,274,861,977 bytes in 0:15:07 (4822.49 megabytes per hour).ANR1392I EXTRACTDB: Extracted 11,123,470 database entries in 622,107 pages and wrote 1,569,211,751 bytes in 0:20:07 (4461.97 megabytes per hour).ANR1392I EXTRACTDB: Extracted 12,796,983 database entries in 703,265 pages and wrote 1,794,542,333 bytes in 0:25:07 (4087.33 megabytes per hour).ANR1392I EXTRACTDB: Extracted 14,352,904 database entries in 792,509 pages and wrote 2,005,587,569 bytes in 0:30:07 (3809.19 megabytes per hour).ANR0409I Session 1 ended for server $UPGRADETARGET$ (Windows).ANR1382I EXTRACTDB: Process 1, database extract, has completed.ANR1383I EXTRACTDB: Found 124 database objects.


ANR1384I EXTRACTDB: Processed 82 database objects.ANR1385I EXTRACTDB: Skipped 42 empty database objects.ANR1386I EXTRACTDB: Failed to process 0 database objects.ANR1387I EXTRACTDB: Processed 15,859,059 database records.ANR1388I EXTRACTDB: Read 879,821 database pages.ANR1389I EXTRACTDB: Wrote 2,207,931,596 bytes.ANR1390I EXTRACTDB: Elapsed time was 0:34:47.ANR1391I EXTRACTDB: Throughput was 3631.05 megabytes per hour.

Extraction process completed with return code 0

Figure 23-24 is the Upgrade Complete window. Click Done and review the installation logs.

Figure 23-24 Tivoli Storage Manager 6.1 server upgrade - Upgrade Complete

After the upgrade process is done, we start the Tivoli Storage Manager V6.1 server on the new system. We start the server in the foreground with DSMSERV and look for error messages that would indicate options that are not supported with the Tivoli Storage Manager V6.1 server that was defined in the V5.5 test database.

Important: It is possible, after the upgrade to V6.1 is complete, that conditions might cause the need to temporarily revert to the previous version of the server. Successfully reverting to the previous version of the server is possible only if you performed all of the preparation steps. To understand why this is important, review the procedure for reverting an upgraded server to its previous version in 23.8, “How to rollback to V5 if needed or restart the process” on page 560.


23.4 Steps after V6.1 server is started

After the server is upgraded, you need to perform steps to verify that the server was successfully upgraded and can operate normally.

23.4.1 Initial verification

The steps include starting the server, registering licenses, and backing up the database:

1. Verify access to storage pools on disk:

For all disk space that was used for storage pools (device types of FILE or DISK) by the V5 server, verify that the user ID that owns the upgraded Tivoli Storage Manager server instance has ownership or read/write permission.

2. Start the server instance after the upgrade:

Verify that the server instance is correctly set up by starting the server instance.

Remember that starting the server is an operating system-level operation and has certain restrictions. If you do not have the permissions to use the DSMSERV program, you cannot start it. If you do not have authority to read or write files in the instance directory, you cannot start that instance of the server.

3. Register the licenses:

Immediately register any Tivoli Storage Manager licensed functions that you have purchased so that you do not lose any data after you begin using the server. Use the REGISTER LICENSE command for this task.

4. Back up the database after upgrading the server:

After successfully upgrading the server, perform a full backup of its database as soon as possible. Before performing the backup, you must first select the device class for backups of the database.

Complete the following steps:

a. If you did not use the upgrade wizard (dsmupgdx) to upgrade the server, ensure that you have completed the steps to manually configure the system for database backups.

b. If you used the media method for upgrade and used a tape device, remove or check out from the library the tape that was used to hold the extracted data. Prevent the tape from being reused until you are sure that the upgraded server is running properly and you do not need to repeat the database insertion step.

c. Select the device class to be used for automatic backups of the database. Issue the following command from a IBM Tivoli Storage Manager administrative command line.

set dbrecovery device_class_name

The device class that you specify is used by the database manager for all automatic database backups.

d. Back up the database using the backup command:

backup db devclass=device_class_name type=full

The device class can be the same as or different from the device class that you specified with the SET DBRECOVERY command. If the device class is different, you receive a warning message, but the backup operation continues.


23.4.2 Database backup

In this section we provide information about the backup of the database in Tivoli Storage Manager V6.1.

MethodsThe following methods are used for backup of for the Tivoli Storage Manager V6.1 database:

� Full backup:

This is typically done through Tivoli Storage Manager Admin Schedule. You can also use server-to-server for device class of backup.


This is not quite the same as Tivoli Storage Manager 5.x incremental backup. You also use server-to-server for device class of backup.


This is typically done through Tivoli Storage Manager Admin Schedule and it does not clear out archive logs. You can also use server-to-server for device class of backup.

Number of volumes used for the V6.1 database backupHere we list the number of volumes used for the various types of backup:

� Full backup:

– For devclass tape, at least one tape volume is used:It contains the database backup and also active/archive logs since the last full backup.

– For devclass file, at least two volumes are used. Each name ends in .dbv.The first contains the database backup; the second contains active/archive logs since the last full backup.


– For devclass tape, at least one tape volume is used.It contains the database backup and also active/archive logs since last full backup.

– For devclass file, at least two volumes are used. Each name ends in .dss.The first contains the database backup, the second contains active/archive logs since the last full backup.


– Contains all archive logs since last full db backup– For devclass tape, at least 1 volume used– Contains Changed pages, plus initial database metadata– For devclass file, at least 2 volumes used, name ends in ‘.dbv’– Contains Changed pages, plus initial database metadata

The point to emphasize here is that a FILE DEVCLASS verses a TAPE DEVCLASS uses a different number of volumes, and that the extensions for a database backup verses a snapshot backup are different. Also, be sure to check your file includes/excludes on the system if you are doing FILE devclass database backups.

Note: DB2 Snapshot is not supported in this release.

Note: You must add new exclude statements into the dsm.opt files to make sure that you do not back up the database backups.


23.5 Sample commands to run for database upgrade validation

Run these commands before and after you upgrade a server to get a summary of information about the contents of the server database. Comparing the results of the commands before and after the upgrade can help confirm that all data transferred correctly. The samples provide a set of commands to start with.

The following commands show examples for getting summary information for some specific types of objects:

� File spaces:

select node_name, count(*) as “Number of Filespaces” from filespaces group by node_name order by 2

Nodes select platform_name, count(*) as “Number of Nodes” from nodes group by platform_name

� Backed-up files:

select node_name,sum(num_files) as "Number of Backup Files" from occupancy where type='Bkup' group by node_name

� Archived files:

select node_name,sum(num_files) as "Number of Archive Files" from occupancy where type='Arch' group by node_name

� Management classes:

select count(*) as “Number of Management Classes” from mgmtclasses

� Server scripts:

select count(*) as “Number of Server Scripts” from script_names

� Storage pools:

select count(*) as “Number of Storage Pools” from stgpools

� Example 23-4 shows a more complete set of commands. You can run this set of commands as a script from a Tivoli Storage Manager server command line. Redirect the output to a file to save the results.

Example 23-4 Select commands

select node_name, count(*) as “Number of Filespaces” from filespaces group by node_name order by 2select platform_name, count(*) as “Number of Nodes” from nodes group by platform_nameselect count(*) as “Number of Administrators” from adminsselect node_name,sum(num_files) as "Number of Backup Files" from occupancy where type='Bkup' group by node_nameselect node_name,sum(num_files) as "Number of Archive Files" from occupancy where type='Arch' group by node_nameselect count(*) as “Number of Schedule Associations” from associationsselect count(*) as “Number of Backupsets” from backupsetsselect count(*) as “Number of Client Option Sets” from cloptsetsselect count(*) as “Number of Collocation Groups” from collocgroupselect count(*) as “Number of Archive CopyGroups” from ar_copygroupsselect count(*) as “Number of Backup CopyGroups” from bu_copygroupsselect count(*) as “Number of Data Movers” from datamoversselect count(*) as “Number of Device Classes” from devclasses


select count(*) as “Number of Domains” from domainsselect count(*) as “Number of Drives” from drivesselect count(*) as “Number of Libraries” from librariesselect count(*) as “Number of Library Volumes” from libvolumesselect count(*) as “Number of Volumes” from volumesselect count(*) as “Number of Management Classes” from mgmtclassesselect count(*) as “Number of Node Groups” from nodegroupselect count(*) as “Number of Device Paths” from pathsselect count(*) as “Number of Policy Sets” from policysetsselect count(*) as “Number of Client Schedules” from client_schedulesselect count(*) as “Number of Admin Schedules” from admin_schedulesselect count(*) as “Number of Server Scripts” from scriptsselect count(*) as “Number of Servers Defined” from serversselect count(*) as “Number of Servers Groups Defined” from server_groupselect count(*) as “Number of Storage Pools Defined” from stgpools

23.6 Common database maintenance tasks

Here we walk through several database maintenance examples that are new in V6.1:

� Move the Tivoli Storage Manager V6 database to a new location:

a. Back up DB type=full devclass=xxx, halt server.

b. Make new empty directories, create new dbdir file.

c. Using DB2, drop the DB.

d. Dsmserv restore db on=dbdir.file.

e. Start the Tivoli Storage Manager Server.

� Move the active logs to a new location:

a. Create a new directory to contain the active logs.

b. Update dsmserv.opt ActiveLogDir to point to new directory.

c. Halt and restart the Tivoli Storage Manager Server. DB2 automatically moves active logs to new directory.

� Add mirroring to the Tivoli Storage Manager V6 database:

a. Make a new empty directory for the log mirrors.

b. Update the dsmserv.opt file MirrorLogDir Parameter.

c. Stop and restart the Tivoli Storage Manager Server.

� Extend the Tivoli Storage Manager V6 database:

a. Create a new empty directory to contain the database volumes.

b. Issue the Extend DBSpace command with the new database directory.

c. Database is dynamically extended; there is no need to restart Tivoli Storage Manager.

Note: The procedure is different for moving archive logs to a new location. You should specify a new directory for the archive logs in the dsmserv.opt file on the archivelogdir parameter. In this case, however, when Tivoli Storage Manager is restarted, the existing archive logs are not moved but rather are just kept in the old location. New archive logs are written to the new location. The archive logs are then cleared when a database backup is done, and the logs are older than two full backups ago.


� Recover the database when a disk from the database goes bad using a database restore to the current point in time:

a. Determine a new location with the same amount of space.

b. Create a text file containing the list of directories for the database.

c. Using DB2, drop the DB.

d. Do a dsmserv restore db on=filename where filename is the name of the file created in previous step.

e. Restart the Tivoli Storage Manager Server.

� Increase the size of the Active Logs:

a. Ensure that the location for the active logs has enough space for the new log size to be used.

b. Edit dsmserv.opt file for the Tivoli Storage Manager Server instance. Change or Add the ActiveLogSize parameter to the file. (Size is in MB; minimum is 2 GB, maximum is 128 GB).

c. Restart Tivoli Storage Manager.

d. New logs will be automatically defined, each 512MB in size until the ActiveLogSize amount is reached. Mirrors, if being used. are also re-defined.

� Reduce Tivoli Storage Manager V6.1 database after deleting data:

a. Create a file containing list of directories that you want to use.

b. Do a full database backup.

c. Halt the Tivoli Storage Manager server.

d. Using DB2, drop the database.

e. Do a dsmserv restore db on= command specifying the file you created in the first step.

f. Restart the Tivoli Storage Manager server.

23.7 Scripting and reporting

Scripting in Tivoli Storage Manager V6.1 has been expanded with the DB2 database.

23.7.1 SQL function

In Tivoli Storage Manager V6.1 we have now complete SQL function. You can obtain information from the server database more easily than before with full-function SQL queries. The database makes more sophisticated SQL queries on the data possible.

You can directly access DB2 database, this should be in read-only mode. Tivoli Storage Manager DB2 database is exposed but not documented. Schema is proprietary and might change in the future.

Check compatibility of third party reporting tools to determine if they work with Tivoli Storage Manager V6.


23.7.2 SQL syntax enforcement examples

Here we list some examples of SQL syntax enforcement:

� The LIKE predicate is not supported for a nested SELECT statement. For example, you receive an error if you use the LIKE predicate as in this statement:

select * from volumeusage where volume_name like (select distinct volume_name from volumeusage where node_name='node1')

� Replace such usage with the = operator, as in this statement:

select * from volumeusage where volume_name=(select distinct volume_name from volumeusage where node_name='node1')

� Labeled duration cannot be compared in a SELECT statement. For example, the following statement results in an SQL error:

select * from actlog where (current_time-date_time) seconds <= 60 seconds

� The following statement is an example of correct usage:

select * from actlog where second(current_time-date_time) <= 60

SQL exampleExample 23-5 shows a select command that creates temporary workspace within DB2.

Example 23-5 This is an example of a select command that creates temporary workspace within DB2

select node_name,count(*) as Number_of_Objects, sum(file_size) as Bytes_of_WKLD from contents where node_name='61SOURCE18' and filespace_id=1 and file_name like '\WKLD%' group by node_name

Example 23-6 shows how to find Centera “ClipID” through DB2.

Example 23-6 Example of how to find Centera “ClipID” through DB2

db2 "select TSMDB1.AS_SEGMENTS.PVRPOS as ClipID from TSMDB1.AS_SEGMENTS,TSMDB1.AF_SEGMENTS where TSMDB1.AF_SEGMENTS.BFID=‘42803004’ and TSMDB1.AS_SEGMENTS.VOLID=TSMDB1.AF_SEGMENTS.VOLID and TSMDB1.AS_SEGMENTS.START=TSMDB1.AF_SEGMENTS.START"

db2 "select tsmdb1.AF_SEGMENTS.BFID as ObjID from tsmdb1.AF_SEGMENTS,tsmdb1.AS_SEGMENTS where tsmdb1.AS_SEGMENTS.PVRPOS=x'37 ... 542’ and tsmdb1.AS_SEGMENTS.VOLID=tsmdb1.AF_SEGMENTS.VOLID and tsmdb1.AS_SEGMENTS.START=tsmdb1.AF_SEGMENTS.START“

23.8 How to rollback to V5 if needed or restart the process

The following steps show how to go back to the previous V5 Tivoli Storage Manager if necessary.

1. If the source server is at Tivoli Storage Manager 5.3 when dsmupgrd preparedb is done:

You will need to restore your database from backups prior to restarting your server and you will need to re-install Tivoli Storage Manager 5.3 from installation media if using in-place upgrade methods.


2. If your source server is at Tivoli Storage Manager 5.4 when dsmupgrd preparedb is done:

You will need to restore your database from backups prior to restarting your server and you will need to re-install Tivoli Storage Manager 5.4 from installation media if using in-place upgrade methods

3. If your source server is at Tivoli Storage Manager 5.5.0 – 5.5.2 when dsmupgrd preparedb is done:

You will not need to restore your database from backups prior to restarting your server. You need to re-install Tivoli Storage Manager 5.5 from installation media if using in-place upgrade methods

More detailed instructions for fallback are given in the database upgrade section of the manual IBM Tivoli Storage Manager Server Upgrade Guide, SC23-9554. This discussion is only the requirements for the database restore in order to go back to V5. This is discussed in the section “Reverting from V6.1 to the previous V5 Server Version”.

If you need to restart the upgrade process If you need to restart the upgrade process, note that it is not checkpoint restartable. If for any reason the process fails or is cancelled, it needs to be restarted from the beginning.

If you are using the extract to media method for upgrade and have completed the extract, you can restart the upgrade from the INSERTDB step after cleaning up directories and reformatting the database as shown in Example 23-7.

Example 23-7 Cleanup prior to restart upgrade

db2 start database managerdb2 drop db TSMDB1

23.9 Debugging

In cases where you need to investigate log messages, there are several files where information is available, as described next.

Ways to debug the installationHere we present various ways to debug the installation:

� Logs are available in logs.zip

Windows: <Install Dir>\logs.zip

� Start with the main log file:

coi\plan\install\MachinePlan_localhost\logs\MachinePlan_localhost_[INSTALL_0414_22.35].log

� Look for the step where the install has failed. This leads us to our next log:

MachinePlan_localhost_[INSTALL_0414_22.35].log

Note: dsmupgrd will work to upgrade a 5.3 database to Tivoli Storage Manager V6.1, but Tivoli Storage Manager V5.3 is no longer supported for other support issues.

Note: This might change at level of 5.5.3. Review the readme files to see if this applies.


� DB2 step logs:

coi\plan\install\MachinePlan_localhost\00002_DB2_9.5\DB2_9.5.logcoi\plan\tmp:

� Administration Center step logs:

coi\plan\install\MachinePlan_localhost\00003_TSM_AdminCenter\logs:

� Deployment Engine Logs:

Windows: C:\Program Files\IBM\Common\acsi\logs\<system user>

23.10 Gathering logs

In the case where logs.zip is not created during the installation, you can gather logs manually by following the paths listed in 18.14, “Gathering logs” on page 404.

Code Description of various Exit Error codes in InstallAnywhere can be found in 18.14, “Gathering logs” on page 404.

23.11 Upgrade for NAS TOC data on AIX

The following process demonstrates the manual extractdb and insertdb to media, for the purpose of validating that the V6.1.2 server software now supports NAS TOC upgrades, which had been a restriction and disabled in the V6.1.0 and V6.1.1 releases.

23.11.1 Steps for the upgrade

To begin this scenario, we will use the select statements developed during the V6.1 beta testing program, as a method to compare before and after database content. This macro is shown in Example 23-8.

Example 23-8 Macro with a series of select statements for use to compare the database upgrade

select node_name, count(*) as "Number of Filespaces" from filespaces group by node_name order by 2select platform_name, count(*) as "Number of Nodes" from nodes group by platform_nameselect node_name,sum(num_files) as "Number of Backup Files" from occupancy where type='Bkup' group by node_nameselect node_name,sum(num_files) as "Number of Archive Files" from occupancy where type='Arch' group by node_nameselect count(*) as "Number of Management Classes" from mgmtclassesselect count(*) as "Number of Server Scripts" from script_namesselect count(*) as "Number of Storage Pools" from stgpools

After running these select statements in a macro, the output of our Tivoli Storage Manager V5.5.2 server is as shown in Example 23-9.

Example 23-9 Select statement output

ANS8000I Server command: 'select node_name, count(*) as "Number of Filespaces" from filespaces group by node_name order by 2'


NODE_NAME Number of Filespaces------------------ --------------------BMICHLER 1BOGDAN_ORACLE 1BRIGITTE 1BZIEMANN 1JONATHAN 1KARIN 1LINUX-TEST 1ORA1 1LT-JS 2NAS1 2RAINER 2TESTPC-081 3GERD 8RS6000_CLIENT 9

ANS8000I Server command: 'select platform_name, count(*) as "Number of Nodes" from nodes group by platform_name'

PLATFORM_NAME Number of Nodes---------------- --------------- 2AIX 1Linux86 2Mac 1NetApp 1TDPO Linux86 2WinNT 9

ANS8000I Server command: 'select node_name,sum(num_files) as "Number of Backup Files" from occupancy where type='Bkup' group by node_name'

NODE_NAME Number of Backup Files------------------ ----------------------BMICHLER 17258BOGDAN_ORACLE 61BZIEMANN 118GERD 48097JONATHAN 6966KARIN 6LINUX-TEST 470LT-JS 696138NAS1 5ORA1 46RAINER 1974RS6000_CLIENT 110683TESTPC-081 195254ANS8000I Server command: 'select node_name,sum(num_files) as "Number of Archive Files" from occupancy where type='Arch' group by node_name'

NODE_NAME Number of Archive Files------------------ -----------------------GERD 40852LT-JS 32


TESTPC-081 38ANS8000I Server command: 'select count(*) as "Number of Management Classes" from mgmtclasses'

Number of Management Classes---------------------------- 11ANS8000I Server command: 'select count(*) as "Number of Server Scripts" from script_names'

Number of Server Scripts------------------------ 20ANS8000I Server command: 'select count(*) as "Number of Storage Pools" from stgpools'

Number of Storage Pools----------------------- 15

Now, after collecting our comparison data, we then proceed to perform the manual upgrade steps, as indicated in the process flow that follows:

1. Extract the data from the V5.5.2 server as shown in Example 23-10.

Example 23-10 AIX sample data extraction

# export | grep DSMdeclare -x DSMSERV_CONFIG="/usr/tivoli/tsm/server/bin/dsmserv.opt"declare -x DSMSERV_DIR="/usr/tivoli/tsm/upgrade/bin"

# cd /usr/tivoli/tsm/upgrade/bin

# /usr/tivoli/tsm/upgrade/bin/dsmupgrd preparedbANR7800I DSMSERV generated at 12:32:53 on Mar 11 2009.

Tivoli Storage Manager for AIX-RS/6000Version 5, Release 5, Level 2.0



ANR0900I Processing options file /usr/tivoli/tsm/server/bin/dsmserv.opt.ANR7811I Using instance directory /usr/tivoli/tsm/server/bin.ANR4726I The ICC support module has been loaded.ANR0990I Server restart-recovery in progress.ANR0200I Recovery log assigned capacity is 1112 megabytes.ANR0201I Database assigned capacity is 2144 megabytes.ANR0306I Recovery log volume mount in progress.ANR0353I Recovery log analysis pass in progress.ANR0354I Recovery log redo pass in progress.


ANR0355I Recovery log undo pass in progress.ANR0352I Transaction recovery complete.ANR1635I The server machine GUID, 00.00.00.00.ac.29.11.dd.a1.26.08.63.c0.a8.6f-.0e, has initialized.ANR2283I Database backup trigger defined, but is disabled.ANR4726I The NAS-NDMP support module has been loaded.ANR1794W TSM SAN discovery is disabled by options.ANR1747W The data mover NAS1 was not found on the SAN. The data moverdefinition has been marked offline.ANR8440E Initialization failed for SCSI library LIB1; will retry in 2minute(s).ANR1305I Disk volume /usr/tivoli/tsm/server/bin/backup.dsm varied online.ANR1305I Disk volume /usr/tivoli/tsm/server/bin/tcovol01.dsm varied online.ANR1305I Disk volume /usr/tivoli/tsm/server/bin/archive.dsm varied online.ANR1305I Disk volume /usr/tivoli/tsm/server/bin/spcmgmt.dsm varied online.ANR1412W Volume 610AGB access mode is "unavailable".ANR2718W Schedule manager disabled.ANR0129I Database upgrade completed successfully.ANR0993I Server initialization complete.ANR0916I TIVOLI STORAGE MANAGER distributed by Tivoli is now ready for use.ANR1444W PREPAREDB: Database upgrade may not be supported for this serverbecause it uses backup sets.ANR1445W PREPAREDB: Database upgrade may not be supported for this serverbecause it uses NAS backups with TOCs.ANR0991I Server shutdown complete.

# /usr/tivoli/tsm/upgrade/bin/dsmupgrd extractdb devclass=dcupgrade manifest=/tsm/upgrade/manifest.txtANR7800I DSMSERV generated at 12:32:53 on Mar 11 2009.

Tivoli Storage Manager for AIX-RS/6000Version 5, Release 5, Level 2.0



ANR0900I Processing options file /usr/tivoli/tsm/server/bin/dsmserv.opt.ANR7811I Using instance directory /usr/tivoli/tsm/server/bin.ANR4726I The ICC support module has been loaded.ANR0990I Server restart-recovery in progress.ANR0200I Recovery log assigned capacity is 1112 megabytes.ANR0201I Database assigned capacity is 2144 megabytes.ANR0306I Recovery log volume mount in progress.ANR0353I Recovery log analysis pass in progress.ANR0354I Recovery log redo pass in progress.ANR0355I Recovery log undo pass in progress.ANR0352I Transaction recovery complete.ANR1635I The server machine GUID, 00.00.00.00.ac.29.11.dd.a1.26.08.63.c0.a8.6f-.0e, has initialized.ANR2283I Database backup trigger defined, but is disabled.ANR4726I The NAS-NDMP support module has been loaded.


ANR1794W TSM SAN discovery is disabled by options.ANR1747W The data mover NAS1 was not found on the SAN. The data moverdefinition has been marked offline.ANR8440E Initialization failed for SCSI library LIB1; will retry in 2minute(s).ANR1305I Disk volume /usr/tivoli/tsm/server/bin/spcmgmt.dsm varied online.ANR1305I Disk volume /usr/tivoli/tsm/server/bin/archive.dsm varied online.ANR1305I Disk volume /usr/tivoli/tsm/server/bin/backup.dsm varied online.ANR1305I Disk volume /usr/tivoli/tsm/server/bin/tcovol01.dsm varied online.ANR1412W Volume 610AGB access mode is "unavailable".ANR1444W EXTRACTDB: Database upgrade may not be supported for this serverbecause it uses backup sets.ANR1445W EXTRACTDB: Database upgrade may not be supported for this serverbecause it uses NAS backups with TOCs.ANR4029I EXTRACTDB: Database checkpoint started.ANR4030I EXTRACTDB: Database checkpoint completed.ANR0610I EXTRACTDB started by ADMINISTRATOR as process 1.ANR8340I FILE volume /tsm/upgrade/45449177.ost mounted.ANR1360I Output volume /tsm/upgrade/45449177.ost opened (sequence number 1).ANR8439I SCSI library VTL_BIG is ready for operations.ANR8439I SCSI library VTL_SMALL is ready for operations.ANR8439I SCSI library VTL1 is ready for operations.ANR1361I Output volume /tsm/upgrade/45449177.ost closed.ANR1380I EXTRACTDB: Output stream 1 used volume /tsm/upgrade/45449177.ost.ANR1382I EXTRACTDB: Process 1, database extract, has completed.ANR1383I EXTRACTDB: Found 121 database objects.ANR1384I EXTRACTDB: Processed 82 database objects.ANR1385I EXTRACTDB: Skipped 39 empty database objects.ANR1386I EXTRACTDB: Failed to process 0 database objects.ANR1387I EXTRACTDB: Processed 2,999,980 database records.ANR1388I EXTRACTDB: Read 141,121 database pages.ANR1389I EXTRACTDB: Wrote 464,498,292 bytes.ANR1390I EXTRACTDB: Elapsed time was 0:01:41.ANR1391I EXTRACTDB: Throughput was 15754.46 megabytes per hour.

2. Prepare the disk for the database and logs on the UNIX system.

3. Issue the DSMSERV LOADFORMAT command, as shown in Example 23-11.

Example 23-11 Preparing Tivoli Storage Manager Server instance directories and DB2 environment

$ dsmserv -u tsm2 -i /home/tsm2 loadformat dbdir=/tsm2/dbdir001,/tsm2/dbdir002,/tsm2/dbdir003,/tsm2/dbdir004 activelogsize=8192 activelogdir=/tsm2/actlog archlogdir=/tsm2/archlog mirrorlogdir=/tsm2/activelogm





ANR7801I Subsystem process ID is 442498.ANR0900I Processing options file /home/tsm2/dsmserv.opt.ANR7811I Using instance directory /home/tsm2.ANR4726I The ICC support module has been loaded.ANR0152I Database manager successfully started.ANR0152I Database manager successfully started.ANR1380I The buffer pool monitor switch is enabled.ANR1004I Server formatting complete, database ready for loading.ANR0369I Stopping the database manager because of a server shutdown.ANR2976I Offline DB backup for database TSMDB1 started.

ANR2974I Offline DB backup for database TSMDB1 completed successfully.$

Next, we perform the DSMSERV INSERTDB command, as shown in Example 23-12.

Example 23-12 DSMSERV INSERTDB command

$ dsmserv insertdb man=/code/upgradedb/manifest.txt




ANR7801I Subsystem process ID is 442544.ANR0900I Processing options file /home/tsm2/dsmserv.opt.ANR7811I Using instance directory /home/tsm2.ANR4726I The ICC support module has been loaded.ANR0990I Server restart-recovery in progress.ANR0153I Database manager already running.ANR1380I The buffer pool monitor switch is enabled.ANR1636W The server machine GUID changed: old value (), new value (00.00.00.00-.4f.96.11.de.82.b2.08.63.09.0c.05.7f).ANR1386I Beginning schema verification for the database insert process.ANR1387I Schema verification for the database insert process has completed.ANR8340I FILE volume /code/upgradedb/45449177.ost mounted.ANR1363I Input volume /code/upgradedb/45449177.ost opened (sequence number1).ANR8200I TCP/IP Version 4 driver ready for connection with clients on port1502.ANR1337I A DBBACKUP trigger has been removed.ANR1337I A LOGSPACE trigger has been removed.ANR1526I INSERTDB: Building indices and checking table integrity.ANR1364I Input volume /code/gerd-upgradedb/45449177.ost closed.ANR1527I INSERTDB: Checked 82 of 82 database objects in 0:00:43.ANR0136I Table updating statistics performed successfully for 4 of 4.ANR1524I INSERTDB: Beginning database update phase.ANR1525I INSERTDB: Updated 750,338 of 750,338 database entries in 0:00:43.ANR1395I INSERTDB: Process 1, database insert, has completed.ANR1397I INSERTDB: Found 82 database objects.


ANR1398I INSERTDB: Processed 82 database objects.ANR1399I INSERTDB: Failed to process 0 database objects.ANR1517I INSERTDB: Processed 2,999,980 database records.ANR1518I INSERTDB: Read 464,498,436 bytes.ANR1519I INSERTDB: Elapsed time was 0:04:00.ANR1445I INSERTDB: Throughput was 6630.00 megabytes per hour.ANR1446I RUNSTATS: Table updating statistics started.ANR0136I Table updating statistics performed successfully for 119 of 119.ANR1528I RUNSTATS: Table updating statistics completed in 0:00:28.ANR0369I Stopping the database manager because of a server shutdown.

After the insertion has completed, we then start the Tivoli Storage Manager Server instance and review the content to ensure we have transferred all our nodes and object pointers. Here is the V6.1 Tivoli Storage Manager Server macro output for comparison after our database upgrade, as seen in Example 23-13.

Example 23-13 Select commands run on V6.1 Tivoli Storage Manager Server after insertdb completed

ANS8000I Server command: 'select node_name, count(*) as "Number of Filespaces" from filespaces group by node_name order by 2'

NODE_NAME Number of Filespaces---------------------------------------------------------------BMICHLER 1BOGDAN_ORACLE 1BRIGITTE 1BZIEMANN 1JONATHAN 1KARIN 1LINUX-TEST 1ORA1 1LT-JS 2NAS1 2RAINER 2TESTPC-081 3GERD 8RS6000_CLIENT 9

ANS8000I Server command: 'select platform_name, count(*) as "Number of Nodes" from nodes group by platform_name'

PLATFORM_NAME Number of Nodes------------------ ----------------AIX 1Linux86 2Mac 1NetApp 1TDPO Linux86 2WinNT 9 2


ANS8000I Server command: 'select node_name,sum(num_files) as "Number of Backup Files" from occupancy where type='Bkup' group by node_name'

NODE_NAME Number of Backup Files-----------------------------------------------------------------------BMICHLER 17258BOGDAN_ORACLE 61BZIEMANN 118GERD 48098JONATHAN 6966KARIN 6LINUX-TEST 470LT-JS 696138NAS1 5ORA1 46RAINER 1974RS6000_CLIENT 110683TESTPC-081 195254

ANS8000I Server command: 'select node_name,sum(num_files) as "Number of Archive Files" from occupancy where type='Arch' group by node_name'

NODE_NAME Number of Archive Files------------------------------------------------------------------------GERD 40852LT-JS 32TESTPC-081 38

ANS8000I Server command: 'select count(*) as "Number of Management Classes" from mgmtclasses'

Number of Management Classes---------------------------- 11ANS8000I Server command: 'select count(*) as "Number of Server Scripts" from script_names'

Number of Server Scripts------------------------ 20ANS8000I Server command: 'select count(*) as "Number of Storage Pools" from stgpools'

Number of Storage Pools------------------------15


Next, we query for the volume that contains the NAS TOC data to verify that these objects have been transferred when using the Tivoli Storage Manager V6.1.2 INSERTDB utility. First we use the Tivoli Storage Manager command query NASBACKUP * and show the output in Example 23-14.

Example 23-14 Query content against the volume which holds the NAS TOC pointers and data

tsm: RS6000>q vol stgp=TOCPOOL

Volume Name Storage Device Estimated Pct Volume Pool Name Class Name Capacity Util Status-------------------- ----------- ---------- --------- ----- --------/usr/tivoli/tsm/- TOCPOOL DISK 0.0 M 0.0 Off-Lineserver/bin/tcovol01-.dsm

tsm: RS6000>q content /usr/tivoli/tsm/server/bin/tcovol01.dsm

Node Name Type Filespace FSID Client's Name for File Name--------------- ---- ---------- ---- ------------------------NAS1 Bkup /vol/vol0 1 /TSM/TOCNAS1 Bkup /vol/mixe- 2 /TSM/TOC dvol01

23.11.2 Summary

This short review demonstrates that in Tivoli Storage Manager V6.1.2, the NAS TOC capabilities have been enabled and are functioning as they should. This review also demonstrates the processes for upgrading from the PREPAREDB, through the EXTRACTDB and into the INSERTDB phases.


Part 10 Appendixes

This part of the book contains several appendixes of reference information.

Part 10


Appendix A. Configuring ODBC connections

Tivoli Storage Manager V6.1 uses the DB2 open database connectivity (ODBC) driver to query the database and display the results.

In this Appendix we describe the setup steps to establish a communication between an ODBC client and a Tivoli Storage Manager server database as the target.

A


DB2 configuration for ODBC

The plan is to establish communication between a target Tivoli Storage Manage Server and a client. In this Appendix we guide you through the detailed steps required to do so.

ODBC target machine configuration

The DB2COMM setting is used to specify a communication protocol for the DB2 instance used by a given DB2 server, in your case the Tivoli Storage Manager system. By default, DB2 does not set the communication protocol, so your first step is to set/verify if DB2COMM is configured for your system:

1. You can use the db2set command, as shown in Example A-1, to query and set the command.

Example A-1 db2set: Setting the DB2COMM option

$ db2set -all[i] DB2_SKIPINSERTED=ON[i] DB2_KEEPTABLELOCK=ON[i] DB2_EVALUNCOMMITTED=ON[i] DB2_SKIPDELETED=ON[i] DB2_PARALLEL_IO=*[g] DB2SYSTEM=utah[g] DB2INSTDEF=tsm1

$ db2set DB2COMM=tcpip

$ db2set -all[i] DB2_SKIPINSERTED=ON[i] DB2_KEEPTABLELOCK=ON[i] DB2_EVALUNCOMMITTED=ON[i] DB2_SKIPDELETED=ON[i] DB2COMM=tcpip[i] DB2_PARALLEL_IO=*[g] DB2SYSTEM=utah[g] DB2INSTDEF=tsm1

2. If you want to activate the changes, you need to stop and start DB2 using the db2stop and db2start commands. Trying to stop DB2 will fail while your Tivoli Storage Manager is up and running. Example A-2 shows the SQL1025N message being returned.

Example A-2 SQL1025N, databases are still active.

$ db2stop06/13/2009 18:52:39 0 0 SQL1025N The database manager was not stopped because databases are still active.SQL1025N The database manager was not stopped because databases are still active


3. If your Tivoli Storage Manager server is stopped, and you try to you stop and restart your DB2 right now, you receive an ADM7006E error message as shown in Example A-3. You can find the message in the db2diag.log file.

Example A-3 ADM7006E: SVCENAME not configured

2009-06-06-11.25.48.246673-240 E1194476A497 LEVEL: ErrorPID : 385174 TID : 258 PROC : db2sysc 0INSTANCE: tsm1 NODE : 000EDUID : 258 EDUNAME: db2sysc 0FUNCTION: DB2 UDB, common communication, sqlcctcpconnmgr, probe:50MESSAGE : ADM7006E The SVCENAME DBM configuration parameter was not configured. Update the SVCENAME configuration parameter using the service name defined in the TCP/IP services file.

4. Because you now know that the service name is not configured, use the db2 update dbm command as shown in Example A-4. The service name that you configure is DB2_TSM1.

Example A-4 DB2 command: update dbm config

$ db2 update dbm config using svcename DB2_TSM1DB20000I The UPDATE DATABASE MANAGER CONFIGURATION command completedsuccessfully.$ db2 get dbm cfg | grep SVC TCP/IP Service name (SVCENAME) = DB2_TSM1

5. Again, if you try to stop and restart DB2 now, you will receive a message (in this case SQL5043N) indicating the configuration is not complete. The exact message is shown in Example A-5.

Example A-5 SQL5043N, support for a communication protocol failed

$ db2start06/13/2009 18:31:11 0 0 SQL5043N Support for one or more communications protocols failed to start successfully. However, core database manager functionality started successfully.SQL1063N DB2START processing was successful.

6. We did not configure the TCP service port so far. So next you need to open the /etc/services file and add the service details. On a Windows machine, you configure the service port with the %SYSTEMROOT%\system32\drivers\etc\services file. We decided to configure the DB2_TSM1 service to use port 50000. Just place the statement next to the ports already configured for DB2 usage (do not use any of these ports for ODBC). See Example A-6 for the details.

Example A-6 TSM1 TCPIP service port configured

DB2_TSM1 50000/tcp # This is for servicename for instance TSM1DB2_tsm2 60004/tcpDB2_tsm2_1 60005/tcpDB2_tsm2_2 60006/tcpDB2_tsm2_END 60007/tcp

Appendix A. Configuring ODBC connections 575

7. Example A-7 shows the SQL1063N message being returned by the db2start command. DB2 is up and running and you are finished with the server or target ODBC setup.

Example A-7 DB2 command: dbstart

$ db2start06/13/2009 18:56:24 0 0 SQL1063N DB2START processing was successful.SQL1063N DB2START processing was successful.

ODBC client machine configuration

Before we can go ahead and configure the client machine, we first need to install a copy of the ODBC driver. Go to:

http://www-01.ibm.com/software/data/db2/ad/deploy.html

Then search for “IBM DB2 Driver for ODBC and CLI”. This package comes with a complete set of DB2 client applications and includes a Control Center that allows to manage DB2 databases by a graphical interface.

Client ODBC driver installationAfter the download of the package is completed and the installation package is extracted, we proceed as follows:

1. We start the installation by setup.exe. The installation Welcome window is displayed, as shown in Figure A-1, Click Install a Product to continue.

Figure A-1 IBM DB2 Data Server: Welcome window


http://www-01.ibm.com/software/data/db2/ad/deploy.html

2. The Install a Product window is presented, as shown in Figure A-2. Click Install New to continue.

Figure A-2 IBM DB2 Data Server: Install New

3. The InstallShield Wizard prepares the installation, the progress window shown in Figure A-3 on page 577 is displayed.

Figure A-3 IBM DB2 Data Server: Preparing to Install

4. The Install Shield Wizard progress is followed by the Windows Installer notification window; see Figure A-4.

Figure A-4 IBM DB2 Data Server: Preparing notification


5. On the IBM Data Server Client Setup window, shown in Figure A-5, click Next.

Figure A-5 IBM DB2 Data Server: Setup

6. After you read the license agreement, you select to accept the license terms as shown in Figure A-6. Click Next to continue.

Figure A-6 IBM DB2 Data Server: License


7. On the next window, Figure A-7, you stay with the default installation type of Typical and click Next to continue.

Figure A-7 IBM DB2 Data Server: Installation type

8. Figure A-8 shows that you can create a response file during installation. With this installation, select Install IBM Data Server Client on this computer and click Next to continue.

Figure A-8 IBM DB2 Data Server: Response file creation


9. Figure A-9 allows you to select the installation folder. Stay with the default and click Next again.

Figure A-9 IBM DB2 Data Server: Installation folder

10.By default, operating system security will be enabled with the package installation. As shown in Figure A-10, you could disable this option, but here we stay with the default again. Click Next to continue.

Figure A-10 IBM DB2 Data Server: Security options


11.On the next window, Figure A-11, click Install to start the installation of the files.

Figure A-11 IBM DB2 Data Server: Start copying

The installation window, see Figure A-12, informs you about the installation progress.

Figure A-12 IBM DB2 Data Server: Copying files


12.After all the files are copied, the setup is complete. The notification window, Figure A-13, gets displayed. It reminds you to complete some security related post-install steps. In our example we are running with Administrator authority, so we do not need to do anything. Click Next to continue.

Figure A-13 IBM DB2 Data Server: Setup complete

13.On the final window, Figure A-14, you could select to install additional products, here you see the IBM Database Add-Ins for Visual Studio 2005. You just click Finish to complete the installation.

Figure A-14 IBM DB2 Data Server: Finish installation


You have now successfully completed the installation of the IBM DB2 Driver for ODBC and CLI. The next step is to configure the driver so you can access your Tivoli Storage Manager servers database.

Client ODBC configurationBecause we are configuring a Windows system, to open a DB2 command window, click Start → All Programs → IBM DB2 → <DB2 Instance> → Command Line Tools → Command Window. Then follow these steps:

1. To complete the configuration, you need to catalog at least a node and the database. Use the db2 catalog command as shown Example A-8. Make sure to use the service port number, 50000, instead of the service name DB2_TSM1 when cataloging the node.

Example A-8 Catalog node and database

C:\Program Files\tivoli\TSM\db2\BIN>db2 catalog tcpip4 node utah remote utah.itso.ibm.com server 50000DB20000I The CATALOG TCPIP4 NODE command completed successfully.DB21056W Directory changes may not be effective until the directory cache isrefreshed.

C:\Program Files\IBM\SQLLIB\BIN>db2 catalog db tsmdb1 as utahdb1 at node utahDB20000I The CATALOG DATABASE command completed successfully.DB21056W Directory changes may not be effective until the directory cache isrefreshed.

2. You can immediately verify if the configuration was successful by using the db2 connect command, as shown in Example A-9.

Example A-9 ODBC configuration verification.

C:\Program Files\tivoli\TSM\db2\BIN>db2 connect to utahdb1 user tsm1 using <password>


Database server = DB2/AIX64 9.5.2 SQL authorization ID = TSM1 Local database alias = TSMDB1


3. Figure A-15 shows that with the node and database being configured to the local DB2 client, you can already use the DB2 Control Center to display the database. You will be prompted for user ID and password. We do not show that step here.

Figure A-15 Control Center display tables

You have now completed the ODBC configuration for client and target machine. After you completed both catalog commands in Example A-8 on page 583, you can already access the database using the Control Center that comes with the IBM DB2 Driver for ODBC and CLI.

ODBC connection examples

In this section we look at several ODBC connection examples.

Connecting to the database using a perl scriptFollow these steps to establish the connection:

1. In this example our goal is to connect to the database using a simple perl script. For this to work, you need to install the DB2 Perl Database Interface for LUW. For details, see:


2. Because we are using the ActiveState Perl distribution on Windows, install the DBI module by issuing the ppm install DBI command. The DBI module is a prerequisite for the DBD::DB2 module, it is the standard database interface module for Perl. For further details, see:

http://www.activestate.com



http://www.activestate.com

3. Because we installed ActivePerl 5.10, we need to install the 10xx/DBD-DB2.ppd module. Example A-10 documents the installation of both modules.

Example A-10 Install DB2 Perl Database Interface

C:\Documents and Settings\Administrator>ppm install dbiDownloading ActiveState Package Repository packlist...doneUpdating ActiveState Package Repository database...doneNo missing packages to install

C:\Documents and Settings\Administrator>ppm install http://cpan.uwinnipeg.ca/PPMPackages/10xx/DBD-DB2.ppdDownloading DBD-DB2-1.7.1...doneUnpacking DBD-DB2-1.7.1...doneGenerating HTML for DBD-DB2-1.7.1...doneUpdating files in site area...done 11 files installed

4. Now we just need a small perl script that connects to the database and reads some information out of the database. We save the sample script shown in Example A-11 as dbaccess.pl. After being connected to the database, the script reads the available nodes and their platforms from the nodes table and writes them to standard output. More examples and code for the C programming language or php interpreters are available from the DB2 installation samples subdirectory.

Example A-11 Simple sample perl script

#!/usr/bin/perl -w# connect to a remote TSM database and collect some information

# DB2 Perl Database Interface for LUW# http://www-01.ibm.com/support/docview.wss?rs=71&uid=swg21297335 use DBI; use DBD::DB2::Constants; use DBD::DB2; my $database = "utahdb1";my $user = "tsm1";my $password = "<valid password>";my $schema = "tsmdb1";

my $dbh = DBI->connect("dbi:DB2:". $database, $user, $password, {RaiseError => 1});

my $stmt = "SELECT nodename, platform FROM " . $schema . ".nodes;"; my $sth = $dbh->prepare($stmt);

$sth->execute();

while( @row = $sth->fetchrow ) { print $row[0] . " " . $row[1] . "\n";}

$dbh->disconnect or warn "Disconnection failed: $DBI::errstr\n";

exit; # Done


5. Now invoke the perl interpreter against the script. The result is documented in Example A-12.

Example A-12 Execute the perl script

C:\tsmtools>perl dbaccess.plUTAH AIXBUFFALOSTEAK AIX

The script can connect to the database and returns the nodes and their platforms.

Connecting to the database using OpenOfficeOpenOffice ia a multiplatform and multilingual office suite and an open-source project. For more information, see:

http://www.openoffice.org

Here the task is to connect to the Tivoli Storage Manager database using Calc, the OpenOffice spreadsheet module. Follow these steps:

1. On your Windows system, click Start → All Programs → OpenOffice.org 3.0 → OpenOffice.org Calc. An untitled spreadsheet is opened, select File → New → Database (see Figure A-16).

Figure A-16 OpenOffice: Open new database


http://www.openoffice.org

2. As shown in Figure A-17, you specify to connect to an existing database using ODBC, then click Next to continue.

Figure A-17 OpenOffice: Select database dialog

3. To set up the ODBC connection on Figure A-18 you click Browse to search for existing databases.

Figure A-18 OpenOffice: Setup ODBC connection dialog


4. On the Data Source window, Figure A-19, click Organize.

Figure A-19 OpenOffice: Data source window

5. Figure A-20 does not yet list the DB2 ODBC drive as an available data source; click Add.

Figure A-20 OpenOffice: Data Source Administrator

6. In the Create New data Source window, shown in Figure A-21, select the IBM DB2 ODBC DRIVER and click Finish.

Figure A-21 OpenOffice: Create new data source


7. In the next window, as you can see with Figure A-22, specify Data Source Name, in our lab UTAHDB1, and a comment describing the database. Click OK to continue.

Figure A-22 OpenOffice: Add ODBC IBM driver to data sources

8. From the Data Source Administrator window, Figure A-23, select the data source you just created, UTAHDB1. Click OK to proceed.

Figure A-23 OpenOffice: Select data source UTAHDB1

9. Again select the UTAHDB data source, see Figure A-24. Click OK to continue.

Figure A-24 OpenOffice: data source selection


10.After the database connection is specified, as shown in Figure A-25, click Next to continue.

Figure A-25 OpenOffice: Completed setup ODBC connection dialog

11.When asked for authentication details, provide the user ID and make the Password required field active. The user authentication window, Figure A-26, does allow you to immediately test the connection. We do not do this, so click Next to continue.

Figure A-26 OpenOffice: User authentication


12.On the final configuration window, Figure A-27, stay with the defaults and click Finish.

Figure A-27 OpenOffice: Finish setup

13.A dialog appears that allows you to save the database you just configured, see Figure A-28. In this example you save to folder tsmtools.

Figure A-28 OpenOffice: Save database dialog


14.When you try to open the database, you are prompted for the credential. Provide the password provided in Figure A-26 and click OK as shown in Figure A-29.

Figure A-29 OpenOffice: Password prompt

15.By default, the SYSCAT tables branch is expanded; see Figure A-30. Click the collapse selector (-).

Figure A-30 OpenOffice: SYSCAT tree


16.As in Figure A-31, click the expansion selector (+) for the TSMDB1 database.

Figure A-31 OpenOffice: TSMDB1 database


17.From the expanded database tables, right-click the Administrators table and click Open; see Figure A-32.

Figure A-32 OpenOffice: Open Administrators table

18.Figure A-33 shows how the Administrators table is displayed by OpenOffice.

Figure A-33 OpenOffice: Administrator table

You have now completed the tasks to allow you to access the Tivoli Storage Managers databases through OpenOffice.


SummaryYou can connect to the Tivoli Storage Manager database by programs that support ODBC connections. The ODBC support is now provided by DB2. The Tivoli Storage Manager ODBC driver is no longer required and is no longer supported.


Appendix B. DB2 and SQL commands

After installing and configuring Tivoli Storage Manager V6.1, you should seldom need to issue DB2 commands. In this appendix we briefly describe a limited set of DB2 commands that you might have reason to use.

The commands are grouped into the following three categories:

� Setting up, configuring, or updating the database environment� Diagnosing and troubleshooting the database environment� Monitoring the status and health of the database

In addition, we discuss changes that you might need to make to existing SQL commands in order for your commands to work.

B


Commands to manage the database environment

The commands in this section are used to set up, configure, or update the Tivoli Storage Manager DB2 database environment. These commands are issued by the Tivoli Storage Manager configuration wizard or by the server itself. They are provided for reference and informational purposes.

db2cmd: Open DB2 command window commandOpen the command line processor-enabled DB2 window, and initialize the DB2 command line environment. This command is only available on Windows operating systems.

db2icrt: Create instance commandOn Linux and UNIX operating systems, this utility is located in the DB2DIR/instance directory, where DB2DIR represents the installation location where the current version of the DB2 database system is installed. On Windows operating systems, this utility is located under the DB2PATH\bin directory where DB2PATH is the location where the DB2 copy is installed. The db2icrt command creates DB2 instances in the home directory of the instance owner.

db2osconf: Utility for kernel parameter values command The db2osconf system utility makes recommendations for kernel parameter values based on the size of a system. The recommended values are high enough for a given system that they can accommodate most reasonable workloads. This command is currently available only for DB2 on HP-UX on 64-bit instances and the Solaris operating system.

We recommend that the Tivoli Storage Manager server environment use these db2osconf values as the minimum setting for those values. It can also be beneficial to exceed the recommended value. Consideration should be given to this information and the kernel settings that are recommended to be changed. These settings can significantly affect normal operations and how well the server performs in this environment. Not following the kernel setting recommendations could result in an unstable or under performing Tivoli Storage Manager server for this environment.

See “HP-UX and Sun Solaris systems recommendations” on page 47 for the actual recommendations. Example 23-15 shows that you can use the command to verify the current settings.

Example 23-15 db2osconf command output

# /opt/IBM/db2/V9.5/bin/db2osconf

set msgsys:msginfo_msgmni = 3584set semsys:seminfo_semmni = 4096set shmsys:shminfo_shmmax = 30816549273set shmsys:shminfo_shmmni = 4096set rlim_fd_max = 65536

Total kernel space for IPC:0.56MB (shm) + 1.27MB (sem) + 1.66MB (msg) == 3.49MB (total)

Note: The Tivoli Storage Manager configuration wizard creates the instance used by the server and database. After a server is installed and configured, the db2icrt command would not typically be used.


db2set: DB2 profile registry commandThe db2set system command displays, sets, or removes DB2 profile variables. Before you issue the DSMSERV LOADFORMAT command, log on to the system as the server instance owner. If you are not running under the English regional locale, set the DB2CODEPAGE system environment variable to 819.

db2set -i tsminst1 DB2CODEPAGE=819

Set the DSMI_ api environment variable configuration for the database instance.

db2set -i server1 DB2_VENDOR_INI=d:\tsmserver1\tsmdbmgr.env

Catalog database commandUse the CATALOG DATABASE command to store database location information in the system database directory. The database can be located either on the local workstation or on a remote database partition server.

The server configuration wizard typically takes care of any catalog needed for using the server database. This command would only need to be considered or run manually after a server has been configured and running if something in the environment changes or is damaged.

Example 23-16 shows the usage of the command and the messages returned.

Example 23-16 Catalog database command

C:\Program Files\IBM\SQLLIB\BIN>db2 catalog db tsmdb1 as utahdb1 at node utahDB20000I The CATALOG DATABASE command completed successfully.DB21056W Directory changes may not be effective until the directory cache isrefreshed.

Create database commandThe create database command initializes a new database with an optional user-defined collating sequence, creates the three initial tablespaces, creates the system tables, and allocates the recovery log file. This command is used only to create the Tivoli Data Warehouse database for Tivoli Storage Manager reporting and monitoring and not the database for the Tivoli Storage Manager server.

When you initialize a new database, the AUTOCONFIGURE command is issued by default.

Example B-1shows how you can invoke the create database command.

Example B-1 DB2 commands: create database

C:\Program Files\Tivoli\TSM\db2\BIN>db2 create database WAREHOUS using codeset utf-8 territory USDB20000I The CREATE DATABASE command completed successfully.

Drop database commandThe drop database command deletes the database contents and all log files for the database, uncatalogs the database, and deletes the database subdirectory.

Note: When the instance and database directories are created by the DB2 database manager, the permissions are accurate and should not be changed.

Appendix B. DB2 and SQL commands 599

Get database configuration commandThe get database configuration command returns the values of individual entries in a specific database configuration file. See Example 5-7 on page 66 for sample output collected with the get database configuration command.

Get database manager configuration commandThe get database manager configuration command returns the values of individual entries in the database manager configuration file.

See Example 5-50 on page 116 for sample output collected with the get database manager configuration command. To get information in order to verify database configuration and settings, log mode, maintenance settings, and so on, you can use the additional show detail parameters.

db2 get db config for tsmdb1 show detail

DB2 get snapshot commandThe DB2 get snapshot command collects status information and formats the output. The information returned represents a snapshot of the database manager operational status at the time the command was issued.

Example B-2 shows the output collected with the DB2 get snapshot for dbm command.

Example B-2 DB2 command: get snapshot for dbm

C:\Program Files\Tivoli\TSM\db2\BIN>db2 get snapshot for dbm

Database Manager Snapshot

Node name =

Attention: This command causes the database to be dropped, which removes the references to the database from DB2 and deletes the underlying space used for the database. The drop database command should not be used for a production Tivoli Storage Manager server or a server that you want to continue to use. Dropping a database renders it unusable and unrecoverable. If a database is inadvertently dropped, the only recourse is to restore the database from an available database backup if one exists.

Note: The database manager and database configuration parameters are typically set and managed directly by DB2. They are listed here for informational purposes and a means to view the existing settings. Changing these settings should only be done through the use of Tivoli Storage Manager server commands or procedures. Changing these settings might be recommended by IBM service or through service bulletins such as APARs or Technical Guidance documents (Technotes). These settings should not be changed manually and should only be changed at the direction of IBM.

Note: The database manager and database configuration parameters are typically set and managed directly by DB2. They are listed here for informational purposes and a means to view the existing settings. Changing these settings should only be done through the use of Tivoli Storage Manager server commands or procedures. Changing these settings might be recommended by IBM service or through service bulletins such as APARs or Technical Guidance documents (technotes). These settings should not be changed manually and should only be changed at the direction of IBM.


Node type = Database Server with local and remote clientsInstance name = SERVER1Number of database partitions in DB2 instance = 1Database manager status = Active

Product name = DB2 v9.5.201.3237Service level = special_21101 (WR21421_21101)

Private Sort heap allocated = 0Private Sort heap high water mark = 0Post threshold sorts = Not CollectedPiped sorts requested = 2407Piped sorts accepted = 2407

Start Database Manager timestamp = 06/22/2009 13:45:23.359082Last reset timestamp =Snapshot timestamp = 06/23/2009 15:45:32.685317

Remote connections to db manager = 4Remote connections executing in db manager = 0Local connections = 15Local connections executing in db manager = 0Active local databases = 1

High water mark for agents registered = 25Agents registered = 23Idle agents = 1

Committed private Memory (Bytes) = 25755648

Switch list for db partition number 0Buffer Pool Activity Information (BUFFERPOOL) = ON 06/22/2009 13:45:23.359082Lock Information (LOCK) = ON 06/22/2009 13:45:40.431420Sorting Information (SORT) = OFFSQL Statement Information (STATEMENT) = OFFTable Activity Information (TABLE) = OFFTake Timestamp Information (TIMESTAMP) = ON 06/22/2009 13:45:23.359082Unit of Work Information (UOW) = OFF

Agents assigned from pool = 6435Agents created from empty pool = 28Agents stolen from another application = 0High water mark for coordinating agents = 25Hash joins after heap threshold exceeded = 0OLAP functions after heap threshold exceeded = 0

Total number of gateway connections = 0Current number of gateway connections = 0Gateway connections waiting for host reply = 0Gateway connections waiting for client request = 0Gateway connection pool agents stolen = 0

Node FCM information corresponds to = 0Free FCM buffers = 128


Free FCM buffers low water mark = 128Free FCM channels = 640Free FCM channels low water mark = 640

Memory usage for database manager:

Node number = 0 Memory Pool Type = Other Memory Current size (bytes) = 14614528 High water mark (bytes) = 15007744 Configured size (bytes) = 33488896

Node number = 0 Memory Pool Type = FCMBP Heap Current size (bytes) = 786432 High water mark (bytes) = 786432 Configured size (bytes) = 917504

Node number = 0 Memory Pool Type = Database Monitor Heap Current size (bytes) = 327680 High water mark (bytes) = 327680 Configured size (bytes) = 327680

Get health snapshot commandThe get health snapshot command retrieves the health status information for the database manager and its databases. The information returned represents a snapshot of the health state at the time the command was issued.

Tivoli Storage Manager monitors the state of the database using the health snapshot and other mechanisms that are provided by DB2. There might be cases where the health snapshot or other DB2 documentation indicates that an item or database resource might be in an alert state, indicating that action should be considered to remedy the situation. Tivoli Storage Manager monitors the condition and takes action as appropriate. Not all declared alerts by the DB2 database are acted on.

To collect a report on DB2 health monitor indicators submit

db2 get health snapshot for database on tsmdb1

GRANT (Database Authorities) statementUse the grant statement to grant authorities that apply to the entire database rather than privileges that apply to specific objects within the database (see Example B-3).

Example B-3 DB2 commands: grant authorities

C:\Program Files\Tivoli\TSM\db2\BIN>db2 grant connect on database to useritmuserDB20000I The SQL command completed successfully.

C:\Program Files\Tivoli\TSM\db2\BIN>db2 grant createtab on database to user itmuserDB20000I The SQL command completed successfully.


runstats commandThe runstats command updates statistics about the characteristics of a table and associated indexes or statistical views. These characteristics include number of records, number of pages, and average record length. The optimizer uses these statistics when determining access paths to the data including the most efficient means to process the data and whether or not to exploit an index and such for the operation.

For a table, this utility should be called when the table has had many updates, or after reorganizing the table. For a statistical view, this utility should be called when changes to underlying tables have substantially affected the rows returned by the view. The view must have been previously enabled for use in query optimization using the ALTER VIEW command.

The Tivoli Storage Manager server has a monitor and tuning algorithm that evaluates the workload and changes against the server's tables. As needed it invokes RUNSTATS for a table to update the statistics as necessary. If issues arise with how this monitoring and tuning algorithm work, IBM might recommend manually performing RUNSTATS for one or more tables.

db2start commandThe db2start command starts the current database manager instance background processes on a single database partition or on all the database partitions defined in a multi-partitioned database environment.

The Tivoli Storage Manager server starts and stops the instance and database whenever the server starts and halts. While the server is running, a db2start is not needed or recommended. Similarly, while the server is running, stopping the database might adversely affect the server including causing current workloads and activity to fail or possibly causing the server to crash. It is important to allow the Tivoli Storage Manager server to manage the starting and stopping of the instance and database. See “ODBC target machine configuration” on page 574 for sample usage of the command.

db2 stop dbm commandUse the stop dbm command to stop the current database manager instance. Unless explicitly stopped, the database manager continues to be active. This command does not stop the database manager instance if any applications are connected to databases. If there are no database connections, but there are instance attachments, it forces the instance attachments and stops the database manager. This command also deactivates any outstanding database activations before stopping the database manager. In a partitioned database environment, this command stops the current database manager instance on a database partition or on all database partitions. When it stops the database manager on all database partitions, it uses the db2nodes.cfg configuration file to obtain information about each database partition.

This command can also be used to drop a database partition from the db2nodes.cfg file (partitioned database environments only). This command is not valid on a client.

The Tivoli Storage Manager server starts and stops the instance and database whenever the server starts and halts. While the server is running, a db2start is not needed or recommended. Similarly, while the server is running, stopping the database might adversely affect the server including causing current workloads and activity to fail or possibly causing the server to crash. It is important to allow the Tivoli Storage Manager server to manage the starting and stopping of the instance and database.


Set db2instance commandThe set db2instance command is available on supported Windows platforms only, use it to determine which instance applies to the current session.

Diagnosing and troubleshooting the database environment

Use the commands to diagnose or troubleshoot issues with the Tivoli Storage Manager servers' DB2 database environment. These are commands that might be requested by an IBM service representative for the purpose of evaluating or diagnosing an issue or problem with the Tivoli Storage Manager server.

db2cmd: Open DB2 command window commandThe db2cmd command opens the CLP-enabled DB2 window, and initializes the DB2 command line environment. This command is only available on Windows operating systems.

db2ilist: List instances commandThe db2ilist command lists all the instances that are created using the db2icrt command from the same DB2 copy location that you are running the db2ilist command. This command can be useful for diagnosing problems or for reporting information about the Tivoli Storage Manager database configuration.

When running commands against DB2 databases, you should always make sure to run them against the correct Tivoli Storage Manager server instance. The db2ilist command, as shown in Example B-4, provides that information. If you want to query the current instance, use the db2 get instance command. See Example B-4 for details.

Example B-4 DB2: db2ilist system command

C:\Program Files\Tivoli\TSM\db2\BIN>db2ilistSERVER2SERVER1DB2TSM

db2mtrk: Memory tracker commandThe db2mtrk command provides a complete report of memory status for instances, databases, agents, and applications. This command outputs the following memory pool allocation information:

� Current size Maximum size (hard limit)� Largest size (high water mark)� Type (identifier indicating function for which memory will be used)� Agent who allocated pool (only if the pool is private)� Application

The same information is also available from the Snapshot monitor.

You can use this command and other information available directly from the Tivoli Storage Manager server to diagnose memory and performance related issues.

The following call returns database and instance normal values and repeats every 10 seconds:

db2mtrk -i -d -v -r 10


db2pd: Monitor and troubleshoot DB2 database commandThe db2pd utility retrieves information from the DB2 database system memory sets. The -logs or some of the db2pd options can be effective for monitoring status of the server's database as well. Example B-5 shows an example of the db2pd utility syntax.

Example B-5 db2pd utility


C:\Program Files\Tivoli\TSM\db2\BIN>db2pd -db tsmdb1 -logs

Database Partition 0 -- Database TSMDB1 -- Active -- Up 0 days 01:18:45

Logs:Current Log Number 2Pages Written 1605Method 1 Archive Status n/aMethod 1 Next Log to Archive 2Method 1 First Failure n/aMethod 2 Archive Status n/aMethod 2 Next Log to Archive n/aMethod 2 First Failure n/a

Address StartLSN State Size Pages Filename0x7FCBFF34 0x000041400000 0x00000000 131072 131072 S0000002.LOG0x7FCFFED4 0x000061400000 0x00000000 131072 131072 S0000003.LOG0x7FCFFF74 0x000081400000 0x00000000 131072 131072 S0000004.LOG0x5634FCE4 0x0000A1400000 0x00000000 131072 131072 S0000005.LOG

db2support: Configuration list and log commandYou can use the db2support command to create an entire TSMDB1 configuration list and log collection within a single .ZIP File called db2support.zip

Example B-6 shows a sample invocation of the command; the parameters used translate to:

� -d database_name or -database database_name � -c or -connect� -s or -system_detail � -g or -get_dump

Example B-6 db2support command invocation

C:\Program Files\Tivoli\TSM\db2\BIN>SET DB2INSTANCE=SERVER1

C:\Program Files\Tivoli\TSM\db2\BIN>db2support . -d tsmdb1 -c -s -g

After being started, the db2support Welcome panel is presented as shown in Example B-7. Press Enter to complete the documentation collection.

Example B-7 db2support command log

_______ D B 2 S u p p o r t ______

This program generates information about a DB2 server, includinginformation about its configuration and system environment. The output ofthis program will be stored in a file named 'db2support.zip', located


in the directory specified on the application command line. If you areexperiencing problems with DB2, it may help if this program is runwhile the problem is occurring.

NOTES:

1. By default, this program will not capture any user data from tables or logs to protect the security of your data.

2. For best results, run this program using an ID having SYSADM authority.

3. On Windows systems you should run this utility from a db2 command session.

4. Data collected from this program will be from the machine where this program runs. In a client-server environment, database-related information will be from the machine where the database resides via an instance attachment or connection to the database.

Press <Enter> key to continue.

Output file is "C:\Program Files\Tivoli\TSM\db2\BIN\db2support.zip"Time and date of this collection: "10/30/2009 7:56:32 AM Eastern Daylight Time"

Collecting "System files" "db2eventlog.000" "db2systm" "HealthRulesV82.reg" "DB2SYSTM" "db2cli.ini" "SQLDBBAK" "SQLDBDIR" "SQLDBINS" "report.log"

Collecting "Detailed operating system and hardware information"

Collecting "System resource info (disk, CPU, memory)"

Collecting "Operating system and level"

Collecting "JDK Level"

Collecting "DB2 Release Info"

LIC1440I License compliance report generated successfully.

Collecting "DB2 install path info"


Collecting "Registry info" Collecting "Get dbm cfg" Collecting "db2audit describe" Collecting "Get admin cfg" Collecting "List database directory"

Collecting "Sqllib directory listing"

Collecting "Sqllib directory listing" SQL Code: "-1027" Collecting "List node directory show detail" SQL Code: "-1027" SQL Code: "-1027" Collecting "List admin node directory show detail" SQL Code: "-1027" SQL Code: "-1311" Collecting "List DCS directory" SQL Code: "-1311" Collecting "Get cli cfg" Collecting "List DCS applications extended" Collecting "Query client" Collecting "List active databases" Collecting "Get db cfg for TSMDB1 " Collecting "List history since 20090930 for db TSMDB1" Collecting "List applications for database TSMDB1 show detail"

...attempting to connect to database: "TSMDB1"

Collecting "Buffer pool information"

Collecting "Table space information" Collecting "Get snapshot for all applications" Collecting "Select count(*) from sysibm.systables where type='T' and creator <> 'SYSIBM'" Collecting "Select max(stringid) from sysibm.sysxmlstrings" Collecting "Get snapshot for all databases" Collecting "List packages for all show detail" Collecting "List tables for all show detail" Collecting "List indoubt transactions" SQL Code: "-1462" Collecting "List DRDA indoubt transactions" SQL Code: "-1462" Collecting "List command options" Collecting "List nodes" Collecting "List ODBC data sources"

Creating final output archive "db2support.html" "db2_sqllib_directory.txt" "db2_log_directory.txt" "db2supp_system.zip" "admin.supp_cfg" "bp.supp_cfg"


"cli.supp_cfg" "db2audit.supp_cfg" "dbm.supp_cfg" "dbm_detailed.supp_cfg" "JDKlevel.supp_cfg" "spcs_bp.supp_cfg" "TSMDB1_db.supp_cfg" "TSMDB1_detailed_db.supp_cfg" "active_db.supp_out" "admin_nodedir.supp_out" "appsnap.supp_out" "db2level.supp_out" "db2licm.supp_out" "db2licm_report.supp_out" "db2set.supp_out" "dbmsnap.supp_out" "dbsnap.supp_out" "db_dir.supp_out" "dcsext.supp_out" "dcs_dir.supp_out" "list_apps.supp_out" "list_cmd_opts.supp_out" "list_DRDA_trans.supp_out" "list_nodes.supp_out" "list_packages.supp_out" "list_tables.supp_out" "list_transactions.supp_out" "nodedir.supp_out" "ODBC_datasources.supp_out" "query_client.supp_out" "tbspc.supp_out" "TSMDB1_list_hist.supp_out" "db2diag.log" "stmm.0.log" "db2optstats.0.log"

db2support is now complete. An archive file has been produced: "db2support.zip"

You can easily transfer the db2support.zip to your IBM support contact for review. For additional information, go to the following URL for complete documentation of the command:

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.admin.cmd.doc/doc/r0004503.html

DB2 attach commandUse the DB2 attach command to specify the instance at which instance-level commands are to be executed. This instance can be the current instance, another instance on the same workstation, or an instance on a remote workstation. Attach to an instance of the database manager.

You would run this command preceding a db2 get dbm cfg command, for example.


http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.admin.cmd.doc/doc/r0004503.html

DB2 detach commandThe DB2 detach command removes the logical DBMS instance attachment, and terminates the physical communication connection if there are no other logical connections using this layer.

DB2 list database directory commandThe DB2 list database directory command lists the contents of the system database directory. If a path is specified, the contents of the local database directory are listed. See Example 5-4 on page 64 for a sample invocation.

DB2 list history commandThe DB2 list history command lists entries in the history file. The history file contains a record of recovery and administrative events. Recovery events include full database and tablespace level backup, incremental backup, restore, and roll-forward operations. Additional logged events include create, alter, drop, or rename tablespace, reorganize table, drop table, and load. Example B-8 shows sample output collected for table drops on database tsmdb1.

Example B-8 DB2 command: list history

C:\Program Files\Tivoli\TSM\db2\BIN>db2 list history dropped table all for tsmdb1

List History File for gtsmdb1

Number of matching file entries = 119

Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID -- --- ------------------ ---- --- ------------ ------------ -------------- D T 20090618082638 000000000900ed0a000200a4 ---------------------------------------------------------------------------- "TSMDB1 "."ADMIN_SQL_TABLES" resides in 1 tablespace(s):

00001 USERSPACE1 ---------------------------------------------------------------------------- Comment: DROP TABLE Start Time: 20090618082638 End Time: 20090618082638 Status: A ---------------------------------------------------------------------------- EID: 466

DDL: CREATE TABLE "TSMDB1 "."ADMIN_SQL_TABLES" ( "ADMIN_SQL_TABNAME" VARCHAR(257) NOT NULL ) COMPRESS YES IN "USERSPACE1" INDEX IN "IDXSPACE1" ; ----------------------------------------------------------------------------

Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log Backup ID -- --- ------------------ ---- --- ------------ ------------ -------------- D T 20090618082648 000000000900890b00020080 ---------------------------------------------------------------------------- "TSMDB1 "."ADM_SCHEDT" resides in 1 tablespace(s):

00001 USERSPACE1


---------------------------------------------------------------------------- Comment: DROP TABLE Start Time: 20090618082648 End Time: 20090618082648 Status: A ----------------------------------------------------------------------------

EID: 467

db2 ? sqlxxxx commandThis command explains the meaning of an sqlxxxx code. Example 5-6 on page 65 shows an example of usage.

db2 connect to commandThe Tivoli Storage Manager server as an application uses connections to and from the database extensively to perform normal operations and administrative tasks. To manually connect to the database, use the DB2 connect to command as shown in Example A-9 on page 583.

Monitoring the status and health of the database

In this section we describe commands relating to database health and status.

db2cmd: Open DB2 command window commandThis command opens the CLP-enabled DB2 window, and initialize the DB2 command line environment. This command is only available on Windows operating systems.

db2pd: Monitor and troubleshoot DB2 database commandThe db2pd utility retrieves information from the DB2 database system memory sets. The -logs option or some of the db2pd options can be effective for monitoring status of the server's database as well.

Example B-9 db2pd utility


C:\Program Files\Tivoli\TSM\db2\BIN>db2pd -db tsmdb1 -logs

Database Partition 0 -- Database TSMDB1 -- Active -- Up 0 days 01:18:45

Logs:Current Log Number 2Pages Written 1605Method 1 Archive Status n/aMethod 1 Next Log to Archive 2Method 1 First Failure n/aMethod 2 Archive Status n/aMethod 2 Next Log to Archive n/aMethod 2 First Failure n/a

Address StartLSN State Size Pages Filename0x7FCBFF34 0x000041400000 0x00000000 131072 131072 S0000002.LOG


0x7FCFFED4 0x000061400000 0x00000000 131072 131072 S0000003.LOG0x7FCFFF74 0x000081400000 0x00000000 131072 131072 S0000004.LOG0x5634FCE4 0x0000A1400000 0x00000000 131072 131072 S0000005.LOG

Get database configuration commandThe get database configuration command returns the values of individual entries in a specific database configuration file. See Example 5-7 on page 66 for sample output collected with the get database configuration command.

Get database manager configuration commandThe get database manager configuration command returns the values of individual entries in the database manager configuration file.

See Example 5-50 on page 116 for sample output collected with the get database manager configuration command. To get information in order to verify database configuration and settings, log mode, maintenance settings, and so on, you can use the additional show detail parameters:.

db2 get db config for tsmdb1 show detail

Get health snapshot commandThe get health snapshot command retrieves the health status information for the database manager and its databases. The information returned represents a snapshot of the health state at the time the command was issued.

Tivoli Storage Manager monitors the state of the database using the health snapshot and other mechanisms that are provided by DB2. There might be cases where the health snapshot or other DB2 documentation indicates that an item or database resource might be in an alert state, indicating that action should be considered to remedy the situation. Tivoli Storage Manager monitors the condition and takes action as appropriate. Not all declared alerts by the DB2 database are acted on.

To collect a report on DB2 health monitor indicators submit

db2 get health snapshot for database on tsmdb1




DB2 get snapshot commandThe DB2 get snapshot command collects status information and formats the output. The information returned represents a snapshot of the database manager operational status at the time the command was issued.

Example B-2 on page 600 shows the output collected with the command:

db2 get snapshot for dbm

DB2 list history commandThe DB2 list history command lists entries in the history file. The history file contains a record of recovery and administrative events. Recovery events include full database and tablespace level backup, incremental backup, restore, and roll-forward operations. Additional logged events include create, alter, drop, or rename tablespace, reorganize table, drop table, and load. Example B-8 on page 609 shows sample output collected for table drops on database tsmdb1.

Runstats commandThe runstats command updates statistics about the characteristics of a table and associated indexes or statistical views. These characteristics include number of records, number of pages, and average record length. The optimizer uses these statistics when determining access paths to the data including the most efficient means to process the data and whether or not to exploit an index and such for the operation.

For a table, this utility should be called when the table has had many updates, or after reorganizing the table. For a statistical view, this utility should be called when changes to underlying tables have substantially affected the rows returned by the view. The view must have been previously enabled for use in query optimization using the ALTER VIEW command.

The Tivoli Storage Manager server has a monitor and tuning algorithm that evaluates the workload and changes against the server's tables. As needed it invokes RUNSTATS for a table to update the statistics as necessary. If issues arise with how this monitoring and tuning algorithm work, IBM might recommend manually performing RUNSTATS for one or more tables.

db2 connect to commandThe Tivoli Storage Manager server as an application uses connections to and from the database extensively to perform normal operations and administrative tasks. To manually connect to the database, use the DB2 connect to command as shown in Example A-9 on page 583.

Changes to the SELECT command

The SELECT command in previous versions of the server allowed syntax that did not always conform to SQL syntax rules. With V6.1, the server conforms to SQL syntax rules in use by its database manager. Some examples illustrate changes that you might need to make to SELECT statements that you use.


LIKE predicate for a nested SELECT statement

You cannot use the LIKE predicate for a nested SELECT statement. For example, you receive an error if you use the LIKE predicate as in Example B-10.

Example B-10 ANR0516E with LIKE predicate for a nested select

tsm: TIRAMISU>select * from volumeusage where volume_name like (select distinctvolume_name from volumeusage where node_name='CAPITOLA')ANR0162W Supplemental database diagnostic information: -1:42824:-132([IBM][CLI Driver][DB2/NT] SQL0132N A LIKE predicate or POSSTR scalar function is not valid because the first operand is not a string expression or the second operand is not a string. A LOCATE or POSITION scalar function is not valid because the first operand is not a string or the second operand is not a string expression. SQLSTATE=42824).ANR0516E SQL processing for statement select * from volumeusage where volume_name like ( select distinct volume_name from volumeusage where node_name = 'capitola' ) failed.ANS8001I Return code 3.

Replace use of the LIKE predicate with the in parameter as follows and as customized in Example B-11.

select * from volumeusage where volume_name in (select distinct volume_name from volumeusage where node_name='node1')

Example B-11 Use “ in “ with nested select commands

tsm: TIRAMISU>select * from volumeusage where volume_name in (select distinct volume_name from volumeusage where node_name='CAPITOLA')

NODE_NAME: CAPITOLA COPY_TYPE: BACKUPFILESPACE_NAME: \1000000KB_of_10KB STGPOOL_NAME: FILEPOOL VOLUME_NAME: D:\TSM\SERVER1\FILECLASS\0000005A.BFS FILESPACE_ID: 3

NODE_NAME: CAPITOLA COPY_TYPE: BACKUPFILESPACE_NAME: \1000000KB_of_10KB STGPOOL_NAME: FILEPOOL VOLUME_NAME: D:\TSM\SERVER1\FILECLASS\0000005B.BFS FILESPACE_ID: 3

SELECT statements for time calculation

Labeled duration cannot be compared in a SELECT statement. Example B-12 shows a sample statement resulting in an error.

Example B-12 ANR0516E with labeled duration for time calculation

tsm: TIRAMISU>select * from actlog where (current_time-date_time) seconds <= 60 secondsANR0162W Supplemental database diagnostic information: -1:42819:-402


([IBM][CLI Driver][DB2/NT] SQL0402N The data type of an operand of an arithmetic function or operation "-" is not numeric. SQLSTATE=42819).ANR0516E SQL processing for statement select * from actlog where SECOND (current_time-date_time) <= 60 seconds failed.ANS8001I Return code 3.

While the V5 servers did return a result, this is not valid SQL syntax. The select statement from Example B-13 documents correct syntax using the timestampdiff() function. The timestampdiff() function takes a numeric expression as first interval, we use the number 2 which translates to seconds interval. Microseconds would be 1, minutes 4, hours 8 and so on. For a complete description, refer to the DB2 reference information manuals.

Example B-13 Corrected statement for time calculation

tsm: TIRAMISU>select * from actlog where timestampdiff(2, char(current_timestamp-date_time)) <= 60

DATE_TIME: 2009-10-29 14:03:11.000000 MSGNO: 2017 SEVERITY: I MESSAGE: ANR2017I Administrator ADMIN issued command: select * from actlog where timestampdiff(2, char(current_timestamp-date_time)) <= 60 (SESSION: 1)ORIGINATOR: SERVER NODENAME: OWNERNAME: SCHEDNAME:DOMAINNAME: SESSID:SERVERNAME: SESSION: 1 PROCESS:

The index_keyseq and index_order columns

The system catalog tables SYSCAT.COLUMNS and SYSCAT.TABLES are now processed by the database manager, instead of directly by the Tivoli Storage Manager server. The INDEX_KEYSEQ and INDEX_ORDER columns are not available. Use the KEYSEQ column instead. For information, use the search string keyseq in the following information center:


Access to database objects using the SELECT command

The database objects that can be accessed using the SELECT command are the same as for earlier versions of the server, with some additions for new functions in V6.1.

However, the SYSCAT.COLUMNS and SYSCAT.TABLES catalog tables now include all database objects that are known to the server, including some objects that cannot be accessed through the SELECT command. You receive an error message if a SELECT command includes an attempt to access one of these objects.



Table joins and column labeling

To retrieve information from more than one table, use a join process. Many types of join processes can be used.

You can declare names for columns that are retrieved from multiple tables so that a conditional statement can be run with the results that you want from the SELECT command. Example B-14 shows a sample command to join tables and label columns.

Example B-14 Joining tables and labeling columns

tsm: TIRAMISU>select entity,activity,sum(bytes) sum_bytes,sum(end_time-start_time) sum_time, sum(affected) sum_affected, sum(failed) sum_failed, sum(mediaw) sum_mediaw from summary su, nodes nd where su.entity=nd.node_name and cast((current_timestamp-start_time)hours as decimal)<24 group by entity,activity

ENTITY: CAPITOLA ACTIVITY: BACKUP SUM_BYTES: 27219109316 SUM_TIME: 8400.000000SUM_AFFECTED: 524236 SUM_FAILED: 0 SUM_MEDIAW: 16

Results of the SELECT command for the DISK device class

Results when you use the SELECT command to get information from the DEVCLASSES table have changed slightly in V6.1 for the DISK device class.

In previous releases, the SHARED field was blank (null) for the DISK device class. In V6.1, the SHARED field contains the value NO as shown in Example B-15. The SHARED field does not apply to the DISK device class, and the value NO can be ignored.

Example B-15 Changed results of the SELECT command for the DISK device class

tsm: TIRAMISU>select devclass_name, access_strategy, shared from devclasses where access_strategy like 'Random'

DEVCLASS_NAME ACCESS_STRATEGY SHARED-------------------------------- --------------------------------- -------DISK Random NO


Extra spaces appearing in output

Spaces might appear in output where they did not appear before, such as in the tabschema output shown in Example B-16.

Example B-16 SQL output with extra spaces

C:\Program Files\tivoli\TSM\baclient>dsmadmc -errorlogn=errorlog -id=admin -pa=admin -comma -dataonly=y

tsm: TIRAMISU>select tabschema,tabname from tablesTSMDB1 ,ACTIVITY_SUMMARYTSMDB1 ,ACTLOGTSMDB1 ,ADMINS..<lines deleted>

For example, if you are writing scripts for automation and need to strip out the additional spaces, you can use the RTRIM scalar function as shown in Example B-17.

Example B-17 RTRIM function

C:\Program Files\tivoli\TSM\baclient>dsmadmc -errorlogn=errorlog -id=admin -pa=admin -comma -dataonly=y

tsm: TIRAMISU>select rtrim(tabschema),tabname from tablesTSMDB1,ACTIVITY_SUMMARYTSMDB1,ACTLOGTSMDB1,ADMINS..<lines deleted>


Appendix C. Recovering from log exhausted conditions

If a full database backup is not taken in time to prune the archive logs, the Tivoli Storage manager server crashes. In 5.4.2, “Restoring the database” on page 102, we describe how to recover from this situation using a database restore.

Technote http://www-01.ibm.com/support/docview.wss?uid=swg21394424 describes how you can get your server up and running again by using plain DB2 commands. Here we guide you through a complete example scenario.

C



Preparing for the out of log space condition

Because it is our goal here to describe the recovery procedure, we first need to get the Tivoli Storage manager server into the out of log space condition.

The server crash scenario

By design, we configure the server to have the database volumes, active log directory, archive log directory, instance directory and storage pool volumes on a single drive. While this setup is not recommended, it allows us to get into the out of log space condition easily. We do not take any database backups and we generate some load. When the file system becomes full, the server crashes as shown in Example C-1.

Example C-1 File system full condition

TSM:TSMINST1>ANR8340I FILE volume D:\TSM\FILECLASS\0000000F.BFS mounted.ANR0511I Session 17 opened output volume D:\TSM\FILECLASS\0000000F.BFS.ANR0171I dbieval.c(812): Error detected on 20:15, database in evaluation mode.ANR0175E dbieval.c(905): Space exhausted for one or more of the following: DB,LOG, or instance directory.ANR0162W Supplemental database diagnostic information: -1:57011:-968-[IBM][CLI Driver][DB2/NT] SQL0968C The file system is full. SQLSTATE=57011

Any subsequent attempt to start the server fails with the ANR0130E out of log space condition as shown in Example C-2.

Example C-2 ANR0130E. out of log space

D:\tsm\tsminst1>"c:\Program Files\Tivoli\tsm\server\dsmserv.exe"ANR0900I Processing options file D:\tsm\tsminst1\dsmserv.opt.ANR7800I DSMSERV generated at 13:10:23 on Aug 6 2009.




ANR4726I The ICC support module has been loaded.ANR0990I Server restart-recovery in progress.ANR0152I Database manager successfully started.ANR0130E rdbdb.c(1386): Server LOG space exhausted.

Now the question is, how to recover from this condition, because the V5 DUMP/LOAD utilities are not available with the Tivoli Storage Manager V6 server and no database backup is available for restore.


Recovering the server

With the ANR0130E condition met, the Tivoli Storage Manager server cannot start and cannot be used to move the active log or archive log to a directory with more space. In order to get the server up and running, we need to prune the archive logs to free up space.

The way we do that is by taking database backups using DB2 commands. Next we describe the procedure.

Create a temporary archive log directoryWe have enough space available on the E: drive that we can use to temporarily hold the active logs. There we create a directory as shown in Example C-3. You can check the dsmserv.opt file for the ACTIVELOGSIZE value to identify your space requirements. In this example we are running with the default of 2 GB, so with the 20 GB space of drive E: we have plenty of space.

Example C-3 Temporary active log directory

E:\>mkdir temp_activelog

E:\>dir Volume in drive E is MoreSpace Volume Serial Number is 34F1-BF7B

Directory of E:\

10/31/2009 05:51 AM <DIR> temp_activelog 0 File(s) 0 bytes 1 Dir(s) 20,906,221,568 bytes free

Update DB2 active log directoryWe configure the new log directory to the database using the DB2 UPDATE DB command as shown in Example C-4, make sure to operate on the correct server instance.

Example C-4 DB2: Update db command



C:\Program Files\Tivoli\TSM\db2\BIN>db2 update db cfg for tsmdb1 using newlogpath e:\temp_activelogDB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.

Activate the database changesTo copy and rename the active log files to the newlogpath we just defined, we need to activate the database as shown in Example C-5.

Example C-5 DB2: Activate database command

C:\Program Files\Tivoli\TSM\db2\BIN>db2 activate db tsmdb1DB20000I The ACTIVATE DATABASE command completed successfully.

Appendix C. Recovering from log exhausted conditions 619

Note that the current log files in the old active and archive directories do not change. Example C-6 shows that the “old” active log files are still under the old active log directory path:

Example C-6 The “old” active logs

D:\tsm\tsmactivelog>dir Volume in drive D is Server Volume Serial Number is 24DC-C90D

Directory of D:\tsm\tsmactivelog

10/31/2009 06:05 AM <DIR> .10/31/2009 06:05 AM <DIR> ..10/23/2009 10:43 AM 536,879,104 S0000023.LOG10/23/2009 10:52 AM 536,879,104 S0000024.LOG10/23/2009 11:02 AM 536,879,104 S0000025.LOG10/23/2009 11:48 AM 515,272,704 S0000026.LOG 4 File(s) 2,125,910,016 bytes 2 Dir(s) 154,566,656 bytes free

Example C-7 shows the copies under the new archive log path, renamed to the next volumes in sequence.

Example C-7 The “new” active log copies

E:\temp_activelog>dir Volume in drive E is MoreSpace Volume Serial Number is 34F1-BF7B

Directory of E:\temp_activelog

10/31/2009 07:08 AM <DIR> .10/31/2009 07:08 AM <DIR> ..10/31/2009 06:15 AM 536,879,104 S0000027.LOG10/31/2009 06:38 AM 536,879,104 S0000028.LOG10/31/2009 07:08 AM 536,879,104 S0000029.LOG10/31/2009 07:20 AM 536,879,104 S0000030.LOG10/31/2009 06:05 AM 512 SQLLPATH.TAG 5 File(s) 2,147,516,928 bytes 2 Dir(s) 18,758,701,056 bytes free

Back up the databaseAfter the db2 activate db tsmdb1 command has returned to a command prompt, we are ready to take the first of two database backups.

Before we process and start the backup process, we create a directory on the E: drive to temporarily hold the database as shown in Example C-8.

Note: The database backups we take here are temporary and will be deleted. The purpose is to prune the archive logs.


Example C-8 Temporary database backup directory

E:\>md temp_db_backup

E:\>dir Volume in drive E is MoreSpace Volume Serial Number is 34F1-BF7B

Directory of E:\

10/31/2009 07:08 AM <DIR> temp_activelog10/31/2009 08:00 AM <DIR> temp_db_backup 0 File(s) 0 bytes 2 Dir(s) 18,758,701,056 bytes free

Now we start two consecutive database backups as shown in Example C-9. After the second backup, the archive log directory and original active log directory are empty of log files.

Example C-9 Take DB2 backups



C:\Program Files\Tivoli\TSM\db2\BIN>db2 backup db tsmdb1 to e:\temp_db_backup

Backup successful. The timestamp for this backup image is : 20091031080830

C:\Program Files\Tivoli\TSM\db2\BIN>db2 backup db tsmdb1 to e:\temp_db_backup

Backup successful. The timestamp for this backup image is : 20091031090213

After the second backup, the archive log directory and the original active log directory are emptied from the log files. The active log files are stored under the new active log directory path we defined above. Keep the backup image timestamps so you can later prune them from DB2.

Example C-10 shows the empty original log directory after the second database backup, The archive log directory is also empty at this point in time.

Example C-10 Empty original active log directory

D:\tsm\tsmactivelog>dir Volume in drive D is Server Volume Serial Number is 24DC-C90D

Directory of D:\tsm\tsmactivelog

10/31/2009 09:50 AM <DIR> .10/31/2009 09:50 AM <DIR> .. 0 File(s) 0 bytes 2 Dir(s) 13,560,594,432 bytes free


Prune the temporary database backupNow we can go ahead and delete the first database backup we just created. Remember that we just created it for the purpose of pruning the logs.

Example C-11 shows the steps to take to complete the pruning.

Example C-11 Prune database backup



C:\Program Files\Tivoli\TSM\db2\BIN>db2 connect to tsmdb1



C:\Program Files\Tivoli\TSM\db2\BIN>db2 prune history 20091031080830 with forceoption and deleteDB20000I The PRUNE command completed successfully.

Restore original active log directoryAt this point we now can restore the original active log directory. If you do not know the original value you can look up the ACTIVELOGDIRECTORY option in the server instance dsmserv.opt. Example C-12 shows how we revert back the active log path.

Example C-12 Revert back the active log path

C:\Program Files\Tivoli\TSM\db2\BIN>db2 update database config for tsmdb1 usingnewlogpath d:\tsm\tsmactivelogDB20000I The UPDATE DATABASE CONFIGURATION command completed successfully.SQL1363W One or more of the parameters submitted for immediate modificationwere not changed dynamically. For these configuration parameters, allapplications must disconnect from this database before the changes becomeeffective.

Activate the changeExample C-13 shows how we activate the change we just made. The connect command triggers DB2 to move the active logs back to the original directory, this is a real move and not a copy operation.

Example C-13 Activate the log path change

C:\Program Files\Tivoli\TSM\db2\BIN>db2 force application allDB20000I The FORCE APPLICATION command completed successfully.DB21024I This command is asynchronous and may not be effective immediately.




C:\Program Files\Tivoli\TSM\db2\BIN>db2 connect to tsmdb1



Complete the recovery

At this point we are able to start the server again. However, we need to complete some remaining tasks for the full recovery. Example C-14 shows the restart of the server instance in the foreground.

Example C-14 Recovered from the out of log space condition

D:\tsm\tsminst1>"c:\Program Files\Tivoli\tsm\server\dsmserv.exe"ANR0900I Processing options file D:\tsm\tsminst1\dsmserv.opt.ANR7800I DSMSERV generated at 13:10:23 on Aug 6 2009.




ANR4726I The ICC support module has been loaded.ANR0990I Server restart-recovery in progress.ANR1380I The buffer pool monitor switch is enabled.ANR1635I The server machine GUID, 6b.9e.90.31.ba.4f.11.de.95.00.02.00.4c.4f.4f-.50, has initialized.ANR2100I Activity log process has started.ANR4726I The NAS-NDMP support module has been loaded.ANR1794W TSM SAN discovery is disabled by options.ANR7808W Sun Microsystems Library Attach module libacs.dll is not availablefrom the system.ANR0984I Process 1 for EXPIRE INVENTORY (Automatic) started in the BACKGROUNDat 12:34:28.ANR0811I Inventory client file expiration started as process 1.ANR2803I License manager started.ANR8200I TCP/IP Version 4 driver ready for connection with clients on port1500.ANR2560I Schedule manager started.ANR2828I Server is licensed to support IBM System Storage Archive Manager.ANR2828I Server is licensed to support Tivoli Storage Manager Basic Edition.ANR2828I Server is licensed to support Tivoli Storage Manager Extended Edition.ANR0993I Server initialization complete.


ANR0916I TIVOLI STORAGE MANAGER distributed by Tivoli is now ready for use.TSM:TSMINST1>

We take two more full backups, this time from inside the Tivoli Storage Manager server of course. Example C-15 shows how we take two database backups while we disabled the server for incoming client sessions.

Example C-15 Database backups completing the recovery procedure

TSM:TSMINST1>disable sessionsANR2017I Administrator SERVER_CONSOLE issued command: DISABLE SESSIONSANR2553I Server now disabled for Client access.TSM:TSMINST1>backup db type=full devc=fileANR2017I Administrator SERVER_CONSOLE issued command: BACKUP DB type=fulldevc=fileANR4559I Backup DB is in progress.ANR0984I Process 4 for DATABASE BACKUP started in the BACKGROUND at 12:49:07.ANR2280I Full database backup started as process 4...lines deleted..ANR4550I Full database backup (process 4) completed.ANR0985I Process 4 for DATABASE BACKUP running in the BACKGROUND completed withcompletion state SUCCESS at 13:55:36.TSM:TSMINST1>backup db type=full devc=fileANR2017I Administrator SERVER_CONSOLE issued command: BACKUP DB type=fulldevc=fileANR4559I Backup DB is in progress.ANR0984I Process 5 for DATABASE BACKUP started in the BACKGROUND at 14:31:18.ANR2280I Full database backup started as process 5...lines deleted..ANR4550I Full database backup (process 5) completed.ANR0985I Process 5 for DATABASE BACKUP running in the BACKGROUND completed withcompletion state SUCCESS at 14:39:45.ANR0136I Table updating statistics performed successfully for 1 of 1.TSM:TSMINST1>enable sessionsANR2017I Administrator SERVER_CONSOLE issued command: ENABLE SESSIONSANR2552I Server now enabled for Client access.

At this point we are almost completed with the recovery procedure. As a last step we delete the second database backup taken using the DB2 backup db command. Example C-16 shows how we submit the prune command for the backup image with timestamp 20091031090213.

Example C-16 Prune command for backup image

C:\Program Files\Tivoli\TSM\db2\BIN>db2 prune history 20091031090213 with forceoption and deleteDB20000I The PRUNE command completed successfully.


Summary

We have guided you through the complete scenario to recover from a log space exhausted condition using DB2 commands while the Tivoli Storage Manager server is down. However, you should strive to prevent that condition from happening in the first place, because the procedure to fix it can be very time consuming, depending on the log space to manage. Make sure to investigate why you got the ANR0130E message and take the necessary precaution steps.


Related publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this book.

IBM Redbooks publications

For information about ordering these publications, see “How to get IBM Redbooks publications” on page 629. Note that some of the documents referenced here might be available in softcopy only:

� IBM Tivoli Storage Management Concepts, SG24-7447

� IBM Tivoli Storage Manager Implementation Guide, SG24-5416

Other publications

These publications are also relevant as further information sources:

� IBM Tivoli Storage Manager Server Upgrade Guide, SC23-9554

� IBM Tivoli Storage Manager for Windows Backup-Archive Clients Version 6.1, SC23-9792

� IBM Tivoli Storage Manager for UNIX and Linux Backup-Archive Clients 6.1, SC23-9791

� IBM Tivoli Storage Manager for AIX Installation Guide V6.1, GC23-9781

� IBM Tivoli Storage Manager for AIX Administrator's Guide V6.1, SC23-9769

� IBM Tivoli Storage Manager for AIX Administrator's Reference V6.1, SC23-9775

� IBM Tivoli Storage Manager for SAN for AIX Storage Agent User's Guide V6.1, SC23-9797

� IBM Tivoli Storage Manager for HP-UX Installation Guide V6.1, GC23-9782

� IBM Tivoli Storage Manager for HP-UX Administrator's Guide V6.1, SC23-9770

� IBM Tivoli Storage Manager for HP-UX Administrator's Reference V6.1, SC23-9776

� IBM Tivoli Storage Manager for SAN for HP-UX Storage Agent User's Guide V6.1, SC23-9798

� IBM Tivoli Storage Manager for Sun Solaris Installation Guide V6.1, GC23-9784

� IBM Tivoli Storage Manager for Sun Solaris Administrator's Guide V6.1, SC23-9772

� IBM Tivoli Storage Manager for Sun Solaris Administrator's Reference V6.1, SC23-9778

� IBM Tivoli Storage Manager for SAN for Sun Solaris Storage Agent User's Guide V6.1, SC23-9800

� IBM Tivoli Storage Manager for Linux Installation Guide V6.1, GC23-9783

� IBM Tivoli Storage Manager for Linux Administrator's Guide V6.1, SC23-9771

� IBM Tivoli Storage Manager for Linux Administrator's Reference V6.1, SC23-9777

� IBM Tivoli Storage Manager for SAN for Linux Storage Agent User's Guide V6.1, SC23-9799


� IBM Tivoli Storage Manager for Windows Installation Guide V6.1, GC23-9785

� IBM Tivoli Storage Manager for Windows Administrator's Guide V6.1, SC23-9773

� IBM Tivoli Storage Manager for SAN for Windows Storage Agent User's Guide V6.1, SC23-9553

� IBM Tivoli Storage Manager Messages V6.1, GC23-9787

� IBM Tivoli Storage Manager Performance and Tuning Guide V6.1, GC23-9788

� IBM Tivoli Storage Manager Problem Determination Guide V6.1, GC23-9789

� IBM Tivoli Storage Manager for UNIX and Linux Backup-Archive Clients Installation and User's Guide V6.1, SC23-9791

� IBM Tivoli Storage Manager for Windows Backup-Archive Clients Installation and User's Guide V6.1, SC23-9792

� IBM Tivoli Storage Manager for Space Management for UNIX and Linux User's Guide V6.1, SC23-9794

� IBM Tivoli Storage Manager Using the Application Program Interface V6.1, SC23-9793

� IBM Tivoli Storage Manager for Mail Data Protection for Microsoft Exchange Server Installation and User's Guide V6.1, SC23-9796

� IBM Tivoli Storage Manager for Enterprise Resource Planning Data Protection for SAP Installation and User's Guide for Oracle V6.1, SC33-6340

� IBM Tivoli Storage Manager for Enterprise Resource Planning Data Protection for SAP Installation and User's Guide for DB2 V6.1, SC33-6341

� IBM Tivoli Storage Manager for Advanced Copy Services Data Protection for Snapshot Devices Installation and User's Guide V6.1, SC23-8331

Online resources

These Web sites are also relevant as further information sources:

� IBM product announcement letters:


� Additional IBM Tivoli Storage Manager V6.1 products:


� Tivoli Storage Manager V6.1 documentation:


� UNIX client installation media:


� TSM V6.1 product and capacity planning information:


� TSM V61. product support site:


� Cygwin site:

http://www.cygwin.org







http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?topic=/com.ibm.itsmc.doc/baclients.html


http://www.cygwin.org

How to get IBM Redbooks publications

You can search for, view, or download Redbooks publications, Redpapers publications, Technotes, draft publications, and Additional materials, as well as order hardcopy Redbooks publications, at this Web site:

ibm.com/redbooks

Help from IBM

IBM Support and downloads

ibm.com/support

IBM Global Services

ibm.com/services

Related publications 629



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

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

http://www.ibm.com/services/

http://www.ibm.com/services/

Index

AACTIVATE DATABASE command 62active data pool names

syntax rules 123active data pools 123active data volumes 123Active Directory 196

database 198individual object recovery 409platform support 198V6.1 enhancements 197

ACTIVE log 251Active log

considerations 56active log 259, 383, 544

data deduplication 259mirror space 52size 58space estimate 52

active log directory 55ACTIVE log mirror 253Active log mirror 259

considerations 56space 514

Active-Data storage Pools 123ACTIVEDATASTGPOOL parameter 123ACTIVELOGDIR 34, 55ACTIVELOGDIRECTORY option 622ACTIVELOGSIZE value 619ActivePerl 5.10 585adaptive subfile backup 148adlocation option 409ADM7006E message 575ADM7514W message 119Administration Center 309, 432, 449

client nodes 453coexist 451create server instance 460credential entry 443DRM support 454expiration processing 166Expire Inventory 168features 452Health Monitor 454messages 453Reporting 433reporting CSV file 458upgrade considerations 451

administration notification log 117Administrator Center

autostart function 333administrator registration 325ADP 123ADSM 6

© Copyright IBM Corp. 2009. All rights reserved.

Advanced Copy Services 17aggregate size 178AIX

csum command 146installation 304

AIX configurationdatabase directories 336

AIX installAdministration Center 309administrator registration 325cleanup 347command line console wizard 307component selection 314configure DB2 database 319customize 316database backup 323database instance 319db2 update 320Disk Structure 317dsmserv format 321file permissions 305installation log 316logs 346Passport Advantage 305post install tasks 328root user 305time command 323update_all command 343upgrade 342X11 client 306X11 remote setup 311

AIX server 322disk structure 317options file 318server instance 318

AIX systemsupgrade 502

ANALYST privilege 35announcement letter 12ANR0130E 618ANR0130E message 105, 625ANR0165I message 171ANR0166I message 171ANR0190I message 171ANR0191I message 171ANR0985I message 89ANR1291 message 536ANR1336I message 293ANR1337I A LOGSPACE 552ANR1525I message 275ANR2590E message 87ANR2639E message 101ANR2968E message 89ANR2974I message 86, 390ANR2976I message 390

631

ANR4529I message 99ANR4531I message 98ANR4794E message 213ANR4896I message 172ANR4976W message 93ANS2837E message 224, 231API

DB2 backup 132ARCHIVE FAILOVER log 253Archive failover log

space 53archive failover log 260ARCHIVE log 252archive log 348–349

considerations 56new location 558prune 620size 58space requirements 259

archive log directory 383archive log files

pruned 514Archive.Objects table 163ARCHLOGDIR 34, 55ARIES/NT technology 42audience xviiAUDITDB facility 43autoconf tool 27autoconf utility 28automatic backup 98AUTOMATIC STORAGE parameter 54

Bbackup 471

device configuration 297, 526storage pools 296, 525

BACKUP ARCHIVEsoftware 415

BACKUP DB command 395backup db command 296, 525backup operations 401backup set 467

concept 472configuration 467DRM 474retention 472table of contents 473wizard 471

backup setsbreadcrumb navigation 473

BACKUP STGPOOL command 296, 525backup systemservices command 412Backup.Objects table 163backup/archive client

password 411Backup-Archive Client 408

migration guidelines 411BACKUPImage parameter 217BC Tier 0 140BC Tier 1 141

BC Tier 2 141BC Tier 3 141BC Tier 4 141BC Tier 5 142BC Tier 6 142BC Tier 7 142best practices

naming 264BIRT editor 447BIRT install 448BIRT package 434breadcrumb navigation 473BUFPOOLSIZE option 38–39, 46

Ccancel session command 296–297, 525–526CENTERA device 282CIFS 531circular log 102Client

enhancements, additions and changes 8install 411migrating,backup-archive client

migrating 411Version 5.1.5

improvements 9Client level support 250Client Node Group 469client nodes

upgrade 518client option

RESOURCEUTILIZATION 60schedlogretention 296, 525

Client Options file 426client restore 206client server

login 427command-line console wizard 307Common File Exclusion 425components 4, 356

installcomponents 357

Composite Offering Installer 356compression

deduplication 146configuration

backup set 467configuration wizard 132, 421, 425

Client Node Name 423Communications 423options file 422TCP/IP communication 424

configure server instance 374connect 65console installation wizard 370convert ussfilespace 295, 524COPY ACTIVEDATA 285copy pool protection 122Credential Store 487

delete 490


csum command 146Custom install 419Custom Setup window 419customize AIX 316customized reports 447Cygwin 311cygwin shell 312

Ddaily housekeeping 297, 526data deduplication 145, 259

disaster recovery 122data life cycle 137data migration 284Data Protection for Exchange 14Data Protection for Microsoft Exchange 236

compatibility 237requirements 236

Data Protection for Microsoft Exchange Server 14data shredding 286database 52

activated 62active log directory 55ACTIVELOGDIR 55ARCHLOGDIR 55Automatic Storage 54backup 395, 555commands 63, 598configuration 53disk storage 54extracting to media 289extraction process 515FORMAT 395full backup considerations 53future growth 513increase space 111insert process 256inserting data 516insertion process 300instance directory 264instance name 264log file flow 57log file sizing 57monitoring 54page sizes 54performance 516query 343QUERY DB FORMAT=DETAILED 52raw logical volumes 259recovery mode 58reduce size 559REORG 251restore 102, 617schema 559server upgrade 51setup tips 513SMS 54space estimates 513space requirements 49summary information 557

test system 290transaction activity 58uncommitted read 46V6 size estimate 52

database audits 247database backup 138, 390

example 96manual 87

database backupsverification 97

database capacity 251database component 45database directory 383database expiration processing 284database instance

AIX 319restart 396

database maintenance 558DB2

database maintenance 85database name 264database operations 513database reorganization 101database restore 111database size

planning 356database sizing formula 258database space

directories 265database space requirements 258database upgrade 247database volume 247DB.STORAGEPATHS 134DB2

ACTIVE log 251automatic backup 98constraints 43database and log directories 49expanded database size 43kernel parameter 47log file naming 61referential integrity 43reusing current code install 247rollforward operation 62striping 53triggers 43useful commands 63user limits 47

DB2 applications 437DB2 command

db2 connect reset 65db2 drop db db_alias 108

DB2 commandsattach 608Catalog database 599connect to 610, 612Create database 599db2 64db2 ? sqlxxxx 610db2 catalog 583

Index 633

db2 connect 65, 583db2 connect reset 65db2 describe table 69db2 get db cfg 66db2 get instance 69db2 list db directory 68db2 select 65db2 update dbm 575detach 609Get database manager configuration 600, 611get database manager configuration 116get snapshot 600, 612GRANT 602list history 609, 612runstats 603set db2instance 604stop dbm 603

DB2 configurationquery 343

DB2 database 41archive log 348backup 323Cached copies 50log function 348transition 44

DB2 database backup 132DB2 Driver for ODBC 583DB2 instance

environment variable 85DB2 options

db2instance 85DB2 password 365DB2 system commands

db2cc 85db2cmd 598, 604, 610db2icrt 598db2ilist 604db2level 70db2mtrk 604db2osconf 47, 598db2set 70, 574, 599db2start 70, 574, 603db2stop 70, 574

Db2 system commandsdb2pd 605

db2 update command 131, 320DB2 UPDATE DB command 619DB2 version 500DB2_VENDOR_INI variable 91DB2COMM setting 574db2diag utility 118db2diag.log 119db2diag.log file 117, 575db2icrt command 293, 319, 393db2osconf system utility 598db2set command 91db2stop command 119db2support.zip 608DB2TSM 365DBBACKUPTRIGGER command 98

dbdir.txt file 108DBMEMPERCENT 34DBMEMPERCENT option 46, 398DBMEMPERCENT parameter 328DBPAGESHADOW option 39DBPAGESHADOWFILE option 39DBREPORTMODE setting 114dd storagepool 153ddtrace utility 27deduplicated copy storage pool 139deduplicated storage pools 138deduplication 137, 146, 154

commands 151dd storagepool 153disabling 154encrypted files 151hash functions 146hyperfactor 147log sizing 61ratios 147Single Instance Store 146space considerations 154workloads 146

default server 394DEFINE

DBBACKUPTRIGGER 37DBCOPY 37DBVOLUME 37LOGVOLUME 37

DELETE VOLHISTORY command 296, 525Deployment Engine

Initialization 372remove 403

DEVCLASSES table 615DEVCONFIG option 274DFS links 412diagnostic information 114, 118diagpath

configuration parameter 119DIAGPATH parameter 117diffsnapshot 221diffsnapshot option 408DiffSnapShot=Latest option 221disable reclamation 284DISABLENQR YES option 158disabling sessions 296, 525disaster

preparation 43recovery 43

disaster recovery 216data deduplication 122

Disaster Recovery Manager 5license 121

disaster recovery plan 126Disaster Recovery solution 142DISK device class 615Disk Structure 317dismount tapes 298, 526DMS tablespace 53DPI protocol 400


DRMADP 123DSMSERV RESTORE 126

DRM SET command 124dsm.opt file 224, 416dsmapipw command 92dsmclc migrate command 193dsmclc migratelist command 193dsmclc tool 186dsmcutil command 92DSMFMT utility 38dsmformat command 332dsmhsmclc check command 190dsmhsmclc command 194DSMI_ api variable 396DSMI_CONFIG

environment variable 90dsmicfgx program 333dsmicfgx wizard 369, 437dsmicfgx.exe 378dsmifgx program 94dsmmfc.exe file 414DSMSERV

AUDITDB 38DISPLAY DBBACKUPVOLUME 38DISPLAY DBSPACE 32, 39DISPLAY LOG 32DUMPDB 39EXTEND LOG 39INSERTDB 33LOADDB 39LOADFORMAT 36REMOVEDB 33RESTORE DB 36, 39UNLOADDB 39

dsmserv command 322DSMSERV DISPLAY DBSPACE 55DSMSERV FORMAT command 394–395dsmserv format command 86, 321DSMSERV INSERTDB 275DSMSERV LOADFORMAT command 566DSMSERV program 555DSMSERV REMOVEDB 133DSMSERV REMOVEDB command 108dsmserv restore db command 126DSMSERV utility 397dsmserv.dsk file 532dsmserv.opt 274dsmserv.opt file 101, 108, 619dsmserv.v6lock file 393dsmupgdx wizard 437DSMUPGRD

EXTEND DB 33EXTEND LOG 33EXTRACTDB 33EXTRACTDB utility 499PREPAREDB 33PREPAREDB utility 499QUERYDB 33

dsmupgrd preparedb

rollback 560dsmupgrd preparedb command 293DSMUPGRD upgrade utilities 499DSMUPGRD utilities 272, 277, 499DSMUPGRD utility 272, 298, 527DUMP/LOAD utilities 618

EEnterprise Edition 150environment variable 394ESTIMATE DBREORGSTATS 37event retention data 294, 523Exchange 14EXPINTERVAL server option 284expiration algorithm 163

proprietary 162EXPIRATION process 161expiration process 170, 481

new with V6 163RESOURCE parameter 166TYPE parameter 166

expiration processingAdministration Center 166

expiration task 169Expire Inventory window 168Expiring.Objects table 163EXTEND DB 273EXTEND DBSPACE 38, 111EXTEND DBSPACE command 32, 113, 251EXTEND LOG 38extract process 256EXTRACTDB command 272extraction

physical disk drive 515extraction process 515

Ffailover archive log 514failover log 402fallback 296, 524File and Print Sharing 531file level recovery 212file level restore 220file permissions 305filel restore 212Filer logs 219firewall

port 445 531fix packs 359

ftp site 357FlexVol volume 220FORMAT database 395full backup 95full database backup 98future growth 52

Ggathering logs 404

Index 635

GENERATE BACKUPSET command 474get health snapshot command 602grant auth admin 325

Hhash functions 146Health Monitor 432, 454

multi-threaded model 455help

non-English online 414Help command 410HP-UX

passthru driver 27HP-UX systems

upgrade 504HSM

introduction 186threshold migration 187

HSM for Windowsmigration jobs 186V5.4 enhancements

hyperfactor 147

IIBM Autonomic Deployment Engine 366IBM Tivoli Monitoring 432IBM Tivoli Storage Manager

Client enhancements, additions, and changes 8disaster preparation and recovery 43new features overview 7, 10overview 4, 42, 122product components 4product positioning 5Server enhancements, additions and changes 7

IBM Tivoli Storage Manager Client. see ClientIBM Tivoli Storage Manager for ERP 15IBM Tivoli Storage Manager for Mail 14IBM Tivoli Storage Manager for Space Management see Tivoli Storage Manager for Space ManagementIBM Tivoli Storage Manager HSM for Windows see HSM for WindowsIBM Tivoli Storage Manager see Tivoli Storage ManagerIBM Tivoli Storage Manager Server. see ServerIDENTIFY DUPLICATES command 32Identify Duplicates processes 153identify processes 153Incremental backup 556incremental database backup 98index_keyseq 614index_order column 614Individual Mailbox Restore 238

limitations 239restoremailbox parameter 242

initial database size 332INSERTDB

ANR1525I message 275insertdb 562INSERTDB utility 274, 570install

restriction 358setup wizard 416

install folder 418InstallAnywhere 357InstallAnywhere platform 293installation 245installation log 316installation wizard 360installer program

dsmicfgx.exe 378instance configuration

database backup 390instance creation 462instance directory 258, 264, 393, 542instance startup 322instance user ID 379instance wizard

database directory 383Integrated Solution Console 449Integrated Solutions Console 487introduction 146ipcs - l command 48ISC 449

default location 492default timing 492enhancements in V7.1 487multitasking 487partial refresh 487preserving scroll location 487single sign-on 487startup pages 487upgrade 451upgrade considerations 451url login 452

ISC/ACremote connection 326

ISC/AC server process 325Itanium system 504, 510

JJFS2 file system 349JVM 448

Kkernel parameter 47kernel parameters 48

LLABEL LIBVOLUME operation 24language packs 416library clients 517library managers

upgrade 517Linux on System z

upgrade 508Linux system

upgrade 505Local disaster recovery 128


log configurationdatabase

log config 55log directories

setup tips 513log directory 621log exhausted 618log file flow 57log file sizing 57log files

naming 61log sizing

deduplication 61log space 105log space condition 618log space usage 179log utilization ratio 98Log volume 247Logical Volume Snapshot Agent 414LOGPOOLSIZE option 39LOGWARNFULLPERCENT 39LZW-based algorithm 151

Mmailbox restore feature 14mailboxoriglocation parameter 14maintenance

script edit 484maintenance plan 474maintenance script 453

expiration process 481Manage Global Refresh 490management classes 453manual create server 392MAXSESSIONS option 178Media method 267media method 260, 278, 538media method upgrade 257memory usage 46Microsoft Exchange 14Microsoft Exchange Server 236migrating

processor architecture 412migration

passwords 411migration considerations

processor architectures 412migration jobs 186mirror log 544mirror log directory 383MIRRORREAD option 39MIRRORWRITE option 39mkdir command 376, 392Monitor Service 189Monitoring and Reporting 432

installation 437setup options 434

Monitoring feature 432components 434

MOVE DRMEDIA command 124

MOVE DRMEDIA, 123multiple NICs 248

NNamed Pipes 400NAS backups 411NAS devices

backup 212file level recovery 212

NAS file systemssnapdiff option 225

NAS TOCmanual upgrade 564query NASBACKUP * 570

NAS TOC dataAIX insertdb 562extractdb 562

NAS TOC upgrades 562NDMP 211

IP address 213IPV4 address 213SETOPT command 213

NDMP support requirements (Extended Edition only) 414NetApp FilerView tool 408NetApp SnapMirror to Tape 212NetApp Snapshot Difference API 408network connection 401network method 257, 538

upgradenetwork method 270

new server instance 369no query restore 156NOMIGRRECL option 285NOMIGRRECL server option 284non-root user 46NQR algorithm 156

OODBC

configuration 583configuration verification 583DB2COMM setting 574

ODBC driverpackage 576

off site data vaulting 143open database connectivity driver 573Open File Support 414OpenOffice 586

Administrators table 594operating procedures 291operational 285Operational Reporting 291, 435operational reporting 291Operational Reporting tool 432out of log space 618

Ppackage components 356

Index 637

package names 357PA-RISC system 504Passport Advantage 305passthru device driver 27

device configuration 27passthru driver 27Payloads 357performance

extraction process 299TXNGROUPMAX 179

perlsample script 585

perl script 584planning

ACTIVE log mirror 253ARCHIVE FAILOVER log 253database capacity 251database migration 246performance 265

ppm install DBI command 584PREPARE command 124PREPAREDB command 272primary archive log 383processor architectures 412product positioning 5product support site 502proprietary database 42ProtecTIER 150prune command 624

Qq script f=d 484Qtree security 231query adobjects command 409query archive command 410query backup command 410QUERY DB FORMAT=DETAILED 258QUERY DBSPACE 55, 110QUERY DBSPACE command 32QUERY DRMEDIA 124QUERY DRMEDIA command 123QUERY LIBRARY command 25QUERY LOG 110QUERY LOG command 37, 99query mount 526query NASBACKUP * 570QUERY NODE command 91query process 526QUERY PROCESS command 171query san command 23QUERY SERVER command 264query session command 296, 525QUERY SQLSESSION 38QUERY STATUS command 114query stgpool command 154Query SystemState command 200QUERYSUMMARY option 206, 410QUERYSUMMARY output 206

Rraw logical volumes 52, 259RECLAIM parameter 298, 527RECLAIMDELAY option,server option

RECLAIMDELAY 26RECLAIMPERIOD 26RECLAIMPERIOD option,server option

RECLAIMPERIOD 26reclamation

diable 284recovery log 45

ROLLFORWARD 390space requirements 259

recovery log process 348recovery log space 514

naming 265recovery logs 251recovery mode 58recovery plan 127recovery site scenario 129Redbooks Web site 629

Contact us xxREDUCE DB 38REDUCE LOG 38REGISTER LICENSE command 398, 555REGISTER NODE command 179registry keys 394RELABELSCRATCH parameter 24rename system object 413REORG database 251Reporting

Administration Center 433Deployment Engine 434

Reporting and Monitoringfrequently asked questions 435

Reporting featurecomponents 434

reporting monitoring feature 250Reporting package 432RESET

DBMAXUTILIZATION 38LOGCONSUMPTION 38LOGMAXUTILIZATION 38

RESET BUFPOOL 38restore adobjects command 410RESTORE DB command 395restore systemservices command 412restore systemstate 412restore vm 410restoremailbox parameter 242rollback 560rollback upgrade 560ROLLFORWARD 390rollforward operation 62ROLLFORWARD recovery 58rollforward recovery 62rollforward utility 62RTRIM function 616rvoptsetencryptiondisabled option 410


SSAN Device Mapping 22SAP 15

snapshot environments 17SAPOracle 16schger driver 28schgr native driver 27sctl driver 27sdisk driver 28SELFTUNEBUFPOOLSIZE 39Server

enhancements, additions and changes 7Version 5.3

improvements 8server

communication 399FORMAT database 395instance user ID 264

server commandBACKUP DB 35PREPARE 35QUERY DRMSTATUS 35QUERY NASBACKUP 35

server commandsCONVERT ARCHIVE 37DEFINE VOLUME 35deleted 37QUERY DB 35QUERY LOG 35QUERY OPTION 35QUERY PROCESS 36QUERY SESSION 36QUERY STATUS 36SETOPT 36UPDATE ADMIN 36UPDATE DEVCLASS 35UPDATE VOLHISTORY 35

server configurationport 445 379TCP/IP 386

server directories, Windows installserver directories 376

server instanceconfigure 374creation 460initialize 394manual 392starting 397stopping 397tcpport 465user ID 318

server instancesmultiple on system 398

server messages 170, 453server name 264server naming 264server objects

expiration process 162server operations

disable for upgrade 288

server optionACTIVELOGSIZE 34ARCHFAILOVERLOGDIR 34ARCHLOGDIR 34DBMEMPERCENT 398DEDUPREQUIRESBACKUP 34DEVCONFIG 393DISKSTGPOOLMEMSIZE 34MIRRORLOGDIR 34NDMPPREFDATAINTERFACE 213–214TXNGROUPMAX 178VOLUMEHISTORY 104, 393

server optionsTXNGROUPMAX 37

server options file 318Server Options utility 399Server utility

DSMSERV DISPLAY DBSPACE 105DSMSERV DISPLAY LOG 106DSMSERV FORMAT 36

server-connection tasks 453service port 575SET

SQLDATETIMEFORMAT 38SQLDISPLAYMODE 38SQLMATHMODE 38

SET DBRECOVERY command 32, 35, 87, 89, 293SET DBREPORTMODE 32, 114SET DRMACTIVEDATASTGPOOL 32, 123SET LOGMODE 38set password command 222, 410SETOPT command 36, 213setup wizard 416Seven Tiers of DR 140shared library config 256Shared Memory Communication 387shared memory options 400SharePoint Services 15SHMPORT option 400SHOW LOGV command 59silent install

batch script 375silent mode install 374Single Instance Store 146single sign-on 487single signon 488SMB protocol 378, 531snap list command 225Snapdiff

DiffSnapShot=Latest option 221incremental backup 221

SnapDiff API 220, 408preparation 222

snapdiff option 220, 408initial backup 222NAS file system 225

SnapLock volumeRECLAIMDELAY 26

SNAPMirrorTYPE restrictions 218

Index 639

SnapMirror image 215snapmirror log 219SNAPMirror parameter 217SnapMirror restore

unlike geometry 220SnapMirror to Tape 215

restore 219Snapshot 556snapshot difference

performance 233snapshot operations 16snapshotproviderfs option 414snapshotproviderimage option 414snapshotroot option 221snmp daemon 400SNMP subagent 400space 257

Active log 514future growth 513server setup tips 513upgrade process 514V5 server 512

space considerationsdeduplication 154

space estimatesdatabase 513

space requirements 257active log 259active log mirror 259archive failover log 260archive log 259recovery log 259tables 261TSM V6 server 257upgrade 511

space requirements 512work sheet 263

SPACETRIGGER commands 35SQL queries 559SQL1025N message 574SQL1063N message 576SQL5043N message 575stagingdirectory option 411stape driver 28storage agents

upgrade 518storage pool

verify 179storage pool commands 35storage pools 284

DEVTYPE=FILE 393Sun Solaris

upgrade 509SYSSTAT function 215system memory 355system requirements 248system state backup 412System Storage Archive Manager 282

Ttape drive 414tape library 414TCP/IP 386

SHMPORT option 400SSLTCPADMINPORT 399SSLTCPPORT 399TCPADMINPORT 399TCPNODELAY 399TCPPORT 399TCPWINDOWSIZE 399

TCP/IP communication 424TCP/IP options 399tcpport 465tdpexcc command 242telnet session 333test upgrade 288The Deployment Engine 357threshold migration 187

command line client 193environments 188options 192summary 194tasks 194

THROUGHPUTDATATHRESHOLD option 179THROUGHPUTTIMETHRESHOLD option 179timeline 6timestampdiff function 614Tivoli Common Reporting 432, 434Tivoli Event Portal 432Tivoli Storage Manager

Administration Center 449client V5.3 enhancements 9componentsdevelopment timeline 6Extended Edition 5for products 13overviewrelease timeline 6Space Management 188version compatibility 6

Tivoli Storage Manager Extended Edition 5Tivoli Storage Manager for ERP 15Tivoli Storage Manager for Mail 14, 235Tivoli Storage Manager for Space ManagementTivoli Storage Manager for Storage Area Networks 10Tivoli Storage Manager HSM for Windows see HSM for WindowsTivoli Storage Manager V6 Upgrade Guide 283transaction activity 58transaction group 178triggered backups 98TSM

ARCHIVE log 252proprietary database 42recovery logs 251relabel volumes 24

TSM Clientinstall 407

TSM Copy Services


Copy ServicesTSM 17

TSM database 45TSM Enterprise Edition 150TSM for Data Retention 282TSM inventory

delete backup 221TSM V6.1

INSERTDB utility 274TsmAC 452tsmdbmgr.opt file 91, 396tsmddcfg script 28tsmdlst tool 27tsmdlst utility 28tsmservers.xml file 451TXNBYTELIMIT option 178–179TXNGROUPMAX

server option 61TXNGROUPMAX default 177TXNGROUPMAX option 178

performance 179TXNGROUPMAX options

log records 178Typical install 419

Uulimit values 46Uncommitted Read 46UNDO

ARCHCONVERSION 38UNIX

DB2 database 46UNIX client install 415UPDATE

ARCHIVE 38update_all command 343Upgrade

DB fall-back plan 255V5 server space 512

upgrade 254, 517AIX server 502archive log 544backup db command 296, 525client nodes 518compatibility 517creation of server instance 540data shredding 286DB space 258DB2 version 500directories 543disabling sessions 296, 525dismount tapes 298, 526EXTRACTDB utility 273fallback 296, 524HP/UX systems 504hybrid method 282instance directory 542instance owner 541library configuration 248library managers 517

Linux on System z 508Linux system 505LOADFORMAT 274media method 257, 515, 538messages 551–552mirror log 544multiple NICs 248, 256multiple servers 517network method 257, 260, 515, 538network wizard 278, 281new system network 277NOMIGRRECL option 285prepare.out file 536PREPAREDB 272preparing steps 523problem 524process restart 561return code 405 552rollback 560same system 278same system network 280scenario 522scenarios 275server modifications 524server requirements 500server upgrade 548shared library config 256space requirements 257, 511storage agents 518Sun Solaris 509system requirements 248Target System Authentication 531test 288test environment 248time 255time estimate 515total space 260utilities 528verification 555Windows systems 510wizard 277wizard restart 537wizard tool 529

upgrade methods 266upgrade phase 533upgrade process

space 514summary 263, 498

upgrade server 342upgrade utilities 267, 298, 517, 527

FTP downloads site 528upgrade utility 247, 249

resources 501upgrade utility package 500upgrade wizard 517upgrade wizards 293upgradespace

worksheet 263upgrading

external media 269

Index 641

upgrading ISC 451User Account Control 378

VV6.1 database

extraction process 300virtual machine backup 408vmbackdir option 411vmbacknodelete option 411vmbackuptype option 411volume history

backup volhistory 297, 526volume history file 101, 103Volume Shadow Copy Service 16, 414VOLUMEHISTORY option 104VOLUMEHISTORY server option 101VTL

RELABELSCRATCH 24VTL devices 22

WWeb-client language files 414Windows install

216 message 397batch script 375Client install 420communication 399components 358, 363configuration 376configure 369DB2 considerations 354DB2 password 365debugging 402default server 394disk space 355first to know 354initialize server 394installation folder 363installation log 369instance user ID 379log gathering 404planning 354register license 398registry keys 394server instance 376server stop 397silent mode 374software 355system memory 355system requirements 354TCP/IP options 399user account control 378

Windows Registry 411Windows service

server instance 397Windows systems

install server 354upgrade 510

wizard

media method, upgrademedia wizard 276

network method 278wizard tool 529

XX11 client 306X11 environment 311X11 pre-configured 307X11 redirection 333X11 remote setup 311xterm & command 312


(1.0” spine)0.875”<

->1.498”

460 <->

788 pages


Tivoli Storage Manager V6.1

Technical Guide


Technical Guide



Technical Guide


Technical Guide

®

SG24-7718-00 ISBN 0738433691

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE

IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.

For more information:ibm.com/redbooks

®


Learn the new features and function in Tivoli Storage Manager V6.1

Detailed installation, upgrade, and customization provided

Monitoring and reporting enhancement examples

This IBM Redbooks publication provides details of changes, updates, and new functions in IBM Tivoli Storage Manager Version 6.1. We cover all the new functions of Tivoli Storage Manager that have become available since the publication of IBM Tivoli Storage Manager Version 5.4 and Version 5.5 Technical Guide, SG24-7447.

This book is for customers, consultants, IBM Business Partners, and IBM and Tivoli staff who are familiar with earlier releases of Tivoli Storage Manager and who want to understand what is new in Version 6.1. Hence, because we target an experienced audience, we use certain shortcuts to commands and concepts of Tivoli Storage Manager. If you want to learn more about Tivoli Storage Manager functionality, see IBM Tivoli Storage Management Concepts, SG24-7447, and IBM Tivoli Storage Manager Implementation Guide, SG24-5416.

This publication should be used in conjunction with the manuals and readme files provided with the products and is not intended to replace any information contained therein.

Back cover




ibm tivoli storage manager v6.1 technical guide sg247718

Technology

tivoli storage manager

deduplicated storage

covertivoli storage

local disaster recovery

microsoft sharepoint

new server commands

deduplication overview

background42 copyright