I think it is pretty rare, Linday. I count myself as being very unlucky in
that regard. But as unlikely as it can get, I'd think you would still want
to protect yourself against the possibility. Perhaps I am overly sensitive
to it since I was bitten already.
At 05:28 PM 8/2/2001 -0400, you wrote:
>Thanks for the insight, Paul. In your long experience, you've probably seen
>everything bad that can happen. I was assuming that software corruption was
>rare.
>
>If I ask the list how rare it is, I'm sure I'll get flames from everybody
>who HAS seen software corruption, and probably NO response from the many
>people who are running fine.
>
>Maybe somebody in Tivoli support could venture a guess as to how likely it
>is to have TSM trash its own database - and what steps might be taken to
>reduce that risk.
>
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Paul Zarnowski
> > Sent: Thursday, August 02, 2001 4:16 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Recovery Log size / roll forward benefits
> >
> >
> > Lindsay, et al,
> >
> > It is very possible to lose your database but not the log (we have done
> > it). The database can become corrupted through means other than hardware
> > failure, though even a hardware-initiated corruption can occur even when
> > your disk is mirrored. It is a GOOD IDEA to put the log on different
> > disks, and if possible, a different disk subsystem than your database, if
> > you can afford to. I don't view using logmode rollforward as an
> > alternative to mirroring your database volumes.
> >
> > Since our full database backups take so long, we cannot afford to run full
> > backups regularly (we do them twice a week). If you can afford to run a
> > full backup regularly, then by all means do it. I think rollforward has
> > value in environments such as ours, because it allows us to run more
> > frequent incremental database backups.
> >
> > I will also dispute the opinion that a 13GB log will solve everyone's
> > problems. It will help, for sure. But, there are situations where a
> > thread has the log tail pinned and the log head is advancing quickly. The
> > larger log will give the pinning thread longer to complete, but IMHO there
> > will still be situations where the log can still wrap. Examples I have
> > seen of a quickly advancing head include inventory expiration and delete
> > filespace. We have recently automated a process to cancel inventory
> > expiration when the log starts filling, and restart it later after the log
> > utilization drops. This has helped us tremendously. Since implementing
> > this, we have only gotten bitten by a large delete filespace.
> >
> > BTW, we have an 83GB database and a 5GB log.
> >
> > ..Paul
> >
> > At 10:54 AM 6/22/2001 -0400, Lindsay Morris wrote:
> > >I'm with Kelly in thinking that roll-forward is unnecessary in
> > most cases.
> > >
> > >The TSM admin guide seems to recommend roll-forward:
> > >
> > > "To get the best protection for your TSM data, you should use ...
> > >mirrored copies of your database and recovery log, with the recovery log
> > >mode set to roll-forward"
> > > "Roll-forward mode offers the greatest protection for your data."
> > > "(Roll-forward) With an intact recovery log, recover to the
> > most current
> > >state with no loss of client data."
> > >
> > >But for roll-forward mode to be useful, you have to lose your
> > TSM database
> > >volumes, yet somehow NOT lose the TSM log volumes.
> > >How is that ever going to happen?
> > >
> > >Most people mirror the TSM database on a separate disk (and,
> > ideally, on a
> > >separate disk controller). So they have to lose TWO disk drives
> > before they
> > >lose the database.
> > >
> > >If TWO disk drives die at once, the whole machine is probably
> > dead in a fire
> > >or something, right? So the recovery log volumes are gone too, and
> > >roll-forward can't be used. You have to restore the DB from tape, and
> > >that's as current as you can get - just as if you had NEVER used
> > >roll-forward.
> > >
> > >Does anybody have a situation that they feel really merits
> > >logmode=rollforward? If so, would you mind discussing it briefly?
> > >
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On
> > Behalf Of
> > > > Kelly J. Lipp
> > > > Sent: Friday, June 22, 2001 10:36 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: Recovery Log size
> > > >
> > > >
> > > > Doesn't this bring back the issue of Roll-Forward vs. not? I
> > guess I'm
> > > > still in the not camp with no compelling reason to join the
> > other. Also,
> > > > for those in the other camp, I'm thinking if your environment is
> > > > so large as
> > > > to fill a 13 GB log in a 24 hour period perhaps the
> > environment is busting
> > > > at the seems in other areas and should perhaps be split anyway.
> > > >
> > > > Even if larger logs were supported, how long would a db
> > restore take with
> > > > roll-forward enabled? I'm thinking way too long.
> > > >
> > > > Perhaps someone can share their longest db restore story with us.
> > > >
> > > > Kelly J. Lipp
> > > > Storage Solutions Specialists, Inc.
> > > > PO Box 51313
> > > > Colorado Springs CO 80949-1313
> > > > (719) 531-5926
> > > > Fax: (240) 539-7175
> > > > Email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
> > > > www.storsol.com
> > > > www.storserver.com
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On
> > Behalf Of
> > > > Nicholas Cassimatis
> > > > Sent: Friday, June 22, 2001 8:22 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: Recovery Log size
> > > >
> > > >
> > > > With the current limit of 5.3GB, and the steps we've all taken to work
> > > > within that limit, I don't think many people will be hitting the
> > > > 13GB limit
> > > > all that quick. An incremental database backup will still
> > flush the log,
> > > > and, with 13GB, I think we'll be OK if we don't change the way we
> > > > are doing
> > > > our business.
> > > >
> > > > Nick Cassimatis
> > > > [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > >
> > > > >An FYI - TSM 4.2 will increase the limit to 13GB.
> > > >
> > > > I think we're all wondering when the first voice will be heard asking
> > > > when the 13 GB limit will be increased. And I think we're
> > all wondering
> > > > why the increase was little more than a doubling of the
> > current limit -
> > > > which customers are already straining to go beyond. As an Enterprise
> > > > level product, I would expect TSM to be a lot more open-ended. Unless
> > > > this boost was merely a stop-gap in advance of major architectural
> > > > relief, it's not going to be enough to keep up with the demand.
> > > >
> > > > Richard Sims, BU
> > > >
> >
