ADSM-L

Re: Recovery Log size / roll forward benefits

2001-08-02 14:19:54
Subject: Re: Recovery Log size / roll forward benefits
From: "Garrison, Tony" <Anthony.Garrison AT USAA DOT COM>
Date: Thu, 2 Aug 2001 13:20:37 -0500
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
>