RS/6000 model 6h1
600 MHZ
2-way
4 GB RAM
Disk: HP XP 1024
tsm: UNXR>select activity, cast ((end_time) as date) as "Date", (examined/cast
((end_time-start_time) seconds as deci mal (18,13)) *3600) "Objects
Examined Up/Hr" from summary where activity='EXPIRATION' and days (end_time) -
days (start_time)=0
ACTIVITY Date Objects Examined Up/Hr
------------------ ---------- ---------------------------------
EXPIRATION 2004-08-14 4755600
EXPIRATION 2004-08-14 4755600
EXPIRATION 2004-08-16 5137200
EXPIRATION 2004-08-17 5083200
EXPIRATION 2004-08-18 5248800
EXPIRATION 2004-08-19 4957200
EXPIRATION 2004-08-20 4672800
EXPIRATION 2004-08-21 5241600
EXPIRATION 2004-08-23 5626800
EXPIRATION 2004-08-24 6055200
EXPIRATION 2004-08-25 5346000
EXPIRATION 2004-08-26 5004000
EXPIRATION 2004-08-27 5202000
EXPIRATION 2004-08-28 5464800
EXPIRATION 2004-08-30 5076000
EXPIRATION 2004-08-31 5464800
EXPIRATION 2004-09-01 5148000
EXPIRATION 2004-09-02 5018400
EXPIRATION 2004-09-03 5176800
EXPIRATION 2004-09-04 5439600
EXPIRATION 2004-09-06 4395600
EXPIRATION 2004-09-07 6656400
EXPIRATION 2004-09-08 5454000
EXPIRATION 2004-09-09 5025600
EXPIRATION 2004-09-10 3938400
EXPIRATION 2004-09-11 5529600
tsm: UNXR>q db f=d
Available Space (MB): 32 760
Assigned Capacity (MB): 32 760
Maximum Extension (MB): 0
Maximum Reduction (MB): 27 804
Page Size (bytes): 4 096
Total Usable Pages: 8 386 560
Used Pages: 837 206
Pct Util: 10.0
Max. Pct Util: 10.0
Physical Volumes: 4
Buffer Pool Pages: 262 144
Total Buffer Requests: 973 701 185
Cache Hit Pct.: 99.38
Cache Wait Pct.: 0.00
Backup in Progress?: No
Type of Backup In Progress:
Incrementals Since Last Full: 0
Changed Since Last Backup (MB): 0.89
Percentage Changed: 0.03
Last Complete Backup Date/Time: 09/13/04 07:40:58
tsm: UNXR>q dbvol f=d
Volume Name Copy Volume Name Copy Volume Name
Copy Available Allocated Free
(Copy 1) Status (Copy 2) Status (Copy 3)
Status Space Space Space
(MB) (MB) (MB)
---------------- ------ ---------------- ------
---------------- ------ --------- --------- --------
----- ------ --------- --------- --------
/dev/rTSMdbC1 Sync'd /dev/rTSMdbC2 Sync'd
/dev/rTSMdbC1 Sync'd /dev/rTSMdbC2 Sync'd
Undef- 16 380 16 380 0
ined
/dev/rTSMdbB1 Sync'd /dev/rTSMdbB2 Sync'd
Undef- 16 380 16 380 0
ined
>>> christoh AT ABSA.CO DOT ZA 13-Sep-04 2:12:45 AM >>>
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.
|
