On Wed, 21 Apr 1999, Richard Sims wrote:
> Customers seem to be avoiding Roll-Forward mode "because it requires a huge
> recovery log".  It should not if you schedule regular full and incremental
> database backups, which clear the log and are relatively fast to run.  The
> DBBackuptrigger is there as a safeguard rather than a normal means of
> achieving the backups.

I totally agree with the statements about regularly scheduled dbbackups
vs. triggered ones.  Disk space is cheap, so that is not the reason I do
not use rollfoward.  The main reason I do not is that the maximum log
file size (5.3GB) is not enough to get me through the 24 hour period
between scheduled backups!  This means dbbackups will be triggered during
client backups, and therefore the trigger needs to ne set low enough to
ensure the backups will complete prior to the log filling, and crashing
the server.  Once the server crashes, and one has to extend that 5GB log,
bringing the server back up can take several hours.  All of this downtime
is caused by RollForward mode, and avoided in normal mode.  And, once you
are back online, you better reduce that log again, because once you are at
the max file size, if it fills again, you will be doing a restore db!

When/if IBM ups the 5.3GB recovery log limit, I will look at setting the
log back to rollforward.

I really don't like redoing work, but Rollforward caused me more problems
than it saved.

Steve (unVMix Systems Programmer/Dude) Roder
(tkssteve AT ubvm.cc.buffalo DOT edu | tkssteve AT acsu.buffalo DOT edu | 
(716)645-3564 ,
   | http://ubvm.cc.buffalo.edu/~tkssteve)