Today I took a closer look at how often and how much data is reclaimed and
migrated.

Since upgrade of on of our primary stgpool to 700 GByte  2 month ago we
could establish a migdelay of  8 days.
Together with our standard policy (1 active + 3 inactive and 60 days keep
for last deleted) we could reduce the migration amount from
100% to 30% of daily backup volume for that pool (120 small NT server):
(All nodes with name NT% go to BACKUPPOOL)

'select sum(bytes)/(1024*1024*1024) as GBYTE from adsm.summary where
activity = 'BACKUP' and entity like 'NT%' and end_time >= current_timestamp
- 14 days'
Result: 2188
'select sum(bytes)/(1024*1024*1024) as GBYTE from adsm.summary where
activity = 'MIGRATION' and entity = 'BACKUPPOOL' and end_time >=
current_timestamp - 14 days'
Result: 593

In the past these 2 values where the same for each day.... 

My next hope was that the reclamation for the nt nodes should also
significantly have been reduced.
But I could not find a really significant decrease - maybe I have to wait a
little longer for that process

But what I found was the following:   
I have from time to time reclamation processes that move more than 3 times
of the capacity of one 3590 tape !!!!!! i.e.
08/21/2003 11:43:21 ANR0986I Process 199 for SPACE RECLAMATION running in
the BACKGROUND processed 1 items for a total of 33.007.866.134 bytes with a
completion state of SUCCESS at 11:43:21.  

The reclamation process put 1 large file spread over 4 tapes onto 4 new
tapes and scratching the old ones. 
The reason seems to be the reaching of the reclamation threshold (80%) on
one of the 4 tapes. 

Has anyone similar problems? 
How can I avoid that the reclamation process keeps 2 units for hours?

Kind regards,

Stefan Holzwarth

----------------------------------------------------------------------------
--
Stefan Holzwarth
ADAC e.V. (Informationsverarbeitung - Systemtechnik - Basisdienste)
Am Westpark 8, 81373 München, Tel.: (089) 7676-5212, Fax: (089) 76768924
mailto:stefan.holzwarth AT adac DOT de