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:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Paul Zarnowski
> Sent: Thursday, August 02, 2001 4:16 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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:ADSM-L AT VM.MARIST DOT EDU]On
> Behalf Of
> > > Kelly J. Lipp
> > > Sent: Friday, June 22, 2001 10:36 AM
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > 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: lipp AT storsol DOT com or lipp AT storserver DOT com
> > > www.storsol.com
> > > www.storserver.com
> > >
> > >
> > > -----Original Message-----
> > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On
> Behalf Of
> > > Nicholas Cassimatis
> > > Sent: Friday, June 22, 2001 8:22 AM
> > > To: ADSM-L AT VM.MARIST DOT EDU
> > > 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
> > > nickpc AT us.ibm DOT com
> > >
> > >
> > >
> > >
> > > >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
> > >
>