Make sure that none of the 'primary' pool for the data on the offsite volumes are in a DISK storage pool. Especially the target of the DIRMC mgmtclass and then copying this data into the offsite pool with the rest of the data. This is a 'feature', 'working as designed' in the reclamation processes that if the primary copy of the data is on a DISK random-access storage pool, then the file(s) are processed 1 at a time and each file is a transaction. None of the MOVEBATCHSIZE stuff for this process... Do you maybe have CACHE=YES for the disk storage pool(s)? Even though the data has been migrated to onsite tape pool, the most primary copy of the data still could reside in the disk storage pool. For the whole MOVEBATSIZE-stuff to work, the primary copy needs to be on a sequetial storage pool.
Also, what are you using to control the offsite volume movement? Offsite volumes won't go back to SCRATCH until you update their access from OFFSITE. Until then they stay PENDING. Another misconception is that setting the RECLAMMATION threshold back high does not actually stop the currently running reclamation process. For onsite pools, when the current reclamation task ends, no new reclamation tasks should start back up, especially if you put it back to 100%. For offsite, since the reclamation task is doing all volumes that were identified when the process started, it will run to completion...whenever that is. If you want to actually stop reclamation, set the RECLAIM= back to 100% ( of just higher than any volumes' reclamation %) and then cancel the process. Bill Boyer DSS, Inc. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Miles Purdy Sent: Thursday, June 13, 2002 9:37 AM To: [EMAIL PROTECTED] Subject: Re: Slow Reclamation - And a need for speed... Also make sure that: 1. you are NOT using 'collocation' on your COPYPOOL. 2. check the 'Delay Period for Volume Reuse' 3. run expire inventory 4. Define two admin schedules to control reclamation. One to start, one to stop. But set the 'stop' to 99%. I'd set the 'start' to at least 75% - ie. 4 to 1. ex: tsm: UNXR>q stg offsite f=d Storage Pool Name: OFFSITE Storage Pool Type: Copy Device Class Name: 3580 Estimated Capacity (MB): 92 287 026.6 Pct Util: 2.8 Pct Migr: Pct Logical: 98.5 High Mig Pct: Low Mig Pct: Migration Delay: Migration Continue: Migration Processes: Next Storage Pool: Reclaim Storage Pool: Maximum Size Threshold: Access: Read/Write Description: Nisa Offsite Copy Storage Pool Overflow Location: Cache Migrated Files?: Collocate: No Reclamation Threshold: 99 Maximum Scratch Volumes Allowed: 500 Delay Period for Volume Reuse: 1 Day(s) Migration in Progress?: Amount Migrated (MB): Elapsed Migration Time (seconds): Reclamation in Progress?: No Volume Being Migrated/Reclaimed: Last Update by (administrator): PURDYM Last Update Date/Time: 06/12/02 14:00:23 Storage Pool Data Format: Native tsm: UNXR>q sched EXPIRE_INVENTORY t=a f=d Schedule Name: EXPIRE_INVENTORY Description: Expire server objects which are older than retention period Command: expire inventory du=100 Priority: 2 Start Date/Time: 03/06/02 10:15:00 Duration: 5 Minute(s) Period: 1 Day(s) Day of Week: Weekday Expiration: Active?: Yes Last Update by (administrator): PURDYM Last Update Date/Time: 03/08/02 11:06:43 Managing profile: tsm: UNXR>q sched START_RECLAIM_OFFSITE t=a f=d Schedule Name: START_RECLAIM_OFFSITE Description: Reclaim tape space that expire inventory has created Command: upd stg offsite reclaim=89 Priority: 4 Start Date/Time: 03/06/02 12:00:00 Duration: 60 Minute(s) Period: 1 Day(s) Day of Week: Weekday Expiration: Active?: Yes Last Update by (administrator): PURDYM Last Update Date/Time: 06/10/02 11:53:34 Managing profile: tsm: UNXR>q sched RESET_RECLAIM_OFFSITE t=a f=d Schedule Name: RESET_RECLAIM_OFFSITE Description: Reset reclaim value Command: upd stg offsite reclaim=99 Priority: 3 Start Date/Time: 01/04/00 14:00:00 Duration: 5 Minute(s) Period: 1 Day(s) Day of Week: Weekday Expiration: Active?: Yes Last Update by (administrator): PURDYM Last Update Date/Time: 02/19/02 14:25:50 Managing profile: Miles ---------------------------------------------------------------------------- ------------------ Miles Purdy System Manager Farm Income Programs Directorate Winnipeg, MB, CA [EMAIL PROTECTED] ph: (204) 984-1602 fax: (204) 983-7557 "If you hold a UNIX shell up to your ear, can you hear the C?" ---------------------------------------------------------------------------- --------------------- >>> [EMAIL PROTECTED] 06/11/02 03:33PM >>> TSM 4.1.3 on NT 4, 2 LTO drives in IBM 18 tape library. Single SCSI chain. We run reclamation what seems like all day every day, but tapes don't seem to free up in a timely manner. And our offsite tapes are 'growing'. We have been using TSM for about a year with 60 day retention, and have only added two (small) clients in the last 2 months. The pool for onsite TAPEPOOL (that stays in the library) and COPYPOOL that goes off site. The number of tapes in the COPYPOOL (offsite) seem to be growing greater than what would seem reasonable given the size of the TAPEPOOL. Lately I have stopped reclamation and done a 'move data' of some of the lowest use volumes that are offsite, and now they are marked 'pending'. Our current schedule is: Weekdays 1300 till 2000 - update stgpool COPYPOOL rec=20 Weekdays 0900 till 1300 - update stgpool TAPEPOOL rec=10 Saturday 0800 till 2000 - update stgpool TAPEPOOL rec=10 Sunday 0800 till 2200 - update stgpool COPYPOOL rec=20 Would it be a good idea to up the recovery percent? Should I possibly do copypool on MWF from 0900-2000 then tapedata on TTh instead of some on each day? Suggestions? TIA .. JC "MMS <health-first.org>" made the following annotations on 06/11/02 16:27:04 ---------------------------------------------------------------------------- -- This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ============================================================================ ==
