After I received this message, I started investigating my TSM server tape
utilization.
I have to agree that I think this should be called a "bug" not WAD.
I found 128 tapes in FILLING status when I only have 80-nodes (of which 15
go to a non-collocated pool).
Since yesterday, I have been checking every tape in FILLING status, only
to find dozens that are barely used (< 5%) and haven't been used in many
months. I have started randomly picking these tapes and performing MOVE
DATA on them, to the same stgpool.
I have gone from 128 to 99 tape in FILLING status, this morning and am
still checking/moving data !
I am not going to press this issue since my server is a little behind
(z/OS 5.1.8.3) and will be updating to the latest, soon, hopefully finding
something along the way that will adress this issue !
"Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
09/27/2004 10:23 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
Re: Weird tape utilization (the story continues...)
About two weeks ago I asked on this list how TSM could have more than one
filling tape for a collocated node. We indeed discovered that when TSM
cannot append to an existing filling tape ((during migration, because the
client is backing up directly to that tape or because a client restore is
running) TSM will allocate a new tape and it will not use the 'old'
filling
tape anymore. Even when the new one is full, it will not continue to use
the
'old' filling one.
Well, I have tried convincing IBM support that this is a bug, but I keep
on
receiving the answer that this behavior is 'working as designed'.
So, although you think you have an automated backup application, you will
have to monitor it periodically, because you will waist perfectly good
tapes, which will hang around in you system forever (or at least until ALL
files on it expire, which can take a VERY long time.
The SQL statement Neil created (below) will certainly be useful in this
situation.
Thank you all for your help!
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines
-----Original Message-----
From: neil.schofield AT yorkshirewater.co DOT uk
[mailto:neil.schofield AT yorkshirewater.co DOT uk]
Sent: Wednesday, September 08, 2004 22:58
To: ADSM-L AT vm.marist DOT edu
Cc: Loon, E.J. van - SPLXM
Subject: Re: Weird tape utilization
Eric
Good luck with your PMR. In the meantime, below is a script that I wrote
when I realised that we were suffering the "tape leak" that Richard
describes.
It works on the premise that with collocation turned on, there should only
be one filling read-write volume in each storage pool per node/filespace.
The select statements list the filling volumes by node for each storage
pool collocated by node, and the filling volumes by filespace for each
storage pool collocated by filespace. Each node/filespace should be listed
only once per storage pool in the output. Scan down the output and if a
node/filespace appears more than once it means you are using more tapes
than necessary.
In this case, pick one of the volumes (ideally the least utilised), update
its access-mode to read-only and issue a MOVE DATA on it. You should see
one of the other filling volumes listed be mounted as the destination.
I usually run the script once a month or so. It may take a while, but is
worth it for the tapes you get back. Now if only TSM could take care of
this itself ...
Regards
Neil Schofield
Yorkshire Water Services Ltd.
select volumeusage.node_name, volumeusage.stgpool_name,
volumeusage.volume_name from volumeusage, volumes where
volumeusage.volume_name=volumes.volume_name and volumes.status='FILLING'
and volumes.access='READWRITE' and volumeusage.stgpool_name in (select
stgpool_name from stgpools where collocate='YES') group by
volumeusage.node_name, volumeusage.stgpool_name, volumeusage.volume_name
order by stgpool_name
select volumeusage.node_Name, volumeusage.filespace_name,
volumeusage.stgpool_name, volumeusage.volume_name from volumeusage,
volumes
where volumeusage.volume_name=volumes.volume_name and volumes.status
='FILLING' and volumes.access='READWRITE' and volumeusage.stgpool_name in
(select stgpool_name from stgpools where collocate='FILESPACE') group by
volumeusage.node_name, volumeusage.filespace_name,
volumeusage.stgpool_name, volumeusage.volume_name order by stgpool_name
Find out about our new Icytonic drink at http://www.yorkshirewater.com
The information in this e-mail is confidential and may also be legally
privileged. The contents are intended for recipient only and are subject
to the legal notice available at http://www.keldagroup.com/email.htm
Yorkshire Water Services Limited
Registered Office Western House Halifax Road Bradford BD6 2SZ
Registered in England and Wales No 2366682
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee only. If
you are not the addressee, you are notified that no part of the e-mail or
any attachment may be disclosed, copied or distributed, and that any other
action related to this e-mail or attachment is strictly prohibited, and
may be unlawful. If you have received this e-mail by error, please notify
the sender immediately by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission
of this e-mail or any attachments, nor responsible for any delay in
receipt.
**********************************************************************
|
