Hi Ben, I agree with you on these points - ran Dave's script on our main TSM server - and the Database backup performance is exceptionally good - the slowest I'm seeing is 31000000: FULL_DBBACKUP 2004-09-03 62625600 FULL_DBBACKUP 2004-09-04 56156400 FULL_DBBACKUP 2004-09-05 59911200 FULL_DBBACKUP 2004-09-06 51152400 FULL_DBBACKUP 2004-09-07 57801600 FULL_DBBACKUP 2004-09-08 60886800 FULL_DBBACKUP 2004-09-09 52707600 FULL_DBBACKUP 2004-09-10 59018400 FULL_DBBACKUP 2004-09-11 57938400 FULL_DBBACKUP 2004-09-12 58968000
The average seems to be in the region of 50000000 +, so from that point of view it seems excellent - but the expiration sucks according to the script. ACTIVITY Date Objects Examined Up/Hr ------------------ ---------- --------------------------------- EXPIRATION 2004-08-14 856800 EXPIRATION 2004-08-14 867600 EXPIRATION 2004-08-15 864000 EXPIRATION 2004-08-17 770400 EXPIRATION 2004-08-18 669600 EXPIRATION 2004-08-19 846000 EXPIRATION 2004-08-20 734400 So, yes, it seems that Ymmv, but is there anyone out there getting good performance from expiration? If there are people out there, don't you want to share your environment with us - might be able to collectively cast some light on the lower expiration figures. For the record, my environment is as follows: AIX 5.2 TSM 5.2.2.5 DB size 105Gig - 93% utilized - 13 Lun's (One over the recommendation). Disk subsys - FastT900 File system - RLV Tape technology: 3584 with Lto-2 drives. P650 (4 Processors and 4Gig Ram) Regards ChristoH =================================================================== Yes, interesting stats. On all my TSM servers, they get above 5M pages for the DB backup, but none of them are above 3.8M objects on the expire inventory. Some in the 2M, others only in the .5 M range. These random thoughts pointed at the group, not necessarily Joe. Since my db backups (sequential reads) go well, but the expire inventory (random reads and writes) are slow, might that point to DB fragmentation? Improper tuning of TSM buffers? Overcommittal of the fast-write disk cache? Bad karma? One would think that the more files deleted during the expire inventory, the longer it will take for the expire inventory to progress? No? I can run 2 expire inventories in a row and the second one goes much much quicker because there are very few changes to the DB to be made. It seems like the performance on the "number of objects examined" is really one of those "your mileage may vary" kind of stats. Perhaps I'm not getting the performance I should out of the expiration... Ben ______________________________________________________ Important Notice: Important restrictions, qualifications and disclaimers ("the Disclaimer") apply to this email. To read this click on the following address: http://www.absa.co.za/ABSA/EMail_Disclaimer The Disclaimer forms part of the content of this email in terms of section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you are unable to access the Disclaimer, send a blank e-mail to [EMAIL PROTECTED] and we will send you a copy of the Disclaimer.