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:[EMAIL PROTECTED]
