I have found the need to hunt down some non-compressible/dedupable data is
landing on the DD appliance. I use this process, it isn't quick or easy, but it
can point you to the client(s).
On the TSM server, do a "q dev f=d" and look for the sequential devices you
have defined on the DD appliance.
On the datadomain, do a "filesys show compression /backup/(yourvalue)" on all
the TSM devices you have defined on the DD.
- Look for the one that has the worst compression ratio or perhaps the
one that is on a downward trend.
On the TSM server, do a "q volhist ty=stgnew". Look for the volumes on the TSM
device(s) you have defined on the DD. The newest ones are at the bottom of the
list.
On the datadomain, do a "filesys show compression
/backup/(yourvalue)/(volumename)" i.e. "filesys show compression
/backup/databases/00000621.bfs"
Note that depending on the TSM version you are on, the TSM server may
show the volume name in all CAPS, but the DD is actually all in lower case.
Do this command for a bunch of volumes in your device class(es), you
should start to get a picture of a some volumes that have substantially lower
compression.
On the TSM server, look to see what client data is on that those TSM volumes "q
content /BACKUP/databases/00000621.BFS count=100"
Note, if you have collocation set to "node or filespace", this makes it
easy, because all the data for one node will be on the same volume, so you will
have your offending client.
If you have collocation set as "no, or group" on that storage pool, then you
have to look at more volumes to get an idea of what TSM clients may or may not
be involved.
Once you think you have some suspect nodes, look at other volumes from that
node:
On the TSM server, do a "q nodedata (client) stg=(stgpool)". Look for
some volumes that have a lot of that node's data on them.
On the datadomain, do a "filesys show compression
/backup/(yourvalue)/(volumename)" on the other nodes from this client and see
if there is a trend.
Hopefully, by the end of this treasure hunt, you have at least defined the TSM
client(s) that seem to be putting the non-compressible/dedupable data. It is
typically data that is already compressed in some format, i.e. certain JPG or
WAV files, zip or RAR files, or perhaps DB dumps that are compressed as they
are dumped out.
Good Luck,
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Rick Adamson
Sent: Thursday, September 20, 2012 8:07 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Actual TSM client storage utilization using Data Domain
I have a situation where I suspect one, or more, of my TSM clients is rapidly
consuming large amount of storage space and am at odds of how to accurately
determine the culprit.
The TSM server is configured with a data domain dd880 as primary storage of the
device type "file" so obviously when I query the occupancy table in TSM it
provides raw numbers that do not reflect the de-dup and compression of the DD
device. Querying compression on the DD only provides numbers per storage area,
or context.
Has anyone been found a way to determine the actual amount of storage that a
particular client is using within data domain?
All comments welcome.....
TSM Server 5.5 on Windows and Data Domain ddos 5.1.
~Rick
The BCI Email Firewall made the following annotations
---------------------------------------------------------------------
*Confidentiality Notice:
This E-Mail is intended only for the use of the individual
or entity to which it is addressed and may contain
information that is privileged, confidential and exempt
from disclosure under applicable law. If you have received
this communication in error, please do not distribute, and
delete the original message.
Thank you for your compliance.
You may contact us at:
Blue Cross of Idaho
3000 E. Pine Ave.
Meridian, Idaho 83642
1.208.345.4550
---------------------------------------------------------------------
|
