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: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.
>
--
-- 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
|
