Richard,
We too experienced the pretty long initialization times for the TSM server
attached to the VTL with 128 drives(15 -30 minutes). We ended up
changing this setting and it fixed the issue. Check to see if you have
this set?
update library xxxx resetd=no *we had resetd=yes
tsm: TSM>q library f=d
Library Name: xxxx
Library Type: SCSI
ACS Id:
Private Category:
Scratch Category:
WORM Scratch Category:
External Manager:
Shared: Yes
LanFree:
ObeyMountRetention:
Primary Library Manager:
WWN:
Serial Number: xxxxxxxxx
AutoLabel: No
Reset Drives: No
<--------------------------------------we originally had this set to
YES,default I believe
Relabel Scratch: Yes
Last Update by (administrator): xxxxx
Last Update Date/Time: 03/17/11 12:49:58
Another issue was that if we performed a delete volhist t=dbb, with the
Data Domains, we would hose up the TSM server and have to restart it. I
relabel process would kick out and then the TSM server would get hosed up.
That APAR was fixed it when we went from TSM Server code level 5.5.4.0
to 5.5.5.0, there was an APAR out there for it. On a side note. Since
going to 5.5.5.0 we are experiencing the recovery log pinning issue almost
daily which IBM TSM support is working on currently with us and other
TSMers feeling that pain.
We also experienced pretty long initialization times for the TSM server
attached to a virtual library having 100 drives : at restart TSM server
needs at least 15 minutes to recognize all the drives, thus generating
numerous client errors, as they try to get a drive which is defined but
not available. We still have to experiment if defining more smaller
libraries would solve that issue ...
Nancy Leugemors
Enterprise Systems
HealthNow, NY
716-887-7979
From:
"Cowen, Richard" <rco...@sbsplanet.com>
To:
ADSM-L@VM.MARIST.EDU
Date:
06/17/2011 09:20 AM
Subject:
Re: [ADSM-L] tsm and data domain
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>
Brian,
The DD has dedup by volume. If you lookup the contents of a volume on
TSM, you can get an feeling for how dedup varies.
The resulting information is "approximate", due to the fact some of the
data on a DD volume has "expired" from TSM's point of view, and will not
show up in the volumeusage table (I don't think.) Also, the first copy
of any "chunk" will have a dedup ratio of 1.
filesys show compression /backup/vtc/*/*
/backup/vtc/Default/N00022L3:
mtime: 1302728324652916847,
bytes: 47,868,905,726,
g_comp: 47,521,219,818,
l_comp: 8,403,079,871,
meta-data: 154,714,124,
bytes/storage_used: 5.6
Richard
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
PAC Brion Arnaud
Sent: Friday, June 17, 2011 3:11 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] tsm and data domain
Tim,
We are right conducting a POC with a pair of DD860, and are relatively
satisfied with them. The machines are mostly used as VTL except for a
small NFS partition which is used or TSM DB backups.
Deduplication rate is OK : around 10 so far, with a good mix of
Exchange, Oracle, DB2 as well as Win and AIX data.
Ingestion rate is corresponding to our needs, slightly more than 1 GB/s
, and the possibility to define plenty drives.
Negative or "no so impressive" points, so far : deduplication rate is
a "global" factor, impossible to know what type of data dedupes better
than another one, thus lowering the granularity of deduplication
monitoring .
We also experienced pretty long initialization times for the TSM server
attached to a virtual library having 100 drives : at restart TSM server
needs at least 15 minutes to recognize all the drives, thus generating
numerous client errors, as they try to get a drive which is defined but
not available. We still have to experiment if defining more smaller
libraries would solve that issue ...
At least replication : it is still unclear for me what would be
happening if we do rely on replication to replace copy storage pools,
and if our TSM server crashes on primary site while replication is not
completed. To my mind the virtual volumes contents would not be matching
TSM DB content : not sure so far on how to handle such a situation ...
Hope this helped !
Cheers
Arnaud
************************************************************************
******
Corporate IT Systems & Datacenter Responsible
Panalpina Management Ltd., Basle, Switzerland,
CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.br...@panalpina.com
************************************************************************
******
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Tim Brown
Sent: Thursday, 16 June, 2011 21:50
To: ADSM-L@VM.MARIST.EDU
Subject: tsm and data domain
Any one use emc's data domain devices for storage pools and replication
Would like to here positive and negative issues.
Thanks,
Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas & Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbr...@cenhud.com <<mailto:tbr...@cenhud.com>>
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255
This message contains confidential information and is only for the
intended recipient. If the reader of this message is not the intended
recipient, or an employee or agent responsible for delivering this
message to the intended recipient, please notify the sender immediately
by replying to this note and deleting all copies and attachments.
The information contained in this transmission may contain privileged and
confidential information.
It is intended only for the use of the person(s) named above. If you are
not the intended
recipient, you are hereby notified that any review, dissemination,
distribution or
duplication of this communication is strictly prohibited. If you are not
the intended recipient,
please contact the sender by reply email and destroy all copies of the
original message.
To reply to our email administrator directly, please send an email to
postmas...@sbsplanet.com.
