Hi Eric,
Indeed there may be something broken, but you have to understand that from
IBM's perspective, they have fixed it - you go to TSM 6.2. 5.5 will
eventually be removed from support (whether we like it or not) and then
you'll be really stuck.
The reason I ask the DB sizes is on topic. I would suggest that the
published formulas for how long the TSM upgrade takes are inaccurate. I
have performed a number of TSM 5.5 to 6.2 upgrades, some on Windows, some on
AIX.
The smallest one had a 140GB database, it took 8.5h from start to finish.
The biggest one had a 350GB database, it took 26h from start to finish.
There are several factors that will impact how long your upgrade will take,
not just db size. The horsepower of the TSM 6.2 box (whether upgrading in
place or upgrading to a new server), and TSM 6.2 disk layout are two big
ones.
The single best thing you can do, rather than assuming your upgrade will
take 3 days, is to test it. Setup a test server, restore the 5.5 db, then
upgrade it. If doing a network upgrade to new box (ideal situation), then
setup your new TSM 6.2 server, setup a test 5.5 server, restore the 5.5 db,
then do the network upgrade from the test box to your 6.2 server. My
clients (understandably) want to have a realistic idea of how long the
upgrade will take, so I've insisted on doing a test upgrade on every upgrade
I've done so far. In each case my production upgrade came to within 1-2h of
the timing that the test took.
I guess what I'm saying is that you're going to have some pain no matter
what you do, but the pain to upgrade may not be as bad as you think, and the
potential payoff is big....
regards,
Paul
On Thu, May 12, 2011 at 9:05 AM, Loon, EJ van - SPLXO <Eric-van.Loon AT klm DOT
com
> wrote:
> Hi Paul!
> I have 3 servers with 86, 100 and 129 gb databases. I haven't tried
> migrating, but I read a document somewhere which contained some figures
> about what performance one can expect from the migration process. At
> that time I roughly calculated 3 and a half days.
> Anyway, let's stay on the subject here: there is something broken in TSM
> (remember, I'm not the only one struggling with the recovery log size)
> and IBM should seriously look in to it and fix it. I never had any
> problems with the log when we were using 5.3!
> Kind regards,
> Eric van Loon
> KLM Royal Dutch Airlines
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Paul Fielding
> Sent: donderdag 12 mei 2011 15:53
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: TSM Recovery log is pinning since upgrade to 5.5.5.0 code
>
> A couple of questions, Eric
>
> - how big is your DB
> - have you tried a test upgrade to an alternate box to see how long it
> will
> take?
>
> Indeed, I agree that you're going to have to do something, whether it's
> take
> the outage to go to V6 or start to migrate to another product. However,
> if
> you are in a position to move to another product, then (worst case
> scenario), you're probably in a position to move to a clean V6 server
> without migrating. The one thing you really can't do is stay where you
> are
> forever, at least not with support....
>
> Paul
>
> On Thu, May 12, 2011 at 7:38 AM, David E Ehresman
> <deehre01 AT louisville DOT edu>wrote:
>
> > Eric,
> >
> > Pointing out the obvious here, but if you really can't afford to move
> > to TSM v6 then its time for you to start planning your move to
> something
> > else. Support for TSM 5 will be dropped sometime and I suspect the
> move
> > from TSM to something else will take some planning.
> >
> > David
> >
> > >>> "Loon, EJ van - SPLXO" <Eric-van.Loon AT KLM DOT COM> 5/12/2011 8:56 AM
> > >>>
> > Hi Steve!
> > If it would be possible, I would have already done that, but migrating
> > our servers from 5.5 to 6.2 would require multiple days of downtime.
> > Simple not acceptable in our shop...
> > Kind regards,
> > Eric van Loon
> > KLM Royal Dutch Airlines
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> > Of
> > Paul Fielding
> > Sent: donderdag 12 mei 2011 14:33
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: TSM Recovery log is pinning since upgrade to 5.5.5.0 code
> >
> > You could also go to TSM 6.2, which changes to DB2 and changes the way
> > recovery logs are dealt with, including allowing for much, much more
> > log....
> >
> >
> > On Thu, May 12, 2011 at 5:53 AM, Steve Roder <spr AT buffalo DOT edu> wrote:
> >
> > > What's pinning your log? Do a show logpinned, and then look at what
> > > that client is doing. If it is a TDP, they are known for pinning
> > the
> > > log and causing these kinds of issues.
> > >
> > > We see this issue also, and it is nearly always caused by an Oracle
> > TDP
> > > or an Exchange TDP backup.
> > >
> > > Thanks,
> > > Steve
> > >
> > >
> > > Hi Paul!
> > >> We are already running 5.5.5.2 and the log is still filling up,
> > even
> > >> after switching from rollforward to normal mode.
> > >> Management currently is questioning whether TSM is the right
> > product
> > for
> > >> the future. Although I'm a big fan of TSM for 15 years, I'm really
> > in
> > >> doubt too...
> > >> Kind regards,
> > >> Eric van Loon
> > >> KLM Royal Dutch Airlines
> > >>
> > >> -----Original Message-----
> > >> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> > Behalf
> > Of
> > >> Paul Fielding
> > >> Sent: woensdag 11 mei 2011 20:05
> > >> To: ADSM-L AT VM.MARIST DOT EDU
> > >> Subject: Re: TSM Recovery log is pinning since upgrade to 5.5.5.0
> > code
> > >>
> > >> Hi folks, if this has already been commented on, my apologies, I
> > hvaen't
> > >> been following closely but just noticed this thread.
> > >>
> > >> We were experiencing log pinned issues after upgrading to 5.5.0.0
> > code
> > >> at
> > >> one of my client sites. What we were finding was that,
> > occasionally,
> > >> I'd
> > >> get up in the morning and look at the server to see it completely
> > bogged
> > >> down with a huge number of backups still attempting to run, but
> > nothing
> > >> was
> > >> moving - the log was at 84% (over it's trigger), and it had been
> > firing
> > >> off
> > >> db backups for the last 4h to no avail, the log wasn't getting low
> > >> enough.
> > >>
> > >> A key symptom was that in the actlog we were seeing messages to the
> > >> effect
> > >> of "Recovery log is at 84%, transactions will be delayed by 3ms"
> > (or
> > >> something like that).
> > >>
> > >> In opening a ticket, it was found there was an issue in the 5.5.0.0
> > code
> > >> where, when the recovery log gets too full, it would start delaying
> > >> transactions in order to prevent the log from filling too quickly.
> > >> However,
> > >> the side effect was that the pinning transaction would also get
> > delayed,
> > >> causing a bit of a never-ending loop. Transactions keep getting
> > >> delayed,
> > >> pinned transaction never gets to finish, and everything would just
> > grind
> > >> to
> > >> a halt. I would have to halt the server and restart in order to
> > get
> > >> things
> > >> back to normal.
> > >>
> > >> IBM recognized this as an issue and recommended going to any
> > 5.5.5.0
> > >> level
> > >> of code, where the problem was supposed to be fixed. I installed
> > >> 5.5.5.2,
> > >> and the problem has indeed gone away. It was supposed to be fixed
> > at
> > >> 5.5.5.0, though perhaps they didn't quite get it done at that code
> > level
> > >> as
> > >> they hoped? I'd try installing 5.5.5.2 and see what happens....
> > >>
> > >> regards,
> > >>
> > >> Paul
> > >>
> > >>
> > >> On Wed, May 11, 2011 at 9:03 AM, Loon, EJ van - SPLXO
> > >> <Eric-van.Loon AT klm DOT com
> > >>
> > >>> wrote:
> > >>> Hi Robert!
> > >>> Thanks you very much for your reply! Several others on this list
> > >>> reported this behavior and (as far as I know) three other users
> > opened
> > >>>
> > >> a
> > >>
> > >>> PMR too. I hope they have more luck, because I'm stuck. Level 2
> > keeps
> > >>>
> > >> on
> > >>
> > >>> saying that the log keeps on growing because of slow running
> > client
> > >>> sessions. Indeed I see slow running client sessions, but they are
> > >>>
> > >> slowed
> > >>
> > >>> down by the fact that TSM is delaying all transactions because the
> > log
> > >>> is used for more that 80% during a large part of the backup
> > window!
> > >>>
> > >> Now
> > >>
> > >>> they refuse to help me, unless I buy a Passport Advantage
> > >>>
> > >> contract!!!!!!
> > >>
> > >>> Kind regards,
> > >>> Eric van Loon
> > >>> KLM Royal Dutch Airlines
> > >>>
> > >>> -----Original Message-----
> > >>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> > Behalf
> > >>>
> > >> Of
> > >>
> > >>> Robert Clark
> > >>> Sent: woensdag 11 mei 2011 16:05
> > >>> To: ADSM-L AT VM.MARIST DOT EDU
> > >>> Subject: Re: TSM Recovery log is pinning since upgrade to 5.5.5.0
> > code
> > >>>
> > >>> I believe we've been seeing this problem as well.
> > >>>
> > >>> One night in the busiest backup period, I issued a "q actlog
> > >>> begint=now-00:30", and got no results back but an error.
> > >>>
> > >>> I started dsmadmc -console on that server, and could see that the
> > >>> console
> > >>> output was most of an hour behind. (And the console output was
> > >>>
> > >> scrolling
> > >>
> > >>> so fast that it could barely be read.)
> > >>>
> > >>> In that case, I think we determined that SQL LiteSpeed was set to
> > some
> > >>> rediculously small transaction size, and this was causing way too
> > many
> > >>> actlog entries.
> > >>>
> > >>> I think I also noted that the session number incremented by
> > something
> > >>> like
> > >>> 100,000 in an hour.
> > >>>
> > >>> Asking the users of SQL LiteSpeed to make some changes was enough
> > to
> > >>> rememdy this problem, although we continue to fight with the logs
> > >>> getting
> > >>> full.
> > >>>
> > >>> Thanks,
> > >>> [RC]
> > >>>
> > >>>
> > >>>
> > >>> From: "Loon, EJ van - SPLXO"<Eric-van.Loon AT KLM DOT COM>
> > >>> To: ADSM-L AT VM.MARIST DOT EDU
> > >>> Date: 05/11/2011 02:05 AM
> > >>> Subject: Re: [ADSM-L] TSM Recovery log is pinning since
> > upgrade
> > >>> to
> > >>> 5.5.5.0 code
> > >>> Sent by: "ADSM: Dist Stor Manager"<ADSM-L AT VM.MARIST DOT EDU>
> > >>>
> > >>>
> > >>>
> > >>> Hi TSM-ers!
> > >>> Here is a small follow up on my PMR about the recovery log
> > >>>
> > >> utilization.
> > >>
> > >>> I'm at TSM level 2, still trying to convince them that there is
> > >>> something broken in the TSM server code. To convince them, I have
> > >>> changed the logmode to normal on one of my servers. I created a
> > graph
> > >>> (through TSMManager) which shows the recovery log utilization
> > during
> > >>> last night's client backup window and is doesn't differ much from
> > the
> > >>> night before, with logmode rollforward. When running in normal
> > mode,
> > >>>
> > >> TSM
> > >>
> > >>> should only use the recovery log for uncommitted transactions, so
> > >>> utilization should be very low. My log is 12 Gb and the
> > backuptrigger
> > >>> value (75%) was still hit twice!
> > >>> This clearly shows that there is something wrong with TSM, let's
> > hope
> > >>>
> > >> I
> > >>
> > >>> can convince Level 2 too, so my case gets forwarded to the lab.
> > >>> I'll keep you guys posted!
> > >>> Kind regards,
> > >>> Eric van Loon
> > >>> KLM Royal Dutch Airlines
> > >>> ********************************************************
> > >>> For information, services and offers, please visit our web site:
> > >>> http://www.klm.com. This e-mail and any attachment may contain
> > >>> confidential and privileged material intended for the addressee
> > only.
> > >>>
> > >> If
> > >>
> > >>> you are not the addressee, you are notified that no part of the
> > e-mail
> > >>> or
> > >>> any attachment may be disclosed, copied or distributed, and that
> > any
> > >>> other
> > >>> action related to this e-mail or attachment is strictly
> > prohibited,
> > >>>
> > >> and
> > >>
> > >>> may be unlawful. If you have received this e-mail by error, please
> > >>> notify
> > >>> the sender immediately by return e-mail, and delete this message.
> > >>>
> > >>> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
> > and/or
> > >>> its
> > >>> employees shall not be liable for the incorrect or incomplete
> > >>> transmission
> > >>> of this e-mail or any attachments, nor responsible for any delay
> > in
> > >>> receipt.
> > >>> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > >>>
> > >> Dutch
> > >>
> > >>> Airlines) is registered in Amstelveen, The Netherlands, with
> > >>>
> > >> registered
> > >>
> > >>> number 33014286
> > >>> ********************************************************
> > >>>
> > >>>
> > >>>
> > >>> U.S. BANCORP made the following annotations
> > >>>
> > ---------------------------------------------------------------------
> > >>> Electronic Privacy Notice. This e-mail, and any attachments,
> > contains
> > >>> information that is, or may be, covered by electronic
> > communications
> > >>> privacy laws, and is also confidential and proprietary in nature.
> > If
> > >>>
> > >> you
> > >>
> > >>> are not the intended recipient, please be advised that you are
> > legally
> > >>> prohibited from retaining, using, copying, distributing, or
> > otherwise
> > >>> disclosing this information in any manner. Instead, please reply
> > to
> > >>>
> > >> the
> > >>
> > >>> sender that you have received this communication in error, and
> > then
> > >>> immediately delete it. Thank you in advance for your cooperation.
> > >>>
> > >>>
> > >>>
> > >>>
> > ---------------------------------------------------------------------
> > >>> ********************************************************
> > >>> For information, services and offers, please visit our web site:
> > >>> http://www.klm.com. This e-mail and any attachment may contain
> > >>> confidential and privileged material intended for the addressee
> > only.
> > >>>
> > >> If you
> > >>
> > >>> are not the addressee, you are notified that no part of the e-mail
> > or
> > >>>
> > >> any
> > >>
> > >>> attachment may be disclosed, copied or distributed, and that any
> > other
> > >>> action related to this e-mail or attachment is strictly
> > prohibited,
> > >>>
> > >> and may
> > >>
> > >>> be unlawful. If you have received this e-mail by error, please
> > notify
> > >>>
> > >> the
> > >>
> > >>> sender immediately by return e-mail, and delete this message.
> > >>>
> > >>> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
> > and/or
> > >>>
> > >> its
> > >>
> > >>> employees shall not be liable for the incorrect or incomplete
> > >>>
> > >> transmission
> > >>
> > >>> of this e-mail or any attachments, nor responsible for any delay
> > in
> > >>>
> > >> receipt.
> > >>
> > >>> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > >>>
> > >> Dutch
> > >>
> > >>> Airlines) is registered in Amstelveen, The Netherlands, with
> > >>>
> > >> registered
> > >>
> > >>> number 33014286
> > >>> ********************************************************
> > >>>
> > >>>
> > >>> ********************************************************
> > >> For information, services and offers, please visit our web site:
> > >> http://www.klm.com. This e-mail and any attachment may contain
> > >> confidential and privileged material intended for the addressee
> > only.
> > If you
> > >> are not the addressee, you are notified that no part of the e-mail
> > or
> > any
> > >> attachment may be disclosed, copied or distributed, and that any
> > other
> > >> action related to this e-mail or attachment is strictly prohibited,
> > and may
> > >> be unlawful. If you have received this e-mail by error, please
> > notify
> > the
> > >> sender immediately by return e-mail, and delete this message.
> > >>
> > >> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
> > and/or
> > its
> > >> employees shall not be liable for the incorrect or incomplete
> > transmission
> > >> of this e-mail or any attachments, nor responsible for any delay in
> > receipt.
> > >> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> > Dutch
> > >> Airlines) is registered in Amstelveen, The Netherlands, with
> > registered
> > >> number 33014286
> > >> ********************************************************
> > >>
> > >>
> > >>
> > >>
> > ********************************************************
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee only.
> If
> > you are not the addressee, you are notified that no part of the e-mail
> > or any attachment may be disclosed, copied or distributed, and that
> any
> > other action related to this e-mail or attachment is strictly
> > prohibited, and may be unlawful. If you have received this e-mail by
> > error, please notify the sender immediately by return e-mail, and
> delete
> > this message.
> >
> > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
> > its employees shall not be liable for the incorrect or incomplete
> > transmission of this e-mail or any attachments, nor responsible for
> any
> > delay in receipt.
> > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> Dutch
> > Airlines) is registered in Amstelveen, The Netherlands, with
> registered
> > number 33014286
> > ********************************************************
> >
> ********************************************************
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If you
> are not the addressee, you are notified that no part of the e-mail or any
> attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> ********************************************************
>
>
|
