For those people not needing new dedupe or node replication features, v6.3.4.300 has been treating us really well. I doubt we'll need either of those features in the future, so we'll probably stay here until IBM drops support for it.
On Fri, Jan 30, 2015 at 03:02:17PM +0000, Thomas Denier wrote: > 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:[email protected]] On Behalf Of > Rhodes, Richard L. > Sent: Friday, January 30, 2015 8:39 AM > To: [email protected] > 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:[email protected]] On Behalf Of > Remco Post > Sent: Thursday, January 29, 2015 6:07 PM > To: [email protected] > Subject: Re: TSM rant > > > Op 29 jan. 2015, om 22:39 heeft Skylar Thompson <[email protected]> > > 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 ([email protected]) > > -- Genome Sciences Department, System Administrator > > -- Foege Building S046, (206)-685-7354 > > -- University of Washington School of Medicine > > -- > > Met vriendelijke groeten/Kind Regards, > > Remco Post > [email protected] > +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. > -- -- Skylar Thompson ([email protected]) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
