How to free up TSM tapes.
 |
 |
 |
|
 |
|
 |
TSM - Freeing up Old Tapes
Reuse delay
Tape Mount and Dismount issues
maxscratch parameter
How to query # scratch tapes
TSM thinks a tape contains data, but it is empty
Altering the MOUNTABLE state
Running Expire Inventory and Reclamation
Its not unusual for TSM to run out of tapes because of the way it is engineered. That can make it vital that tapes are returned to the 'scratch pool' for reuse quickly. So why does TSM seem to hang on to empty tapes?
Reuse delay
If a tape has no active files left on it, but it still does not become scratch then the ussue might be the reusedelay parm on the copystoragepool.
A tape is not necessarily released for scratch straight away. Imagine the worst has happened, you've had a disaster and have had to restore your database back 48 hours. If tapes have been reused in the past 48 hours, then the database will not be accurate, data will be missing. To prevent this, you have a parameter called REUsedelay. This specifies the number of days that must elapse after all files are deleted from a volume before the volume can be rewritten or returned to the scratch pool. The default value for this is 0, but it may have been set to 5, say, to avoid problems with database rollback. That's one reason why tapes do not get recycled quickly.
Tape Mount and Dismount issues
TSM will keep adding data to a 'filling' tape until it is full. However, it will sometimes mount a scratch tape even if there is a 'filling' tape available for that node. This is because TSM will not wait for a tape that is currently dismounting. The logic is that it is faster to ask for a new scratch tape than to wait while a filling tape is dismounted, stored, retrieved then remounted. There is no easy answer to this feature, except to juggle your KEEPMP and MOUNTRetention values to minimise the risk.
Maxscratch parameter
The name of parameter can be a bit confusing, as it limits the total number of tapes that a storage pool can contain, not the total number of scratch tapes. If your tape pool processing starts failing with insufficient space errors, then one cause can be that the maxscratch limit has been reached. You may have plenty of scratch tapes in your library, but TSM will not use them. The maxscratch sets the maximum number of volumes that can be used by each storage pool.
How to find out how many scratch tapes exist
The q vol command will only give you information about storage pool volumes, and so does not report on scratch volumes as they are not associated with s storage pool. You need to use the following SQL
select count(*) as Scratch_count from libvolumes where status='Scratch'
TSM thinks a tape contains data, but it is empty
You have a CopyPool volume, which is EMPTY and OFFSITE, but the tape does not change to scratch as normal. You cannot move the data off the tape because it is empty. You cannot delete the tape, because it contains data, not even with the discard data option. The tape needs to be audited, but to do this it must be on-site. recall the tape to your site and run an 'AUDit Volume VolName Fix=Yes'.
Altering the MOUNTABLE state
A volume is empty, but is not in scratch status because the volume STATE is mountablenotinlib. To change the STATE of the volume use the command
MOVE MED vol_name STG=pool_name WHERESTATE=MOUNTABLENOTINLIB
This will move the volume back into the scratch category
Running Expire Inventory and Reclamation
Expire Inventory deletes unwanted backups from the TSM catalog and marks the backups on tape as expired. Its best to run expire inventory daily. Once the data is expired, then reclamation can release partly used tapes. To do this, schedule the following command
EXPIRE INVENTORY
Its best to do run expire inventory at a time when no, or few backups are running, as it waits when it hits a filespace that is being backed up, and will hold onto the recovery log, which can cause the log to fill up. You also want to avoid running EXPIRE INVENTORY alongside your TSM database backups.
EXPIRE INVENTORY has two undocumented and unsupported parameters, BEGINNODEID=nn and ENDNODEID=nn where nn are decimal node numbers. These can be used to limit the amount of work the process does but please note, these parameters are UNSUPPORTED, you use them at your own risk.
The only really good reason to run a limited EXPIRE INVENTORY is if you've just deleted lots of data from a node and would like to get it deleted quickly from the database. The problem is that you need to find out the node number of the filespace you just deleted the data from.
The only way I know is to use undocumented SHOW commands. You need
to start with the object number for the NODE table, then drill down
the b-tree to find the Node number of the file space that you are after.
Start by using SHOW OBJDIR to find the node number of the Nodes table.
This is normally 38.
Then use SHOW NODE 38 to see the top level tree structure of the NODE table.
SHOW NODE 38 (SERVVM57) <- Subtree=<8344593> Record 9 (KeyLen=9, DataLen=4):
Then finally do a SHOW NODE number for the subtree that contains the node you
are interest in.
In the SHOW NODE against the subkeys, the KEY is the NODE_NAME. Field 1 is the node number and field2 is PLATFORM_NAME.
SHOW NODE 8344593
Key:
->(SERVVM3V)<-
Data: ->(00000134)(WinNT)(plus lots more fields..)
So from that you see the the client node that you are interested in, SERVVM3V
has a node number of 134.
Roger Deschner has pointed out an error in the original text of this
page 'The node numbers you get out of the database with the SHOW NODE
command are in hexadecimal. However, the node numbers you specify on
the EXPIRE INVENTORY command must be decimal. You've got to convert
them from hex to decimal yourself. To expire node SERVVM3V you must
specify node number 308 (decimal), rather than 134 (hex)'.
So using the correct decimal number, to just expire data from that node you would use the command
EXPIRE INVENTORY BEGINNODEID=308 ENDNODEID=308
You should always use the CANCEL EXPIRATION command to cancel expire inventory, as that will terminate the command cleanly. Next time you run the transaction, it will start up from where it left off. If you want to start expiration again from the beginning use EXPIRE INVENTORY RESTART=NO.
Reclamation copies half empty tapes onto empty new tapes to consolidate the data and free up tapes. You probably want to control the times when reclamation can run, as it will use 2 tape drives. Schedule command
UPD STG cartpool RECLAIM=40
to start it, and switch it off again with
UPD STG cartpool RECLAIM=100
If you run command Q VOL F=D, this will show how many tapes have reclaimable space of 40% or more, and will be processed. The numbers on this command don't necessarily add up. Estimated Capacity (MB) shows what is the apparent full capacity of this tape devclass. This may be much lower than what can actually be put on tape. Pct Util shows how much of that estimated capacity is currently used. Pct. Reclaimable space shows how much of the space that was occupied by data is now free, not the percent of the ACTUAL capacity of the tape that is free.
Estimated Capacity (MB): 18,499.6
Pct Util: 47.9
Volume Status: Full
Access: Read/Write
Pct. Reclaimable Space: 54.0