ADSM-L

Re: [ADSM-L] TSM rant

2015-01-30 10:47:38
Subject: Re: [ADSM-L] TSM rant
From: "Prather, Wanda" <Wanda.Prather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 30 Jan 2015 15:45:27 +0000
The bug is IT02929; for us it affects Exports as well as restores (so I'm 
guessing would affect backupsets as well).
And yes, hits any copypool, LTO or not.

OTOH, it's not necessarily hard to live with, depending on your situation.  
More details of that below.

What you get with 7.1.1 that may make IT02929 worth living with for you:

- much more function in the OC
- ability to make the active log larger than 128G (important for people doing 
dedup)
- migration from DISK pools occurs at filespace level instead of node level 
(fixes a pain point for people using VE, or other PROXY relationships)

My experience with IT02929:
It can hit you if
1) the data you are trying to restore or export is on both a primary and 
copypool volume
2) the copypool volume is marked reado or readw

So if your copypool is tape, and you vault your copypool daily (so your 
copypool volumes are generally marked OFFSITE), you are unlikely to ever see 
the problem.

We found it's easy to circumvent; before we do an export or if we see the 
problem occurring during a restore we do:

     update vol * wherestgpool=copypoolname whereaccess=readw 
access=unavailable 

When we are done with exports, we reverse it with:

   update vol * wherestgpool=copypoolname whereaccess=unavailable access=readw

So for us it is quite manageable, as we don't do that many restores.  Your 
circumstances may differ. 


Wanda Prather
TSM Consultant
ICF International Enterprise and Cybersecurity Systems Division



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Thomas Denier
Sent: Friday, January 30, 2015 10:02 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM rant

The 7.1.1.100 server code has a rather serious bug affecting restores. If copy 
storage pool volumes are available the TSM server will mount both primary pool 
volumes and copy pool volumes when performing a restore. This is expected to be 
fixed in 7.1.1.200. The last time I checked, the target date for 7.1.1.200 was 
second quarter of 2015. That pretty much rules out a 6.2 to 7.1 upgrade, unless 
you are prepared to live with the bug described above. We are currently at 
6.2.5.0, and expect to upgrade to 6.3.5.0 or 6.3.5.100.

Thomas Denier,
Thomas Jefferson University

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Rhodes, Richard L.
Sent: Friday, January 30, 2015 8:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM rant

We just completed our conversion from v5 to v6.2.5 the end of December.  In 
general we're very happy with v6.2.5, but then we don't use any of the newer 
features like dedup - and don't plan to.  (we have DataDomain for our dedup 
load)

V6 has really solved our v5 pain points:  very long expirations (+24hr) and 
very slow db processing.  We run a "morning report" every morning against our 
TSM servers.  It generates a lot of info about an instance that we keep for 
documentation/reporting.  Some of our "morning reports" ran over an hour due to 
heavy SQL cmds.  Now on V6 the morning report runs in a few minutes!  V6 has 
definitely raised the scalability of TSM.

Yes, I have a long list of complaints about TSM, but in general we are happy 
with V6.

Now that we are completely on V6.2.5, we have to upgrade quickly due to ending 
support in April.  Our debate is going to v6.3.x or jumping to 7.1.x.  I'd be 
interested in any recommendations for this.

Thanks

Rick


PS:  Just in case you are curious, here are the reports we generate in our 
"morning report":

  print "= r000 report index and beginning time stamp "
  print "= r010 activity summary "
  print "= r011 admin schedule activity "
  print "= r015 scratch count "
  print "= r019 scratch tape usage "
  print "= r020 tape vol summary for all TSM instances"
  print "= r021 reclaimable tapes by pct-reclaim "
  print "= r022 volume info "
  print "= r023 volumes per stgpool status and maxscratch  "
  print "= r024 volume average utilization by stgpool "
  print "= r025 q dr "
  print "= r030 q path (not emailed)"
  print "= r036 drive activity "
  print "= r040 q db"
  print "= r045 q log"
  print "= r050 log consumption and utilization"
  print "= r055 log pin info (not emailed)"
  print "= r065 q sess"
  print "= r070 q stgpool"
  print "= r075 q copygroup (not emailed)"
  print "= r076 q events for exceptions - missed backups (not emailed)"
  print "= r077 slow backups"
  print "= r080 db backups"
  print "= r085 expiration - completions "
  print "= r090 expiration - detail (not emailed)"
  print "= r095 drive and media errors"
  print "= r097 nodes with tcp_ip or tcp_name changes"
  print "= r100 recplan dir listings"
  print "= r105 q volhost type=dbb"
  print "= r110 q volhost type=dbs (not emailed)"
  print "= r120 stgpool volumes: 7 day trend (not emailed)"
  print "= r125 aix errpt"
  ###print "= r129 tdp notes - summary "
  ###print "= r130 tdp notes - full (not emailed)"
  ###print "= r131 tdp notes - incremental (not emailed)"
  ###print "= r132 tdp notes - logs (not emailed)"
  print "= r140 session per node where count > 1 (not emailed) "
  print "= r141 q option (not emailed)"
  print "= r145 occupancy by server "
  print "= r150 occupancy by domain "
  print "= r152 occupancy by stgpool "
  print "= r153 occupancy by collocation group "
  print "= r155 occupancy by node (not emailed)"
  print "= r157 q audotocc (not emailed)"
  print "= r159 nodes locked (not emailed)"
  print "= r160 nodes with no associations"
  print "= r161 nodes with no associations EXCLUSION LIST"
  print "= r165 nodes never backed up (not emailed)"
  print "= r166 zzrt nodes with associations (not emailed)"
  print "= r167 nodes by collocation group (not emailed)"
  print "= r170 filespaces not backed up in 7 days (not emailed)"
  print "= r175 filespaces never backed up (not emailed)"
  print "= r180 server critical errors"
  print "= r184 backup objects and bytes per domain (not emailed)"
  print "= r185 backup objects and bytes per node (not emailed)"
  print "= r190 q vol  for tape (not emailed)"
  print "= r195 q libvol (not emailed)"
  print "= r999 report end timestamp"






-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Remco Post
Sent: Thursday, January 29, 2015 6:07 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM rant

> Op 29 jan. 2015, om 22:39 heeft Skylar Thompson <skylar2 AT U.WASHINGTON DOT 
> EDU> het volgende geschreven:
>
> TSM between v6.1 and the end of v6.2 was really rough, mostly related 
> to DB2. By v6.3 it got a lot more stable. I'm glad we upgraded from v5 
> early, though, since we really benefit from DB2's improved indexing 
> and table compression - between two TSM instances we have close to 2 
> billion file versions tracked by TSM. That would have overwhelmed any
> v5 server, but we get by with relatively modestly-sized hardware.

v5 was stable as a rock, but was going nowhere. All of the new features since 
6.1 are possible thanks to DB2. And I vividly recall the days of TSM v4 where 
the day would start with yet another patch of the server and hoping that that 
version would run for more than 24 hours. And yes… I’m still waiting for 
somebody to explain why you need 64 GB of RAM for a medium sized server without 
deduce or replication.

>
> On Thu, Jan 29, 2015 at 09:29:53PM +0000, David Ehresman wrote:
>> I've been admin TSM since the V3 days if memory serves, and sometimes it 
>> doesn't so much anymore.  I've had a lot less problems with TSM since the 
>> move to DB2. We are now at 7.1.1.  I do not know DB2 and have not had a need 
>> to learn it.  We back up about 400 servers, 350 VMs, 100 databases, and an 
>> Exchange systems which is just big.  FWIW, we do not do software (TSM) dedup.
>
> --
> -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> -- Genome Sciences Department, System Administrator
> -- Foege Building S046, (206)-685-7354
> -- University of Washington School of Medicine

--

 Met vriendelijke groeten/Kind Regards,

Remco Post
r.post AT plcs DOT nl
+31 6 248 21 622


-----------------------------------------
The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately, and delete the original message.
The information contained in this transmission contains privileged and 
confidential information. It is intended only for the use of the person 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.

CAUTION: Intended recipients should NOT use email communication for emergent or 
urgent health care matters.

<Prev in Thread] Current Thread [Next in Thread>