John Thanks, First, I checked the log and found that at times Reclamation has failed due to being preempted by a higher priority operation. Recently, I believed it failed due to a server database deadlock situation. We are scheduling when reclamation using the administrative schedule, But I noticed that the turn off reclaim schedule was inactive on both pools so your right Reclamation was running almost all the time set to 30. I activated both Storage pools turn off reclaim schedules the other day and noticed that the Volume Reclamation warnings went from 47 yesterday down to 18 this morning. As for setting the reclaim threshold to 50 or higher I am checking on that, I believe at one time it was set higher but we decided to lower it.
Tim Sorry if this partial activity log comes out looking hard to read I tried to adjust it several times so it would look somewhat presentable. ANR1441I Volume C00081 is in use. Process 1095 being preempted by higher priority operation.(SESSION: 145235, PROCESS: 1075) 11/18/06 21:36:01 ANR0986I Process 1095 for SPACE RECLAMATION running in the BACKGROUND processed 22591 items for a total of 138,680,320,263 bytes with a completion state of FAILURE at 21:36:01.(PROCESS: 1095) ANR0379W A server database deadlock situation has been encountered; the lock request for the df bitfile root lock, will be denied to resolve the deadlock. ANR2183W afmove.c(5267): Transaction 0:332333810 was aborted.(PROCESS: 1673) ANR1093E Space reclamation is ended for volume C00149. The transaction is ended.(PROCESS: 1673) ANR0986I Process 1673 for SPACE RECLAMATION running in the BACKGROUND processed 63311 items for a total of 36,161,800,216 bytes with a completion state of FAILURE at 09:08:03.(PROCESS: 1673) 11/29/06 09:08:03 ANR4936I Reclamation of storage pool H3592POOL has ended. Files reclaimed: 187980, Bytes reclaimed: 227772188417, Files reconstructed: 260184, Unreadable files: 0 John Monahan wrote:
First, your reclamation threshold should be set to 50 or higher so two tapes can be reclaimed to one. You might be running reclamation almost all the time with it set to 30 and just wasting tape cycles. You also need to have scratch tapes available for reclamation to be successful. If you post the activity log entries at the time the reclamation is failing, we might be able to tell you why. I tend to prefer setting the reclamation threshold to 100 and then scheduling when reclamation occurs by using an administrative schedule. In the admin schedule either lower the reclamation threshold or use the "reclaim stgpool" command. To see the tapes that are triggering that TOR alert, run this query: select volume_name, stgpool_name, pct_utilized, status, access, pct_reclaim from volumes where (status='FULL') AND (pct_utilized<48) order by pct_reclaim desc ______________________________ John Monahan Consultant Infrastructure Solutions Group Computech Resources, Inc., a Logicalis Company Office: 952-833-0930 ext 109 Cell: 952-221-6938 http://www.computechresources.com http://us.logicalis.com Timothy Hughes <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[email protected]> 11/29/2006 09:54 AM Please respond to "ADSM: Dist Stor Manager" <[email protected]> To [email protected] cc Subject [Fwd: Volume Reclamation warning:] I have checked the log and seen a few failures on reclamation also I noticed that the failures are occurring on the the Primay pool volumes only. This morning reclamation failed without showing a reason in the TSM log. It started up again a couple minutes later. Sequential Access Storage Pools : H3592POOL Storage Pool Name H3592POOL Storage Pool Type PRIMARY Device Class Name 3592CLASS Estimated Capacity 352210838.0 Space Trigger Util - Pct Util 27.8 Pct Migr 36.6 Pct Logical 99.5 High Mig Pct 90 Low Mig Pct 70 Migration Processes 1 Next Storage Pool - Maximum Size Threshold - Access READWRITE Description Hub 3592 Tape Pool Overflow Location - Cache Migrated Files? - Collocate? NO Reclamation Threshold 30 Maximum Scratch Volumes Allowed 500 Number of Scratch Volumes Used 183 Delay Period for Volume Reuse 0 Migration in Progress? NO Amount Migrated (MB) 0.0 Elapsed Migration Time (seconds) 0 Reclamation in Progress? YES Last Update Date/Time 2006-11-29 07:10:13.000000 Last Update by (administrator) Reclaim Storage Pool - Migration Delay 0 Migration Continue YES Storage Pool Data Format Native Copy Storage Pool(s) R3592POOL Continue Copy on Error? YES CRC Data NO Reclamation Processes 1 Offsite Reclamation Limit - Reclamation Type THRESHOLD -------- Original Message -------- Subject: Volume Reclamation warning: Date: Wed, 29 Nov 2006 08:19:03 -0500 From: Timothy Hughes <[EMAIL PROTECTED]> To: ADSM: Dist Stor Manager <[email protected]> Hello all, I noticed in TSM reporter that the Volume Reclamation warning is at 47. Reclamation is active on both Storage Pools (Local and Remote) I know the Reporters SQL query is means (pct_utilized<48), But Reclamation has been working does anyone have any idea what could be the cause (s) of this warning? TSM 5.3.4 Thanks in Advance!
