Re: Slow Offsite Reclamation (Was Tape drive recomendations)

So,,, the upshot is, for good performance of OFFSITE reclamation:
- empty the DISK (ie, RANDOM) storage pool(s) that feed any
offsite/copy-pool before running reclamation.

This, loosely translates to "only run reclamation for offsite storage-pools
on weekends" -- since we sized the DISK pools to be 2.25 x the daily load,
and set migdelay=1 to allow restores (of most recent backup data) to work
from disk, rather than incur tape mounts.

Thusly, we end up with more tapes in offsite storage (since their
reclamation only occurs once a week);  best to set the rec=60 (as
distasteful as that might seem), when starting reclamation at 2pm on
Saturday, after doing disk-to-tape migration (with migdelay=0) to empty out
the disk pools.

And, for those folks contemplating HUGE primary pools on disk, with no
migration to tape --- you'd better plan on periodic migration to sequential
pools on disk, else your offsite, copy-pool reclamation will take days, not
hours, to complete.  Remember, this product is optimized for (a) disk
(random-access) pools for initial destination (to maximize concurrency with
minimal tape contention for backups), and (b) sequential pools for the
long-term destination of all data, both primary and copy-pool data.


Don France
Technical Architect -- Tivoli Certified Consultant
Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390
San Jose, Ca
(408) 257-3037
mailto:don_france AT ayett DOT net (change ayett to att for replies)

Professional Association of Contract Employees
(P.A.C.E. -- www.pacepros.com)



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Rushforth, Tim
Sent: Friday, November 01, 2002 7:26 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Slow Offsite Reclamation (Was Tape drive recomendations)


Yes! An old APAR cover's this issue, see below.  When you are running
offsite reclamation watch the throughput when it is reading from disk as
opposed to reading from tape.  It just crawls.

Apar IC15925:
--------------------------------------------------------------------
ERROR DESCRIPTION
During an offsite reclamation process; where files are being transfered from
disk to tape.  ADSM fails to group the files together into transaction
groups.  Instead the files are processed sequentially.  Hence a file will be
reclaimed and committed before the next file will be process. ADSM needs to
honor the movebatchsize and movesizethresh options in the server options
file, so that the files will be grouped together properly for reclimation.
As a note, this problem will only be seen where off-site reclamation is
occuring from disk to tape.
COMMENTS:
After taking a very close look at the solution for this APAR, it was
determined that the code needed for this performance enhancement is
significant because it requires a restructure in the offsite reclamation
transaction processing.  A requirement can be taken to include this
performance improvement in the next release or version.
--------------------------------------------------------------------

Tim Rushforth
City of Winnipeg

-----Original Message-----
From: Steve Schaub [mailto:Steve.Schaub AT HAWORTH DOT COM]
Sent: October 31, 2002 11:15 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Tape drive recomendations

If I'm reading this correctly, only migrating my diskpool down to 10% is
hurting my DRM reclamation?
Are you saying that putting in a 10TB diskpool that never goes to
primary tape (only dr copies) would give me monstrously bad
reclamations?  Our current main diskpool is 100gb on SSA and has caching
on.  I haven't had a terrible problem with DR reclamation, though the
storage pool backup to DRM only has a throughput of about 5mb/sec.

-----Original Message-----
From: TRushfor AT CITY.WINNIPEG.MB DOT CA
Sent: Thursday, October 31, 2002 11:03 AM
To: CITY.WINNIPEG.MB.CA.TRushfor; VM.MARIST.EDU;.ADSM-L
Subject: Re: Tape drive recomendations


And the issue is still there if you don't use CACHE=YES but don't
completely clear your backup pool.

We have more disk in our storagepool than is required for one night's
incremental - so we thought keeping some backups on disk was a good
thing (why migrate to tape if you don't need the space).


Tim Rushforth
City of Winnipeg

-----Original Message-----
From: Bill Boyer [mailto:bill.boyer AT VERIZON DOT NET]
Sent: October 31, 2002 9:01 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Tape drive recomendations

Be careful of your copypool reclamations with the disk cache turned on!!
There is a BIG performance hit on reclamation when the primary copy of
the file is on a DISK direct access storage pool. Then the
MOVESIZETHRESH and MOVEBATCHSIZE values are thrown out the window and
the files are processed one at a time.

What I've done to relieve the restore times is to not MIGRATE the disk
pools until the end of the day. That way restoring from last night is
quick. I had a client where they wanted CACHE=YES on a 60GB disk pool.
The offsite copypool reclamation ran for 2-days! Changed it so that
migration started at 5:00pm and nobody complained about restore times.

Bill Boyer
DSS, Inc.