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
> ********************************************************
>
|
