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                                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 disclaimer AT absa.co DOT za and we
will send you a copy of the Disclaimer.