TSM Virtual volumes

yampam

ADSM.ORG Member
Joined
Dec 19, 2006
Messages
101
Reaction score
0
Points
0
PREDATAR Control23

Hi all ,

We are using TSM 5.4 EE ,preforming DRM using virtal volumes .

I checked the size of the stgpool on the source server and on the target server by the following command :
select STGPOOL_NAME,SUM(EST_CAPACITY_MB*PCT_UTILIZED)/100 from volumes GROUP BY STGPOOL_NAME
on the source server I get that the capacity of the virtual stgpool is 32T
on the target server I get that the capacity of the stgpool is 45T???

1.Is my select is correct ?


2.I checked expiration on the source server -it's seems like it's working good,there is expiration of archive files,who can I know if the expired archives are the Virtual volumes ?

3.Who managed the expiration the source policy or by the target policy ? the backup policy or the arcive ? (the command is backup ,but in fact it's archive files ).

4.who expiration works for a client that is no longer backed up ?

If you read so far -it's really appreciated ,if you have an answer -thanks.
 
PREDATAR Control23

1. Yes, but. You're querying for the utilized size, not the total size. (I guess you know that, but you write something different in your post.)
If your target server does not store other data in that storage pool (it can), there may still be overhead, expired files, holes etc.. Do you reclaim the virtual volumes (from the source server) ?
2. I wouldn't know offhand.
3. The source server manages its data. The target server doesn't touch it. I'm not sure what you mean with your questions.
4. The server doesn't care. You'll be running out of days specified in Retain Extra/Only Versions rather than out of versions specified in Versions Data Exists/Deleted for inactive versions, so after long enough, you'll only have active versions stored. (Active versions are never expired.)

I suppose in questions 2 and 4 you mean how, not who. Your questions and remarks in 3 just confuse me. I realise English may not be your first language, but you have me wondering what you really mean. (English is not *my* first language either.)
 
PREDATAR Control23

Thanks JohanW,
The stgpool contain only DR data ,reclamation is working on the source server.
My problem is the difference between the virtual pool on the source server and the physical pool on the target server .What can couse the difference ?
 
PREDATAR Control23

Might be because of reclamation working a lot more effective on the source server (which sees volumes) than on the target server (which sees archived objects). Could you post the output of Q STGP <stgpool> F=D for the respective stgpools from the source and target servers?
 
PREDATAR Control23

Hi JohanW ,
I think is has nothing to do with reclamation becouse the output of the select above is the estimated capacity of the data .

the output of the Q STGP:
on the source server :
Storage Pool Name: source_COPYPOOL
Storage Pool Type: Copy
Device Class Name: source_CLASS
Estimated Capacity: 28,958,663 G
Space Trigger Util:
Pct Util: 0.1
Pct Migr:
Pct Logical: 99.9
High Mig Pct:
Low Mig Pct:
Migration Delay:
Migration Continue: Yes
Migration Processes:
Reclamation Processes: 1
Next Storage Pool:
Reclaim Storage Pool:
Maximum Size Threshold:
Access: Read/Write
Description:
Overflow Location:
Cache Migrated Files?:
Collocate?: No
Reclamation Threshold: 60
Offsite Reclamation Limit: No Limit
Maximum Scratch Volumes Allowed: 1,000,000
Number of Scratch Volumes Used: 1,350
Delay Period for Volume Reuse: 2 Day(s)
Migration in Progress?:
Amount Migrated (MB):
Elapsed Migration Time (seconds):
Reclamation in Progress?: Yes
Last Update by (administrator): AVI
Last Update Date/Time: 06/23/09 10:31:06
Storage Pool Data Format: Native
Copy Storage Pool(s):
Active Data Pool(s):
Continue Copy on Error?:
CRC Data: No
Reclamation Type: Threshold
Overwrite Data when Deleted:

On the target :

Storage Pool Name: TARGET_POOL
Storage Pool Type: Primary
Device Class Name: LTOCLASS3
Estimated Capacity: 7,841,357 G
Space Trigger Util:
Pct Util: 0.6
Pct Migr: 0.9
Pct Logical: 100.0
High Mig Pct: 100
Low Mig Pct: 0
Migration Delay: 0
Migration Continue: Yes
Migration Processes: 1
Reclamation Processes: 1
Next Storage Pool:
Reclaim Storage Pool:
Maximum Size Threshold: No Limit
Access: Read/Write
Description:
Overflow Location:
Cache Migrated Files?:
Collocate?: Group
Reclamation Threshold: 60
Offsite Reclamation Limit:
Maximum Scratch Volumes Allowed: 9,999
Number of Scratch Volumes Used: 87
Delay Period for Volume Reuse: 0 Day(s)
Migration in Progress?: No
Amount Migrated (MB): 0.00
Elapsed Migration Time (seconds): 0
Reclamation in Progress?: No
Last Update by (administrator): DUDU
Last Update Date/Time: 05/06/09 14:18:51
Storage Pool Data Format: Native
Copy Storage Pool(s):
Active Data Pool(s):
Continue Copy on Error?: Yes
CRC Data: No
Reclamation Type: Threshold
Overwrite Data when Deleted:
 
PREDATAR Control23

How many scratch tapes? :eek:

Could you update that to a little more realistic values, where %Util actually starts to mean something (and won't be rounded off to the point of introducing errors as large as the value itself), and post again?
 
PREDATAR Control23

Hi JohanW ,
Do you mean to update "Maximum Scratch Volumes Allowed: 9,999" ??what wrong with that ,it's the maximum value(we are using virtual volumes,it's a logical volume every backup is a virtual tape.)
How do I update the "Estimated Capacity" to realistic values??

For now I ignor "Estimated Capacity" ,and instead I ran the select that show me (hopefully)the "Estimated Capacity" .the two stgpool are actually the same one,the first one is a virtual and the second is the real volumes .why is there a diffrance between them ??
 
PREDATAR Control23

I said what's wrong with that: %Util is meaningless and may be off by 100%.

Your query did show allocated capacity. The storage pools are not the same, one is stored in the other, introducing a layer of overhead, indirection, however you look at it. This should not have to be 50% but will always be non-zero. For now I can't explain where that 13 TB went.
 
PREDATAR Control23

You're correct that reclamation should not enter into it. I still can't figure out where you discrepancy originates. If you don't get an answer here anytime soon, ask IBM (then post the answer here :)).
 
Top