Question & Answer
Question
Why does the "select * from occupancy" command, which is used to obtain LOGICAL_MB and REPORTING_MB values to calculate space saved by data deduplication, show larger values for LOGICAL_MB than for REPORTING_MB?
Cause
In the Tivoli Storage manager Knowledge Center document "Querying file spaces for information about deduplicated data" (see URL section) the following is stated:
Issue the "select * from occupancy" command to get LOGICAL_MB and REPORTING_MB values.
The values are:
- LOGICAL_MB is the amount of space that is used by a file space after
it is reduced by data deduplication.
- REPORTING_MB is the amount of space that is occupied before the data
is deduplicated.
Use the REPORTING_MB and the LOGICAL_MB values to calculate the space that you save by using data deduplication:
REPORTING_MB - LOGICAL_MB = Space that you can save by using data deduplication (in MB)
An example of expected output:
tsm: SERVER1>select * from occupancy where NODE_NAME='BRIAN'
NODE_NAME: BRIAN
TYPE: Bkup
FILESPACE_NAME: /home/brian
STGPOOL_NAME: DEDUPPOOL
NUM_FILES: 63
PHYSICAL_MB: 0.00
LOGICAL_MB: 200.00
REPORTING_MB: 300.00
FILESPACE_ID: 17
The LOGICAL_MB value is 200 and the REPORTING_MB value is 300, which is expected.
However in some situations it may happen, that LOGICAL_MB value will be larger that REPORTING_MB.
An example of unexpected output:
tsm: SERVER1>select * from occupancy where NODE_NAME='STEVE'
NODE_NAME: STEVE
TYPE: Bkup
FILESPACE_NAME: /home/steve
STGPOOL_NAME: DEDUPPOOL
NUM_FILES: 4838
PHYSICAL_MB: 0.00
LOGICAL_MB: 5500000
REPORTING_MB: 3800000
FILESPACE_ID: 1
A misleading conclusion derived from this output might be, that the deduplication process has in fact grown the data, since the result from equation REPORTING_MB - LOGICAL_MB = Space that you can save by using data deduplication (in MB) would be negative.
Answer
There are three possible reasons for this symptom to occur:
- The occupancy information in the server is incorrect, and customer can run the REPAIR OCCUPANCY utility to fix this as described in Technote 1579500 (see URL section)
- Server is lagging behind in the dereferenced deduplicated chunks deletion, which a SHOW DEDUPDELETE command will confirm whether this is the case.
- If affected filespace is always the first one to be backed up and has a lot of base chunks still around because other files link to it but those base chunks are no longer needed by this filespace, then we can also see this situation. Following SQL query will confirm whether this cause applies.
db2 "SELECT bfaa.numfiles, bfaa.numchunks, afbf.size, bfaa.lsize, bfaa.rsize FROM bf_aggregate_attributes AS bfaa LEFT JOIN af_bitfiles AS afbf ON ( afbf.srvid=bfaa.srvid AND afbf.bfid=bfaa.superbfid ) WHERE afbf.poolid=? AND afbf.ck1=? AND afbf.ck2=? AND ( bfaa.lsize > bfaa.rsize )"
Before running the SQL query, a filespace id, node id and stgpool id must be obtained, and the values replaced in the following part:
"afbf.poolid=? AND afbf.ck1=? AND afbf.ck2=?"
Where:
poolid=<stgpool_id>
ck1=<node_id>
ck2=<filespace_id>
To obtain the stgpool id for deduppool:
SHOW SSPOOL
To obtain node id for affected node:
select node_id from nodes where node_name='STEVE'
To obtain filespace id for affected node:
QUERY FILE STEVE /home/steve
If in the SQL query output there are aggregated bitfiles with RSIZE 0, then this cause applies.
Related Information
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21964663