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 <Timothy.Hughes AT OIT.STATE.NJ DOT US>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
11/29/2006 09:54 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To
ADSM-L AT VM.MARIST DOT EDU
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 <timothy.hughes AT oit.state.nj DOT us>
To: ADSM: Dist Stor Manager <ADSM-L AT VM.MARIST DOT EDU>
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!
|
