icewalker
ADSM.ORG Member
I'm having a problem with the storage amounts and utilization. More detail below. Messy I know, I apologize, I'm trying to get it all cleaned up. Please, somebody explain the problem here:
q stg
q stg backuppool f=d
q devclass bvtape f=d
A Nice query to show logical MB and Num Files
And a query to show the percent utilization
What Gives? Basically, I'm worried about that 80.2 Percent Utilization on the BACKUPPOOL. If you haven't guessed, we are storing the BACKUPPOOL as a FILE Devclass on a Deduplication device which is mirrored across a WAN to a colo site. We are at 38% utilization on the Dedup which has 5 TB of Raw Storage. At this time, it is deduping 19TB of data.
Anyway, the estimated capacity of the backuppool storage pool doesn't seem to "jive" with any other numbers. Since I have a maxscratch of 5000 and I'm only using 1298 volumes at 10Gig each, I would expect a utilization of 26%. With 62% of the Dedup available, I really don't want to hit that 90% utilization migration threshold anytime soon but at the rate we backup, if it truly thinks we are 80%, it may migrate much to my displeasure.
So would this have anything to do with out the Dedup relays it's raw storage to TSM. The OS sees a 5TB partition. So, I'm guessing that TSM may be just as confused as I am, that it sees that I have 5TB of storage that is at 38% utilization, but that the storage pool, which contains 1298 volumes has somehow stored far more data than the partition should allow? Is that why it is confused?
Is anybody else confused? Man I wish we had opted for the VTL on this thing.
Thanks
James
q stg
Code:
Storage Device Estimated Pct Pct High Low Next Stora-
Pool Name Class Name Capacity Util Migr Mig Mig ge Pool
Pct Pct
----------- ---------- ---------- ----- ----- ---- --- -----------
ARCHIVEPOOL AVTAPE 2,557 G 30.2 30.2 90 40 ARCHIVETAP-
EPOOL
ARCHIVETAP- LTOCLASS3 555,745 G 1.1 1.7 100 70
EPOOL
BACKUPPOOL BVTAPE 15,659 G 80.2 80.2 90 40 BACKUPTAPE-
POOL
BACKUPTAPE- LTOCLASS3 784,783 G 1.7 3.5 100 70
POOL
COPYPOOL1 LTOCLASS3 754,845 G 6.3
COPYPOOL2 LTOCLASS3 761,310 G 4.6
COPYPOOL3 TESTTAPE 0.0 M 0.0
DEDUPPOOL FILE_CLAS- 0.0 M 0.0 100.0 90 70
S_2
DISKPOOL DISK 0.0 M 0.0 0.0 90 70 LTOPOOL1
DOMINOPOOL DVTAPE 5,022 G 38.4 38.4 90 40 DOMINOTAPE-
POOL
DOMINOTAPE- LTOCLASS3 5,992,275 0.0 0.1 100 70
more... (<ENTER> to continue, 'C' to cancel)
POOL G
ECMPOOL DISK 20 G 0.0 0.0 80 40 ECMTAPEPOOL
ECMTAPEPOOL LTOCLASS3 0.0 M 0.0 0.0 100 70
LTOPOOL1 LTOCLASS3 0.0 M 0.0 0.0 100 70
SPACEMGPOOL DISK 0.0 M 0.0 0.0 90 70
SQLPOOL SVTAPE 3,071 G 25.6 25.6 90 40 SQLTAPEPOOL
SQLTAPEPOOL LTOCLASS3 8,594,855 0.1 0.1 100 70
G
VMWAREPOOL VVTAPE 0.0 M 0.0 100.0 90 40 VMWARETAPE-
POOL
VMWARETAPE- LTOCLASS3 540,707 G 0.8 1.2 100 70
POOL
Code:
Storage Pool Name: BACKUPPOOL
Storage Pool Type: Primary
Device Class Name: BVTAPE
Estimated Capacity: 15,659 G
Space Trigger Util: 94.8
Pct Util: 80.2
Pct Migr: 80.2
Pct Logical: 99.9
High Mig Pct: 90
Low Mig Pct: 40
Migration Delay: 0
Migration Continue: Yes
Migration Processes: 1
Reclamation Processes: 1
Next Storage Pool: BACKUPTAPEPOOL
Reclaim Storage Pool:
Maximum Size Threshold: No Limit
Access: Read/Write
Description: Primary Sequential Backup Storage Pool on the
DDR. Uses devclass bvtape
Overflow Location:
Cache Migrated Files?:
Collocate?: No
Reclamation Threshold: 80
Offsite Reclamation Limit:
Maximum Scratch Volumes Allowed: 5,000
Number of Scratch Volumes Used: 1,298
Delay Period for Volume Reuse: 1 Day(s)
Migration in Progress?: No
Amount Migrated (MB): 0.00
Elapsed Migration Time (seconds): 0
Reclamation in Progress?: No
Last Update by (administrator): ADMJJB
Last Update Date/Time: 2009-03-18 12:40:44
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:
Code:
Device Class Name: BVTAPE
Device Access Strategy: Sequential
Storage Pool Count: 1
Device Type: FILE
Format: DRIVE
Est/Max Capacity (MB): 10,240.0
Mount Limit: 20
Mount Wait (min):
Mount Retention (min):
Label Prefix:
Drive Letter:
Library:
Directory: \\DDR\BACKUP\TSMDATA\R0B-TSMP01\BACKUP
Server Name:
Retry Period:
Retry Interval:
Twosided:
Shared:
High-level Address:
Minimum Capacity:
WORM: No
Drive Encryption:
Scaled Capacity:
Last Update by (administrator): ADMJJB
Last Update Date/Time: 2009-03-18 12:53:26
Code:
SELECT stgpool_name,SUM(logical_mb)AS Logical_MB,SUM(num_files)AS Num_Files FROM occupancy WHERE stgpool_name='BACKUPPOOL' GROUP BY stgpool_name
STGPOOL_NAME LOGICAL_MB NUM_FILES
------------------ --------------------------------- -----------
BACKUPPOOL 12556761.92 5502914
Code:
SELECT pct_utilized FROM stgpools WHERE stgpool_name='BACKUPPOOL'
PCT_UTILIZED
------------
80.2What Gives? Basically, I'm worried about that 80.2 Percent Utilization on the BACKUPPOOL. If you haven't guessed, we are storing the BACKUPPOOL as a FILE Devclass on a Deduplication device which is mirrored across a WAN to a colo site. We are at 38% utilization on the Dedup which has 5 TB of Raw Storage. At this time, it is deduping 19TB of data.
Anyway, the estimated capacity of the backuppool storage pool doesn't seem to "jive" with any other numbers. Since I have a maxscratch of 5000 and I'm only using 1298 volumes at 10Gig each, I would expect a utilization of 26%. With 62% of the Dedup available, I really don't want to hit that 90% utilization migration threshold anytime soon but at the rate we backup, if it truly thinks we are 80%, it may migrate much to my displeasure.
So would this have anything to do with out the Dedup relays it's raw storage to TSM. The OS sees a 5TB partition. So, I'm guessing that TSM may be just as confused as I am, that it sees that I have 5TB of storage that is at 38% utilization, but that the storage pool, which contains 1298 volumes has somehow stored far more data than the partition should allow? Is that why it is confused?
Is anybody else confused? Man I wish we had opted for the VTL on this thing.
Thanks
James
