William, Being at the level of TSM you are at, could you be experiencing the wonderful 'system objects' problem? This is the level we were at when it really bit us and we started experiencing the same slow downs you are currently experiencing (we couldn't get through expiration in a day any longer, reclamation couldn't stay caught up, DB growth, etc.).
Once we went to 4.2 and performed the cleanup backupgroups and actually deleted all of our system objects and just started over on that filespace, we have been able to rid ourselves of these issues. But, the total process of getting through everything took about 5 months. 1. Since then, we have been able to reduce our 35 GB DB utilization from 92% to 46%. Our buffpoolsize is set to 212992 and we are running really well right now. 2. No experience with damage to DB. 3. Ran an auditDB in development and cancelled it after 30 hours. Not feasible for the production environment. Cinda Mullen Ascension Health ISD -----Original Message----- From: William White [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 6:51 AM To: [EMAIL PROTECTED] Subject: TSM Performance OS/390 Dear helpful TSMers, We are having trouble with performance. Symptoms are extremely slow expiration, database backup, migration, backup, restore, admin commands. As an example, after an incremental database backup of about 360000 pages, there was a message on the console saying all of the pages were backed up and yet it took about an hour for the process to end. Normal performance of database backup in our environment is about 15000 pages every 30 seconds (when the progress message is issued) Yesterday, I was seeing a few hundred pages increase between messages. TSM environment: z800 (2066 0A2) OS/390 V2.10 (32 bit mode) STK 9840 tape (20 GB cartridges) HDS 7700 E DASD TSM server 4.1.6 150 clients, mostly wintel 250 GB per night backup I know that the server software is out of date and we are working on getting V5. I think the basic problem is bad performance of the TSM database: tsm: ADSM>q db f=d Available Space (MB): 57,120 Assigned Capacity (MB): 52,516 Maximum Extension (MB): 4,604 Maximum Reduction (MB): 4,396 Page Size (bytes): 4,096 Total Usable Pages: 13,444,096 Used Pages: 12,319,606 Pct Util: 91.6 Max. Pct Util: 91.6 Physical Volumes: 25 Buffer Pool Pages: 200,000 Total Buffer Requests: 98,206,939 Cache Hit Pct.: 97.27 Cache Wait Pct.: 0.00 Backup in Progress?: No Type of Backup In Progress: Incrementals Since Last Full: 2 Changed Since Last Backup (MB): 923.31 Percentage Changed: 1.92 Last Complete Backup Date/Time: 06/11/2003 13:38:46 My Questions: 1) Does the size of the buffer pool seem appropriate? What values are other sites using? 2) Does anyone have any experience of pervasive damage to the TSM database? 3) Does anyone think an AUDIT DB would help? I am reluctant to try that because I think it would take a very long time and the server would be out of service for all that time. I did an AUDIT DB years ago and it ran over 9 hours on a 6GB database. Extrapolating, an AUDIT DB might finish in four days ( a reasonable guess ? ) Thanks, www. --------------------------------------------------------- William White Service Delivery Section International Computing Centre (ICC) e-mail: [EMAIL PROTECTED]
