At 08:35 AM 6/22/2001 -0600, Kelly J. Lipp wrote:

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.

I don't believe this is a pure issue of database size.  Rather, I think it
is the combination of performance characteristics of the server, the
network, and the client - the entire environment.  roll-forward makes sense
when the time it takes to run an incremental backup is much less than what
it takes to run a full backup.  If you can afford to run a full backup
every day, then go for it.  Your recovery time will be short.  The time it
takes depends not just on DB size, but also tape speed, processor speed,
processor memory, etc.  When we upgraded our server, we found that database
backups ran faster - no surprise there.  We run roll-forward because we
don't have enough wall clock time to perform a full backup every day, but
we want the protection.  While recovery time is an issue, backup time can
be too and it is in our environment.

In the configuration we have now, the log is a key limitation that might
have forced us to split our database.  And this is not just because the log
size controls the time interval between incremental backups.  In
logmode=normal, the log size also affects how long a single transaction can
pin the log tail without causing an operational problem.  The larger the
log, the longer the transaction can be in flight.  Even with
logmode=rollforward this can be an issue, and has been for us.  As servers
and networks get faster, this becomes a bigger issue, IMHO.  Especially in
complex environments that have a variety of clients.

..Paul