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