Thanks for your input, Tony.

If I understand you, you're concerned that your log might fill up, so you
set logmode roll-forward just because dbbackuptrigger requires it. Then
dbbackuptrigger kicks off incremental db dbackups which clean out the log
periodically.

Is that what you mean?


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Garrison, Tony
> Sent: Thursday, August 02, 2001 2:21 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Recovery Log size / roll forward benefits
>
>
> We use Roll-forward here.  This is primarily due to the fact that
> we can set
> the db trigger to backup the db if the log reaches a predefined
> percentage.
> This is extremely important due to the size of our environment.  We would
> rather run in normal, but until we can use the db trigger we are
> stuck with
> what we have.
>
>  -----Original Message-----
> From:   Lindsay Morris [mailto:lmorris AT servergraph DOT com]
> Sent:   Friday, June 22, 2001 9:55 AM
> To:     ADSM-L AT VM.MARIST DOT EDU
> Subject:        Re: Recovery Log size / roll forward benefits
>
> 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
> >
>