Tom,
        I guess it comes down to how much data you can afford to lose.  We run
with a mirrored recovery log and our database is on a 7137 Raid 5 array
so we're covered on the hardware side of things but, in case of a
catastrophic failure, I've decided we can live with point-in-time
recovery (i.e. as of the last full database backup).  Running in
roll-forward mode allows you to recover the db to its most recent state
if you lose a db volume(s)  but does require significantly more recovery
log space.  If you're using the HSM feature, I think the recommendation
is to run in foll-forward mode.  Our previous environment was on an 3090
running MVS - I could only run a full database backup once a week
because it took so long (3 hours +) so I had to rely on the incremental
backups the rest of the week. .

Tim Pittson
tpittson AT himail.hcc DOT com


>----------
>From:  Thomas A. La Porte[SMTP:tlaporte AT ANIM.DREAMWORKS DOT COM]
>Sent:  Friday, March 07, 1997 1:12 PM
>To:    ADSM-L AT VM.MARIST DOT EDU
>Subject:       Re: Recovery log
>
>Tim,
>
>I was with you on this (I hadn't considered all the transactions,
>etc. that were covered by the recovery log) until the last
>sentence, b/c you just described our environment. We do a
>full database backup every day. I'm running on a wide node SP2
>with 256MB of ram, and am connected to three 3590s (each on their
>own SCSI bus).
>
>We seem to get through about 5-6 hours of the nightly schedule
>before triggering a database backup.
>
> -- Tom
>
>> Date:    Wed, 5 Mar 1997 14:47:30 -0500
>> From:    "Pittson, Timothy ,HiServ/US" <tpittson AT HIMAIL.HCC DOT COM>
>> Subject: FW: Recovery log
>>
>> Tom,
>>
>>         When running in 'roll-forward recovery' mode, the recovery log
>>tracks
>> all transactions since the last database backup - this significantly
>> increases the recovery log storage requirements.  Database growth will
>> certainly contribute to this but keep in mind that database transactions
>> also incrlude client backups/archives and 'background' processing such
>> as migrations, reclamations, expiration processing, etc.. What you're
>> seeing in your environment isn't out of line with what I saw when
>> running in roll forward mode - our database was about 7 GB and I had to
>> increase our recovery log from 600 MB to about 3 GB (dbbackuptrigger set
>> to 80%)  to avoid database backups being triggered while the incremental
>> backups were running.  Since migrating to an RS/6000 and fast tape
>> drives, I've given up on this method and have gone to full database
>> backups every day since they only take 45-50 minutes.
>>
>> Tim Pittson
>> tpittson AT himail.hcc DOT com
>