|
Re: [ADSM-L] Question Tsm for VE
2012-07-27 15:15:33
I was trying to figure some of this stuff out a while ago. I think I
stole some of this from somewhere (maybe even this list) and added it to
my own stash of documentation. One very important thing to know when
dealing with deduplication: The first node to backup a block owns it
(for dedupe purposes), so it's usually not practical to report dedupe at
the node level, as the first node doesn't get any benefit of the dedupe
(at least in the reporting).
-------
The Occupancy table can show how much physical space is occupied by a
filespace after removing the deduplication savings gained by removing
duplicated data from this file space. You can use "select * from
occupancy" to get the LOGICAL_MB and REPORTING_MB.
REPORTING_MB is the amount of space that would be occupied if the data
wasn't placed in a deduplication-enabled storage pool.
LOGICAL_MB is how much space is actually being used by this filespace.
*Example:* filespace \\brian\c$ is managing 30 MB of space but 10 MB was
eliminated via either client- or server-side data deduplication. The
resulting occupancy tables would show:
tsm: SERVER1>select * from occupancy where NODE_NAME='BRIAN'
NODE_NAME: BRIAN
TYPE: Bkup
FILESPACE_NAME: \\brain\c$
STGPOOL_NAME: MYFILEPOOL
NUM_FILES: 63
PHYSICAL_MB: 0.00
LOGICAL_MB: 10.00
REPORTING_MB: 30.00
FILESPACE_ID: 17
*Important:* The LOGICAL_MB value only takes into account how much data
was removed or not stored because the data was identified as duplicate
of data that was already stored elsewhere. Consider this example:
Filespace \\brian\c$ backs-up 20 MB of unique data; LOGICAL_MB = 20.00
Filespace \\jim\c$ doesn't have to backup any data because it is an
exact duplicate of \\brian\c$; LOGICAL_MB = 0.00
Note that in this case \\brian\c$ doesn't report any duplication
efficiencies, even though filespace \\jim\c$ was able to identify
duplicate data between the filespaces
On 7/27/2012 4:54, Robert Ouzen wrote:
Hi to all
Did anybody know how to actually see the correct amount of data store in a
storage pool with Tsm 6 dedup.
When running the conventional command
tsm: POSTBACK>q occ haifa_datacenter got:
Node Name Type Filespace FSID
Storage Number of Physical Logical
Name
Pool Name Files
Space Space
Occupied Occupied
(MB) (MB)
---------- ---- ---------- ----- ---------- ---------
--------- ---------
HAIFA_DATACENTER Bkup \VMFULL-bidev 11 DEDUP6VM
6,527 - 399,530.5
HAIFA_DATACENTER Bkup \VMFULL-cldVCD1 12 DEDUP6VM
402 - 25,615.19
HAIFA_DATACENTER Bkup \VMFULL-notes 6 DEDUP6VM
18,738 - 832,130.6
HAIFA_DATACENTER Bkup \VMFULL-shiltest 25 DEDUP6VM
2,403 - 138,700.0
HAIFA_DATACENTER Bkup \VMFULL-vmproxy 23 DEDUP6VM
526 - 31,187.29
HAIFA_DATACENTER Bkup \VMFULL-websrv05 13 DEDUP6VM
330 - 14,698.87
What command to run (if any) to see the Physical Space Occupied ? The same for
q fi f=d ?
Tried to write a script:
select cast(node_name as varchar(20)) as "Nodename" , cast(Type as varchar(6)) as "Type" ,
cast(stgpool_name as varchar(15)) as "StgPool Name" ,cast(filespace_name as varchar(28)) as
"Filespace" ,
cast(filespace_id as varchar(4)) as "Filespace ID" , cast(logical_mb as varchar(15)) as
"Backup DeFactor" , cast(reporting_mb as varchar(15)) as "Original Backup" ,
cast((reporting_mb -
logical_mb) * 100 / reporting_mb as varchar(5)) as "Saved in %" , cast((reporting_mb) /
(logical_mb) as varchar(5)) as "Factor" from occupancy where stgpool_name='DEDUP6VM'
order by 1
Here the output:
Nodename Type StgPool Name Filespace
Filespace ID Backup DeFactor
Original Backup Saved in % Factor
--------------------- ------- ----------------
--------------------------------------------------------- -------------
---------------- ---------------- ----------- -------
HAIFA_DATACENTER Bkup DEDUP6VM \VMFULL-websrv05
13 198.05
14698.87 98.65 74.21
HAIFA_DATACENTER Bkup DEDUP6VM \VMFULL-cldVCD1
12 3882.41
25615.19 84.84 6.597
HAIFA_DATACENTER Bkup DEDUP6VM \VMFULL-vmproxy
23 2300.13
31187.29 92.62 13.55
HAIFA_DATACENTER Bkup DEDUP6VM \VMFULL-shiltest
25 138700.03
138700.01 -.000 .9999
HAIFA_DATACENTER Bkup DEDUP6VM \VMFULL-bidev
11 199516.10
399530.56 50.06 2.002
HAIFA_DATACENTER Bkup DEDUP6VM \VMFULL-notes
6 73523.07
832130.70 91.16 11.31
I though is was a good one but very strange output for \VMFULL-shiltest !
Any ideas if is it a conventional report to get the correct occupancy for vm ,
by the way this backup process was done with Tsm for VE on astorage with Tsm
dedup (deduplication on the client side)
Tsm server version 6.2.3.0 on Windows 2008R2 64B
Regards Robert
|
|
|
