move data and reclamation

ammu440

ADSM.ORG Member
Joined
Aug 20, 2019
Messages
50
Reaction score
0
Points
0
PREDATAR Control23

Hi all,

I am trying to move data for the volumes, though it has some data on it, it always throws me warning. I have almost tried for many of the volumes and its same. I use IBM spectrum protect version 8.1.0
ANR2209W Volume contains no data
When I try to do reclamation it does not happen though and here is the warning.
RECLAIM STGPOOL: The storage pool is not a sequential-access pool.


Please suggest.
 
PREDATAR Control23

ANR2209W Volume contains no data
That would mean there's no data on the volume. How did you come to the determination that there is data on it?
RECLAIM STGPOOL: The storage pool is not a sequential-access pool.
As the message says, the pool is not sequential, sequential is tape or file device class pool. If you have a random disk pool or a directory container pool, those aren't sequential.

Why are you trying to move the data? What's the end goal? Might be able to help you better if we know what you are trying to achieve.
 
PREDATAR Control23

That would mean there's no data on the volume. How did you come to the determination that there is data on it?

I could see the percentage utilized, for ex: 2.414, 25.7 and so on. These volumes are not completely full.

As the message says, the pool is not sequential, sequential is tape or file device class pool. If you have a random disk pool or a directory container pool, those aren't sequential.

ok we have containerpool, then the reclamation does not work?

Why are you trying to move the data? What's the end goal? Might be able to help you better if we know what you are trying to achieve.

I want to increase the scratch tapes. so If i move the data, I can achieve with more scracth tapes as the space reclamation is not running in our environment.
we often face the below issue:

mount request denied: insufficent space in the destination storage pool.
 
PREDATAR Control23

I want to increase the scratch tapes. so If i move the data, I can achieve with more scracth tapes as the space reclamation is not running in our environment.
we often face the below issue:

mount request denied: insufficent space in the destination storage pool.

Also I see all the volumes are full, though its not 100 percent utilized.
 
PREDATAR Control23

To run reclamation, first you will need to run it against your tape pool, not a disk pool like you did earlier (disk pools are not seqeuential.).

You will also need 1 scratch tape to start reclamation, without 1 scratch tape, you can't do anything.

Tapes full but not 100% use is common, as data expires, it empties some space. However, when looking at full tapes, you have to pay more attention to percent reclaimable. If percent reclaimable is high, there's space to gain. If it's full with very little percent reclaimable, you have nothing to gain.

So, you need to get a scratch tape. Either you buy a new one, or free one up. You can do a MOVE DATA on a tape, but that will not work in the same pool if you don't have scratch tapes. So you would need to specify a different storage pool with enough space to hold that tape move date {volume_name} stgpool=target_pool.

If you can't do that, you will have to delete a tape. If you keep several days of database backups, you could potentially get rid of the last one, if you are comfortable with that. If you have export tapes you don't need anymore and/or backupset tapes you don't need anymore, you can delete those too. Check what you have:
query volhistory type=dbbackup query volhistory type=export query volhistory type=backupset

I the 3 above outputs, if there are dbbackups, exports or backupsets you are willing do delete, use the delete volhistory command to do that. For syntax: help delete volhistory
 
PREDATAR Control23

To run reclamation, first you will need to run it against your tape pool, not a disk pool like you did earlier (disk pools are not seqeuential.).

You will also need 1 scratch tape to start reclamation, without 1 scratch tape, you can't do anything.

Tapes full but not 100% use is common, as data expires, it empties some space. However, when looking at full tapes, you have to pay more attention to percent reclaimable. If percent reclaimable is high, there's space to gain. If it's full with very little percent reclaimable, you have nothing to gain.

So, you need to get a scratch tape. Either you buy a new one, or free one up. You can do a MOVE DATA on a tape, but that will not work in the same pool if you don't have scratch tapes. So you would need to specify a different storage pool with enough space to hold that tape move date {volume_name} stgpool=target_pool.

If you can't do that, you will have to delete a tape. If you keep several days of database backups, you could potentially get rid of the last one, if you are comfortable with that. If you have export tapes you don't need anymore and/or backupset tapes you don't need anymore, you can delete those too. Check what you have:
query volhistory type=dbbackup query volhistory type=export query volhistory type=backupset

I the 3 above outputs, if there are dbbackups, exports or backupsets you are willing do delete, use the delete volhistory command to do that. For syntax: help delete volhistory



I have ran a audit volume for some tapes and audit library, so i got new empty tapes. Is'nt it a good idea ? I cannot update these empty tapes to Scratch unfortunately
 
PREDATAR Control23

Either way, you should be able to start reclamation if you have 1 empty or scratch tape.
 
PREDATAR Control23

Either way, you should be able to start reclamation if you have 1 empty or scratch tape.

for ex: we have Primary and Copy pool. Primary is a "Container Pool" and Container copy is "tapepool". so now I have to start the reclamation with the "Primary" itself and move the data with in the "Primary"
 
PREDATAR Control23

we have Primary and Copy pool. Primary is a "Container Pool" and Container copy is "tapepool".
Oh oh. That changes everything. Forget everything I ever said in this thread, except the part where you need scratch tapes. This explains why the MOVE DATA and RECLAIM STGPOOL didn't work, those are for sequential pools only.

so now I have to start the reclamation with the "Primary" itself and move the data with in the "Primary"
Impossible to do on a directory container pool, but you can reclaim on the container copy pool, just not with the reclaim command.

The reclamation of a copy container pool is triggered by PROTECT STGPOOL. If you want to reclaim without running protect, you use RECLAIM=ONLY or RECLAIM=ONLYLIMITED. The differences between the 2 is explained in HELP PROTECT STGPOOL in this section: "Syntax when the target is a tape storage pool on the same server"
 
PREDATAR Control23

To run reclamation, first you will need to run it against your tape pool, not a disk pool like you did earlier (disk pools are not seqeuential.).

You will also need 1 scratch tape to start reclamation, without 1 scratch tape, you can't do anything.

Tapes full but not 100% use is common, as data expires, it empties some space. However, when looking at full tapes, you have to pay more attention to percent reclaimable. If percent reclaimable is high, there's space to gain. If it's full with very little percent reclaimable, you have nothing to gain.

So, you need to get a scratch tape. Either you buy a new one, or free one up. You can do a MOVE DATA on a tape, but that will not work in the same pool if you don't have scratch tapes. So you would need to specify a different storage pool with enough space to hold that tape move date {volume_name} stgpool=target_pool.

If you can't do that, you will have to delete a tape. If you keep several days of database backups, you could potentially get rid of the last one, if you are comfortable with that. If you have export tapes you don't need anymore and/or backupset tapes you don't need anymore, you can delete those too. Check what you have:
query volhistory type=dbbackup query volhistory type=export query volhistory type=backupset

I the 3 above outputs, if there are dbbackups, exports or backupsets you are willing do delete, use the delete volhistory command to do that. For syntax: help delete volhistory
Oh oh. That changes everything. Forget everything I ever said in this thread, except the part where you need scratch tapes. This explains why the MOVE DATA and RECLAIM STGPOOL didn't work, those are for sequential pools only.

Impossible to do on a directory container pool, but you can reclaim on the container copy pool, just not with the reclaim command.

The reclamation of a copy container pool is triggered by PROTECT STGPOOL. If you want to reclaim without running protect, you use RECLAIM=ONLY or RECLAIM=ONLYLIMITED. The differences between the 2 is explained in HELP PROTECT STGPOOL in this section: "Syntax when the target is a tape storage pool on the same server"

Thank you so much for the clarification. So here is the step to go

protect stgpool tapepool type=local reclaim=only
 
PREDATAR Control23

Hi,

For container pools, you can play around with move container and the option defrag=yes. You can play around with select like this:

Code:
select 'move container '||cast(CONTAINER_NAME as char(40))||' defrag=yes' from containers where STATE='AVAILABLE' and (CONTAINER_NAME like '/tsm/stg/0%' or CONTAINER_NAME like '/tsm/stg/1%')   order by TOTAL_SPACE_MB-FREE_SPACE_MB
 
PREDATAR Control23

I have ran a audit volume for some tapes and audit library, so i got new empty tapes. Is'nt it a good idea ? I cannot update these empty tapes to Scratch unfortunately
Hi,

For container pools, you can play around with move container and the option defrag=yes. You can play around with select like this:

Code:
select 'move container '||cast(CONTAINER_NAME as char(40))||' defrag=yes' from containers where STATE='AVAILABLE' and (CONTAINER_NAME like '/tsm/stg/0%' or CONTAINER_NAME like '/tsm/stg/1%')   order by TOTAL_SPACE_MB-FREE_SPACE_MB

When I ran this command, I got no match found.

I tried to run reclamation with the following command, But the process went success but i see still many volumes are full though its not full.
Code:
protect stgpool containerpool type=local reclaim=only
 
PREDATAR Control23

I tried to run reclamation with the following command, But the process went success but i see still many volumes are full though its not full.
It's not reclaiming ALL volumes. A FULL volume doesn't automatically qualify for reclamation, there needs to be reclaimable space on it and the percent of reclaimable space has to be greater than the RECLAIM threshold of the pool.

1 - What's the RECLAIM set at for your Container Copy Pool?
2 - Are there volumes in your Container Copy Pool with a Pct Reclaim > RECLAIM?

Also make sure you are running 8.1.9.300 of the server, there has been a few APARs about local protect reclamation over the last couple of years.
 
PREDATAR Control23

It's not reclaiming ALL volumes. A FULL volume doesn't automatically qualify for reclamation, there needs to be reclaimable space on it and the percent of reclaimable space has to be greater than the RECLAIM threshold of the pool.

1 - What's the RECLAIM set at for your Container Copy Pool?

Reclaim Volume Limit is set to "No Limit"

2 - Are there volumes in your Container Copy Pool with a Pct Reclaim > RECLAIM?

PctReclaim is 7.53 [/QUOTE]
Storage Pool Name: PROTECTPOOL
Storage Pool Type: Copy Container
Storage Type: DEVCLASS
Cloud Type:
Cloud URL:
Cloud Identity:
Cloud Location:
Estimated Capacity: 87,992.21 G
Space Trigger Util:
Pct Util: 7.53
Pct Migr:
Pct Logical:
High Mig Pct:
Low Mig Pct:
Migration Delay:
Migration Continue:
Migration Processes:
Reclamation Processes:
Next Storage Pool:
Reclaim Storage Pool:
Maximum Size Threshold:
Access: Read/Write
Description:
Overflow Location:
Cache Migrated Files?:
Collocate?:
Reclamation Threshold: 100
Offsite Reclamation Limit:
Maximum Scratch Volumes Allowed: 35
Number of Scratch Volumes Used: 33
Delay Period for Volume Reuse: 3 Day(s)
Migration in Progress?:
Amount Migrated (MB):
Elapsed Migration Time (seconds):
Reclamation in Progress?:
Last Update by (administrator): TSMADMIN
Last Update Date/Time: 2020-06-09, 10:52:02
Storage Pool Data Format: Native
Copy Storage Pool(s):
Active Data Pool(s):
Continue Copy on Error?:
CRC Data:
Reclamation Type:
Overwrite Data when Deleted:
Deduplicate Data?: No
Processes For Identifying Duplicates:
Compressed:
Additional space for protected data:
Total Unused Pending Space:
Deduplication Savings:
Compression Savings:
Total Space Saved:
Auto-copy Mode:
Contains Data Deduplicated by Client?:
Maximum Simultaneous Writers:
Protect Processes: 1
Protection Storage Pool:
Protect Local Storage Pool(s):
Reclamation Volume Limit: No Limit
Date of Last Protection to Remote Pool:
Date of Last Protection to Local Pool:
Deduplicate Requires Backup?:



Also make sure you are running 8.1.9.300 of the server, there has been a few APARs about local protect reclamation over the last couple of years.[/QUOTE]

Yes, I have to apply a fixpack.
 
PREDATAR Control23

1 - What's the RECLAIM/"Reclamation Threshold" set at for your Container Copy Pool?
2 - Are there volumes in your Container Copy Pool with a Pct Reclaim > RECLAIM?
 
PREDATAR Control23

ammu440,
Please read the doc marclant posted above regarding how to update the container-copy pools. :)

From the output of your message above his, it seems your Reclamation Threshold for your container-copy pool is set at 100. Also, appears that when you do run a reclaim, you will not see those volumes return to scratch until three days later.

The settings I'm looking at are:

Reclamation Threshold: 100
Offsite Reclamation Limit:
Maximum Scratch Volumes Allowed: 35
Number of Scratch Volumes Used: 33
Delay Period for Volume Reuse: 3 Day(s)

So, the value 100 says that volumes in this storage pool are not reclaimed. The general rule of thumb is to have this setting higher than 50, and at or lower than 85. This way you get two tapes for every one filled with the reclaim process. Again, it will take 3 days for those volume to return to scratch tapes based on the 'Delay Period for Volume Reuse' setting. The 'best practice' is not to return tapes to scratch until your oldest database backup is deleted. Just in case you need to restore your database back to a point in time. I know, that will go into a deeper discussion, but it is something you must take into consideration. I understand that you may wish to have scratch tapes right away, so you should update that value to whatever you feel comfortable with (Value of 0 will return to scratch almost immediately). Just remember if you have to change it, set it back to what your db2 database/DRM retention is.

Here's a little query that will help you determine what volumes you could reclaim based on the pct_reclaim. You will need to modify it to fit your environment and I will point you where :)

select volume_name,pct_reclaim from volumes where scratch='YES' and stgpool_name='PROTECTPOOL' and volume_name like '%VOLNAMELIKEHERE' and pct_reclaim>VALUEHERE order by pct_reclaim desc

So you will need to replace VOLNAMELIKEHERE with how your tapes are labeled (Hopefully with a common naming format, in my environment every tape has the type appended to it, like xxxxxL6 = LTO6, so I can use the statement like '%L6' ) and VALUEHERE by a percentage, say 85 for example, so you will see below pct_reclaim>85 . I went ahead and filled in your stgpool_name with the name listed above. If different, then you will need to modify 'PROTECTPOOL' as well.

In my environment, this is what I run and results:
Code:
select volume_name, pct_reclaim from volumes where scratch='YES' and stgpool_name='STGPOOLNAME' and volume_name like '%L6' and pct_reclaim>85 order by pct_reclaim desc

VOLUME_NAME: xxxxx1L6
PCT_RECLAIM: 100.0

VOLUME_NAME: xxxxx2L6
PCT_RECLAIM: 89.5

VOLUME_NAME: xxxxx3L6
PCT_RECLAIM: 89.1

So, those volumes above are 100% reclaimable, and 89% reclaimable or 11% used depending on how you look at it.

You will need at least one scratch tape free to reclaim that data. Here's a query for scratch tapes:
SELECT library_name,COUNT(*) FROM libvolumes WHERE status='Scratch' and volume_name like '%L6' GROUP BY library_name
Again, replace L6 with your common tape naming convention.

My ask if you could:
  1. Please let us know how many tape drives you have.
  2. Output of the query I provided with modifications to fit your environment, and with the reclaim_pct>51 so we may see what we are working with.
  3. Output of scratch volume query with modifications to fit your environment, so we know how many scratch tapes you have.
My concern is if you try to run a reclaim at 51%, and only have a few scratch tapes, and all tapes are half used; Your reclaim process could run a LONG time then run out of scratch tapes. That would affect your daily protect process. Chain of unintended consequences is what I'm looking to avoid.
My recommendation would be start small and slowly lower the reclaim threshold. As you can see, I chose 85, and it only had 3 tapes. If I ran the reclaim process at say 75 then that's nearly 40 tapes for me! Yes, there are other ways to limit the amount of tapes to be reclaimed with each protect process, but I'm trying to keep it simple for now.

Marclant,
I'm a bit fuzzy on this however, in the off chance ammu440 only has one tape drive, the reclaim process for container-copy's don't read data from tape right? its just reseeding data from the disk directory-container pool, so we can get away with a single tape drive?

Hope I didn't leave anything out, and hope this helps!
 
PREDATAR Control23

Thank you so much for the clear explanation RecoveryOne.
We have 3 Tape drives
  1. Output of the query I provided with modifications to fit your environment, and with the reclaim_pct>51 so we may see what we are working with.
Code:
 with Pct>51, I dont have any output but with 85 I got below.

xxxxxxL6    99
xxxxxxL6    99
xxxxxxL6    98.7
xxxxxxL6    98.6
xxxxxxL6    98.5
xxxxxxL6    98.5
xxxxxxL6    98.4
xxxxxxL6    98.1
xxxxxxL6    92.7
xxxxxxL6    91.4
xxxxxxL6    90
xxxxxxL6    89.1
xxxxxxL6    88.8
xxxxxxL6    87.7
[LIST=1]

[*]Output of scratch volume query with modifications to fit your environment, so we know how many scratch tapes you have.
[/LIST]
Code:
   we have 5 scratch tapes
 
Top